Dedicated servers instead of cloud VMs: more performance per euro, more responsibility in operations

Infrastructure discussions usually revolve around “cloud or not”. For many of our customers a different question matters more: dedicated hardware or virtual machine? Under predictable, sustained load the answer is fairly clear — bare metal has the better price-performance ratio. Plenty of people still shy away from it, and that is rarely down to the maths. With your own server you take on tasks the hypervisor used to handle.

Those tasks are exactly what we take on for our customers. So this article covers both sides: what you gain with dedicated hardware, what you have to do for it, and which tools we use to cover day-to-day operations.

What you gain

• Dedicated cores: No steal time and no neighbours saturating the CPU at the wrong time of day. For databases and latency-critical applications, that usually matters more to us than the price.

• Plenty of RAM and NVMe: A MySQL instance with a double-digit GB buffer pool is standard on dedicated hardware. In the cloud, that configuration quickly becomes a budget question.

• Local storage: The NVMe sits in the server itself. There are no IOPS quotas and no storage bill that grows with usage.

• Predictable cost: A fixed monthly price instead of usage-based billing you only understand at the end of the month. In a comparison, storage and traffic often make a bigger difference than the compute price itself.

What you take on for it

• Hardware failures: When a disk dies underneath a VM, the provider moves the instance and at best you never notice. On dedicated hardware, the failed disk or the broken power supply is your problem.

• No snapshots: There is no quick roll-back. The replacement is backups with a regularly tested restore, plus a host described completely in Ansible. The latter is easily underrated: if a machine can be reproduced by a playbook run, rebuilding it stops being a big deal.

• Coarse scaling: There is no adding two more vCPUs; you move to the next size up. That needs planning ahead. A properly sized machine usually has plenty of headroom, though.

• Longer provisioning: A new server arrives in hours rather than seconds, and a hardware swap needs lead time. So we plan for reserves instead of relying on elasticity.

• Hardware monitoring: Temperatures, fans and disk health are yours to watch. On a VM it never comes up; on bare metal it is mandatory.

If you would rather not take that part on yourself, that is what our managed dedicated servers are for. How it works in practice is described further down.

The numbers after Hetzner’s price round in June

Hetzner has adjusted prices more than once in 2026. On 1 April, almost the entire portfolio went up by around 30 %; the background on exploding RAM prices was covered in allesnurgecloud issue 225 (in German). On 15 June 2026 the next round followed, and it hits cloud instances with dedicated vCPUs hardest. The prices according to Hetzner for Germany and Finland, including 19 % German VAT and excluding IPv4:

• CCX23 (4 dedicated vCPUs, 16 GB RAM, 160 GB NVMe): from €37.47 to €102.33 per month, almost three times as much.

• CCX33 (8 dedicated vCPUs, 32 GB RAM, 240 GB NVMe): from €74.36 to €164.80.

• CX23: from €4.75 to €6.53.

• CX33: from €7.72 to €10.10.

The new prices apply to new orders and to rescaling existing instances. Running servers keep their current price. Anyone resizing an old CCX instance pays the new rate afterwards, and according to Hetzner’s FAQ the same goes for certain other changes to a server. So existing machines are not something to touch casually.

The shared CX instances rose comparatively moderately. The catch is that these cheap sizes are currently hard to get in many locations.

Now the comparison worth doing. Since June, an AX42 costs €115.79 per month plus a €58.31 setup fee. For that you get a Ryzen 7 PRO 8700GE with eight physical cores and 16 threads, 64 GB of DDR5 RAM with ECC, and two NVMe SSDs of 512 GB each. The CCX33 has eight dedicated vCPUs, so eight threads, plus 32 GB of RAM and 240 GB of storage, and costs €164.80. Even if you run the two SSDs in the AX42 as RAID 1 and only 512 GB remain usable, the dedicated server has twice the RAM, well over twice the storage, ECC, and local NVMe without an IOPS limit. And it costs around €49 less per month.

It gets cheaper still with Hetzner’s limited offers. AX41 and EX44 are listed there at €68.19 per month with no setup fee, the AX42 at €91.99. According to Hetzner this hardware consists of components sourced at lower cost, and availability depends mainly on cancellations. So it is fair to assume these servers have often been running for a while. On top of that there is the server auction, where prices are set by auction and which, according to Hetzner, is not affected by the June adjustment. In both cases the acceptance check described below pays off.

That leaves availability. In mid-August, the Hetzner shop listed the CCX instances as not orderable, and the small CX sizes were scarce in most locations too. The best price is of little help if you cannot get the machine. With dedicated servers the lead time is at least predictable, and from the server auction a machine is often ready the same day.

Two caveats belong with the maths. It applies to sustained load. If you only need machines by the hour, delete them after a load test or move them between regions regularly, the cloud remains the better fit — that is what it was built for. And the setup fee belongs in the calculation. Against the CCX33 it is recovered after about a month; with smaller machines or a short runtime it looks different.

Our advice: if you are about to order or scale up a cloud instance with a dedicated CPU at the new price, check first what the same money buys as a dedicated machine.

Hardware monitoring: temperatures, power draw, fans

