Managed dedicated servers at Hetzner: sized to fit, operated by us

Under predictable, sustained load, dedicated hardware gives you considerably more performance per euro than a comparable cloud VM. The cores are yours alone, RAM and NVMe come in sizes that get expensive fast in the cloud, and the bill is the same every month. Most of these machines we run at Hetzner and pick the model, its configuration and the RAID level to fit your load.

In exchange you take on more responsibility. When a disk, a memory module or the power supply fails on a dedicated server, no hypervisor quietly moves the instance to another host. That part we take on: acceptance of new machines, monitoring of temperature and power consumption, RAID and SMART trends, backups and regularly tested restores.

We run dedicated servers, cloud VMs and hardware on customer premises with the same Ansible playbooks and the same monitoring and backup setup. Whether the machine sits in a data centre or a warehouse, and with which provider, makes no difference. Where network connectivity, traffic or the target region call for it, we also run the systems at Latitude, DataPacket or in a rack of your own.

Hardware we run in production

60 s

is how often each of our hardware hosts reports temperatures, power draw and fan speeds to our time-series database.

5 servers

in a customer’s fulfilment centres in Europe and the US, connected over a site-to-site VPN and managed like every machine in the data centre. More on that in the KRUU case study.

2 locations

for our own backup hardware with S3-compatible object storage. Our customers’ backups therefore sit on our own servers.

Dedicated server or VM?

In practice it is often a mix. We use dedicated hardware for sustained load and VMs where location or a short runtime matters more. Usually these four points decide it:

Constant performance: Dedicated cores have no steal time and no neighbours competing for the CPU. For databases and latency-critical applications that often matters more than the price.
Local NVMe: No IOPS quotas and no storage bill that grows with usage. With backups and analytics this item often makes the biggest difference in a comparison.
Scaling in steps: You cannot add two more vCPUs, you move to the next model. Plan a little headroom at the start and you rarely need that step.
Lead time: A new server is ready in hours rather than seconds, and a hardware swap needs lead time. For genuine load spikes we therefore combine with cloud VMs.

What you gain with dedicated hardware and what you take on for it is covered in detail in our article Dedicated servers instead of cloud VMs.

Why mostly Hetzner, and when another provider

For most of our dedicated machines, the Hetzner dedicated root servers are the obvious choice. The price-performance ratio is hard to beat in Europe, 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. Since June 2026 Hetzner offers fixed server variants; RAM and storage can no longer be configured freely on new orders. Sized to fit therefore means: we pick model and variant based on your load, set the RAID level and set the system up for your application.

AX line (AMD) and EX line (Intel) for application and database servers with plenty of dedicated cores, NVMe and lots of RAM. This is where our database primaries and replicas, ClickHouse nodes and complete data warehouses run.
GEX line for GPU load, for instance locally run language models when the data should stay in house.
Server auction for older hardware at considerably lower prices. This is where our acceptance check pays off most: power-on hours, disk wear and ECC errors decide whether we take a machine on or send it back.

We are not tied to Hetzner. If network connectivity, traffic volume or a target region outside Europe argues for another provider, we run the same systems at Latitude or DataPacket or on hardware you own. Playbooks, monitoring and backups stay the same.

The maths shifted noticeably in 2026. On 15 June, Hetzner raised cloud prices again for new orders and rescaling, for instances with dedicated vCPUs to roughly two to nearly three times as much. New dedicated servers also got more expensive, yet the comparison is still clear: an AX42 with 64 GB of ECC RAM costs €115.79 per month, a CCX33 with 32 GB of RAM €164.80 (both including German VAT, excluding IPv4). On top of that, the cheap shared cloud sizes were temporarily hard to get in many locations. So before you order a cloud VM with a dedicated CPU at the new price, we are happy to work through the comparison with a dedicated server for you.

What we run on dedicated hardware

Database clusters with a large buffer pool, primary and replica on separate machines. ClickHouse servers for analytical queries, plus Elasticsearch. Complete data warehouse servers with ingestion and dashboards. Object storage for backups, as described in our article on SeaweedFS on Hetzner. GPU hosts for local language models. And applications that need constant response times and cannot work with burst credits.

When very high request rates come in, we tune the kernel and the network: file and socket limits, network buffers, connection backlogs, TCP and scheduler parameters. On a VM you have no influence over some of this, because the hypervisor sits in between.

On top of that come servers outside the data centre, for instance in warehouses and fulfilment centres, where they have to keep running even when the internet connection is down. They hang on the same playbooks, ship their logs to central logging and report temperatures and fan speeds like every other machine. In a warehouse that matters more, because dust and temperature are likelier to become a problem than in a data centre.

How we keep an eye on the hardware

On a VM you never deal with fans, disks and memory modules. On dedicated hardware you do, so we watch them closely.

Acceptance before commissioning: Before a server goes into production we check the memory population, whether ECC is active, the ECC error counters, SMART values of every disk, power-on hours and RAID status. The result is a verdict in three levels, at worst “do not accept”.
Sensor data every minute: Temperatures by source, power draw in watts and fan speeds, depending on the machine from IPMI, lm-sensors, SMART or the RAID controller. If power consumption rises at the same load, we see it before an application slows down.
Alerting and trends: Icinga2 raises alerts, Grafana shows us the trends over weeks. With SMART we look at trends rather than individual readings, to spot failing disks as early as possible.
Reproducible hosts: Every server is fully described in Ansible, backups run with restic onto our own infrastructure. Rebuilding a server is therefore a playbook run.

Which values the acceptance check looks at in detail, and how the hardware monitoring is built, is described 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 the costs apart: the hardware is billed by Hetzner or the provider of your choice directly to your account, and from us comes a management fee per server. We add no markup on the hardware. Whether dedicated or virtual works out cheaper we calculate for your load up front, including storage and traffic. Those two items often matter more than the compute price alone.

Do you only run dedicated servers at Hetzner?

No. Most of our machines are at Hetzner, because price-performance and the locations fit many requirements well. Where network connectivity, traffic volume or a region outside Europe argues against it, we also work with Latitude or DataPacket, or with hardware in a rack of your own. It changes nothing about operations.

And if a disk fails?

It happens eventually. That is why we rely on RAID, SMART trends and backups at another location. What matters is spotting the failure as early as possible and having rehearsed the restart. We access the machine remotely via BMC or iLO and the rescue system; the physical swap in the data centre is handled by the provider.

Can you take on used hardware?

Yes, that is what the acceptance check is for. We look at power-on hours, disk wear, ECC error counters and whether a SMART self-test has ever run at all. If that does not add up, we do not accept the machine. With hardware from the server auction in particular, it saves a lot of trouble later.

How do you roll changes back without snapshots?

Two ways: every host is fully described in Ansible and can be rebuilt by a playbook run, and the data comes from the backup. A snapshot only helps with your own mistakes anyway. With a hardware failure you need the backup regardless.

Do you also look after servers on our premises?

Yes, for instance machines in fulfilment centres in Europe and the US. They are connected over a site-to-site VPN and managed with the same playbooks as the servers in the data centre. Two things we settle in advance: which spare parts are kept on site, and who handles the physical work on the machine.

Are we too small for our own servers?

Usually not. A database with a constant base load often pays for itself on dedicated hardware from the very first machine. In the cloud you pay for elasticity even if you never use it.

Let us work through your load

We look at what you run and tell you whether dedicated, virtual or a mix fits best, even when the answer argues against dedicated hardware. If a dedicated server is an option, we take on selection, acceptance, setup and operations, with monitoring, backups and 24/7 on-call availability, alerted by our on-call system. Write to us or book a free initial call.