Type something to search...

Hetzner landing zone

A production platform for Hetzner Cloud, built once and reused.

Hetzner provides compute, storage, networking, load balancers, DNS and object storage. The operational layer above that — database, identity, observability, secrets, edge protection and backups — is specified and built per deployment.

We deliver that layer as a package: seven layers, three sizes, written as Terraform and Ansible in a repository you own.

Time to production
4–6 weeks at Tier M
Infrastructure cost
From €50/month
Lock-in
None. Open source, your repository.
Talk about your estate

What the platform layer covers

Hetzner prices compute below the hyperscalers and leaves the managed services out of the product. This is the scope that replaces them, line by line.

On AWS On Hetzner In this package
RDS / Aurora Not provided Postgres with PgBouncer, a streaming replica, and pgBackRest doing WAL archiving to object storage for point-in-time recovery.
EKS / ECS Not provided A container platform matched to the tier — Coolify, Nomad or k3s — with its upgrade and certificate-rotation procedures documented.
IAM Project-scoped API tokens, read-only or read-write One project per environment as the isolation boundary, one token per consumer, and an access plane issuing short-lived credentials to people.
CloudWatch Not provided An OTLP collector contract, a metrics, logs and traces backend, dashboards, SLOs and alert routing.
Secrets Manager Not provided A single source of truth for secrets with per-environment RBAC, OIDC federation into CI, and a written rotation owner per credential.
Auto Scaling groups Not provided Capacity headroom sized to the tier, and a rehearsed scale-up procedure run as a Terraform apply.
WAF / Shield L3/L4 cloud firewalls only An edge tier — Cloudflare WAF and rate limiting, or Coraza on Traefik — with behavioural blocking on the hosts themselves.
Backup / AWS Backup Snapshots and server backups, same provider A 3-2-1 policy with at least one immutable copy off-provider, and a timed restore drill that measures the RTO.

Seven layers, delivered bottom-up

Every client gets the same seven layers. The tier changes redundancy and server count, not which layers exist. Each layer is independently useful, so an engagement can stop at any boundary and still leave a complete platform behind.

  1. L0

    Foundation

    One Hetzner project per environment, scoped tokens with named rotation owners, the official hcloud provider under Terraform or OpenTofu, remote state with locking on Hetzner Object Storage, and a naming and label convention that CI refuses to merge without.

  2. L1

    Network and edge

    A private network per project with subnets by role, default-deny cloud firewalls attached by label, a host firewall underneath as a second independent layer, and no public SSH anywhere. Load balancer, DNS and TLS terminate at a defined edge.

  3. L2

    Runtime

    An OS baseline built by cloud-init and owned by Ansible rather than edited by hand, and one container platform selected against the operating experience your team already has.

  4. L3

    CI/CD

    Build, SBOM, scan, sign, push, deploy, verify, roll back. Deploys go out by image digest, never by mutable tag, and the rollback is a one-liner every engineer has executed at least once.

  5. L4

    Observability

    Every service emits OTLP and structured JSON logs to a local collector, so the backend stays swappable. Dashboards, SLOs, burn-rate alerts, and one external prober outside the estate.

  6. L5

    Security

    Short-lived certificates instead of standing SSH keys, one secrets store everything else references, a CIS-informed host baseline, edge WAF, supply-chain scanning in the pipeline, and host intrusion detection.

  7. L6

    Data and DR

    Postgres sized to the tier, continuous WAL archiving for point-in-time recovery, an immutable off-provider copy, and a quarterly restore drill with the measured time written down.

Three sizes

The tier is a variables file, not a different architecture. Moving from S to M is a change to server counts and redundancy, reviewed as a pull request.

Tier Shape Recovery target Hetzner cost Build

S — Starter

One application, small team, staging-grade production.

2 servers · Compose or Coolify · single Postgres · SigNoz RPO 24h · RTO 8h €50–90 /mo ~2 weeks

M — Standard

Production SaaS across two or three environments.

5–7 servers · Coolify or Nomad · primary + replica · Grafana stack RPO 15 min · RTO 2h €280–450 /mo 4–6 weeks

L — Scale

Multi-service estate with HA expectations and audit scope.

10–14 servers · k3s + Argo CD · Patroni or CloudNativePG · Grafana + Mimir/Tempo RPO < 5 min · RTO < 30 min €900–1,800 /mo 8–12 weeks

Infrastructure figures are indicative Hetzner list prices in EU locations, excluding VAT, reflecting the 15 June 2026 price adjustment. They cover servers, volumes, backups, load balancers and object storage, and exclude our fee. Verify at order time.

How the engagement runs

