Add cloud servers

To add cloud capacity, add one worker pool to your Cluster resource, pick a machine type and a region, and apply. A worker pool is one machineDeployments entry. Syself Autopilot then requests the machines, installs Syself Linux , and joins them to the workload cluster.

Prerequisites#

• Access to the management cluster Syself runs for you (or your GitOps repository that syncs to it).
• An existing Cluster object. If you have not created one yet, start with creating your first cluster .

Add a machine deployment#

Add an entry to spec.topology.workers.machineDeployments. Each entry is one pool, with a single machine type and a unique name that shows up in the machine names in Hetzner.

		apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: mycluster
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["10.128.0.0/12"]
    pods:
      cidrBlocks: ["192.168.0.0/16"]
    serviceDomain: "cluster.local"
  topology:
    classRef:
      name: hetzner-apalla-1-36-v2
    version: v1.36.3
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: workeramd64hcloud
          name: md-0
          replicas: 5
          failureDomain: nbg1
          variables:
            overrides:
              - name: workerMachineTypeHcloud
                value: cpx42
        - class: workeramd64hcloud
          name: md-1
          replicas: 3
          failureDomain: nbg1
          variables:
            overrides:
              - name: workerMachineTypeHcloud
                value: cx53
	

class: workeramd64hcloud is the fixed class for x86 cloud workers. Every cloud pool uses it and the same underlying node image, so only name, replicas, failureDomain, and the workerMachineTypeHcloud override change between pools.

Because a pool carries a single machine type, you create a separate machine deployment for every type you want to run. The example above runs five cpx42 machines and three cx53 machines. You can define as many pools as you like and scale them independently .

Pick the machine type#

We support all Hetzner Cloud types with at least 4 GB of RAM, shared or dedicated vCPU:

• CPX (Regular): the balanced default. For control planes, use at least a CPX32 (4 vCPU / 8 GB); CPX42 gives most clusters better headroom.
• CCX (Dedicated): dedicated vCPU for latency-sensitive or CPU-bound workloads.
• CX (Cost-optimized): cheapest, but older hardware with limited availability and variable performance.

For the machine types you can pick from, see Server types and sizing .

Set the region#

The region variable sets where your infrastructure lives. All control-plane nodes stay in one region. A machine deployment's failureDomain picks a specific location (a zone) inside that region.

		spec:
  topology:
    variables:
      - name: region
        value: nbg1
	

Hetzner has regions in the EU (Germany and Finland), the US, and Singapore.

Worker nodes can run in different locations. The single-region rule is only about the control plane, so you can place worker pools wherever your workload needs them. Cross-region traffic pays for the distance, though: pods on workers in different regions talk with noticeably higher latency than same-region pods, so keep chatty workloads together.

For real resilience across locations, do not stretch one cluster. Run separate clusters in different locations or regions and fail over between them, or run active-active at the workload level.

A region can still put two machines on the same physical host. To spread a pool's machines across separate hosts, so one hardware failure cannot take out more than one at a time, see Spread nodes with placement groups .

Apply and watch the machines come up#

		$ kubectl get machines -w
	

Scale by changing replicas#

To grow or shrink the pool, change replicas and re-apply. See Scale a node pool for what happens on scale-up and scale-down, or Autoscale a cluster to let the autoscaler do it.

When to add a second pool instead#

Add another machine deployment rather than resizing an existing one when you need a different machine type, a different role or label, or a different failure domain. One pool is one class and one type, so any of those differences is a new pool. To give a pool an identity your workloads can target, add a metadata.labels block to its machine deployment. Label nodes and assign roles walks through it. For control-plane sizing and count, see High-availability control plane .