What Kubernetes on Hetzner Costs, and When I Wouldn't Use It

By Vicente Arteaga Gomez

MisLinux · Last updated: May 5, 2026

This article is part 6 of my MisLinux series on Kubernetes on Hetzner. It reflects my personal experience and tradeoff analysis only; I am not affiliated with, sponsored by, or endorsed by Hetzner.

The strongest argument for running Kubernetes on Hetzner is not that it is the most feature-rich platform. It is that the cost-to-control ratio can be excellent for the right workload profile.

The question that matters more than the cheapest invoice

When I revisit the economics now, I ask a slightly different question than I did at the beginning:

> What is the cheapest platform that still gives me a boring recovery story?

That framing matters because infrastructure cost is not only node price. It is also the number of future incidents that force a skilled operator to stop everything else and debug the platform under pressure.

What the platform saves you

Compared with larger managed-cloud setups, Hetzner can keep infrastructure spend far more predictable. That matters when the cluster supports a real product but the team is still sensitive to recurring cost.

The savings come from straightforward compute and infrastructure pricing, not from some hidden optimization trick. If your workloads are stable and your team can operate the cluster responsibly, the economics can be compelling.

Real Hetzner costs: what I actually pay

The table below reflects real Hetzner pricing (Falkenstein datacenter, April 2026) for a production cluster with one control-plane node, one general worker, and one dedicated workload node. These are list prices in EUR excluding VAT; your exact invoice will vary by datacenter, usage, and any discounts.

Compute (ARM64 cax series — best price/performance for most workloads)

Node role	Machine type	vCPU	RAM	Monthly price
Master / control plane	cax21	4 vCPU (ARM64)	8 GB	~€7.49
General worker	cax41	16 vCPU (ARM64)	32 GB	~€22.49
Dedicated workload node	cax21	4 vCPU (ARM64)	8 GB	~€7.49
Compute subtotal				~€37.47

Storage and network add-ons

Item	Spec	Monthly price
Block volumes (7 PVCs, ~170 GB total)	€0.0571/GB/month	~€9.72
Primary IPv4 addresses (3 nodes)	€0.50/IP/month	~€1.50
Server backup for master node	20% of server price	~€1.60
Add-ons subtotal		~€12.82

Total: ~€50–60/month for a real three-node production cluster

The full monthly cost including compute, storage, IPs, and backups is approximately €50–60/month depending on storage usage. This compares directly against:

Platform	Comparable setup	Approximate monthly cost
Hetzner (self-managed k3s)	3 nodes, 7 PVCs, 1 load balancer	~€50–60
GKE Autopilot	3-node equivalent	~€150–250
EKS (AWS)	3 × t3.large + EBS + ELB	~€200–300
DigitalOcean DOKS	3 × basic-2vCPU-4GB + volumes	~€90–120
Fly.io / Render	Comparable compute	~€80–150

The Hetzner number is real; the others are estimates based on list prices for comparable node sizes. All managed Kubernetes providers include control-plane costs that Hetzner does not charge for directly — you pay for that with operator time instead.

The command trail behind the monthly numbers

The reason I trust cost notes more when they are written down is that the verification path is concrete:

# Inventory the live Hetzner shape
hcloud server list
hcloud volume list

# Check what the cluster is actually using
kubectl get nodes -o wide
kubectl get pvc -A

The kind of output I want from that first command is something I can reason about quickly:

master-node      cax21
worker-node-0    cax41
vpaidd-worker-0  cax21

Even when I later graph or summarize the costs, those are still the commands that keep the cost discussion grounded in real infrastructure instead of in generic provider marketing.

What the platform asks from you in return

The lower infrastructure cost is balanced by higher operational ownership.

You are taking responsibility for things such as:

• node configuration and cloud-init templates
• cluster networking assumptions (Flannel VXLAN, firewall rules)
• firewall correctness (both Hetzner Cloud Firewall and in-cluster network policies)
• storage strategy (PVCs, backup, restore)
• upgrade execution for k3s, OS packages, and cluster components
• incident recovery when a node or service fails

That trade can be worth it. But it is only worth it if the team actually has the time and skill to own those areas.

The hidden cost: operator hours

A rough estimate for a team that is comfortable with Linux and Kubernetes:

• Initial cluster setup: 8–16 hours
• Routine monthly maintenance (patches, cert rotation checks, backup verification): 2–4 hours/month
• Incident response per year (a bad node, a full disk, a certificate miss): 4–12 hours/year

