Encrypted VPS hostingEncryption at rest protects a machine that is switched off.

Three states, and the one the industry does not sell

Data is described as being in one of three states, and the distinction is the whole of this page. At rest is a disk nobody is reading. In transit is a packet on a wire. In use is a process holding the plaintext in memory so that it can do something with it.

The first two are solved and every provider sells them. The wire is TLS and the platters underneath you are almost certainly encrypted. Very little is said about the third, because the third is where the provider is standing: a running server has the volume unlocked, the key resident and the data in the clear. That is not a flaw in the encryption. That is what running means.

What “encrypted at rest” means when a host says it

Provider-side encryption at rest is real and worth having. It means the drive, the array or the snapshot store is encrypted under a key the provider manages, so a disk that leaves the building — failed, swapped, resold, stolen — is a brick rather than a copy of your database. Every serious platform does this and it costs you nothing.

What it cannot do is exclude the provider, because the provider holds the key by definition. It is a control against the loading dock, not against the operator. A host that answers a question about its own access by describing encryption at rest has answered a different question, and usually knows it.

The version that does exclude the provider is the one where the key never arrives. The trade is written down in the runbook for it: snapshots here are stored encrypted, this estate holds no key to the contents of a disk you encrypted yourself, and it therefore cannot rescue that disk for you either. Both halves of that sentence are the same fact, and a host offering only the first half is holding a key.

Three machines, three different answers

“Can my host read my disk” resolves differently on a shared instance, on a whole machine and in a cabinet you rent by the unit. The differences are worth setting out, because they are usually sold as the same product with different numbers against them.

None of those rows is an argument against the product above it. They are an argument for knowing which threat you are buying against. An operator that runs the hypervisor can read the memory of a guest running on it, and a provider claiming otherwise has misread its own stack. What it reads is either your data or it is noise, and which of the two was decided months earlier by where you put the key.

The key ceremony is the entire guarantee

Everything above reduces to one operational question: at the moment the machine boots, where does the key come from? There are three answers in use and they are not close in strength.

1. Stored on the machine. A key file on the same volume, or a passphrase baked into a provisioning script, so the server can boot unattended. This is encryption as a checkbox: whoever can read the disk can read the key lying beside it.
2. Held by the provider. Convenient, recoverable, and precisely the arrangement a legal order can act on. The key exists, somebody holds it, and holding it is a thing a court can name in an instrument.
3. Supplied by you at each boot. The machine comes up into an initramfs and does nothing at all until you connect and hand it the passphrase. The key exists in that machine's memory, only while it runs, and nowhere else on earth.

Only the third moves the question out of the legal register. An order can compel a provider to produce what it holds; it cannot compel it to produce a key it was never given. That is a difference in kind rather than in degree, and it is why the signed warrant canary here carries a separate claim about compelled weakening of a cryptographic protection. A promise about behaviour and a fact about arithmetic are different instruments, and only one of them outlives the person who made it.

What full-disk encryption still leaves in the clear

An encrypted root filesystem is not an opaque box. Several things sit outside it by construction, and knowing which is the difference between a threat model and a feeling.

• The boot chain. /boot and the initramfs are read before anything can be decrypted, so they are unencrypted and, on rented hardware whose firmware you cannot attest, unverified. Whoever can write there can write something that keeps your passphrase.
• Swap and hibernation. Unencrypted swap will hold pages of decrypted memory without complaint. Encrypt it or switch it off; there is no third option that is safe.
• The shape of the machine. Partition sizes, the LUKS header, how much of the volume is in use, and the plain fact that it is encrypted at all.
• Everything the running process holds. The database in page cache, the TLS private key the web server loaded at start-up, the environment variables, the open sockets. This is the largest category on the list and encryption at rest does not touch any of it.
• Your traffic. Who you talk to, when and how much, exactly as before. That is the subject of the no-logs guide rather than this one.

The boot chain is the item people underestimate. If the initramfs is where you type the passphrase, the initramfs is now a credential prompt on a machine you do not physically control — so the fingerprint of its SSH host key matters as much as the passphrase does. It is a different key from the one the running system presents, which is exactly why a changed fingerprint at boot gets waved through. Record it the first time and check it every time. A prompt that looks right and is not is the whole attack.

What it stops, and what it does not

Read down the middle column. Encryption is decisive in exactly the cases where the machine is off or the key was never handed over, and irrelevant in every case where the machine is running and somebody is already inside it. That is not a weakness to be engineered around. It is what encryption is, and a page that implies otherwise is selling something.

The cost, stated before you commit to it

This is the section that pages advertising “encrypted hosting” do not have, and the reason is that every item on it is a real inconvenience you will meet inside a month.

• No unattended reboot. A kernel update, a power event or a host migration leaves the machine sitting at a passphrase prompt until a human arrives. Availability is now a function of your sleep schedule.
• No rescue. A provider that cannot read the volume cannot repair it. Filesystem checks, data recovery and “could you just copy the config off it” all become yours alone.
• Backups are ciphertext. Which is correct, and means a restore needs the key too. A backup you cannot open is not a backup.
• A damaged header is fatal. The LUKS header holds the wrapped master key in a small region at the start of the volume. Copy it off the machine on day one; without it, a correct passphrase opens nothing at all.
• Some overhead. Real, visible on a benchmark, and rarely the constraint on a workload — every current processor does AES in hardware. Measure it on the machine you rented rather than arguing about it.

Setting it up so that it is worth having

The commands are in the knowledge base. What follows is the order to do them in, which is the part that is not a command.

1. Arrange console access before you start rather than after. The first mistake happens at the boot prompt, and SSH is precisely what is not available there.
2. Encrypt a second volume first. Data on a separate encrypted disk is most of the benefit for a fraction of the operational risk, and it teaches you the failure modes on a machine that still boots on its own.
3. Move the root filesystem behind it only once that is routine, with a small SSH server in the initramfs to take the passphrase at boot.
4. Record the initramfs host key fingerprint on the first unlock and verify it on every one after. It is not the same key the running system presents, and treating a change as normal is how a passphrase gets collected.
5. Back the LUKS header up to somewhere that is not that machine, then prove the backup opens the volume rather than assuming it.
6. Encrypt or disable swap, and then check what you actually built: lsblk -o NAME,FSTYPE,MOUNTPOINT shows what sits behind the mapper and what quietly does not.
7. Reboot it once, deliberately, before there is anything on it you would miss. A first unattended reboot at three in the morning is not the moment to learn the procedure.

How to check a host's encryption claim in ten minutes

The same test as everywhere else on this shelf: each question below has a document as its answer, or it does not have one.

1. Is the thing being encrypted the platform, the volume or the guest — and which of those was the one you asked about?
2. Who generates the key, where does it live, and what is the procedure when a customer loses it? A recovery path is a second key, and a second key is a second thing that can be ordered produced.
3. Can you bring your own key and refuse to share it? If the answer is yes, ask what breaks. If nothing breaks, the encryption was not doing anything.
4. Is there a console that works when the machine will not boot, and is it included or billed by the hour?
5. What does the provider say it can no longer do once you have encrypted? A host claiming both perfect privacy and full support has not thought it through, or is describing a key it holds.

The last one is the tell. Every honest answer in this area costs the provider something, and a claim that costs nothing is describing a product rather than a guarantee. What this estate will and will not do is set out in the law-enforcement guide and counted in the transparency report.

Questions people actually ask

Every price on this estate is published in full, in one place. See the whole catalogue