Run a single-writer workload on block storage

A rolling Deployment update on a ReadWriteOnce (RWO) volume deadlocks as soon as the new pod lands on a different node: the old pod still holds the volume, so the new pod cannot attach and never starts. ReadWriteOnce means the volume mounts on one node at a time, so only pods on that same node can share it. When pods on different nodes need the same files, you need shared storage (RWX) or replication in the app, not one block volume. A StatefulSet or a Deployment with strategy: Recreate gets around this, because both retire the old pod before the new one claims the volume.

This page is for a single-writer application that is not a database, or a dev or staging instance kept simple. A production database belongs on local NVMe under an operator , which handles replication and backups for you, not on a single block volume behind one pod.

Use a StatefulSet#

A StatefulSet is built for this. It replaces pods one at a time, terminating the old pod before creating its replacement, so the volume is free when the new pod attaches. Its volumeClaimTemplates also gives each replica its own PersistentVolumeClaim (PVC), the object a pod uses to claim a disk, with no shared handle to fight over.

		apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: writer
spec:
  serviceName: writer
  replicas: 1
  selector:
    matchLabels:
      app: writer
  template:
    metadata:
      labels:
        app: writer
    spec:
      containers:
        - name: writer
          image: my-app:1.0
          ports:
            - containerPort: 8080
          volumeMounts:
            - name: data
              mountPath: /data
          readinessProbe:
            tcpSocket:
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 5
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: instance.hetzner.cloud/is-root-server
                    operator: NotIn
                    values:
                      - "true"
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        storageClassName: standard
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi
	

The node affinity keeps the pod on cloud nodes, where a Hetzner Cloud volume can attach. Bare metal and control-plane nodes cannot hold one. See Volume attach constraints and reclaim policies .

The readiness probe matters here. It holds traffic back until the app has opened its port on the reattached volume, so clients do not hit a pod that is still mounting its disk.

Or a Recreate Deployment#

When you want a Deployment, set strategy: Recreate. It stops every old pod before starting any new one, which sidesteps the RWO deadlock at the cost of a brief downtime during each rollout.

Unlike a StatefulSet, a Deployment has no volumeClaimTemplates, so you create the PVC yourself and reference it by name. It needs the same node affinity too, or the pod can land on bare metal where the volume cannot attach:

		apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: app
spec:
  replicas: 1
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: app
  template:
    metadata:
      labels:
        app: app
    spec:
      containers:
        - name: app
          image: my-app:1.0
          volumeMounts:
            - name: data
              mountPath: /data
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
              - matchExpressions:
                  - key: instance.hetzner.cloud/is-root-server
                    operator: NotIn
                    values:
                      - "true"
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: app-data
	

Plan for the reattach gap#

Syself Autopilot reprovisions nodes during upgrades, scaling, and self-healing. When the node under your pod is drained, the volume detaches and reattaches to the pod's new node, so the data follows the workload, but there is a short gap while that happens. A single writer means the app is briefly unavailable during the handoff. This is expected, not a failure.

Because the volume already exists, it pins the pod to its Hetzner location through a volume node affinity, so the pod can only start where the volume is. See Access modes and volume binding for why the existing volume leads the pod.

When you need to survive a node event with no outage, one volume behind one pod is not enough. Run replication at the application level instead, with several replicas each holding their own copy, so another replica keeps serving while one reattaches. That is a different storage decision: Choose storage for a workload weighs single-writer block storage against replicated local disks.

For the data this workload holds, plan Disaster recovery for stateful workloads next.