Disk encryption on a machine you do not own

Every host that sells privacy says the disks are encrypted. It is usually true, and it usually answers a question nobody asked. Encryption has three states to worry about, and a server spends its entire working life in the one that full-disk encryption does not cover. This is where the line actually falls, what sits on each side of it, and which of the two arrangements sold under the same four words is the one where you hold the key.

Three states, and the one nobody encrypts

Data is described as being in one of three states, and the industry has convincingly solved two of them. At rest is data sitting on a disk that nothing is currently reading: solved by full-disk encryption, and by database or object-store encryption layered above it. In transit is data crossing a network: solved by TLS, thoroughly enough that a mis-issued certificate is now news. In use is data loaded into the memory of a running process — which is where every byte your server serves has to be, however briefly, in order to be served at all.

The phrase encryption at rest is exact, and it is exact in a way that is easy to read past. It describes the state your data is in while the machine is off. A server is a machine whose entire job is not being off. For the months it spends running, its volumes are open, its database files are readable by any process running as the right user, and the encryption is doing nothing except waiting for a power cut.

The second thing those four words hide is whose key it is. Two completely different arrangements are sold under them. A provider can encrypt the storage layer with keys the provider manages: that protects the provider’s decommissioning process and shrinks its own breach exposure, and it does protect you against a drive walking out of the building — but the party holding the key is the party you were asking about. Or the volume can be encrypted inside your own machine, with a key that exists nowhere except in your head and in the memory of a running kernel. Only the second arrangement changes what a third party is able to obtain, and only the second is what the rest of this guide means.

None of this is an argument against encrypting disks. It is an argument for knowing which of the eight scenarios below you have covered and which you have not. Encryption that stops one real thing is worth having; encryption you believe stops eight is worse than none, because the belief ends the conversation.

Where the key lives while the machine runs

When you unlock a LUKS volume, the passphrase you type is not the key. It unwraps a master key stored in the volume header, and that master key is then held in kernel memory until the volume is closed or the machine loses power. Every read and every write passes through it. There is no configuration of a working encrypted disk in which the key is somewhere else while the disk is in use — that is not an implementation detail anyone could fix, it is what using an encrypted disk means.

On hardware you own, that memory sits in a case in a room you control, and the attack against it is exotic: physical presence, and the seconds of residue that memory chips hold after the power is cut. On a VPS the situation differs in kind rather than in degree. Your kernel’s memory is a region of the host’s memory. The hypervisor can address it by definition, because addressing it is how the hypervisor gave it to you in the first place. Three entirely ordinary operations read it:

• A live migration. Moving a running virtual machine between physical hosts copies its memory across while it runs. This is a feature — it is how a host gets maintained without rebooting you — and your master key is in the pages being copied.
• A snapshot that includes memory. A disk-only snapshot of a volume you encrypted yourself contains ciphertext and nothing else. A snapshot that lets the machine resume exactly where it was contains the key, because the key is part of what “exactly where it was” consists of.
• A memory dump. Your guest’s memory lives inside the address space of a process on the host. Reading that process’s memory is a routine debugging operation, and the tooling ships with the virtualisation stack rather than having to be smuggled in.

None of that asserts your provider does any of it. It asserts that these actions require no cooperation from you, leave no trace in anything you can see, and are indistinguishable from ordinary platform maintenance. That is the only property worth writing into a threat model: not what somebody is doing, but what they are able to do without you finding out. The same reasoning one layer further out is why the registry and the proxy in front of you belong on the same list as the host.

The reboot problem, and the shortcut that undoes it

An encrypted root volume has to be unlocked before the system boots far enough to accept an SSH connection. On a laptop you type the passphrase at the keyboard. On a machine two thousand kilometres away, in a building you have never entered, there is no keyboard you can reach at the moment it is wanted. Every practical answer to that is a trade — and one of the four below is not a trade at all, but a way of appearing to have made one.

