Full-disk encryption on a VPS: LUKS and remote unlock

What your provider can actually see

Start with the physics rather than the policy, because a policy can change and physics cannot. On a virtual machine the disk image lives on hardware someone else racked. If that image is not encrypted, it is readable by anyone who ends up holding the storage: an operator with hypervisor access, a technician swapping a failed NVMe out of a RAID-1 pair, whoever eventually receives that drive when it is decommissioned, and — in the case everybody is really asking about — anyone who arrives with a binding order from a court that has jurisdiction over the machine. None of that requires malice or a backdoor. An unencrypted volume is simply a file, and files can be copied.

The second layer is memory. Our VPS plans are KVM full virtualization, so you run your own kernel rather than sharing one — but the hypervisor still owns the RAM it hands you, and any hypervisor can technically introspect a guest. The third layer is everything that never touches the disk at all: the traffic leaving your network interface, the metadata your application emits, the DNS you resolve. On the account side we hold very little by design — an argon2id password hash, your balance and its ledger, order specifications, and access logs rotated after 14 days, with no name, address, phone number or card anywhere in it, as itemised on the no-KYC policy page. Holding nothing about you is a different guarantee from being unable to read your disk, and only one of those two is something you can enforce yourself.

What full-disk encryption fixes, and what it does not

Full-disk encryption is a control for data at rest. It covers exactly the scenarios above in which a volume changes hands while the machine is off or the copy is taken offline: a decommissioned or RMA'd drive, an imaged disk, a volume cloned out of the storage layer, a cold snapshot pulled from underneath you. In every one of those, an encrypted LUKS container is an opaque blob and the person holding it needs a passphrase that only ever existed in your head or on your laptop. That is a real, hard boundary, and it is the single largest improvement most people can make to a rented server.

It is equally important to be blunt about the other half. A running server has the key in RAM — that is what makes the filesystem readable to your own processes — so encryption does nothing against a live root compromise, a hostile process inside the guest, a memory dump taken while the box is up, or a hypervisor that introspects that memory. It does not encrypt what leaves the network port, and it does not help if your application writes secrets to a log you then ship somewhere else. If your threat model genuinely excludes hypervisor introspection, the honest answer is not a better cipher: it is dedicated hardware from $66.00/mo, where there is no hypervisor above you at all. For everything short of that, encryption at rest plus a provider that retains almost nothing covers the realistic cases — the terms in play here are defined in the glossary.

Encrypted data volume, or encrypted root?

There are two designs and they suit different situations. The first is an encrypted data volume: the operating system stays in the clear and you put everything that matters — your application state, your database, your document store, your keys — inside a LUKS container mounted at a path of your choosing. It is installable on a box that is already in production, it never blocks a reboot, and it protects the material anyone would actually want. What it leaves readable is the shape of the system: your package list, your systemd units, your nginx vhosts, your shell history, your logs.

The second is an encrypted root, where everything but a small boot partition is inside the container. Nothing about the machine is legible when it is off, which is the outcome most people picture when they say they want an encrypted server. The price is paid at every boot: a reboot stops dead at a passphrase prompt on a console you cannot see, until you give it a way to ask you remotely. That is the whole reason the next section exists. As a rule of thumb — encrypt the root when you are building a box from scratch and can test it before it carries anything; encrypt a data volume when the box already exists and downtime is expensive. In-place conversion of a live root with cryptsetup reencrypt is possible on LUKS2 and is not something we would recommend doing to a production server you cannot rebuild.

Remote unlock: a tiny SSH server in the initramfs

The trick that makes an encrypted root practical on a remote machine is dropbear-initramfs. The initramfs is the miniature system the kernel unpacks before the real root exists; because you own the kernel on a KVM VPS, you can put a very small SSH daemon inside it. On boot the machine brings up its network interface, starts that daemon, and waits. You connect, run one command, the passphrase unlocks the container, boot continues into the real system and the tiny daemon disappears. From the outside it looks like a server that takes an extra thirty seconds and one deliberate action to come back.

