K3s on Hetzner: What to Trust and Isolate

Running K3s on Hetzner is the cheapest credible path to real Kubernetes: a lightweight, fully-conformant distribution on Europe’s best price-to-performance hardware. The tradeoff is that bare metal means you own every security boundary a managed cloud would handle for you. Trust the things Hetzner actually guarantees, isolate everything else, and the savings are real without the footguns.

The mistake that bites self-hosters is assuming a private network or a default install gives you the isolation a managed Kubernetes service provides. It does not. On Hetzner you are the platform team, and the boundaries are yours to draw.

Why self-hosted Kubernetes needs a trust model

Managed Kubernetes (EKS, GKE) hides a lot of security work: the control plane is hardened for you, the network has sane defaults, backups of the control-plane datastore are handled. You pay for that, both in money and in lock-in.

Self-hosting on Hetzner removes the cost and the lock-in, and hands you the responsibility. Every boundary the managed service drew silently is now a boundary you must draw explicitly, or it does not exist. Getting the trust model right is the difference between a cheap, solid cluster and a cheap, exposed one. This post is part of the Kubernetes operations series, alongside Kubernetes Namespace Strategy for SaaS Platforms and Readiness Probes That Don’t Lie.

Is K3s production-ready on Hetzner?

Yes. K3s is a CNCF-conformant Kubernetes distribution, just packaged lean: a single binary, a lighter default datastore, and trimmed-down components. On Hetzner it runs production workloads well, as long as you own the parts Hetzner does not manage, namely the firewall, the network boundary, datastore backups, and node hardening.

The performance and cost story is the draw. Hetzner’s dedicated and cloud servers offer some of the best price-to-performance available, which is exactly why cost-conscious teams self-host there.

Is the Hetzner private network safe to trust?

No, not as a security boundary. The Hetzner private network (vSwitch / private cloud networks) is a convenience for routing internal traffic, not a guarantee of isolation. Do not assume traffic on it is automatically protected or that a private IP means a safe surface. Layer a firewall on top, and encrypt sensitive traffic in transit.

This is the single most common self-hosting misconception: “it’s on the private network, so it’s fine.” A private network reduces exposure; it does not replace a firewall, network policy, or encryption. Treat private connectivity as a routing tool and build your real boundaries explicitly on top of it.

What should you isolate when running K3s on Hetzner?

Isolate four things: the Kubernetes API server (bind it to a private interface, never the public one by default), node-to-node and control-plane traffic (behind Hetzner Cloud Firewalls), pod-to-pod traffic (default-deny with NetworkPolicy), and your etcd/datastore backups (stored off the cluster). The public surface should be exactly what you choose to expose, and nothing more.

A practical isolation layering:

• Hetzner Cloud Firewall at the edge: deny everything inbound except the ports you actually serve, and the admin access you need (ideally over a VPN, not the open internet).
• API server binding: the Kubernetes API should not be reachable from the public internet by default. Bind it privately and reach it over a VPN or a tunnel.
• NetworkPolicy default-deny: as with any cluster, pods can talk to each other freely until you say otherwise. A default-deny policy per namespace makes the in-cluster network a real boundary, the same discipline covered in the namespace-strategy guide.
• Edge in front of the origin: put public services behind a CDN/proxy so origin IPs stay private and TLS terminates at the edge, shrinking the attack surface that ever sees your Hetzner IPs.

K3s vs K8s on Hetzner: which should you use?

For most small-to-medium self-hosted clusters, K3s is the better choice: lighter, simpler to operate, and fully conformant, so your manifests and tooling work unchanged. Reach for full upstream Kubernetes only when you need components K3s trims, or you are operating at a scale and team size that can absorb the extra operational weight.

Factor	K3s	Full K8s (kubeadm)
Footprint	Single lightweight binary	Heavier, more components
Ops complexity	Lower	Higher
Conformance	Full	Full
Best for	Small/medium self-hosted	Large scale, dedicated platform team
Default datastore	Lightweight (SQLite/etcd)	etcd

For a solo operator or small team on Hetzner, K3s hits the sweet spot: you get real Kubernetes without the operational tax of running the full distribution yourself.

How much does K3s on Hetzner cost versus managed Kubernetes?

Dramatically less for the raw infrastructure, which is the whole reason to self-host. A managed Kubernetes service charges a control-plane fee per cluster plus a premium on every node, while Hetzner charges you for the servers and nothing for a control plane you run yourself. For a small cluster, the difference is routinely several times cheaper.

The honest accounting, though, includes the operational cost you take on. Managed Kubernetes bundles the price of a team that patches the control plane, handles upgrades, and manages backups. Self-hosting on Hetzner moves that labor to you, so the true comparison is “Hetzner hardware plus your time” against “managed price minus your time.” For a solo operator or small team comfortable with the operational work, the math strongly favors Hetzner; for a team that would rather buy back that time, managed can be worth the premium.

The decision is therefore not purely financial. Self-host on Hetzner when the savings are large relative to your scale and you are willing to own the platform work this guide describes. Choose managed when your engineers’ time is better spent on the product than on patching nodes. Either way, price the hardware against a managed quote with the operational labor made explicit, rather than comparing sticker prices alone.

A K3s-on-Hetzner hardening checklist

Before you run anything real on it:

• Hetzner Cloud Firewall denies all inbound except deliberately exposed ports.
• The Kubernetes API is not on the public internet; admin access is over VPN.
• A default-deny NetworkPolicy is applied per namespace.
• etcd/datastore is backed up automatically to off-cluster storage, and a restore has been tested.
• Nodes are hardened: no password SSH, minimal packages, automatic security updates.
• Public services sit behind an edge proxy so origin IPs stay private.
• You have an upgrade plan for K3s and the OS; self-hosting means patching is your job.

Should you run a single-node or HA K3s cluster?

Run single-node only for non-critical workloads where downtime during a reboot or failure is acceptable; run a high-availability control plane (an odd number of server nodes, typically three) for anything you cannot afford to have go down with one machine. The choice is a direct tradeoff between cost and your tolerance for a single point of failure.

A single-node K3s cluster is the cheapest and simplest option, and it is genuinely fine for side projects, internal tools, and staging. Its weakness is obvious: that one node is a single point of failure, and when it reboots or dies, the cluster is down. For a solo project that is an acceptable risk; for anything customer-facing it usually is not.

An HA setup runs multiple server (control-plane) nodes with an embedded distributed datastore, so the loss of one node does not take down the cluster. On Hetzner this means paying for at least three servers instead of one, plus a load balancer in front of the API. That is more cost and more to operate, and it is the price of not having a single machine be your whole platform. Decide based on what an outage actually costs you, and remember that whichever you choose, tested off-cluster backups of the datastore are non-negotiable.

What I’d do differently

The lesson self-hosters learn the hard way is treating the private network as security and discovering an exposed API server or an unencrypted internal hop after the fact. The cost savings of Hetzner are real, but they come bundled with responsibilities a managed service quietly handled, and skipping them turns a cheap cluster into a liability.

If I were standing up K3s on Hetzner again, I would draw the trust boundaries before deploying a single workload: firewall first, private API binding, default-deny networking, tested backups. Self-hosting is a great deal precisely when you do the platform-team work that the price excludes, and a poor deal when you pretend that work is optional.

Sources

• K3s documentation: docs.k3s.io
• Hetzner Cloud, Firewalls: docs.hetzner.com/cloud/firewalls
• Kubernetes, Network Policies: kubernetes.io/docs/concepts/services-networking/network-policies