Managed dedicated servers at Hetzner: individually configured, operated by us

For predictable, sustained load, dedicated hardware has the far better price-performance ratio than a comparable cloud VM: real cores instead of shared compute time, memory and NVMe in quantities that get unaffordable fast as a VM, and a fixed price instead of a bill that grows with usage. Most of these machines we run at Hetzner – tailored to your load rather than picked from a package catalogue.

The catch is not the maths, it is the responsibility. On bare metal the disk, the DIMM and the power supply are yours – and nobody moves you away when one of them fails. That is exactly the part we take on: acceptance of new machines, temperature and power monitoring, RAID and SMART trends, backups and a restore we rehearse.

Dedicated servers, cloud VMs and hardware standing in a customer’s warehouse are all operated with the same Ansible, the same monitoring and the same backup path. Whether the machine sits in a data centre or a warehouse, and whoever owns it, makes no difference to operations – and neither does the provider: where network connectivity, traffic volume or the target region call for a different one, we run the same systems at Latitude, DataPacket or in a rack of your own.

Hardware we run in production

60 s

the interval at which every hardware host reports temperatures, power draw and fan speeds – into a time-series database, not into a log file.

5 servers

in a customer’s fulfilment centres in Europe and the US – connected over a site-to-site VPN, managed like every machine in the data centre.

2 locations

of our own backup hardware with S3-compatible object storage. We back our customers up onto our own machines rather than into someone else’s cloud storage.

Bare metal or VM?

It is not either-or. We use dedicated hardware where sustained load lives, and virtual machines where geography or a short lifespan counts. Four points decide it:

Constant instead of fluctuating performance. Dedicated cores know no steal time and no noisy neighbours. For databases and anything latency-sensitive, that is the main reason – not the price.
Local NVMe instead of network storage. No IOPS quotas and no storage bill that grows with usage. With backup and analytics load, this is the item that tips the comparison.
Coarse-grained scaling. Growth happens in steps: instead of booking two more vCPUs, you move up a model. Plan headroom from the start and you rarely reach that step.
Lead time instead of elasticity. Provisioning takes hours rather than seconds, and a hardware swap has lead time. Anyone with genuine load spikes therefore combines it with cloud VMs.

We wrote up the full trade – what you gain and what you really take on – in a separate article: dedicated servers instead of VMs.

Why mostly Hetzner – and when another provider

For most of our dedicated machines, Hetzner dedicated root servers are the obvious choice: the price-performance ratio is hard to beat in the European market, the data centres are in Germany and Finland, and the range runs from a small application machine to a server with several hundred gigabytes of RAM. Individually configured means we size for your load – cores, RAM, NVMe capacity, RAID level – rather than picking a package that is either too small or too expensive.

AX line (AMD) and EX line (Intel) for application and database servers: plenty of dedicated cores, NVMe and a RAM build-out that would be unaffordable as a VM. This is where our database primaries and replicas, ClickHouse nodes and the machines running complete data warehouses live.
GEX line for GPU load, such as locally run language models where the data should not leave the building.
Server auction for used hardware at a fraction of the price. This is exactly where our acceptance check pays off immediately: power-on hours, disk wear and ECC errors decide whether a machine is accepted or goes back.

We are not tied to it. Where network connectivity, traffic volume or a target region outside Europe tips the balance, we run the same systems at providers such as Latitude or DataPacket – or on hardware you own yourself. What gets swapped is the foundation, not the way it is operated: same playbooks, same monitoring, same backup path.

One thing that has shifted the maths lately: the prices for cloud servers went up on 15 June 2026, for instances with dedicated vCPUs to more than double in places, and the cheap shared sizes are currently hard to get in most locations. Before paying the higher price for a cloud VM with a dedicated CPU, it is worth comparing directly against a machine of your own – under sustained load that comparison tips towards bare metal more often than people expect. We work it through beforehand rather than asserting it.

What we run on dedicated hardware

