Storage on Syself Autopilot runs on hardware you own. Your data sits on Hetzner Cloud volumes or on the disks inside your own bare metal servers . Kubernetes stores that data in a PersistentVolume (PV), which a pod claims through a PersistentVolumeClaim (PVC), and a StorageClass decides which backend fills the claim.

Most workloads that need storage are a database, and for a database the answer is short: run it on local NVMe on bare metal, under a Kubernetes operator. It is the fastest and usually the cheapest option, and most teams never weigh the rest. Set up local NVMe with TopoLVM is the how, and Choose storage for a workload makes the call. The four backends below are the full map for everything that is not a database.

Block, local, shared, or object#

Block storage uses Hetzner Cloud volumes. A volume attaches over the network to one cloud server at a time, holds a single writer, and outlives the node it was attached to. Hetzner stores each volume on Ceph and keeps three copies, so a cloud volume is durable on its own, which a local disk is not. Two limits shape how you use it: a volume attaches only to a cloud server, never to bare metal, and Hetzner allows at most 16 volumes on one server. Because the access mode is ReadWriteOnce, only pods on the same node can share a volume; when pods on different nodes need the same files, that is what shared storage is for. See Use Hetzner Cloud volumes .

Local storage is the disks physically inside a bare metal server, NVMe, SSD, or HDD, reached through TopoLVM. Reads and writes skip the network, so it is the fastest disk on the platform. The data stays on one server and has no redundancy of its own, so it suits workloads that keep their own copies. In practice this is where most production databases belong, run by a Kubernetes operator that handles replication and backups. See Set up local NVMe with TopoLVM and Choose storage for a workload .

Shared storage lets pods on different nodes write the same directory at once, the ReadWriteMany access mode, through JuiceFS or NFS. For sharing data across pods, object storage is usually the better answer; a shared filesystem is the fallback for an app that needs real file semantics and cannot use the S3 API. See ReadWriteMany with JuiceFS and Choose an RWX backend .

Object storage serves buckets over the S3 API for uploads, artifacts, and backups. Run SeaweedFS as your own S3 store, or point workloads at any S3-compatible endpoint. See Run SeaweedFS .

Data does not follow a replaced node#

Syself Autopilot treats nodes as replaceable. During a Kubernetes upgrade, a scale-down, or a self-healing event, a node can be drained and rebuilt. What that means for your data depends on where it lives:

• A Hetzner Cloud volume detaches from the old node and reattaches to the new one, so the data survives and follows the workload.
• Local disk data stays on the physical server. It survives a reprovision of that same server, but it does not move when the workload lands on a different server.
• Object and shared storage keep data off the node entirely, so node replacement never touches it.

Pick storage by this behavior first. Choose storage for a workload walks through the decision, and Data survival across reprovision covers the local case in detail.

How a CSI driver puts a volume in your pod#

A CSI driver turns a PVC into a real disk. When a pod claims a volume, the driver provisions it, attaches it to the pod's node, and mounts it into the container. When the claim is deleted, the driver detaches the volume and either keeps or removes it, following the StorageClass reclaim policy.

The hcloud driver for block storage ships built in. It configures itself when you claim a volume, so the standard StorageClass works the moment your cluster starts, with nothing to set up.

TopoLVM for local disks, JuiceFS for shared filesystems, and SeaweedFS for object storage are open-source drivers you install yourself. They are not enabled by default because each has many configuration options and no single default fits every cluster. Each page walks the setup in detail, so running them stays simple. If you would rather not run them yourself, the Syself Consulting team can set them up, share best practices, or run them for you as a full service.

Where to go next#

• Access modes and volume binding
• Storage classes reference
• Choose storage for a workload