Full-Disk Encryption on a VPS

Full-disk encryption answers exactly one question: what does an adversary get when they are holding your storage and the machine is switched off? Every other question you might have — what the host can see, what happens if a running server is seized, whether your backups are safe — has a different answer, and treating them all as one is how people end up with encryption that protects nothing.

That distinction is worth being blunt about, because "LUKS-encrypted" appears on every privacy-hosting page in this industry, ours included. It is a real control, it costs almost nothing to run, and it is also the most over-claimed control in hosting. This guide covers what encryption at rest genuinely stops on a rented server, the three arrangements worth deploying and the commands for each, the two settings that actually matter on a small VPS, and the handful of mistakes that turn the whole exercise into decoration.

What encryption at rest actually protects against

Encryption at rest means the bytes on the storage medium are ciphertext whenever the volume is closed. That is a narrow claim, and its worth depends on a single variable: where the key is at the moment the adversary arrives.

Read that as a definition rather than a disappointment. Removing the pulled-disk class of exposure is worth an hour of work precisely because it is the class you have no other defence against, and the one that happens without anyone targeting you: hardware fails and gets returned, arrays get retired, volumes get re-issued to the next tenant. Encryption turns all of that into a non-event.

Why a VPS is not a laptop

On a laptop the design is self-evident. You type a passphrase at boot, the key exists only in RAM while the machine is awake, and shutting it down ends the story. A server has nobody at the console. Something must supply the key on every boot, and each candidate for "something" trades availability against protection:

• A human types it. The strongest arrangement, because the key never rests on the machine — but the server cannot return from a reboot without you, and you need a way in before the operating system exists.
• The machine holds it. Convenient, and in most home-brewed setups self-defeating: a key file on the same virtual disk means whoever holds the disk holds the key.
• Another machine hands it over. Network-bound unlock, usually Clevis with a Tang server. The server unlocks itself only while it can still reach a host you control, which is a genuinely useful property — and a relocation of trust, not an elimination of it.

There is a second difference that most guides skip. On a VPS, /boot and the initramfs are plaintext, they live on storage the provider ultimately controls, and there is no boot chain you can verify — no TPM that belongs to you, no measured boot, nothing to attest. A host that wanted your passphrase could alter the initramfs and collect it the next time you unlock. That is not a description of anything we do; it is a description of what the architecture permits, which is the only honest way to reason about a computer you rent. Our VPS versus dedicated comparison walks the same trust boundary from the hardware side, and our honest answer on offshore anonymity applies the same discipline to the marketing around it.

The three arrangements worth deploying

There is no single correct setup — there is the one whose failure mode you can live with. These three cover essentially every real case.

Start with the first unless you have a specific reason not to. It delivers most of the protection for a fraction of the operational risk, and it has the one property the other two lack: nothing about it can stop the server coming back online. Arrangement three is the only one where the passphrase is a fact the host cannot reach rather than a promise the host makes, which is why our dedicated servers take LUKS at install with a passphrase we never see.

Encrypting a data volume on a running VPS

This is the arrangement to reach for first. Nothing is reinstalled, nothing about the boot process changes, and if you make a mistake the worst outcome is a container file you throw away. Fifteen minutes on a live Debian or Ubuntu server.

• Install the tooling. apt install cryptsetup. If your plan gave you a second block device, use it directly and skip the next step.
• Create a container. On a single-disk VPS the practical route is a file: fallocate -l 40G /var/lib/vault.img. It behaves like a disk and can be grown later.
• Format it as LUKS2. cryptsetup luksFormat --type luks2 /var/lib/vault.img. Take the defaults for the cipher; the section below covers the one parameter worth touching on a small server.
• Open it and lay down a filesystem. cryptsetup open /var/lib/vault.img vault gives you /dev/mapper/vault; then mkfs.ext4 /dev/mapper/vault and mount /dev/mapper/vault /srv/vault.
• Move the data that matters, then point services at it. A bind mount, or an rsync with the service stopped, is usually cleaner than symlinks — databases in particular dislike being followed around.
• Back up the LUKS header. cryptsetup luksHeaderBackup /var/lib/vault.img --header-backup-file vault-header.bin, then move that file off the server. A few corrupted kilobytes at the start of the container destroy every byte behind it, permanently, and this is the only insurance that exists.
• Close it and prove you can get back in. umount /srv/vault && cryptsetup close vault, then open it again from your notes rather than from memory. Do this before there is anything valuable inside.