Database clusters with a large buffer pool, primary and replica on separate machines. Dedicated ClickHouse servers for analytical queries, plus Elasticsearch. Complete data warehouse servers including ingestion and dashboards. Object storage for backups. GPU hosts for local language models. And applications with hard performance requirements that need constant response times rather than burst credits. Where very high request rates pile up, kernel and network tuning gets out what the defaults leave on the table: file and socket limits, network buffers, connection backlogs, TCP and scheduler parameters. On a VM that road ends where the hypervisor begins. How we run our own S3-compatible storage infrastructure on it is covered in a separate article.

Hardware that does not sit in a data centre is part of it too: servers in warehouses and fulfilment centres that have to keep running when the line to the outside world fails. They hang on the same playbooks, ship their logs out centrally and report temperatures and fan speeds like every other machine – a warehouse, after all, is not a data centre.

How we keep the hardware under control

A VM has never once told you about a fan. On bare metal that is exactly the difference between a good decision and a careless one – which is why we make the hardware visible instead of trusting it.

Acceptance before commissioning. Before a machine goes into production we check the memory population and whether ECC is really active, the ECC error counters, SMART values per disk, power-on hours and RAID status. The result is a verdict in three levels – up to “do not accept”.
Sensors every minute. Temperatures broken down by source, power draw in watts, fan speeds – from IPMI, lm-sensors, SMART and the RAID controller, depending on what the machine offers. A server pulling more at the same load reports its problem before any process slows down.
Alerting and trends kept apart. Grafana shows the trend over weeks, Icinga2 wakes someone up. SMART trends instead of snapshots in time, so a disk stands out before it fails.
Reproducibility instead of snapshots. Every host is fully described in Ansible, backups run with restic onto our own infrastructure. Rebuilding is therefore a playbook run, not a drama.

What that looks like in detail – including the values an acceptance check turns up on used hardware – is in our article on dedicated servers.

FAQ on managed dedicated servers

What does a managed dedicated server cost?

As with the managed cloud server, we keep it clean: hardware costs run directly on your account with Hetzner or the provider of your choice, plus our management fee per server. No hidden markup on the hardware bill. Whether dedicated or virtual works out cheaper we calculate up front for your load – including storage and traffic, because those two items tip the comparison more often than the compute price.

Do you only run dedicated servers at Hetzner?

No. Most of our machines are at Hetzner, because price-performance and the locations in Germany and Finland fit most requirements. Where network connectivity, traffic volume or a region outside Europe argues against it, we work just as well with providers such as Latitude or DataPacket – or with hardware standing in a rack of your own. It changes nothing about operations: same playbooks, same monitoring, same backup path.

And when a disk dies?

It will, eventually – hence RAID, SMART trends rather than snapshots in time, and off-site backups. The question is not whether a disk fails, but whether you see it coming and whether the restart is rehearsed. Remote management runs via BMC or iLO and a rescue system; the physical swap is handled by the provider on site.

Can you take over used hardware?

Yes, and that is exactly what our acceptance check is for. Power-on hours, disk wear, ECC error counters and a self-test that never ran – if the picture is not right, the machine is not accepted. With auction and marketplace hardware in particular, that is the difference between a good price and an expensive mistake.

Without snapshots – how do you roll changes back?

Through two routes that together cover more than a snapshot: every host is fully described in Ansible, so a rebuild is a playbook run. And data comes back from the backup. A snapshot saves you from your own mistake, not from a hardware failure – for that you need a backup anyway.

Do you also look after servers on our own premises?

Yes. Among others we look after machines in fulfilment centres in Europe and the US, connected over a site-to-site VPN and managed with the same playbooks as everything in the data centre. Two things need settling in advance: spare parts on site and clear responsibility for the physical handling.

Are we too small for our own servers?

Usually it is the other way round. A database carrying the same base load around the clock often pays for itself on your own hardware from the very first machine. Elasticity only pays if you actually use it; anyone running the same base load around the clock is paying the cloud for flexibility they never call on.

Let us work through your load

We look at what you run and tell you honestly, in both directions, whether dedicated, virtual or a mix fits. If dedicated is an option, we take on selection, acceptance, setup and day-to-day operations – with monitoring, backup and 24/7 availability via Slack. Write to us or book a free initial call.