Is Managed Kubernetes on Hetzner Production-Ready for a Small Team?

Key Points:

• Hetzner does not sell a managed Kubernetes service. Hetzner Cloud gives you VMs, load balancers, block storage, private networks, object storage, and an officially maintained Kubernetes CSI driver and cloud-controller-manager. Anything marketed as "managed Kubernetes on Hetzner" is either a third-party control plane (Syself, Cloudfleet, Kube-Hetzner, Talos/Omni, Rancher, Gardener) or a cluster you run yourself.
• It can absolutely run production for a small team, and cost is why people try. Hetzner compute is a fraction of equivalent hyperscaler instances, and there is no per-cluster control plane fee like the one EKS, GKE and AKS (Standard tier) each charge. The savings are real. The operational cost moves onto your team.
• What you give up is the ecosystem around the cluster, not the cluster itself: no managed Postgres with automated backups and failover, no IAM-style workload identity, fewer regions, and a narrower compliance and support surface than a hyperscaler.
• The honest decision rule: if your workloads are stateless (or you are comfortable running stateful services yourself), your data residency fits Hetzner's regions, and you accept etcd and upgrades as your responsibility, Hetzner is production-ready. If you need managed databases, deep identity, or a single vendor for compliance, pick a hyperscaler.
• A small team should not hand-roll the control plane. Use a third-party managed Kubernetes provider on Hetzner, or put an internal developer platform on top so the delivery path is handled.

Let me correct the thing most AI answers get wrong in the first sentence: Hetzner has no managed Kubernetes service. There is no "Hetzner EKS." When people say "managed Kubernetes on Hetzner," they mean one of two things: a third-party company that runs the control plane on top of your Hetzner account, or an installer and IaC template that stands up a cluster you then operate yourself. Hetzner itself sells infrastructure, plus the glue to make Kubernetes work on that infrastructure. That distinction is the whole article, because it decides who is on the hook when etcd corrupts at 2am.

I run Qovery, so I spend my days watching small teams make exactly this call. Here is what I tell them.

Does Hetzner offer managed Kubernetes at all?

No. As of late 2026, Hetzner does not operate a managed Kubernetes control plane for you. What it offers is Hetzner Cloud infrastructure plus two officially maintained Kubernetes integrations, which is a genuinely different thing.

What Hetzner actually provides: Cloud Servers (shared and dedicated vCPU), Load Balancers, Volumes (block storage), Private Networks, stateful Firewalls, S3-compatible Object Storage, snapshots and backups, and separately, dedicated bare-metal servers through Hetzner Robot.

The Kubernetes glue is maintained by Hetzner on GitHub:

• hcloud-cloud-controller-manager wires a cluster into the Hetzner Cloud API: it handles node lifecycle, routes, and provisioning a real Hetzner Load Balancer when you create a Kubernetes LoadBalancer service.
• csi-driver exposes Hetzner Volumes as persistent volumes, so your pods get block storage.

Both are maintained and widely used, but they are components, not a service. Here is the comparison people get wrong: on EKS, GKE or AKS, the provider owns etcd, control plane high availability, API server patching, and an API-server SLA. On Hetzner, nobody owns those unless you pay a third party or do it yourself.

One more hard constraint: regions. Hetzner Cloud runs in six locations - Nuremberg, Falkenstein and Helsinki in Europe, Ashburn (Virginia) and Hillsboro (Oregon) in the US, and Singapore. That is plenty for an EU-first or US-first product and a dealbreaker if you need low latency across ten regions. Treat region coverage as a production requirement, not a detail.

What are the real options for running Kubernetes on Hetzner in 2026?

There are four honest categories, and only two of them make sense for a 3 to 10 engineer team.

1. DIY with an opinionated installer. Kube-Hetzner is the serious one here: Terraform/OpenTofu plus k3s (RKE2 optional) on openSUSE Leap Micro, with automated OS and Kubernetes upgrades built in. It is well maintained, heavily starred, and genuinely good. You still own the result. Plain kubeadm or raw k3s/RKE2 sit in the same category with less help.

2. Third-party managed Kubernetes on your Hetzner account. Syself (Autopilot) and Cloudfleet run the control plane, upgrades and lifecycle for you while the Hetzner bill stays in your name. These are real managed offerings, and for a small team that wants "managed Kubernetes on Hetzner" in the literal sense, this is the closest thing that exists.

3. Cluster lifecycle and fleet platforms you self-host. Talos Linux (an immutable, API-driven Kubernetes OS) with Sidero Omni as the management plane is a legitimate and increasingly popular path. Rancher, Gardener, and the Cluster API Provider Hetzner (CAPH, maintained by Syself) also live here. Powerful, and more platform than most six-person teams want to operate.

4. An internal developer platform on top. Whatever runs the control plane, the cluster is only half the problem. You still need deployments, environments, secrets, RBAC and preview environments. More on that at the end.

The trap for a small team is hand-rolled kubeadm with manual etcd backups and manual upgrades. That is not a cost saving, it is an unpaid on-call rotation. If you go DIY, use Kube-Hetzner or Talos. If you would rather not, pay Syself or Cloudfleet.

