Order and prepare a Robot (bare-metal) server
Buy the dedicated server through Hetzner Robot, clear its disks, and find the WWN to install onto. Once that is done, Add bare-metal servers registers the server and attaches it to a cluster.
Note
Syself Autopilot manages the software install and cluster membership. It does not buy, return, or sell hardware. You order the server; Syself Autopilot provisions it.
Order through Hetzner Robot#
Buy the dedicated server in Hetzner Robot. Note the server's numeric ID from its detail page. Add bare-metal servers needs it as spec.serverID on the HetznerBareMetalHost object.
Hetzner has several dedicated-server lines. The AX line runs AMD Ryzen and EPYC CPUs, and other lines run Intel. The server auction sells in-stock and returned machines at a discount, often the fastest way to get a specific build. You can individualize a server with add-ons too, for example a 10 Gbit uplink in place of the standard 1 Gbit NIC. See Hetzner's docs on the server lines, the add-ons, and the 10 Gbit uplink.
Note
Availability varies by location: not every model or add-on can be ordered in every datacenter. Check the location selector on the order page before you commit to a specific build.
For stateful workloads, favor a model with the local NVMe you need, because data on the extra disks survives a reinstall . See bare-metal Kubernetes for why owning the hardware beats a managed control plane.
Account preparation#
Registering a bare-metal server needs your Hetzner account set up first: the hetzner and robot-ssh secrets in the management cluster, and a Robot webservice user. That is a one-time step in Prepare your Hetzner account .
Clear factory RAID first#
Newly purchased Hetzner dedicated servers ship with RAID enabled by default. Sealed nodes install onto plain disks, and the provisioner refuses to install while a disk carries RAID or a foreign OS. It does not wipe for you, so clear the disks in the Hetzner rescue system before you register the server: see Wipe a disk .
Before installing, Syself Autopilot checks the target disk and the rest of the server. It refuses to install in four cases:
- Any disk in the server carries a RAID member signature or an assembled RAID array.
- More than one disk reports the same WWN as the target, so the target is ambiguous.
- The target disk holds an LVM (Logical Volume Manager, a Linux tool for flexible disk partitioning) physical volume.
- Another disk in the same server holds a Linux installation.
Any of these can mean the server is still in use, or the target disk is not what you think it is. Syself Autopilot stops rather than risk wiping the wrong disk. Wiping is a one-time step you do once, at purchase, not something the platform does on its own, so a forgotten setting can never turn an OS disk into a wiped data disk later.
Find the disk WWN#
Syself Autopilot installs onto the disk you name by its WWN. The WWN (World Wide Name) is a stable hardware ID for a disk, so it always points to the same disk. There are two ways to get it.
Read it in the rescue system. Boot the server into the Hetzner rescue system (a small Linux that Hetzner boots over the network). The wwn-* symlinks under /dev/disk/by-id/ are the reliable source, because the WWN column in lsblk is often blank in rescue:
$ ls -l /dev/disk/by-id/ | grep -E 'wwn|nvme'
Or let the inventory pass surface it: register the HetznerBareMetalHost without rootDeviceHints. Syself Autopilot boots the server into rescue, collects the hardware inventory, and then stops with an error because no disk was specified (this is expected). Read the WWN from the inventory and re-apply with it set:
$ kubectl describe hetznerbaremetalhost <name>
Look under Hardware Details → Storage for the disk and its WWN.
Single-disk vs multi-disk servers#
- Single-disk server: there is one WWN; use it.
- Multi-disk server: choose the disk you want the OS installed onto and use its WWN. The remaining disks become data disks, which survive reinstalls and are where stateful workloads should live.
Before touching the disk, Syself Autopilot runs machine-level checks in the rescue system. Any failure here stops the install before anything is written:
- The required tools are present.
- The target disk resolves from its WWN, exists, and is large enough (at least about 24 GiB).
- A short read-speed test passes (at least 20 MiB/s for an HDD, 40 MiB/s for an SSD or NVMe). A disk below the floor stops the install.
- On NVMe disks, a SMART health read runs. It is advisory and does not stop the install on its own.
It installs both a UEFI and a legacy-BIOS bootloader, so the rescue system's firmware mode does not gate the install.