Dedicated servers instead of VMs: the better price-performance ratio – and what you take on for it

Most infrastructure discussions stop at “cloud or not”. The more interesting question sits one level down: dedicated hardware or virtual machine. And the answer to that one is fairly unromantic – for predictable, sustained load, bare metal has by far the better price-performance ratio. Plenty of people still do not dare. Not because the maths does not work out, but because with bare metal you take on responsibility the hypervisor used to carry for you.

That responsibility is exactly our job. So here is the honest trade: what you gain, what you really have to do for it – and which tools we use to cover the second half.

The trade: what you gain

• Dedicated cores instead of vCPUs. No steal time, no noisy neighbours, no performance that varies with the time of day. For databases and anything latency-sensitive, that is the main reason – not the price.

• RAM and NVMe at sizes that become absurdly expensive when virtualised. A MySQL instance with a double-digit GB buffer pool is a given on bare metal rather than a budget question.

• Local NVMe instead of network storage. No IOPS quotas, 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. Storage and traffic in particular tip a comparison more clearly than the raw compute price does.

And what you take on for it

• The failure domain is yours. On a VM a disk dies and the hypervisor moves you away – chances are you never notice. On bare metal it is your disk, your DIMM, your power supply.

• No snapshot, no quick roll-back. The replacement has two parts: real backups with a rehearsed restore, and a host fully described in Ansible. The second part is the underrated one – if the machine is reproducible, rebuilding it is a playbook run rather than a drama.

• Scaling is coarse-grained. You do not add two vCPUs, you move to the next machine. That needs thinking about in advance – in exchange, a properly sized machine pushes that limit a very long way out.

• Provisioning takes time. Not seconds, more like hours, and a hardware swap has lead time. So plan for headroom instead of hoping for elasticity.

• You have to watch the hardware yourself. A VM has never once told you about a fan.

In short: the VM sells you the luxury of forgetting the hardware. On bare metal you have to know it – and in return you get all of it.

We take on that second part if you want us to – the service itself is described on our page about managed dedicated servers. What it looks like in practice is the rest of this article.

What that means in numbers

Since 15 June 2026, Hetzner has been charging new cloud prices, and it is the instances with dedicated vCPUs that are hit hardest. For the German and Finnish locations, including 19% VAT and excluding IPv4:

• CCX23: 4 dedicated vCPUs, 16 GB RAM, 160 GB NVMe. From €37.47 to €102.33 per month – roughly two and a half times as much.

• CCX33: 8 dedicated vCPUs, 32 GB RAM, 240 GB NVMe. From €74.36 to €164.80 per month.

• The shared CX instances rose more moderately: CX23 from €4.75 to €6.53, CX33 from €7.72 to €10.10. On the other hand, those cheap sizes are currently hard to get in most locations – which is little help when you need a machine now.

Now the comparison worth doing. An AX42 – eight real cores on a Ryzen 7 PRO 8700GE, 64 GB of DDR5 with ECC, two 512 GB NVMe SSDs – costs €115.79 per month plus a one-off €58.31 setup fee. Put that next to the CCX33: also eight cores, but 32 instead of 64 GB of RAM, 240 GB instead of a terabyte of storage, and €164.80 instead of €115.79 per month. So the dedicated machine is the smaller bill with the larger specification, and it comes with error correction in memory and local NVMe without an IOPS quota. Buying from the server auction puts you well below that again: AX41 and EX44 sit at €68.19 per month with no setup fee – used hardware, where the acceptance check from the next section pays for itself immediately.

And then there is a point that does not fit into a table: at the time of writing, the Hetzner shop lists the CCX instances as currently not orderable, and the cheap CX sizes are scarce in most locations too. The best price is of little use if the machine is not available – with dedicated hardware the lead time is at least predictable, and via the server auction it is often same-day.

Two caveats, so the maths stays honest. It applies to sustained load. If you spin machines up by the hour, throw them away after a load test or move them between regions daily, the cloud is still the better fit – that is what it was built for. And the setup fee wants including: spread over twelve months it fades, over two months it does not. The point is not that the cloud is expensive. It is that before you pay the new price for a cloud instance with a dedicated CPU, you should look at what the same sum buys as a machine of your own. That gap got considerably wider in June.

Making hardware visible: temperatures, watts, fans

That last point is where it is decided whether bare metal is a good idea or a careless one. So on every one of our hardware hosts runs a dedicated script that collects everything the machine will reveal about itself, once a minute, and outputs it in Prometheus format. Telegraf reads it, a VictoriaMetrics time-series database stores it, a Grafana dashboard displays it.

Where the values come from is something the script works out per machine: IPMI or the BMC, lm-sensors, the kernel thermal zones, hwmon, SMART including drivetemp for disk temperatures, ssacli for the RAID controllers in the ProLiants, nvidia-smi on the GPU host. Whatever a machine cannot do is reported as a missing capability. So in the dashboard you can see why a curve is absent, instead of guessing whether the sensor broke or was never there.