Two details cause almost all of the pain. The first is that the initramfs SSH server has its own host key, different from the one the running system presents on the same address — so if you leave it on port 22 your client will refuse the second connection with a host-key mismatch every single time. Give it a separate port and a separate known_hosts file and the problem evaporates. The second is the timeout: the daemon should not sit there forever if you are asleep, but it also should not give up before you can reach a terminal. Five minutes is a sensible default. Restrict the key so it can do nothing except unlock, and treat the address of that boot listener as something you do not publish — the same instinct that runs through keeping your name off a server.

Key slots, headers, and the failure everybody hits

A LUKS2 container does not encrypt your data with your passphrase. It encrypts a master key with your passphrase, stores that wrapped copy in a key slot in the header, and encrypts the volume with the master key. The consequence is worth internalising: there are several slots, so you can enrol a second passphrase or a keyfile without re-encrypting a byte, and you can revoke one without touching the others. The other consequence is sharper — the header is the data. Overwrite the first few megabytes of that volume and every slot is gone at once, along with any prospect of recovery. Back the header up, off the machine, at the moment you create the container and again whenever you add or remove a key.

Then there is the failure mode this host makes unusually stark. Registration here is a handle and a password with eight recovery codes and no email anywhere in the loop, precisely so there is no identity to leak — which also means there is no identity-based recovery path for anything, yours included. Nobody can vouch for you, and nobody has a copy of your passphrase. So build the encrypted machine while you still have a working one, reboot it deliberately and unlock it remotely before it carries data, keep the header backup and a second key slot somewhere you would still reach after losing your laptop, and make sure your recovery plan ends in redeploy and restore from backup rather than in someone else typing a passphrase for you.

The leaks around the edges: swap, snapshots and backups

An encrypted root with a plaintext swap partition is a lock on a door with the window open — the kernel will page anything, including key material, out to that swap. The fix is to re-key swap from /dev/urandom at every boot, which costs nothing because swap never needs to survive a reboot. Give /tmp the same treatment with tmpfs where you can, disable hibernation on a server, and think about discard before you enable it: passing TRIM through to the storage layer is good for the drive and leaks the pattern of which blocks are in use, which is a small but real disclosure about how full your volume is and where.

Backups deserve their own thought, because a backup is a copy of your data somewhere the encryption you just configured does not reach. Our daily encrypted backups add-on stores snapshots off-host on VPS plans, and manual snapshots — which live on the same host — are a rollback convenience rather than a backup, as the FAQ puts it. If you consider the provider in scope for your threat model, then encrypt client-side before anything leaves the machine, with a key that is not stored on it. That single habit also makes the restore path portable: a backup that only you can read is a backup you can restore anywhere, including on a different VPS plan in a different region.

Where encryption sits in an offshore threat model

Encryption is one of three controls that fail independently, which is exactly why using all three is not paranoia but ordinary engineering. The first is what the host knows about you — nothing, when the account is a handle funded by a prepaid crypto balance from $30.00, across 8 coins and network variants covering 7 currencies, with no card and no document in the chain; that is the subject of paying for hosting anonymously. The second is whose law applies, which is decided by where the machine sits rather than where you do, and is worked region by region in which offshore location should you pick? and legally in offshore hosting jurisdictions compared.

The third is what is readable at rest, and that one is yours alone — no provider can do it for you, because a provider that holds your key has not solved the problem you were worried about. Stack them and each covers a distinct failure: an identity leak does not expose the disk, a jurisdictional surprise does not hand over a passphrase, and a stolen drive does not name you. There are 6 regions to choose between across our locations, with a VPS online in about 15 min; on dedicated hardware, handed over in 2–12 h with IPMI credentials, you can go further still and boot your own installer rather than trusting a provider-supplied image at all.

Performance, and the boxes not worth encrypting

The performance question is mostly settled by hardware. Every VPS in the fleet runs on AMD EPYC 9354 with AES-NI, so aes-xts-plain64 moves data at several gigabytes per second per core — far past what any single workload asks of an NVMe RAID-1 array. Run cryptsetup benchmark on the box and read the numbers rather than trusting a blog post, including ours. The overhead you can actually measure shows up in latency rather than throughput, and only on workloads that are already fsync-bound: a write-heavy relational database, a busy mail spool, a queue committing every message. For a web server, an application backend, a VPN endpoint or a file store, the cost rounds to nothing.

