Servers and nodes
This is where you add machines to your clusters and keep them running, on your own Hetzner account. Syself Autopilot manages the machines. You decide how many, what kind, and what runs on them.
What a node is#
A node is a real Hetzner machine that has joined your Kubernetes cluster and runs your workloads. Syself Autopilot installs Syself Linux on it, joins it to the cluster, and keeps it in the shape your Cluster resource declares. You never install an operating system by hand, and you never patch one in place.
Syself Autopilot also watches every node. If a node fails a health check and cannot recover on its own, Syself Autopilot repairs or replaces it, with no action from you. See Self-healing and node replacement .
Cloud VMs and bare metal#
Hetzner Cloud gives you virtual machines you can add and remove in seconds. Hetzner bare metal gives you dedicated physical servers with local disks, at the best price for steady load. You can run either, or both in one cluster .
| Hetzner Cloud | Bare metal | |
|---|---|---|
| Capacity model | Add and remove servers on demand | A fixed pool of servers you already own |
| Node ready in | A few minutes | A few minutes |
| Storage | Hetzner Cloud volumes (network) | Local disks, best for databases |
Both start the same way: Syself Autopilot writes the sealed OS to the server from the Hetzner rescue system, then the node joins the cluster. The only difference is how Syself Autopilot gets the machine. To add cloud capacity, see Add cloud servers . To use your own hardware, see Add bare-metal servers .
Pools are the unit of capacity#
You do not add machines one at a time. You declare a pool: one machineDeployments entry in your Cluster resource, with a class, a machine type, and a replica count. Syself Autopilot turns that pool into Machines, and each Machine into a Node.
flowchart LR C["Cluster<br/>resource"] -->|declares| P["Pool<br/>one machineDeployments entry"] -->|creates| M["Machines"] -->|becomes| N["Nodes<br/>real Hetzner servers"]
To grow or shrink capacity, change the replica count and re-apply. Everything else builds on the pool, so start with Node pools and machine deployments .
You send objects to a central API#
You manage your cluster the way Kubernetes works: you declare the end result you want, and the platform makes it real. You do not send those objects (Cluster, Machine, HetznerBareMetalHost) to your own workload cluster. You send them to a central API that manages the infrastructure. That API is itself a Kubernetes cluster, the management cluster Syself runs for you, so your normal kubectl and Kubernetes tooling work against it.
So some commands target the management cluster, and some target your workload cluster. Each page says which.
| Target the management cluster to | Target your workload cluster to |
|---|---|
Edit a pool, annotate a Machine | Drain a node, read node conditions |
Tip
If the management cluster is unreachable, your workload cluster keeps serving traffic. Syself needs the management cluster only to provision new nodes, roll an upgrade, or replace a failed machine.
For the full model, see Declarative cluster management and Management and workload clusters .
The sealed OS means replace, not patch#
Syself Linux is read-only and dm-verity sealed. You cannot install a package, edit /usr or /etc, or load a kernel module on a running node. When something needs to change, Syself Autopilot replaces the node from a fresh image instead of changing it in place. That one rule shapes the maintenance, customization, and debugging pages, so read What you can and cannot change on a sealed node early.
Where to go next#
- Provision capacity
- Add GPU nodes
- Node pools and roles
- Scheduling controls
- Node taints
- Node OS and customization
- Node maintenance
- Access, debug, and troubleshoot
- Multi-client and fleet
For the machine types you can pick from, see Server types and sizing . For why running your own machines beats a managed control plane, see bare-metal Kubernetes .