Four ways to unlock an encrypted root volume on a remote machine

Method	Unattended reboot	Stops a stolen disk	What it costs you
SSH into the boot image	No	Yes	A minimal SSH server inside the initramfs lets you connect and type the passphrase. The machine stays down until a human is awake and reachable. This is the honest option, and the cost is real: a reboot at four in the morning is an outage until somebody notices it.
Network-bound key	Yes	Partly	The machine fetches its unlock key at boot from a server you run elsewhere, and you can refuse to serve a key to a machine that has moved or that you did not reboot. The key server has to stay up, and it has to sit somewhere the same order cannot reach — otherwise you have split the key across two doors with one lock.
Key file in the boot image	Yes	No	The key sits in the initramfs, the initramfs sits on an unencrypted boot partition, and the boot partition sits on the disk you were protecting. Whoever takes the disk takes the key with it. This configuration is common, it boots beautifully, and it defends against nothing whatsoever.
Sealed to a TPM	Yes	Partly	On hardware you own, a real security chip releases the key only to a boot chain that has not been altered. On a VPS that chip is emulated by the host, so sealing a key to it hands the key to precisely the party you were sealing it away from.

The third row deserves a long look. It is where you end up when the requirement was written as the disks must be encrypted and nobody asked what for. The audit passes. The block device genuinely is encrypted. The key rides along on the same piece of metal, in a file a recovery shell will read in about four seconds.

This is also the clearest practical difference between a rented virtual machine and a machine of your own. On dedicated hardware the out-of-band management interface gives you a console that survives a reboot, so the first row stops being an outage and becomes a two-minute interruption — and the emulated-chip problem in the fourth row goes away, because the chip is soldered to a board rather than written in software by the party you are defending against.

What full-disk encryption actually buys

The same question, asked eight ways. The column that matters is the last one, because in every row where encryption does not help, something else does — and naming that something is the entire value of the exercise.

Eight scenarios, and whether full-disk encryption changes the outcome

Scenario	Encryption helps	What actually decides it
A drive is retired, resold or returned under warranty	Yes	Nothing else covers this. Drives leave data centres constantly, sanitisation is a process, and processes fail quietly. This is the scenario full-disk encryption was invented for, and against it it works exactly as advertised.
The machine is powered off and the disk removed	Yes	The same protection with the same boundary, and the boundary is the word off. A machine taken while it is running is a machine taken unlocked, with its volumes open and its key resident.
A backup copy sits somewhere else	Partly	Encryption on the source volume does nothing for a copy of the data. What decides it is whether the backup was encrypted before it left, with a key that is not stored on the machine being backed up.
The platform takes a snapshot	Partly	A disk-only snapshot of a volume you encrypted yourself is ciphertext and useless to anyone without your passphrase. A snapshot that captures memory state captures the key along with it. Both are called snapshots.
Somebody gets a shell on the running machine	No	The volume is already open, and an intruder reads files rather than blocks. Patching, least privilege, and credentials that are not reused across services decide this row, and encryption contributes nothing to it.
The host operator, or anyone holding the host operator’s access	No	Only encryption whose key never enters the machine at all. Hardware memory encryption is the single exception and it is off by default everywhere, which is covered in the next section.
An order is served on the provider	Partly	Jurisdiction decides who may ask and on what showing; encryption decides what an answer could contain. Our own published position is two separate sentences, and both of them matter: we do not hold customer keys and cannot produce them, and an unencrypted volume on a virtual server still requires an order naming that service.
You have to disclose a breach	Partly	If your users are in the EU, Article 32 of the GDPR names encryption among the measures expected of you, and Article 34 lifts the duty to notify the individuals — never the regulator — where the data was rendered unintelligible. Whether that applies turns entirely on where the key was when the data left.

Above the disk: what survives a hostile host

Everything so far concerns a layer that stops at the block device. Three things sit above it, and between them they are the only answers to the fifth, sixth and seventh rows of that table.

