Node pools
A cluster’s worker nodes come from node pools, and the first question about any pool is its source: where do the machines come from?
- Managed — PaaSbox orders on-demand servers in your Hetzner project, at current prices.
- Pooled — the pool draws from your fleet of adopted servers, at the price each server already has — grandfathered, if you adopted before rescaling or deleting it.
That one choice determines everything else about how the pool behaves.
Managed pools: cattle
Section titled “Managed pools: cattle”Managed nodes are interchangeable. Kubernetes (and PaaSbox) may delete and recreate them at any time — on upgrades, on scale-down, on node failure. That’s not a bug; it’s what makes them elastic:
- Resize freely. Set minimum and maximum node counts; the autoscaler moves within them.
- Scale to zero. A minimum of 0 means an idle pool costs you nothing at Hetzner.
- Change server type. Swap
cpx32forcpx42and the pool rolls onto the new type. - Pick your shape. Any supported Hetzner Cloud server type; nodes get public IPs today (private-only pools behind a NAT gateway are planned).
The trade-off: every replacement node is a new order at current Hetzner prices. Managed pools are for burst and for workloads that don’t have a grandfathered rate to protect.
Pooled pools: pets
Section titled “Pooled pools: pets”Pooled nodes are named, long-lived machines — your machines. The constraint is the value:
- Never deleted. Rebuilt in place on upgrades and repairs; released back to your fleet when a cluster lets them go. The delete path doesn’t exist — structurally.
- Grow horizontally only. A pooled pool is capped at the number of Ready servers in the backing fleet group (same server type, same location). Want a bigger pool? Adopt more servers.
- No resize, no minimum, no scale-to-zero. You own the machines either way; an unused pooled server still bills at Hetzner (at its old rate). “Scaling down” means releasing servers to your fleet, not destroying them.
In the console, the actions a pooled pool doesn’t offer — resize, scale-to-zero, delete — are shown greyed out with the reason, not hidden: never deleted, keeps your price is exactly what you’re paying for.
Mixing pools in one cluster
Section titled “Mixing pools in one cluster”The recommended production shape is both at once:
- a pooled baseline over your grandfathered fleet — your cheap, steady capacity, and
- a managed burst pool with
min 0— elastic headroom at current prices.
The autoscaler fills your pooled nodes first and only spills to on-demand nodes when the pool is full; when load drops, the managed pool scales back to zero and your baseline keeps running at the old rate. One cluster, one flat PaaSbox fee, two sources.
Day-2 behavior
Section titled “Day-2 behavior”| Managed | Pooled | |
|---|---|---|
| Kubernetes / OS upgrade | node replaced (new order, current price) | rebuilt in place (price-safe) |
| Node failure | replaced automatically | repaired / rebuilt in place |
| Hibernate | nodes deleted; recreated on wake at current prices | servers released to your fleet; re-claimed on wake |
| Cluster deleted | nodes deleted | servers return to your fleet, price intact |
| Pool removed | nodes deleted | servers return to your fleet, price intact |
The one caveat worth repeating: a hibernate/wake cycle recreates managed nodes at current prices — only pooled servers carry a protected rate. If a price matters, adopt the server that holds it.
Where the money shows up
Section titled “Where the money shows up”Node pools are entirely on the Hetzner side of the two bills: every node — managed or pooled — lives in your Hetzner project and is billed by Hetzner to you directly. PaaSbox’s flat per-cluster fee doesn’t change with node count or pool shape; fair use bounds the extremes.