After a reboot the vault stays shut until you log in and open it. That is not a limitation to engineer around — it is the entire point. A volume that opens itself is a volume whose key is on the machine.

Full-root encryption with remote unlock over SSH

When the requirement is that nothing readable survives a powered-off seizure — logs, shell history, package lists, the shape of what you run — the root filesystem has to be inside the container too. The problem then becomes getting a passphrase into a machine that has not booted yet, and the answer is a tiny SSH server living in the initramfs.

• Install encrypted from the start. Boot the distribution installer through custom ISO upload and choose guided partitioning with encrypted LVM. Converting a running root filesystem in place is possible and not worth the risk.
• Add the pre-boot SSH server. apt install dropbear-initramfs, then put your public key in /etc/dropbear/initramfs/authorized_keys. This is a separate key set from your normal SSH — use a dedicated key.
• Lock it down. In /etc/dropbear/initramfs/dropbear.conf, set DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s": no password logins, no port forwarding, its own port, and an idle timeout so a stuck session cannot hold the boot open.
• Give the initramfs a network. Add a static ip= parameter to GRUB_CMDLINE_LINUX in /etc/default/grub — the form is ip=address::gateway:netmask::interface:off. Relying on DHCP at this stage is how people end up locked out.
• Rebuild and reboot. update-initramfs -u && update-grub, then reboot and connect with ssh -p 2222 root@your-server and run cryptroot-unlock. Your client will warn about an unknown host key: the initramfs has its own, which is expected and worth pinning in a separate known_hosts entry.
• Test the failure path before you rely on it. Install a kernel update, reboot, unlock again. Kernel upgrades regenerate the initramfs, and that is exactly when a misconfiguration surfaces.

The two settings that matter, and the small-VPS trap

LUKS2 defaults to AES-XTS with a 512-bit key and Argon2id key derivation. Both are correct. Hand-tuning the cipher is a way to be slower and weaker at the same time, and the internet is full of copied command lines that do exactly that. Two things, however, deserve your attention.

Performance is a non-issue, until it is

Check for hardware acceleration with grep -m1 -o aes /proc/cpuinfo and measure with cryptsetup benchmark. On any CPU with AES-NI — which is every node we run — AES-XTS moves several gigabytes per second per core, comfortably above what a single virtual disk delivers, so the visible cost is a few percent of CPU under heavy I/O and a small latency increase. Without AES-NI the picture inverts and encryption becomes the bottleneck; that is the one case where an alternative cipher is a real decision rather than cargo cult.

Argon2id memory is the thing that bites

Argon2id is deliberately memory-hungry, and cryptsetup calibrates it at format time against the RAM of the machine you are formatting on. Format a volume on a 32 GB workstation, move it to a 1 GB VPS, and unlocking can fail outright because the memory the key derivation demands is not there — worse still inside an initramfs, where far less is available than in a running system. On small instances, pin it: cryptsetup luksFormat --type luks2 --pbkdf argon2id --pbkdf-memory 262144 /dev/vdb caps it at 256 MB. Lower is a real reduction in resistance to offline brute force, so compensate with a longer passphrase.

One optional flag deserves a conscious decision rather than a copy-paste: --allow-discards passes TRIM through to the underlying device, which is good for SSD wear and steady-state performance, and which also reveals how much of the volume is in use and roughly where. It is off by default. Turn it on knowing what it leaks.

Swap, logs, snapshots — the parts people forget

An encrypted vault with plaintext leaking around it is the most common failure of all, and it stays invisible until someone looks.

• Swap. Anything in memory can be paged to disk, including material you carefully put in the vault. Either disable swap, or give it a random key on every boot with a /etc/crypttab line such as swap /dev/vdb1 /dev/urandom swap,cipher=aes-xts-plain64,size=256.
• Everything that writes where you did not look. /var/log, /tmp, the database data directory, /var/lib/docker, shell history, systemd journals. Encrypting /srv/vault while PostgreSQL writes to /var/lib/postgresql accomplishes precisely nothing. Enumerate before you encrypt.
• Snapshots. A block-level snapshot of an encrypted volume is ciphertext and therefore fine. A snapshot that captures memory state is a different object entirely and can contain the key. Know which kind your provider's panel takes before you use it.
• Backups. The destination is the wrong place to solve this. Tools like restic and BorgBackup encrypt at the source with a key the target never sees, which is why a backup server can be an ordinary machine in another jurisdiction rather than a trusted one.
• The plaintext you already sent somewhere. Encryption at rest is not retroactive. Anything already copied, mailed or synced elsewhere sits outside the boundary you are now drawing.

