By Vicente Arteaga Gomez
MisLinux · Last updated: May 5, 2026
This article is part 1 of my MisLinux series on building and operating a small Kubernetes cluster on Hetzner. It reflects my own hands-on experience and opinions, and I am not affiliated with, sponsored by, or endorsed by Hetzner.
When people talk about Kubernetes, the default assumption is often that you need a major managed cloud to run it properly. That can be true for large teams, strict compliance environments, or globally distributed systems. But for a smaller production footprint, that assumption can be expensive and unnecessary.
I became interested in Hetzner because it sits in an unusual sweet spot: the pricing is attractive, the virtual machines are straightforward, and there is enough flexibility to build a serious cluster without immediately paying the managed-cloud tax. For teams that want control and predictability, that matters.
The decision table I had in front of me
This is the rough matrix I now wish I had written down the first time instead of carrying it around in my head:
| Question | Hetzner self-managed k3s | Managed hyperscaler k8s |
|---|---|---|
| Can I keep a real 3-node footprint affordable from day one? | Yes | Often no |
| Do I need to understand Linux, node IPs, firewalls, and upgrades myself? | Yes | Less, but not never |
| Will I get more built-in services? | No | Yes |
| Will I understand the infrastructure path more directly when something breaks? | Usually yes | Sometimes less |
| Is it a good fit for a small, steady production system? | Often yes | Sometimes overkill |
That table is subjective, but it reflects the real trade I was making. I was not looking for a platform that removed responsibility. I was looking for one where the monthly bill left room for redundancy, backup, and operational experimentation without forcing me into an oversized starting point.
What made Hetzner appealing
The first reason was cost. A small Kubernetes cluster needs more than one machine if you want to do it responsibly. You need room for a control plane, workloads, upgrades, and recovery. On some providers, the monthly bill becomes painful long before the cluster is truly useful. Hetzner makes that early stage much more practical.
The second reason was simplicity. Hetzner Cloud does not try to hide the infrastructure behind layers of abstractions. You get servers, networks, volumes, firewalls, and load balancing options. That means more work than a fully managed Kubernetes service, but it also means fewer surprises when something breaks and you need to inspect the moving parts yourself.
The third reason was performance per euro. For many web workloads, internal tools, API services, or queue consumers, the combination of price and available resources is hard to ignore. If your workload is steady and not wildly bursty, this can be more valuable than a long list of premium cloud features you never use.
The tradeoff is operational responsibility
Hetzner is not magic. Choosing it means accepting more responsibility for the cluster.
You need to think through:
- how nodes discover each other
- which addresses your cluster networking depends on
- how firewalls affect CNI traffic
- how you handle storage and backups
- how you do upgrades without breaking production
- how you expose services safely to the internet
This is exactly why I think Hetzner is interesting. It forces you to understand the platform instead of outsourcing all operational thinking to a managed service. That is not the right choice for everyone, but it is a valuable choice for people who want cost efficiency and direct control.
Where Hetzner works well
In my experience, Hetzner is a good fit when:
- you run a focused set of services instead of a giant multi-team platform
- you are comfortable owning Linux, networking, and Kubernetes operations
- you want predictable infrastructure costs
- you value simple infrastructure primitives over a massive ecosystem of add-on services
- you can tolerate building a few pieces yourself
It is especially attractive for teams running APIs, internal platforms, content delivery backends, cron-heavy systems, or smaller SaaS products that need reliability without hyperscaler overhead.
The command trail that makes the decision feel concrete
Before I trust a provider/platform combination, I want the first operational checks to stay boring:
# Inventory after bootstrap
kubectl get nodes -o wide
# Quick cost-reality mindset: what am I actually paying for?
hcloud server list
hcloud volume list
# If the cluster cannot answer these cleanly, the platform is not "simple" yet
kubectl get pods -A
kubectl get ingress -AThat is not a full decision framework, but it is a useful smell test. If the answers are already messy at this stage, the platform is going to feel expensive in operator time even if the invoice looks cheap.
Where Hetzner is not the best fit
I would be more cautious if the project depends heavily on managed services that are tightly integrated with AWS, GCP, or Azure. I would also think twice if a team is new to Linux operations and expects Kubernetes to remove complexity. Kubernetes does many things well, but it does not eliminate the need to understand the environment it runs on.
There is also a mindset issue. If the goal is to avoid infrastructure responsibility entirely, Hetzner is probably not the best choice. You can absolutely build a clean and reliable platform on it, but you need to earn that reliability with disciplined operations.
A failure case I was explicitly trying to avoid
One of the easiest traps with Kubernetes cost discussions is optimizing for the cheapest possible first invoice instead of the cheapest stable operating model.
For me, the bad version of that decision would have looked like this:
- too few nodes to separate responsibilities cleanly
- no room for a real upgrade / drain workflow
- networking assumptions left implicit
- "we will think about backups later"
That kind of cheap cluster is not actually cheap. It is a deferred incident bill.
My working principle
My approach to Kubernetes on Hetzner is simple: keep the architecture boring, document every network dependency, and assume that future changes will be made under stress. A cluster that looks elegant on day one but is hard to debug under pressure is not a good production design.
That means I prefer:
- explicit firewall rules
- predictable node configuration
- repeatable bootstrap steps
- plain ingress and TLS setup
- careful backup and restore procedures
- fewer components, not more
What I'd do differently now
If I were making the same decision again today, I would document the rejection criteria more explicitly up front:
- when I would stay with a simpler single-host deployment
- when I would choose managed Kubernetes instead
- what exact operator tasks I was accepting in exchange for the lower invoice
The platform choice became much clearer once I started writing those tradeoffs down in plain language instead of treating them as intuition.
Final thought
Hetzner is not the perfect answer to every Kubernetes problem. It is a strong answer for people who want a practical balance between cost and control. If you are willing to own the operational details, it can be an excellent place to run a serious cluster without overbuilding from the start.
Series note
This is the opening article in my six-part Kubernetes-on-Hetzner series. I wanted to start with the decision logic first, because the rest of the series only makes sense if the cost-versus-control tradeoff is clear up front.
In the next article, I will walk through how I think about bootstrapping a Kubernetes cluster on Hetzner, from node roles to first-run configuration choices.