Whether dedicated hardware is a good idea depends above all on whether you keep an eye on it. So every one of our hardware hosts runs a script that collects all available sensor data once a minute and outputs it in Prometheus format. Telegraf reads the values, VictoriaMetrics stores them, Grafana displays them.

The script works out per machine which sources exist: IPMI or the BMC, lm-sensors, the kernel thermal zones, hwmon, SMART and drivetemp for disk temperatures, ssacli for the RAID controllers in the HPE ProLiants, and nvidia-smi on the GPU host. If a machine is missing a source, the script reports it as a missing capability. In the dashboard you can then tell straight away whether a sensor has failed or the hardware never had one.

Recorded are temperatures split by CPU, system, disks, GPU, power supply and chipset, plus power draw in watts, current and voltages where the BMC provides them, and fan speeds. Power consumption is a good early indicator here. If a server suddenly pulls more at the same load and the fans spin up, something is usually wrong long before an application gets slower.

Telegraf invokes the tools through a tightly scoped sudo rule. Only commands listed by name are permitted, and the kernel modules that may be loaded are enumerated individually. Monitoring should not turn into a security risk of its own. Alerting, including the RAID check, runs through Icinga2; we use Grafana for the trends.

Acceptance check before commissioning

Continuous monitoring helps with machines that are already in operation. New and used servers we check beforehand with a second script. It produces a complete hardware and disk health report before a server goes into production — for instance when it comes from the server auction.

First the script reads the inventory: manufacturer, model, mainboard, BIOS version and date, CPU, and every memory module individually with its population, type and clock. It also checks whether ECC is actually active. Then come the values that can get uncomfortable.

• ECC errors: The script reads the error counters from EDAC. Correctable errors are a reason to watch that module; uncorrectable ones are critical. On a VM you never get to see these values.

• SMART: Different rules apply to NVMe and SATA/SAS. For NVMe we look at endurance used in per cent, remaining spare blocks, media errors, critical warning flags and data written. For SATA it is reallocated, pending and uncorrectable sectors plus CRC errors, which usually come from the cable rather than the disk — the script points that out too. On top of that comes the vendor-specific wear indicator.

• Power-on hours: Converted into years. With used hardware, that is the first value we look at.

• RAID and kernel log: Status of mdadm and ZFS, plus storage errors in the kernel log.

At the end there is a verdict in three levels, emitted as a Nagios exit code: fine, usable but keep watching, or do not accept and do not put into production. The script can also start a SMART self-test on every disk, and it reports when a disk has never had one. With cheap hardware from the server auction in particular, that saves us a few nasty surprises.

Three examples from our operations

Servers in the warehouse: For KRUU we look after five servers in the fulfilment centres in Europe and the US, some of them older HPE ProLiants. They sit right by the warehouse so that shipping keeps running even when the internet connection is gone, and so that scanners and printers are connected locally. They run Docker, Node.js applications, GitLab runners and RabbitMQ; fluent-bit ships the logs to central logging. The servers are connected over a site-to-site VPN and managed with the same Ansible as every other machine. A warehouse is of course not a data centre — dust, temperature and power supply are real topics there. Which is why we keep a particularly close eye on temperatures and fan speeds on these servers.

Bare metal as the default: A customer with a larger fleet runs their application servers on dedicated hardware, MySQL primary and replica on separate machines, a ClickHouse server and Elasticsearch. They use cloud VMs in addition, but only where proximity to users matters rather than compute. That is the typical pattern for us: dedicated hardware for sustained load and databases, VMs where location or a short runtime is what counts.

Our own backup infrastructure: Two dedicated servers with plenty of disks at two locations, running SeaweedFS as S3-compatible object storage and VictoriaLogs. So our customers’ backups land on our own hardware rather than in a third party’s object storage. For that purpose dedicated hardware is simply the most economical: plenty of storage per euro, and no retrieval or traffic costs that rise with usage.

Common objections

• “What if a disk fails?” It will, eventually. That is what RAID, SMART trends over a longer period and backups at another location are for. What matters is seeing the failure coming and having rehearsed the restart.

• “Without snapshots you cannot roll anything back.” True. A snapshot only helps with your own mistakes, though; against a hardware failure it does nothing. You need a backup for that anyway, and together with a host fully described in Ansible the restore is easy to plan.

• “Who drives to the data centre at night?” Nobody. We work with remote management via BMC or iLO, the rescue system and the provider’s remote hands service. If the hardware sits at the customer’s site, that has to be settled in advance, including spare parts on site and clear responsibility.

• “Used hardware from the server auction?” That is what the acceptance check is for. If power-on hours, wear or ECC errors do not add up, or a self-test has never run, we do not accept the machine.

• “We are too small for our own servers.” Our experience is rather the opposite. With predictable sustained load such as databases, backups or analytics, dedicated hardware pays off earlier than expected. The elasticity of the cloud only helps if you actually use it.

Dedicated servers without the operational overhead

We run dedicated servers and cloud VMs with the same Ansible roles, monitoring and backups, as managed dedicated servers, provider-independent and with 24/7 availability. That includes the acceptance of new hardware, monitoring of temperature and power consumption, RAID and SMART trends, and regularly tested restores.

Wondering whether dedicated hardware pays off for your load?
Write to us and we will work the comparison through — including when the cloud VM turns out to be the better choice.