At a conservative rate of €50/hour for skilled operator time, the annual non-infrastructure cost is roughly €1,500–3,000. That still compares favorably with managed Kubernetes if your cluster would otherwise cost €100+/month more. But it narrows the gap significantly.

A failure case that changed how I price "cheap"

I think about cost differently after incidents where one operational problem cancels out a lot of monthly savings:

• registry cleanup that needs blob-level validation before it is safe
• disk pressure caused by slow log/layer drift
• certificate / routing issues that depend on remembering too many special cases

Those are not arguments *against* Hetzner. They are arguments for pricing operator clarity into the platform choice.

The costs I think about beyond the invoice

Cloud cost discussions get distorted when they only compare monthly server prices. For me, the real question is broader:

• how many operator hours will this platform consume each month?
• how expensive is a networking mistake or a slow incident response?
• how much complexity is the team adding just to save money on compute?

Sometimes Hetzner still wins easily. Sometimes the operational overhead narrows the gap more than people expect.

Decision matrix: when Hetzner makes sense vs when it does not

Situation	Hetzner self-managed k8s	Managed k8s (GKE/EKS/DOKS)
Small team, cost-sensitive, strong Linux skills	✅ Strong fit	❌ Likely overpaying
First-time Kubernetes operator	❌ High risk	✅ Better starting point
Need hyperscaler-native services (Lambda, RDS, BigQuery)	❌ Wrong provider	✅ Use that provider
Compliance requires specific certifications (FedRAMP, etc.)	❌ Not available	✅ Choose certified provider
Moderate, stable workloads with predictable scaling	✅ Excellent fit	⚠ Fine but more expensive
Rapid unpredictable scaling (viral traffic)	⚠ Manual scale-up lag	✅ Autoscaling built in
Global multi-region with sub-50ms latency	⚠ Limited datacenters	✅ Global POP coverage
Long-running stateful batch jobs with ARM64 compute	✅ cax series is fast	❌ ARM64 on AWS/GCP is limited

When I would use Hetzner

I would seriously consider Hetzner when:

• the workloads are moderate in scale
• the team values cost efficiency and is willing to earn it with operational discipline
• the architecture does not depend heavily on hyperscaler-native services
• the operators are comfortable with Linux and networking
• the platform can stay relatively simple

In that situation, Hetzner can feel refreshingly direct and honest.

When I would not use Hetzner

I would choose a different path if:

• the organization needs extensive managed services immediately
• compliance or governance requirements strongly favor a different provider
• the team is not ready to own cluster operations
• the workload would be better served by a simpler platform than Kubernetes
• global multi-region complexity is a day-one requirement

Sometimes the smartest infrastructure decision is not to use Kubernetes at all. A simpler deployment model is often the better business choice.

My quick decision checklist now

If I had to choose again quickly, I would ask these in order:

1. Do I actually need Kubernetes, or just a reliable deployment target?
2. Do I have someone who can explain the node-IP, firewall, backup, and upgrade story without hand-waving?
3. Is the workload stable enough that Hetzner's lower invoice will really matter over a year?
4. Will one avoided managed-cloud feature later cost me more in custom ops work than I saved?

My practical decision rule

If a small team can clearly explain its node strategy, network model, restore path, and upgrade routine, Hetzner is a serious option. If those answers are fuzzy, then the cheap invoice may hide a platform the team is not actually ready to operate.

That is why I do not treat Hetzner as a universal recommendation. I treat it as a strong option when the team wants control and is honest about responsibility.

The honest conclusion

Kubernetes on Hetzner is powerful when you want control, reasonable performance, and lower recurring cost. It is a poor fit if you want to avoid operational responsibility.

That is the tradeoff in one sentence: you save money and keep flexibility, but you must earn reliability through disciplined configuration and maintenance.

For me, that trade has been absolutely worth it. My cluster costs ~€55/month and handles real production traffic, including latency-sensitive ad-serving workloads that need sub-100ms response times. That would cost three to five times more on a managed platform with comparable performance.

The key is being honest about what the platform gives you, what it does not give you, and what your team is realistically prepared to operate.

What I'd do differently now

If I were writing the first cost memo again, I would include two explicit footnotes:

1. "cheap compute does not mean cheap incidents"
2. "platform fit is a people/skills question as much as a pricing question"

Those two clarifications would have made the recommendation more honest from day one.

Series note

This closes the first six-part Kubernetes-on-Hetzner series on MisLinux. I wanted the final article to be deliberately honest rather than promotional, because platform choice only becomes useful when the tradeoffs are written down as plainly as the benefits.

The series continues with two later articles covering monitoring and multi-architecture image management. The full series index is available on the Series Index page.