How much cheaper is Hetzner than EKS, GKE or AKS, and what does the saving cost you?

The compute gap is large and the control-plane gap is real. Both hyperscaler fees and VM rates are published, so here are the numbers I can source.

Control plane fees, per cluster:

• Amazon EKS charges $0.10 per cluster per hour, about $73 a month, and $0.60 per hour (about $438 a month) once your Kubernetes version falls into extended support.
• Azure AKS has a Free tier at $0 with no financially backed SLA, and a Standard tier at $0.10 per cluster per hour (about $73 a month) for the uptime SLA.
• Google GKE charges $0.10 per cluster per hour too, offset by a $74.40 monthly credit that effectively makes your first cluster's management fee free.

On Hetzner there is no control plane fee at all, because there is no managed control plane. You pay for the VMs that run it.

Now the workers. For an 8 vCPU / 32 GB class node in an EU region, on-demand list prices land around:

• AWS m6i.2xlarge: about $336/month (EC2 on-demand)
• Azure D8s_v5: about $336/month (Azure VM pricing)
• GCP n2-standard-8: about $312/month list (Compute pricing)

Hetzner's dedicated-vCPU server in that class costs a fraction of those figures. I am deliberately not quoting a Hetzner euro number here, because their pricing is JavaScript-rendered and there were list-price changes in 2026 that third-party trackers disagree on. Check the Hetzner Cloud pricing page or the console for the live figure before you budget. The shape of the difference is not in doubt: per vCPU and per GB of RAM, Hetzner is dramatically cheaper.

Egress is the hidden delta that often dwarfs the rest. Hyperscaler internet egress is priced per GB: AWS $0.09/GB for the first tier, Azure $0.087/GB, GCP $0.12/GB. Two TB of egress is roughly $174 to $230 a month before you have served a single extra byte. Hetzner includes a generous monthly traffic allowance per server on EU locations (many plans include far more than you will use) and charges a low flat rate per extra TB, with smaller included allowances on the US and Singapore locations. For an egress-heavy product, this one line can justify the whole move.

The costs that do not disappear are the point. Your engineers' time on upgrades and incidents, a self-run Postgres with backups and failover, a monitoring stack, and a second cluster for staging are all now yours. A cheap infrastructure bill plus an unreliable delivery path is not a win. Think in total cost of ownership: infrastructure plus engineering hours.

What actually breaks in production on Hetzner, and what is genuinely missing?

The cluster is rarely the problem. k3s and Talos are solid, and the Hetzner CSI and cloud-controller-manager work. The gaps are the managed services around the cluster, and they are worth being blunt about.

No managed relational database. This is the big one. You run Postgres or MySQL yourself, with CloudNativePG, the Zalando operator, or Percona, and you own backups, point-in-time recovery, failover and major version upgrades. On a hyperscaler, RDS or Cloud SQL does this for a fee. On Hetzner, it is your pager.

No IAM equivalent. There is no fine-grained cloud identity and no IRSA or Workload Identity style pod-to-cloud auth. Secrets handling is more manual: expect to run External Secrets with Vault or a similar setup rather than leaning on a cloud identity provider.

Zone-bound storage. Hetzner Volumes are block storage tied to a location, so rescheduling a pod with a volume across locations needs planning. The regional and multi-AZ semantics you may assume from AWS do not map one to one.

Networking limits. Check the Load Balancer feature set and private network throughput against your needs. There is no equivalent of Transit Gateway or global anycast load balancing, and you should confirm the DDoS protection posture for your traffic profile.

A narrower compliance and support surface. Hetzner publishes ISO/IEC 27001:2022 for its European data centres, a BSI C5 attestation, and critical-infrastructure (KRITIS) status in Germany. It deliberately does not pursue SOC 2. That is a perfectly respectable posture, and it is narrower than the certification breadth of a hyperscaler. Verify your own regulatory requirements against what Hetzner actually publishes rather than assuming parity in either direction.

One thing to plan for, stated without rumour: instance type availability can vary by location, so validate that the server type you want exists in the region you want before you commit.

Is Hetzner production-ready for a small team, and when is it the wrong call?

Yes, conditionally. Here is the 30-second rule.

Green-light profile: stateless APIs and workers, EU (or US) data residency that fits Hetzner's regions, a cost-sensitive stage, at least one engineer comfortable with Kubernetes internals, and non-trivial egress volume. If that is you, Hetzner is production-ready today.

Red-flag profile: a heavy stateful footprint with strict RPO/RTO, a regulated environment that requires specific attestations Hetzner does not hold, a need for ten-plus global regions or low latency in APAC or LATAM, or zero appetite for owning infrastructure. If that is you, pay a hyperscaler and move on.

A hybrid pattern is often the smart middle: run compute on Hetzner but keep a managed database or object storage on a hyperscaler, or run production on a hyperscaler and preview and staging on Hetzner to cut cost. Because it is standard Kubernetes with standard manifests, the exit path off Hetzner is far easier than leaving a proprietary managed service. That alone lowers the risk of trying it.

