Why Hetzner is so much cheaper, and what the trade-offs are

Comparing Hetzner‘s prices with the major clouds produces a number large enough that people assume a catch. For a given amount of CPU, memory and disk, the difference is frequently several times over, not a few percent.

There is no catch in the sense of hidden fees. There is a genuinely different business model, and it has consequences that matter for some workloads and not at all for others.

Where the difference comes from

Owned data centres in low-cost locations. Hetzner builds and operates its own facilities, concentrated in Germany and Finland. Finland in particular offers cheap power and free cooling for much of the year. Vertical integration removes a layer of margin.

A much narrower catalogue. The hyperscalers fund enormous portfolios of managed services, and those portfolios are cross-subsidised. Hetzner sells compute, storage, networking and a small number of adjacent services. Fewer products means far less engineering and support overhead per euro of revenue.

Generous but finite traffic allowances. Rather than metering every gigabyte, plans include a large monthly traffic allowance with modest overage rates. This is a pricing philosophy difference more than a cost difference, and it happens to suit bandwidth-heavy workloads enormously.

Less redundancy sold by default. Multi-region, multi-zone architectures are available but not the assumed default, and the pricing reflects a single-location baseline.

A leaner support model. Support is competent and responsive for infrastructure issues. It is not a team of solutions architects available to help you design your application, and it is not priced as though it were.

None of this is cutting corners on the hardware. The machines are modern and the network is good. The savings come from the surrounding business.

What you give up

Being honest about this is what makes the decision useful.

Managed service breadth. There is no equivalent to a managed data warehouse, a serverless function platform with a deep event ecosystem, or a dozen specialised database engines. If your architecture leans on those, you would be rebuilding them yourself.

Global footprint. Locations are concentrated in Europe with a smaller presence in the United States and Singapore. If you need low latency in South America, India, Japan or Australia, this is a genuine limitation rather than an inconvenience.

Enterprise contracting. Procurement departments that expect a negotiated master agreement, extensive compliance attestations and named account management will find the experience unfamiliar.

Account onboarding. Identity verification at signup is stricter than most providers, and new accounts sometimes start with lower limits that increase over time. This surprises people expecting to provision a large fleet on day one.

Ecosystem depth. Fewer third-party integrations assume Hetzner. Tooling generally works, but the well-trodden path is narrower.

Cloud servers or dedicated machines

Hetzner sells both, and the distinction matters more here than elsewhere because the dedicated pricing is unusually aggressive.

Cloud servers are virtual machines, billed hourly, created and destroyed through an API in seconds. This is the right choice for anything that scales, anything ephemeral, and anything where you want to treat servers as replaceable.

Dedicated servers are physical machines on a monthly contract, with a setup period rather than instant provisioning. Per unit of raw compute and disk they are dramatically cheaper, and the auction market for previously-used configurations cheaper still. They suit steady, heavy, predictable workloads: large databases, storage-heavy applications, build farms, self-hosted platforms.

The failure mode is treating a dedicated server as though it were elastic. It is not. Provisioning takes time, and you are committed for the billing period.

Which workloads fit well

Hetzner is an excellent fit for European-facing applications, for bandwidth-heavy services where egress pricing elsewhere dominates the bill, for self-hosted platforms and internal tools, for development and staging environments where the hyperscaler bill is pure overhead, for build and CI infrastructure, and for anyone running a workload that is genuinely just Linux servers.

It fits badly for globally distributed low-latency services, for architectures built on managed proprietary services, for organisations whose compliance requirements are written around specific hyperscaler attestations, and for teams with no appetite for operating their own infrastructure.

The pattern that works well in practice

A common and sensible arrangement is not to choose one provider but to place workloads deliberately. Run the parts that are just servers where servers are cheap, and keep the parts that genuinely benefit from managed services where those services live.

Development, staging, CI, batch processing and internal tooling frequently move to cheaper infrastructure with no downside at all, and those categories are often a substantial share of a cloud bill. That is a real saving available without re-architecting anything customer-facing.

For the vendor’s own reference on the services involved here, see the Hetzner documentation.

Questions people ask