Hetzner managed Kubernetes: what the provider does not do for you
Hetzner has the lowest machine prices in Europe, which is why teams move their production there. Then comes the question the catalogue does not answer: where is the managed Kubernetes?
There isn't one. Hetzner rents machines, networking and storage. Building the cluster, running it and maintaining it is on you. This article sets out what that means item by item, so that the choice between doing it yourself and delegating rests on facts rather than instinct.
What Hetzner provides, and where the catalogue stops
Hetzner Cloud covers the infrastructure, and covers it well:
- x86 and ARM virtual servers, on a public price list
- a private network, floating IP addresses and a firewall
- load balancers
- attachable storage volumes
- S3-compatible object storage
The provider also publishes two open source components that bridge to Kubernetes. The cloud controller manager lets a LoadBalancer service provision a real Hetzner load balancer. The CSI driver lets a persistent volume claim create a volume. Both are useful, and neither builds the cluster for you.
What the catalogue does not include: a managed control plane, provider-driven version upgrades, node autoscaling out of the box, application backups, cluster monitoring. At a hyperscaler these pieces come with the managed service and are priced accordingly. Here they stay on your plate.
Three ways to run Kubernetes on Hetzner
Build the cluster by hand
kubeadm for a standard Kubernetes cluster, k3s for a lightweight distribution, Talos Linux for a dedicated immutable operating system. All three work well on Hetzner. It is the most flexible option, and the most instructive, and it leaves the whole of operations on your shoulders.
Automate with a community project
Projects such as kube-hetzner industrialise cluster creation with Terraform, and Cluster API offers a declarative approach. You gain a reproducible build. In exchange you inherit a dependency on a community project you have to follow, test and upgrade, and day-to-day operations remain yours.
Hand the cluster to a third-party platform
A platform builds the cluster on Hetzner, runs it and maintains it, while the machine bill stays Hetzner's. That is the Fransys approach: servers are passed through at the provider's public price, with no markup, and the platform is billed per resource.
What you must assemble for real production
The list below is not theoretical: it is what separates a cluster that starts from a cluster you put customers on.
- A highly available control plane. A single master node is fine for a test, never for production.
- A CNI. Cilium or Calico, to install, configure and keep up to date.
- An ingress controller and TLS certificates that renew themselves.
- The Hetzner cloud controller manager, without which your LoadBalancer services provision nothing.
- The CSI driver for persistent storage, plus a volume backup strategy.
- Node autoscaling, which requires additional tooling.
- Monitoring: metrics, centralised logs, alerts that actually wake someone up.
- Application backups and, above all, a restore procedure you have tested.
- Kubernetes version upgrades, several a year, to be run without downtime.
- Hardening: RBAC, network policies, secret management, security updates to the base layer.
Every line is doable. It is the accumulation, and above all keeping it all current over time, that weighs.
The real cost is not the machines
This is the classic mistake in the maths. You compare the price of a Hetzner server with a managed service at a hyperscaler, you note a considerable gap, and you stop there.
The missing line item is engineering time. Building a production cluster takes several days up front. Then comes routine maintenance: upgrades, incidents, on-call, security fixes. On a small team that load falls on the most qualified person, which is to say the one whose time is worth most elsewhere.
We set out this calculation in our article on the real cost of a DevOps engineer. The order of magnitude is unambiguous: labour far exceeds infrastructure.
When doing it yourself is still the right call
There are cases where building your own cluster is the right decision, and it would be dishonest to pretend otherwise.
- You already have a platform team, and Kubernetes is part of its job.
- Your requirements are unusual enough that a general-purpose platform would constrain you.
- The cluster is not critical: a test environment, an internal project, a lab.
- Learning is an objective in itself, and the time spent is an investment you accept.
Outside those cases, for a product team that wants to ship, running a cluster is an opportunity cost that is hard to justify.
How Fransys works on Hetzner
Fransys builds the cluster on Hetzner, hardens it, monitors it and scales it. You keep a direct, readable contract with each party: the machine at Hetzner's public price, with no markup, and the platform billed per resource on a six-line grid.
What comes out is standard Kubernetes. Your manifests, your Helm files and your CI pipeline are exportable, and the cluster can be redeployed on OVHcloud, Scaleway or Outscale without rewriting the application. That is the difference between choosing to stay and being stuck.
One caveat to know before picking Hetzner: the provider carries neither HDS certification nor SecNumCloud qualification. For health data or a public sector project, OVHcloud or Outscale are the right choices, and the Fransys deployment there is identical.
Key takeaways
Hetzner does not offer managed Kubernetes, and that is not an oversight: the provider sells infrastructure at the best European price, not an application platform.
Running a production cluster on Hetzner means assembling around ten components and keeping them current, version upgrades included.
The honest comparison is machine price plus engineering time, not machine price alone.
Delegating operations without giving up Hetzner pricing or portability is possible: that is exactly what Fransys does.
Want to know what your infrastructure would cost on Hetzner, operated by Fransys? Describe your situation and an engineer will reply within 48 hours with a line-by-line estimate.