Where the key lives is the whole design

Every arrangement above is really a statement about key custody. Four options exist and they are not equivalent:

• In your head, typed each boot. Maximum protection, maximum operational friction. The machine genuinely cannot be read without you.
• In a file on the encrypted machine. Protects against a naive disk resale and nothing else. If that file sits on plaintext /boot, it protects against nothing at all — the single most common mistake in self-hosted encryption.
• On a machine you control, fetched over the network. Clevis bound to a Tang server: clevis luks bind -d /dev/vdb tang '{"url":"https://tang.example.net"}'. The server boots unattended while it can reach home and refuses to unlock anywhere else. Excellent for headless fleets, and it makes the Tang host the thing that must be defended.
• In a TPM. Meaningful on hardware you own. On a VPS the virtual TPM is provided by the same hypervisor you are trying to exclude, so it solves convenience rather than trust.

One test settles most designs: if the machine can reach a login prompt without you, the key is on the machine. That may be an entirely reasonable trade — plenty of workloads want unattended reboots more than they want resistance to a determined adversary. Make the choice deliberately, and do not describe the result as something it is not.

What your host can see, and where jurisdiction takes over

On a VPS a hypervisor sits underneath you. We do not read guest memory, and we keep no traffic, connection or DNS logs and no console trail — but those are policies, and the honest framing is that a VPS asks you to rely on them. On bare metal there is no hypervisor between you and the silicon: full-disk encryption set up at install with a passphrase we never receive is a physical property of the machine rather than an assurance from us. That difference, not the choice of cipher, is what you are really choosing between.

Which is why encryption and jurisdiction are two halves of one answer. Encryption decides what a copy of your disk is worth; jurisdiction decides who can compel the machine to be produced, through which process and how quickly. We run in seven — Iceland, Switzerland, Panama, Romania, Moldova, the Netherlands and Russia — and the reasoning for picking between them is in our jurisdiction guide, or in shorter form through the jurisdiction selector and the locations page.

The part encryption cannot touch is compelled disclosure, because it is aimed at you rather than at the hardware. The United Kingdom, France and Australia are among the countries whose law can require a person to produce a decryption key or face a penalty for refusing. That exposure follows where you are, not where the server is, and no configuration on the box changes it. Signing up without identity documents limits how much of a paper trail exists in the first place — the practical, unglamorous reason no-KYC hosting and encryption end up in the same conversation — but it is not a defence against a court that already has your name.

Nine mistakes that turn encryption into decoration

• Auto-unlocking from a key file on the same disk. The majority of "encrypted" servers, and the equivalent of leaving the key in the lock.
• Encrypting a volume the sensitive data never reaches. The vault is empty and the database is not in it.
• Never backing up the LUKS header. One damaged sector at the front of the container and every byte behind it is gone for good.
• Never testing the unlock path. Then a kernel upgrade regenerates the initramfs and the next reboot becomes a rescue operation.
• Formatting on a large machine and unlocking on a small one. Argon2id asks for memory the VPS cannot provide, and the volume will not open.
• Choosing a passphrase like a login password. Nothing rate-limits an offline attack except the key derivation function. Length is what buys time.
• Migrating plaintext into encryption and assuming the original is gone. On virtualised storage, overwriting does not reliably erase.
• Sending the passphrase down the same channel used to administer the box. Server OpSec covers the correlation problem that creates.
• Confusing your provider's encryption with your own. "All infrastructure is encrypted at rest" — ours included — protects the infrastructure. Only a key you hold protects you from the infrastructure.

So is it worth doing on a VPS?

Yes, with calibrated expectations. For an hour of work and no measurable running cost, an encrypted data volume removes an entire class of exposure you cannot otherwise address, and removes it permanently: retired hardware, re-issued storage, a powered-off machine in someone else's custody. Do that much on every server holding anything that matters, right after the first-hour hardening checklist.

What it does not do is turn a rented computer into your computer. If your threat model has the host itself as the adversary, no cipher fixes that — the answer is dedicated hardware where the key is typed over IPMI and never passes through a hypervisor, a jurisdiction chosen on purpose, and the discipline not to put on any server what does not need to be there. Matching the control to the actual threat is the difference between privacy and the appearance of it.