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](/docs/hetzner/apalla/concepts/internals/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](/docs/hetzner/apalla/concepts/operations/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](/docs/hetzner/apalla/servers-and-nodes/pools/mix-cloud-and-bare-metal).

|                | 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](/docs/hetzner/apalla/servers-and-nodes/provision/add-cloud-servers). To use your own hardware, see [Add bare-metal servers](/docs/hetzner/apalla/servers-and-nodes/provision/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.

```mermaid
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](/docs/hetzner/apalla/servers-and-nodes/pools/node-pools-overview).

## 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](/docs/hetzner/apalla/concepts/foundations/declarative-cluster-management) and [Management and workload clusters](/docs/hetzner/apalla/concepts/foundations/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](/docs/hetzner/apalla/servers-and-nodes/node-os/what-you-can-change-on-a-sealed-node) early.

## Where to go next

- [Provision capacity](/docs/hetzner/apalla/servers-and-nodes/provision/add-cloud-servers)
- [Add GPU nodes](/docs/hetzner/apalla/servers-and-nodes/provision/gpu-nodes)
- [Node pools and roles](/docs/hetzner/apalla/servers-and-nodes/pools/node-pools-overview)
- [Scheduling controls](/docs/hetzner/apalla/servers-and-nodes/scheduling/node-affinity-and-selectors)
- [Node taints](/docs/hetzner/apalla/servers-and-nodes/scheduling/apply-taints)
- [Node OS and customization](/docs/hetzner/apalla/servers-and-nodes/node-os/what-you-can-change-on-a-sealed-node)
- [Node maintenance](/docs/hetzner/apalla/servers-and-nodes/maintenance/machine-health-checks-and-remediation)
- [Access, debug, and troubleshoot](/docs/hetzner/apalla/servers-and-nodes/access/debug-a-node)
- [Multi-client and fleet](/docs/hetzner/apalla/servers-and-nodes/fleet/dedicate-node-pools-per-client)

For the machine types you can pick from, see [Server types and sizing](/docs/hetzner/apalla/reference/server-types-and-sizing). For why running your own machines beats a managed control plane, see [bare-metal Kubernetes](/docs/hetzner/apalla/concepts/internals/bare-metal-and-cloud).