How to Encrypt a VPS Disk with LUKS and Unlock It Remotely

Encrypting a VPS looks like a one-liner — cryptsetup luksFormat, done — and then quietly fails to deliver what people assumed they were buying. On a machine you rent, a hypervisor sits underneath your kernel, so the threat model is not the one full-disk encryption was designed around. This guide is the honest version: what LUKS defeats on a VPS, what it does not, the two deployment paths that work, and how to unlock an encrypted root over SSH so you are never locked out of your own server.

What encryption on a rented server actually buys you

Full-disk encryption protects data at rest. That phrase does a lot of work, and on a VPS it is worth spelling out which moments count as rest and which do not — the gap between those two is where most expectations break.

Choose the shape before you type a command

Four arrangements cover almost every real requirement. Picking the wrong one costs a reinstall, so decide here instead of halfway through.

Path A — encrypt a data volume on a server you already run

This is the version most people actually want: ten minutes of work, no reinstall, and everything that matters ends up inside the container. Attach a second volume first — on a /storage plan that is the large disk; on a standard /vps you can add one at deploy time.

1. 1

   Identify the target device

   Run lsblk and confirm the device you are about to format is the empty one. luksFormat destroys whatever is on it and there is no undo.

2. 2

   Create the LUKS2 container

   cryptsetup luksFormat --type luks2 /dev/vdb asks you to type YES in capitals, then set a passphrase. Choose one you can retype correctly on a console with no history and no echo.

3. 3

   Open it and lay down a filesystem

   cryptsetup open /dev/vdb cryptdata creates /dev/mapper/cryptdata. Then mkfs.ext4 /dev/mapper/cryptdata and mount it where the data will live, for example /srv/data.

4. 4

   Decide how it unlocks at boot

   Either type the passphrase after every reboot, or add a keyfile with cryptsetup luksAddKey and store it on root. The keyfile is convenient and strictly weaker — be clear which trade you are making.

5. 5

   Wire crypttab and fstab

   Add the mapping to /etc/crypttab using UUID= rather than a device name, then mount from /etc/fstab with nofail so a failed unlock never hangs the boot.

Path B — an encrypted root from a custom ISO

When the requirement is that nothing readable exists on the machine while it is powered off, root itself has to be inside LUKS. That means a fresh install driven from the console, on a provider that lets you boot your own ISO.

1. 1

   Boot the installer from the console

   Mount a Debian or Ubuntu netinst ISO as a custom ISO and drive the install over VNC or serial. None of this works over SSH — there is no system to connect to yet.

2. 2

   Use guided partitioning with encrypted LVM

   The installer leaves a small /boot in the clear, because something has to run before the volume opens, and places root and swap inside one LUKS container.

3. 3

   Pick a passphrase you can type blind

   You will retype it over SSH at every reboot with no echo and no autocomplete. A five-word passphrase beats a symbol soup here.

4. 4

   Set up remote unlock before you log out

   A freshly encrypted root will sit at the passphrase prompt forever after the next reboot. Configure remote unlock in the same session, while the console is still in front of you.

Remote unlock over SSH with dropbear-initramfs

An encrypted root needs a passphrase before the operating system exists. dropbear-initramfs puts a tiny SSH server inside the initramfs so you can supply it from anywhere — the difference between an encrypted server and an encrypted brick.

1. 1

   Install the package

   apt install dropbear-initramfs. It hooks into initramfs generation and is rebuilt into every future kernel image automatically.

2. 2

   Authorise a key, and only one command

   Put your public key in /etc/dropbear/initramfs/authorized_keys — on Debian 11 and older, /etc/dropbear-initramfs/authorized_keys. Prefix the line with no-port-forwarding,no-agent-forwarding,no-x11-forwarding,command="cryptroot-unlock" so a stolen key buys nothing but a prompt.

