Private clusters
A private cluster is one where no worker node owns a usable public address. Cloud workers get no public IP; dedicated servers stop using theirs. Every outbound packet leaves through one NAT gateway per cluster that lives in your Hetzner project, is created and retired by the platform, carries a mandatory host firewall, exports metrics and logs, and can enforce an allow-list of where your cluster may talk to.
Inbound traffic is unchanged: your load balancers keep working, they simply target private node addresses. The control plane reaches nodes over an outbound tunnel either way, so private nodes lose nothing.
- A stable egress identity. Partners, payment providers and databases outside the cluster see one address, which you can allow-list on their side. Node rolls and autoscaling do not change it.
- A smaller attack surface. No public port on any worker; SSH only from networks you list.
- Control over what leaves. An allow-list of destinations, by network or by name, with an audit mode that logs what would be blocked before you enforce anything.
What you set
Section titled “What you set”| Setting | What it does |
|---|---|
| Egress: public or private | cluster-wide; a private cluster has no pool with public addresses |
| Gateway server type | the Hetzner type the gateway runs on; validated against what your datacentre sells |
| SSH allowed from | networks that may reach port 22 on the gateway and on your nodes; empty means none |
| Allow-list: networks, names, mode | destinations your cluster may reach; audit logs and counts without blocking, enforce blocks |
| Logging | dropped packets and denials are logged by default; per-connection flow logs are optional; both go to a collector you name in your network |
| Metrics allowed from | networks allowed to poll the gateway’s metrics from outside, behind TLS and basic auth |
Destinations the cluster needs to function — the platform’s own endpoints, the registries the system components pull from, NTP and the resolvers — are always allowed; your list can only add.
What the gateway does for the nodes
Section titled “What the gateway does for the nodes”The gateway is the nodes’ DNS resolver. What it allows by name is, by construction, exactly what it told the nodes, so a name that resolves to changing addresses behind a CDN keeps working. A worker that boots reaches the gateway first, before anything else.
The gateway’s lifecycle
Section titled “The gateway’s lifecycle”- Image. Debian 13 by default, Ubuntu 24.04 available. The gateway upgrades every package once at first boot, installs security updates daily, and reboots only at the start of your maintenance window, jittered so clusters that share a window do not reboot in the same minute. A reboot costs the cluster about half a minute of outbound connectivity; nodes do not go NotReady.
- Replacement, not patching. When a newer gateway image is pinned, a replacement is built and the route moves to it inside your maintenance window; the blip is the route move, about fifteen seconds. You can trigger the replacement earlier from the cluster page.
- Self-healing. The platform probes the gateway through your cluster every 30 seconds. A gateway that stops answering is marked in the console; after two minutes it is powered on if off or hard-reset if hung, and after six minutes it is replaced — measured at 22 seconds to mark, under three minutes to reset, about four minutes to heal. All of it stays inside the ten-minute window after which Kubernetes would start replacing the workers themselves.
- Cost. The gateway is one small Hetzner server in your project, on your Hetzner bill, plus one public IPv4 address.
Metrics, logs, alerts
Section titled “Metrics, logs, alerts”The gateway exports its metrics on its private address; a production cluster’s monitoring stack scrapes them and alerts on a gateway that is down, a firewall that is not enforcing, a connection table above 80 %, denials and a stale allow-list. Any Prometheus you run in the cluster can scrape the same endpoint. Log lines never reach the platform — they are forwarded to the collector you name, inside your network. See monitoring & alerts.
Dedicated servers in a private cluster
Section titled “Dedicated servers in a private cluster”Dedicated (Robot) servers join a private cluster over the vSwitch and use the cluster’s gateway as their route and resolver; their public interface stays configured but carries no default route. Dedicated node pools are available on request during onboarding.
Bring your own network
Section titled “Bring your own network”If you already run a Hetzner network with your own NAT, attach the cluster’s workers to it instead: the platform never creates or deletes that network, only adds the workers’ subnet. A cluster on your network does not get a platform gateway; your NAT is the egress.
Switching an existing cluster
Section titled “Switching an existing cluster”Switching a cluster between public and private egress replaces every worker node — on-demand nodes are re-ordered, adopted servers are rebuilt in place, dedicated servers re-onboard. The console asks for an explicit confirmation and names the blast radius before it starts.