Data-disk encryption protects the local disks under your persistent volumes, so a stolen or decommissioned disk reveals nothing. It matters most on bare metal: a disk that fails and goes back to Hetzner for RMA, or a single-tenant server you decommission, should not carry readable data off-site. Today this is a design you follow by hand, not a product you turn on, and this page covers both the recommended design and the manual steps.

What is and is not encrypted by default#

PersistentVolumes are plaintext by default on this platform. The storage drivers create volumes unencrypted, so the disk contents are readable to anyone who can read the raw disk. The backends differ in what you can do about it:

• Hetzner Cloud volumes are network-attached and managed by Hetzner. They are not encrypted by default and Hetzner offers no switch to turn it on. The CSI driver can put a LUKS layer on them instead, when you give a StorageClass a Secret holding an encryption passphrase.

• Local disks on bare-metal servers (the NVMe and SSDs that back TopoLVM local volumes) are the disks you can encrypt yourself, and the subject here. These are the disks that leave the building on an RMA or a decommission.

This pairs with etcd encryption : etcd encryption protects Secrets in the datastore, data-disk encryption protects the volumes your workloads write. Together they cover data at rest.

The design: LUKS under the LVM volume group#

The recommended architecture puts LUKS (the Linux disk-encryption format) under the LVM volume group that TopoLVM carves local volumes from. Every logical volume TopoLVM provisions then sits on encrypted storage, transparently to the workload. The full design lives in Syself's internal volume-decryptor design document; ask your Syself contact if you want to review it before building.

Getting the key to the node at boot#

The hard part is not the encryption itself. It is getting the key to the node so it can unlock the disk at boot, without a human typing a passphrase and without a TPM to seal the key to. The node OS has no TPM-backed measured boot (see Node and OS security ), so you cannot seal the key to the platform state. The volume-decryptor design addresses this with a network-delivered key: the node fetches its LUKS key at boot from a decryptor service you run, which decides whether to hand it over. That moves the trust to the key service and the network path rather than the disk itself. The key-delivery model is the part that needs care; review it with Syself before you build this.

Set it up#

The steps live with the storage docs: Encrypt data at rest with LUKS has the rescue-shell commands, the boot-time unlock DaemonSet, and the CSI variant for Hetzner Cloud volumes. The shape follows the design above: put LUKS on the data disk, build the LVM volume group TopoLVM expects on the opened device, and unlock at boot before TopoLVM starts.

Because the sealed OS is read-only and cannot be modified at runtime, the unlock mechanism has to fit the node lifecycle rather than being installed onto a running node. This is why it is a design to follow rather than a package to add.

LUKS costs some CPU on every read and write. For most single-tenant compliance cases that is well worth a disk that leaves the building carrying nothing. The storage page covers how to measure the overhead on your own hardware.

For where this sits in the wider at-rest picture and who holds which key, see Data at rest and key custody .