Encrypt above the application, not underneath it

Field-level encryption means the application encrypts a value before it reaches the database and decrypts it after reading it back. A dump of the database yields ciphertext, whoever took the dump and by whatever route. It costs you the ability to search or index the encrypted columns, which is why it belongs on the few fields that deserve it — message bodies, uploaded documents, third-party tokens — and not on everything. The end of that road is end-to-end: the key belongs to the user, the server never holds plaintext, and a hostile host obtains nothing because there is nothing there to obtain. That is the only architecture on this page genuinely indifferent to who runs the metal, and it is a product decision long before it is an infrastructure one.

Backups are a separate decision, not a consequence

The most common way data leaves an encrypted machine is a backup. A snapshot pushed to object storage, a database dump synced to a second provider, an archive pulled down to a workstation — none of them inherit anything at all from the volume they came from. Encrypt at the moment the data is written into the backup, with a key held somewhere the machine itself cannot reach, so that a compromised server cannot decrypt its own history. Then restore one, on a different machine, before you need to: an encrypted backup you cannot open is an unusually tidy way of losing everything at once. A copy in another country is also a copy under another set of rules, which is a second jurisdiction you have chosen without noticing.

Memory encryption, and why you probably do not have it

The state nobody encrypts does have a hardware answer. Confidential-computing extensions — AMD’s SEV-SNP, Intel’s TDX — encrypt a guest’s memory and register state under a key held by a separate security processor rather than by the hypervisor, so a host that dumps the memory gets ciphertext back. It is real and it is shipping. It is also narrow: SEV-SNP requires third-generation EPYC silicon or newer, the host has to be configured for it deliberately, and the guest has to attest to having got it. Almost no general-purpose virtual server offers it, and none offers it silently. Assume you do not have it unless a provider says you do in writing and can tell you how to verify the attestation yourself.

A setup that is honest about its limits

None of this ends at do not bother. It ends at a configuration whose limits you can state out loud without flinching.

1. Write down the single scenario you are defending against (5 min). A retired drive, a machine seized while running, a hostile host, a court order, a breach you must disclose. They have different answers, and a setup aimed at all five reliably achieves none of them.
2. Put the encryption where your key is (decision). If the provider holds the key, you have bought protection against a drive leaving the building and nothing beyond it. If you want more than that, the volume has to be unlocked from inside the guest, by you, with something the platform never sees.
3. Encrypt the data volume rather than the root (setup). An encrypted root means every reboot waits for you. A separate encrypted volume holding the database directory, the uploads and the secrets lets the machine come back on its own while the sensitive part stays closed until you open it. This is the compromise most small platforms should be making, and almost nobody writes it down.
4. Never leave the key file on the unencrypted boot partition (rule). If the machine boots unattended with no key server and no console, the key is on the disk; there is no third possibility. That is a fine trade when a stolen drive genuinely is your whole threat model, and self-deception in every other case.
5. Encrypt backups at the point of writing, with a key kept elsewhere (setup). Then restore one onto a different machine, on a day when nothing is on fire.
6. Say what you have covered, in one sentence (5 min). Something close to: an attacker who pulls this disk out of the rack gets nothing, and anyone with root on the running machine or on its host gets everything. If that sentence is uncomfortable to write down, it is because it is true.

Two of those six are decisions and four are configuration. The decisions take an afternoon and the configuration takes an hour, and the hour is worth nothing without the afternoon. Doing them in the other order is how people end up in the third row of the first table, with an audit-passing machine that protects them from nobody.

Which scenario you are defending against is a threat-modelling question before it is an encryption question, and the one-hour version of that exercise produces the sentence in step six almost as a by-product. If the answer turns out to be a court order rather than a drive, the layer that decides the outcome is not on your disk at all — it is whose law reaches your provider, and how to check that before you trust it.

Written by the engineers who run the platform, and re-read today. If something here is wrong or has gone out of date, say so from the panel — that is where about half of these came from.