Volume attach constraints and reclaim policies

A Hetzner Cloud volume attaches to one cloud node at a time, and when its PersistentVolumeClaim (PVC) is deleted the underlying volume stays behind. Both facts shape how you run stateful apps on block storage, and the second one keeps costing money until you act on it. A PVC is the object a pod uses to claim a disk.

One writer, one node#

The standard class is ReadWriteOnce (RWO): the volume mounts on a single node, and one pod there writes to it. A second pod on a different node cannot mount the same volume at the same time.

Hetzner attaches at most 16 volumes to one server, so plan for that ceiling on a node that holds many of them.

When a pod moves to another node, during a drain, an upgrade, or a reschedule, the volume detaches from the old node and reattaches to the new one. That handoff is not instant. The new pod stays in ContainerCreating for a few seconds until the detach finishes and the volume attaches where the pod now runs. Plan for this short gap in any workload that holds a volume. Run a single-writer workload on block storage shows how to keep an app healthy across it.

A bound volume also stays in one Hetzner location and pins the pod there through a volume node affinity, so the pod can only schedule where the volume already is; if that location has no room, the pod waits. Access modes and volume binding covers why an existing volume leads the pod rather than the other way around.

Cloud nodes only#

A Hetzner Cloud volume attaches only to cloud worker nodes. It cannot attach to a bare metal server or a control-plane node.

A pod that requests a standard volume but is pinned to a bare metal node stays Pending:

		$ kubectl describe pvc data-db-0
...
Events:
  Warning  ProvisioningFailed  error generating accessibility requirements: no topology key found for node bm-1
	

Keep such pods on cloud nodes with node affinity, as shown in Use Hetzner Cloud volumes . For storage that lives on bare metal, use local disks instead: see Local PV lifecycle .

Retain keeps the volume after the PVC#

The standard class uses the Retain reclaim policy. Deleting a PVC releases the claim but leaves the Hetzner volume and its data in your project, detached and unused.

This is deliberate. Syself Autopilot keeps every storage class on Retain so an accidental kubectl delete pvc cannot destroy your data: the command deletes the Kubernetes object, not the volume or the data behind it. The flip side is that freeing the space, and stopping the bill, is a separate intentional step.

Related: Use Hetzner Cloud volumes , Monitor storage capacity .