The more useful question is which machines do not deserve the extra moving part. A box holding no private state buys nothing from encryption and gains a reboot that cannot complete unattended — a public static mirror, a cache node, a Tor middle relay whose only secret is an identity key you could rotate in a minute. Encrypt where there is something to lose: the database, the mail store, the backup target, the machine terminating your WireGuard tunnel and holding its private keys. Decide per box, not per fleet, and write down which is which — the operator six months from now is you, with less context and a worse night's sleep.

Step by step

1. 01

   Decide what you are protecting, and pick the design

   Write down the one sentence that matters: which files would hurt if a copy of this volume left the building. If the answer is a database and a key directory, an encrypted data volume is enough and you keep unattended reboots. If the answer is the whole machine tells a story I would rather it did not, build an encrypted root and accept that every boot needs you. Do not start typing until that sentence exists.

2. 02

   Deploy a fresh VPS and harden it before anything else

   Deploy from the panel — a VPS is online in about 15 min — and do the boring work first, on a clean box, while a mistake still costs nothing. Key-only SSH, a default-deny firewall, unattended security updates, and cryptsetup installed.

   apt update && apt full-upgrade -y
   apt install -y cryptsetup ufw unattended-upgrades
   ufw allow OpenSSH
   ufw enable

3. 03

   Create the LUKS2 container and put a filesystem in it

   For a data volume, a file-backed container is the least invasive option and behaves identically to a partition. Size it for what it holds, not for the disk. Choose a passphrase you can type from memory under stress — this is not a password you will paste from a manager on a machine that has not booted yet.

   fallocate -l 40G /var/lib/vault.img
   cryptsetup luksFormat --type luks2 /var/lib/vault.img
   cryptsetup open /var/lib/vault.img vault
   mkfs.ext4 /dev/mapper/vault
   mkdir -p /srv/vault && mount /dev/mapper/vault /srv/vault

4. 04

   Enrol a second key and back the header up off the machine

   One key slot is one bad day away from total loss. Add a second passphrase or a keyfile, dump the header to a file, and copy that file somewhere off the server — an encrypted volume on your laptop, or offline storage. Repeat the dump whenever you change a slot; a stale header backup can resurrect a key you thought you had revoked.

   cryptsetup luksAddKey /var/lib/vault.img
   cryptsetup luksHeaderBackup /var/lib/vault.img \
     --header-backup-file /root/vault-header.img
   cryptsetup luksDump /var/lib/vault.img

5. 05

   For an encrypted root, install the initramfs SSH daemon

   Only relevant if the root itself is encrypted. Put your public key where the initramfs will find it, move the listener off port 22 so it never collides with the real host key, bring the interface up with DHCP, and rebuild. Paths moved in Debian 12: it is /etc/dropbear/initramfs/ there, and /etc/dropbear-initramfs/ on Debian 11.

   apt install -y dropbear-initramfs
   cat ~/.ssh/id_ed25519.pub > /etc/dropbear/initramfs/authorized_keys
   echo 'DROPBEAR_OPTIONS="-p 2222 -s -j -k -I 300"' \
     >> /etc/dropbear/initramfs/dropbear.conf
   echo 'IP=:::::eth0:dhcp' >> /etc/initramfs-tools/initramfs.conf
   update-initramfs -u -k all

6. 06

   Reboot on purpose, while the box is still empty

   This is the step people skip and regret. Reboot deliberately, before there is data, and unlock over the network exactly as you would at three in the morning. Keep the boot listener in its own known_hosts file so its host key never argues with the real one. If it does not come back, you have lost a test box instead of a production one.

   reboot
   ssh -p 2222 -o UserKnownHostsFile=~/.ssh/known_hosts.boot root@203.0.113.10
   # inside the initramfs:
   cryptroot-unlock

7. 07

   Close the edges and write the recovery plan down

   Re-key swap from /dev/urandom so nothing paged out survives a reboot, keep hibernation off, and encrypt backups client-side before they leave the machine. Then write the recovery runbook — where the header backup lives, which slot is which, and the redeploy-and-restore path you will follow when unlocking is not an option. A plan you have not written is a plan you do not have.

   # /etc/crypttab — swap re-keyed at every boot
   swap  /dev/vda3  /dev/urandom  swap,cipher=aes-xts-plain64,size=256