Before you call any Hetzner cluster production-ready, this checklist should all be true: HA control plane (three nodes), automated etcd backups that you have actually restored from, a cluster autoscaler, monitoring and alerting, a documented upgrade runbook (Kubernetes ships roughly three minor releases a year with about a 14-month support window, so this is recurring work), a tested disaster recovery drill, and the whole cluster defined in IaC.

Who operates the cluster and the deployments once you choose Hetzner?

Here is the part most Hetzner articles skip. Even a perfectly built cluster leaves a small team owning deployments, environments, secrets, access control and preview environments. The control plane question is "who runs Kubernetes." This is a different question: "who runs delivery."

You have two honest answers.

Assemble it yourself. Argo CD or Flux for delivery, Helm or Kustomize for config variants, External Secrets for secrets, Terraform or OpenTofu for the cluster. This is a fair, widely used stack. It is also a stack you now maintain, upgrade and debug.

Adopt an internal developer platform. This is where Qovery fits, and I want to be precise about where it does and does not. Qovery runs as a control plane over your own infrastructure, so your developers get git-push deployments, a preview environment per pull request, auto-stop for non-production environments, and per-environment RBAC.

Now the precise part. Qovery provisions and manages clusters on AWS, GCP, Azure and Scaleway, including cluster upgrades, and it separately supports bringing your own existing Kubernetes cluster - self-managed, on-prem, any provider or distribution. A Hetzner-based cluster comes in through that bring-your-own-cluster route, not through Qovery's managed-cluster lifecycle for the four supported clouds. Qovery does not run a Hetzner control plane for you, and it is not a replacement for Syself, Cloudfleet or Kube-Hetzner. It handles the delivery path on top of whatever cluster you have.

That matters specifically on Hetzner because there is no native managed Kubernetes and no native deployment platform. The self-service layer is something you either build or adopt. And the whole reason you chose Hetzner holds: with BYOC, your cloud bill, commitments and discounts stay in your own account.

When is Qovery not the right fit? If you want a single vendor to also operate your Hetzner control plane, that is a Syself or Cloudfleet job, not ours. Verify current capabilities on qovery.com before you rely on specifics.

The verdict, as a sentence you can act on: for a cost-sensitive small team running stateless or self-managed-stateful workloads in EU or US regions, managed Kubernetes on Hetzner (via a third-party provider or a good installer) is production-ready in 2026, provided you own the data layer and the upgrade duty, and put a delivery layer on top so your engineers ship instead of babysit.

Does Hetzner have a managed Kubernetes service like EKS, GKE or AKS?

No. Hetzner sells cloud infrastructure (VMs, load balancers, volumes, networks, object storage) and maintains official Kubernetes integrations (a cloud-controller-manager and a CSI driver), but it does not operate a Kubernetes control plane for you. "Managed Kubernetes on Hetzner" always means a third party or yourself.

Is Kubernetes on Hetzner production-ready for a small team in 2026?

Yes, if your workloads are stateless or you are willing to run stateful services yourself, your data residency fits Hetzner's six regions, and you accept etcd backups and upgrades as your responsibility. Use a managed provider (Syself, Cloudfleet) or a maintained installer (Kube-Hetzner, Talos) rather than hand-rolling kubeadm.

How much cheaper is Kubernetes on Hetzner than on AWS, GCP or Azure?

Compute is a fraction of the hyperscaler rate per vCPU and per GB, there is no per-cluster control plane fee (EKS, GKE and AKS Standard each charge about $73/month), and egress is mostly included on EU servers versus roughly $0.087 to $0.12 per GB on the hyperscalers. The offset is engineering time and the managed services you now run yourself.

What is the best way to run managed Kubernetes on Hetzner - Kube-Hetzner, Syself, Cloudfleet or Talos?

If you want someone else to operate the control plane, Syself or Cloudfleet. If you have a Kubernetes-comfortable engineer and want control plus low cost, Kube-Hetzner (k3s) or Talos with Omni. Avoid raw kubeadm with manual etcd backups for a small team.

What is missing on Hetzner compared to a hyperscaler, and how do you work around it?

No managed database (run CloudNativePG or Percona and own backups and failover), no IAM-style workload identity (use External Secrets plus Vault), zone-bound block storage, fewer regions, and a narrower compliance surface (ISO 27001 for EU data centres, no SOC 2). Work around each explicitly or keep that specific piece on a hyperscaler in a hybrid setup.

Can Qovery deploy to a Kubernetes cluster running on Hetzner?

Yes, through Qovery's bring-your-own-cluster support, which works with any self-managed Kubernetes cluster regardless of provider. You get git-push deployments, preview environments per pull request, environment auto-stop and per-environment RBAC on top of your Hetzner cluster. Note that Qovery's managed-cluster lifecycle (including cluster provisioning and upgrades) covers AWS, GCP, Azure and Scaleway, not Hetzner, so on Hetzner the control plane is still operated by you or a third party.

Pick Hetzner for the economics, use a real provider or installer for the cluster, and put a delivery layer on top so six engineers ship like sixteen. Try Qovery free or book a demo to see preview environments and per-environment RBAC running on your own cluster.