3. 3

   Give the initramfs a network

   DHCP works where the provider offers it; otherwise add a static ip=ADDRESS::GATEWAY:NETMASK::eth0:off parameter to GRUB_CMDLINE_LINUX and run update-grub. Finish with update-initramfs -u -k all so the change lands in the image.

4. 4

   Test a full reboot before you rely on it

   Reboot with the provider console open in another window, connect, enter the passphrase and watch the boot continue. An untested unlock path is not a feature, it is a future outage.

Key management is where disk encryption usually fails

The cipher is not the weak part and never has been. Every recoverable disaster involving LUKS comes down to a key or a header, so treat both as infrastructure.

• Back up the header immediately — cryptsetup luksHeaderBackup /dev/vdb --header-backup-file luks-header.img — and store it off the server. A header damaged by one careless dd is permanent data loss even with a perfect passphrase.
• Use two slots. LUKS2 gives you 32: your passphrase in one, a long random recovery key in another, kept in a password manager. A single slot is a self-inflicted single point of failure.
• Rotate in the right order on a remote machine — add the new key with luksAddKey, verify it opens the volume, then remove the old one with luksKillSlot. Never the reverse.
• Keep the passphrase and the server's connection details in separate places. One compromised note should not hand over both the address and the key.

What encryption costs in performance

The overhead is real but usually invisible. Measure it on the machine you actually have rather than trusting a benchmark from another decade.

The parts people forget

An encrypted volume with plaintext leaking around its edges is a false sense of security, which is worse than none. Close these five before calling the job finished.

• Swap. An unencrypted swap partition can hold fragments of anything that passed through memory. Encrypt it with a fresh random key at every boot via a /dev/urandom entry in /etc/crypttab.
• Logs written before the mount. Anything logged while the encrypted volume is still closed lands on the plain root. Point application and database logs at a path inside the container.
• Backups. Copying an encrypted volume's contents to plaintext object storage undoes the whole exercise. Encrypt the backup independently with restic, borg or age, and hold those keys elsewhere.
• Snapshots. A provider snapshot captures the disk, not your RAM, so the LUKS volume stays ciphertext inside it — but everything left on the unencrypted root is captured exactly as it was.
• Discard. Passing the discard flag through LUKS keeps NVMe trim working and publishes which blocks are unused, leaking how full the filesystem is and roughly how it is shaped. Choose it deliberately, not by copying a config.

Where the host still matters

Encryption is the layer you control: it decides how expensive your data is to read once a machine is off or a disk leaves the building. The layer around it — who can compel access to the hardware, and what records connect the server to you — belongs to the provider and its jurisdiction. Six of our fifteen regions are privacy-tier jurisdictions; /locations lists them, and /offshore-hosting covers what that actually changes.

Three provider capabilities decide whether the paths above are even available: custom ISO boot, without which Path B is impossible; out-of-band console access for the reboot where remote unlock does not come back; and a signup that never tied the machine to your legal identity to begin with. Every /offshore-vps and /storage plan here boots a custom ISO, ships console access, and bills from a prepaid crypto balance with no KYC — so an encrypted disk is not sitting on top of a paper trail that already names you. /guides has an honest walkthrough of what a host can and cannot see.

The deployment checklist

• Name the threat first: decommissioned drives, detached volumes and offline images are what encryption answers — a live hypervisor is not.
• Encrypt a data volume (Path A) if the server already runs; reinstall from a custom ISO (Path B) only when root itself must be encrypted.
• LUKS2 with aes-xts-plain64, and cap Argon2id memory on any plan under 2 GB of RAM.
• Passphrase in one key slot, a long random recovery key in another, both stored off the server.
• Take a LUKS header backup before writing the first byte of real data.
• dropbear-initramfs on a non-default port, key-only, restricted to the cryptroot-unlock command.
• Test one complete reboot-and-unlock cycle with the provider console still open beside you.
• Encrypted offsite backups, plus one restore drill — an untested backup is a hope, not a backup.