Choosing the right server type is an important part of sizing a Syself Autopilot cluster. The right choice depends on what the node is running, how much CPU and memory it needs, and whether the workload requires dedicated or shared CPU resources.

This page explains the Hetzner Cloud server families available for your cluster and how to choose an appropriate size for control-plane and worker nodes. It also covers why bare-metal and GPU servers sit outside these families, how to change the server type later, and where to find the current Hetzner server types and their specifications.

## The three cloud server families

The server family matters as much as the size:

| Family  | vCPU      | Use it for                                                                                                                                          |
| ------- | --------- | --------------------------------------------------------------------------------------------------------------------------------------------------- |
| **CPX** | shared    | the balanced default, and the default type for both pools                                                                                           |
| **CCX** | dedicated | steady, latency-sensitive workloads that cannot share a vCPU with other tenants                                                                     |
| **CX**  | shared    | the cheapest family, on older hardware with variable performance and limited availability. Fine for a tolerant burst pool, never for control planes |

Bare-metal servers have no type variable. You choose the hardware when you order the server from [Hetzner Robot](/docs/hetzner/apalla/servers-and-nodes/bare-metal/order-and-prepare-a-robot-server), then [add it to a cluster](/docs/hetzner/apalla/servers-and-nodes/bare-metal/add-bare-metal-servers). There is no Hetzner Cloud GPU type either: GPU servers are bare metal, covered in [Add GPU nodes](/docs/hetzner/apalla/servers-and-nodes/gpu/gpu-nodes).

For choosing the right cluster size based on your workload and budget, see [Size a cluster for cost](/docs/hetzner/apalla/servers-and-nodes/fleet/size-a-cluster-for-cost).

## Choosing a type for the control plane

The control plane runs `kube-apiserver`, `etcd`, and the scheduler. These processes are CPU and memory intensive when you have many nodes, many objects in the cluster, or high API request rates.

Start with a type that gives the control plane at least 4 GB of RAM dedicated to the Kubernetes components. After the system processes, reserved memory, and etcd are accounted for, a `cpx32` (8 GB total) has roughly 4 to 5 GB left. For clusters with more than 20 nodes, consider `cpx41` (16 GB RAM) or larger.

Control planes run with a `NoSchedule` taint, so your workload pods do not land on them. You do not need to size for workloads, only for the Kubernetes control-plane processes. For how many control planes to run, see [High-availability control plane](/docs/hetzner/apalla/clusters/configure/high-availability-control-plane).

## Choosing a type for workers

Workers run your application pods. The main inputs are:

- **Workload memory and CPU.** Add up the resource requests in your pods and compare them to the node's allocatable capacity. Some of each node's memory and CPU is set aside for the operating system and the Kubernetes agents, and the scheduler cannot place pods on that reserved part. See [Node resources and limits](/docs/hetzner/apalla/servers-and-nodes/pools/node-resources-and-limits) for the reserved amounts and the pod limit per node.
- **Pod churn.** Nodes with very high pod turnover (many short-lived pods) benefit from more CPU. The container runtime and the kubelet use CPU on every pod start and stop.

A `cpx32` (4 vCPU / 8 GB) is a common starting type for small to medium workloads. For workloads with higher memory requirements, `cpx41` (8 vCPU / 16 GB) or `cpx51` (16 vCPU / 32 GB) are typical next steps.

## How to change the type

Change the `controlPlaneMachineTypeHcloud` or `workerMachineTypeHcloud` variable on the `Cluster` object. Syself triggers a rolling replacement: new nodes come up with the new type, old nodes are drained and deleted. For how the drain affects your workloads, see [Plan maintenance and prechecks](/docs/hetzner/apalla/clusters/upgrades/plan-maintenance-and-prechecks).

For bare-metal nodes, you cannot resize in place. Add a server of the new type to your Hetzner Robot account, label it for the cluster, then drain and remove the old server.

> [!WARNING]
> Changing the control-plane type triggers a rolling replacement of the control-plane nodes. etcd quorum (the minimum number of etcd members required to agree on changes) is maintained throughout if you have three replicas, but the process takes several minutes per node.

## Hetzner Cloud server type reference

For the full and current list of available Hetzner Cloud server types, their vCPU counts, RAM, and pricing, see the [Hetzner Cloud pricing page](https://www.hetzner.com/cloud). The Cluster Stack accepts any valid type name from that list, so new types work as soon as Hetzner makes them available in your region.

## Related

- [Node resources and limits](/docs/hetzner/apalla/servers-and-nodes/pools/node-resources-and-limits)
- [Cluster variables reference](/docs/hetzner/apalla/reference/cluster-variables)
- [Manage HCloud servers](/docs/hetzner/apalla/servers-and-nodes/cloud/add-cloud-servers)
- [Add bare-metal servers](/docs/hetzner/apalla/servers-and-nodes/bare-metal/add-bare-metal-servers)
- [Run GPU workloads](/docs/hetzner/apalla/workloads/specialized/run-gpu-workloads)
- [Bare metal and cloud](/docs/hetzner/apalla/concepts/internals/bare-metal-and-cloud)