What gets recorded: temperatures broken down by source – CPU, system, disks, GPU, power supply, chipset – power draw in watts along with current and voltages where the BMC provides them, and fan speeds. Power draw is more than a data-sheet number here: a server that suddenly pulls more at the same load, with its fans spinning up, is telling you about a problem before any process gets slower.

One detail that belongs to the picture: Telegraf may invoke these tools through a tightly scoped sudo rule – commands listed by name, no blanket permission, and even the kernel modules it may load are enumerated individually. Monitoring that turns itself into a risk would be a bad trade. Above all of it sits Icinga2 as the alerting layer, including a RAID check. Grafana shows the trend, Icinga wakes someone up.

Acceptance instead of trust: the check before commissioning

Continuous monitoring only helps with machines you already have. The second half is acceptance. For that, every hardware host carries a script that pulls a complete hardware and disk health report – written for the moment before you take a server over, from a server auction for instance, and before it goes into production.

It reads the inventory first: manufacturer, model, mainboard, BIOS version and date, CPU, plus every memory module individually with its population, type and clock – and whether ECC is actually active. Then come the numbers that can hurt:

• ECC error counters from EDAC: correctable errors are a warning in the sense of “keep an eye on this module”, uncorrectable ones are critical. This is the check nobody on a VM ever gets to see.

• SMART per disk, with separate rules for NVMe and SATA/SAS. For NVMe: endurance used in per cent, remaining spare blocks, media errors, critical warning flags and data written. For SATA: reallocated, pending and uncorrectable sectors, CRC errors with the note that those usually come from the cable rather than the disk, plus the vendor-specific wear indicator.

• Power-on hours, converted into years. With used machines, the first number you want to see.

• RAID status for mdadm and ZFS, as well as storage errors in the kernel log.

At the end there is a verdict in three levels, emitted as a Nagios exit code: all good, usable but keep watching, or do not accept and do not put into production. The script can also kick off a SMART self-test on every disk – and it reports when a disk has never had one. That is the difference between “ordered cheap hardware” and “took responsibility for cheap hardware”.

Three cases from practice

What is most telling is how different the cases are in which we use bare metal – and how similar they are to operate.

Bare metal that stands in a warehouse. For KRUU we look after five servers that sit in the fulfilment centres in Europe and the US, some of them elderly ProLiants. They sit where the goods are, because shipping has to keep running even when the line to the outside world does not, and because scanners and printers have no patience for detours. They run Docker, Node.js applications, GitLab runners and RabbitMQ; fluent-bit ships the logs out centrally so you can see from outside what is happening inside. They are connected over a site-to-site VPN and managed with the same Ansible as everything else – location and ownership change nothing about the operating model. To be fair, this also belongs in the picture: a warehouse is not a data centre. Dust, temperature and power supply are real topics there, which is exactly why the temperatures and fan speeds of these machines are in Grafana.

Bare metal as the normal case. A customer with a large server park runs their application servers on it, MySQL primary and replica on separate machines, a dedicated ClickHouse server and Elasticsearch. Cloud VMs sit alongside – but only where proximity to the user matters rather than compute. That is the real message: not either-or. Bare metal where sustained load and databases live, VMs where geography or a short lifespan counts.

Our own backup infrastructure. Two dedicated machines with plenty of disks at two locations, running SeaweedFS as S3-compatible object storage plus VictoriaLogs. We back our customers up onto our own hardware rather than into somebody else’s object storage. Here bare metal is not a compromise, it is the whole point: storage per euro, without retrieval and traffic costs that grow with usage.

The objections, answered honestly

• “And when a disk dies?” It will, eventually. Hence RAID, hence SMART trends rather than snapshots in time, hence off-site backups. The question is not whether, but whether you see it coming and whether the restart is rehearsed.

• “No snapshot, no rollback.” True. The replacement is the better one: a host fully described in Ansible, plus a restore from backup. A snapshot saves you from your own mistake, not from a hardware failure – for that you need the backup anyway.

• “Who drives to the data centre at night?” Nobody. Remote management via BMC or iLO, rescue system, remote hands at the provider. For hardware standing at a customer site the answer is a different one and has to be settled in advance: a spare part on site and clear responsibility.

• “Used hardware from an auction?” That is what the acceptance check is for. Power-on hours, wear, ECC errors, a self-test that never ran – if the picture is not right, the machine is not accepted.

• “We are too small for our own servers.” Usually it is the other way round. Precisely with predictable sustained load – databases, backups, analytics – bare metal pays off earlier than people think. Elasticity only pays if you actually use it.

Want the performance without carrying the responsibility alone?

We run dedicated machines and cloud VMs with the same Ansible, the same monitoring and the same backup path – as managed dedicated servers, provider-independent and with 24/7 availability. That includes acceptance of new hardware, temperature and power monitoring, RAID and SMART trends, and a restore we rehearse rather than promise. Write to us – we will work the comparison through for your load, honestly in both directions.