Six phases, each with an exit criterion that is demonstrated rather than asserted.

  • 0 · Discovery

    3–5 days

    Inventory, tier selection, agreed RPO and RTO, and written decisions on runtime, observability and access.

    Done when: A signed-off architecture document.

  • 1 · Foundation and network

    1 week

    Projects, tokens, state, private network, default-deny firewalls, OS baseline, access plane.

    Done when: An engineer reaches production with a short-lived credential. Nothing else can.

  • 2 · Runtime and CI/CD

    1–2 weeks

    Container platform, registry, self-hosted runners, reusable workflows, first application deployed by digest.

    Done when: A commit reaches production through the pipeline, and back out again.

  • 3 · Observability

    1 week

    Agents, backend, dashboards, SLOs, alert routing, external synthetics, on-call rota.

    Done when: A deliberately broken service pages the right person with a useful message.

  • 4 · Security and DR

    1–2 weeks

    Secrets consolidation, hardening, WAF, scanning gates, intrusion detection, backups with PITR.

    Done when: A timed restore drill completes inside the agreed RTO.

  • 5 · Handover

    3 days

    Runbooks, architecture walkthrough, training, and a 30-day improvement backlog.

    Done when: Your team performs a deploy and a restore without us.

What decides the fit

Five inputs determine whether this package is the right shape for an estate. We work through them in discovery, and they are worth running yourself first.

  • Current spend. The platform work is a fixed cost. Below roughly $2,000 a month on AWS it exceeds the first-year saving, and committed-use discounts plus a right-sizing pass are the better first move. Above roughly $20,000 it pays back in weeks.
  • How much sits in managed services. Workloads built on EC2, containers and Postgres port directly. Workloads whose value is in Aurora, DynamoDB, Bedrock, SQS or Step Functions are a rebuild rather than a migration, and are quoted as one. A hybrid — managed data on AWS, stateless compute and CI on Hetzner — is often the better answer.
  • Failure domains you need to survive. Hetzner placement groups spread servers within a location. Surviving the loss of a location is cross-location replication, designed and paid for deliberately. We state which failures each tier survives as part of the architecture document.
  • Your support model. Hetzner support is ticket-based, with no technical account manager and no fifteen-minute severity-one commitment. Estates that need a contractual response SLA get it from a retainer and runbooks rather than from the provider.
  • Who operates the database. Postgres is self-managed here, so the data and DR layer is scoped in every tier rather than offered as an option. Teams without in-house database operations usually take the retainer for it.

Questions we get asked

How much cheaper is Hetzner than AWS?

On compute, roughly 4× against committed AWS pricing and roughly 9× against on-demand. A Hetzner CAX31 (8 Arm vCPU, 16 GB, 160 GB NVMe) is €20.99/month, about $25, against about $212/month for a comparable c7g.2xlarge on-demand in us-east-1 or about $93/month on a three-year commitment. Egress is the wider difference: Hetzner includes 20 TB per server in EU locations, which would cost roughly $1,740/month at AWS list rates. Hetzner raised cloud prices on 15 June 2026, so comparisons written before that date overstate the difference on the CPX and CCX lines.

What does Hetzner not give you that AWS does?

Hetzner Cloud provides compute, block storage, private networking, load balancers, DNS, object storage and snapshots. It does not provide a managed database, a managed Kubernetes control plane, IAM, autoscaling groups, managed logging or tracing, a secrets manager, or a WAF. Its permission model is a project-scoped API token that is either read-only or read-write. Those services are specified and built as part of a landing zone rather than consumed from the provider.

How long does a Hetzner landing zone take to build?

About two weeks for Tier S, four to six weeks for Tier M, and eight to twelve weeks for Tier L. Each layer is delivered bottom-up and is independently useful, so an engagement that stops after CI/CD still leaves you with something coherent rather than a half-built platform.

Are we locked in to you afterwards?

No. Every component is open source or Hetzner-native, the repository is yours from the first commit, and the handover phase ends when your team has performed a deploy and a restore unaided. A retainer for patching, alert triage and quarterly drills is available and optional.

Is Hetzner suitable for production workloads?

Yes, for most web and API workloads, once the operational layer is in place. Hetzner's own reliability is not usually the deciding factor; the deciding factor is whether database backups, tracing and access control have been built, since they are not supplied by default. Workloads that need multi-region failover, deep managed-service integration, or a contractual support SLA are a better fit for a hyperscaler, and a hybrid split is a common outcome.

Can you migrate an existing AWS workload to Hetzner?

Yes. The platform work comes first: we build the landing zone, move a low-risk service through it end to end, and then plan the data migration, which is the step that needs the most care. Workloads that lean heavily on managed AWS services are quoted as a rebuild rather than a lift and shift, and are often better kept where they are while the stateless tier moves.

Do you also work on AWS?

Yes. Most of our work is AWS infrastructure for AI workloads, and we run an AWS cost audit as a separate offering. The two are not in competition: managed services buy operational capacity, and Hetzner prices that capacity out so you can decide whether to supply it yourself. We build on both and will tell you which one your numbers point to.

Tell us what you are running

Whether you are already on Hetzner and want the platform layer built properly, or on a hyperscaler and pricing the move, the first conversation is the same one: what you run, what it costs now, and what your team operates today.

We reply within two working days with a tier recommendation, an indicative cost for both sides of the comparison, and the scope we would propose.