Encrypted VPS: Full-Disk Encryption on a Root Server

LUKS guards the disk at rest while keys live in RAM on a running box. The container pattern on KVM, from $3.00, and where metal takes over.

Published 2026-08-30 · Updated 2026-10-14 · FYRHost Editorial · 17 min read

Full-disk encryption protects the states you are not watching

The honest way to think about LUKS is by state rather than by promise, because encryption is a property of specific situations, not a permanent aura around a machine. Three states are clearly covered: a disk pulled from a decommissioned host, a snapshot parked in cold storage, and a rescue mount performed by someone other than you. In each, the data is ciphertext, and a passphrase you never disclosed is the only key to it. Those are the states where disks actually leak in the real world — after cancellation, after failure, after someone else touches the hardware — which is why the protection is worth an hour of setup.

The running machine is the excluded state, and no configuration changes that: the kernel holds the volume keys in memory while the system is up, and to root on the running host the volume is plaintext, full stop. So the boundary reads plainly — the running host's administrator is out of scope, and nearly everything else is in scope. Anyone selling FDE as protection against the platform you run on is selling a boundary that does not exist; the tool protects against the disk outliving your control of it, which is a different and much more common event.

Where the model surprises people first: backups and old snapshots are disks too. An unencrypted backup of an encrypted server quietly undoes the whole design, sitting on the same shelf with none of the protection, waiting for exactly the decommissioning incident the volume was encrypted against. The discipline below treats every copy the same way, because the threat does not distinguish between originals and copies. The cryptsetup project documents the on-disk behavior; the threat model is yours to draw, and drawing it honestly is most of the work.

The second surprise is how little performance the design costs on modern hardware, where the encryption happens close to the disk and the CPU barely notices. The usual reason people skipped FDE a decade ago has quietly expired, which removes the last excuse for leaving plaintext snapshots in cold storage.

Draw the boundary honestly and the KVM wrinkle that follows stops being a gotcha and becomes a design input — because on a virtual machine, the boot itself is a state with a wire attached.

On a KVM guest the boot wire is the honest boundary

A VPS that unlocks its own disk at boot received the key over the wire from the platform side, which means your key existed in a place you do not administer — even if only briefly, even if never persisted, even if no one was watching. That is the structural fact of virtual FDE, and no amount of configuration inside the guest changes it. The defense is not denial but architecture: keep the secret out of the boot path entirely, and two patterns do that cleanly.

Pattern one, the working middle ground: keep only encrypted volumes inside the machine — LUKS on a loop file or on a secondary disk — and open them over SSH after each boot with a key only you hold. A reboot then waits for you, an unattended restart never silently reopens the data, and nobody mounting the disk out-of-band sees anything but ciphertext. Pattern two is metal: a dedicated server lets you own the boot chain end to end, carry the key in an initrd you control, and keep IPMI as the console of last resort when a boot goes sideways at two in the morning.

Where the middle ground breaks: expecting the provider to have an FDE toggle at provision time, and reading its absence as a missing feature. There is none, by design — root means the keys are yours end to end, and a provider-side encryption feature would put the provider inside the boundary you are trying to draw, which defeats it. The cryptsetup documentation covers the volume formats; the architecture is your call, and the honest one costs a prompt at every reboot.

The same logic explains what the platform does store: billing records and panel actions, retained as any business retains its own books, with connection metadata kept no longer than 24h. The design keeps the platform out of your keys rather than out of your invoice, because only one of those can open your data.

Pick the pattern that matches the threat: containers for most datasets, metal when the boot chain itself must hold no third party. The container pattern is common enough to deserve its own walk-through, command by command, which is exactly what the next section is.

The container pattern, command by command

The workhorse implementation is a LUKS container living on the box's own storage, and the whole build is a handful of commands. Size it with fallocate -l 20G vault.img, attach a loop device with losetup /dev/loop0 vault.img, then cryptsetup luksFormat /dev/loop0 builds the encrypted volume inside the file — the fallocate manual explains the allocation call, and the cryptsetup docs cover every option after it. A secondary disk works identically without the loop layer, and is the better shape when the sensitive set will grow unpredictably.

Open it with cryptsetup open /dev/loop0 vault, build the filesystem inside the mapped device, and move the sensitive set in: keys, mail spools, database dumps, configuration secrets — the things whose loss or exposure actually costs something. Wire it into /etc/crypttab if you want the boot to pause for the passphrase, or leave it manual and open it over SSH after each restart; the fstab manual covers the mount side of the pairing. The whole setup is under an hour the first time and minutes every time after.

Choose the passphrase with the same seriousness as the data it guards: long, generated, stored in a password manager rather than memorized through use, because the volume is opened on your schedule, not daily. Two people who need access means two keyslots, which LUKS supports natively — share the passphrase itself with no one and add slots instead, so revocation stays possible.

The mandatory failure mode to plan for is the header: LUKS stores its metadata in a header, and a header damaged or lost takes the volume with it, passphrase and all, with no recovery path and no negotiation. Back it up before the first real data lands, and keep the backup off the same disk — the next section makes that rule concrete, because it is the one rule in this guide with no second chance attached.

Commands in place, one operational question remains: what happens at reboot. The answer is the difference between encryption and theater, and it deserves its own section.

Reboots that wait for you — and why auto-unlock betrays the point

The container pattern earns its keep at reboot, and the mechanics are worth understanding rather than merely trusting. With a passphrase prompt wired through systemd — the crypttab manual describes the unit machinery, and systemd-cryptsetup does the prompting — the machine stops during boot and waits for you. Nobody reboots their way into your data; the platform can restart the guest a hundred times and the encrypted set stays shut until a human with the passphrase arrives from their own keyboard.

The alternative is opening it manually over SSH after each boot, which is the same discipline with more typing and slightly fewer moving parts — the ssh manual is the entire toolchain, and the session is one command plus a passphrase. Either way the invariant is identical: key material enters the machine only when you, from your side, put it there. The account around the box stays minimal by the usual terms — inbox or token plus a 12-character password — so there is no second identity with standing access to confuse the picture.

The betrayal case deserves its own sentence, because it is the most common way good designs quietly fail: storing the unlock keyfile on the unencrypted root filesystem, so the container opens itself at boot without human help. That arrangement is theater — the platform reboots its way in exactly as if nothing were encrypted, and the passphrase prompt you deleted was the entire security model. If a reboot must be unattended, decide explicitly which data may be online unencrypted and keep the rest in the container; the decision, made consciously, is the design.

The cousin failure is half-automation: a keyfile held on a second machine and fetched over the network at boot. That moves the wire rather than removing it — the fetch is the new boot-time secret transfer, and it inherits every problem the KVM boot wire had. There is no free lunch here; every variant that removes the prompt reintroduces a path the prompt was guarding.

Prompt-at-boot or manual-open, the volume now has a heartbeat that depends on you. Its single point of failure is a few megabytes of metadata, which is what backup discipline is for — and that discipline has exactly one rule worth tattooing somewhere visible.

The header is the volume: backup it like you mean it

Lose the LUKS header and the passphrase becomes decorative: the header carries the encrypted volume keys, and without it the terabytes behind it are indistinguishable from noise to every device on earth. That asymmetry is the whole design — an attacker with the disk but not the header is no better off than one with neither — and it makes header backup the highest-value five minutes in the entire setup. Run cryptsetup luksHeaderBackup, verify the result with luksDump, and store the file somewhere that is not the same disk.

Off-box is the standard; encrypted-off-box is the standard worth meeting, since a plaintext header backup is a small plaintext pointer to everything the volume guards. Wrap the header file with GPG — the GnuPG documentation covers the encryption itself, built on OpenPGP — and keep a copy wherever your other irreplaceable small secrets live. Test a restore once, into a scratch container, because an untested backup is a hope rather than a copy. The passphrase deserves the same treatment: it and the header are the two halves of the volume, and either one lost alone is fatal.

The classic mistake is the backup on the same physical storage — same disk, same host, same snapshot chain. One hardware fault or one platform-side wipe takes the volume and its header together, and the discipline evaporates in the same incident it was meant to survive. The second classic mistake is backup without rehearsal: a header file that restored cleanly in a test two years ago may be corrupted, stale against a re-formatted volume, or simply not where you remember.

Version the backups lightly: keep the current header and the previous one, labeled with the volume's creation date, because headers change when keyslots change and an old header may not fit a volume whose slots were reworked. The storage cost is megabytes; the insurance is total.

Header safe, passphrase safe, reboots gated on you: the technical picture is complete, and what remains is the policy side — what the provider can and cannot do for you, which is shorter than most people assume and more reassuring once said out loud.

No escrow, no reset — and that is the product you bought

The provider-side answer to a lost passphrase is a shrug, and the shrug is the feature rather than a failure of service. No copy of your key exists anywhere in the platform, no escrow service stands behind it, and no reset flow can conjure one — the keys were yours end to end, which is precisely why a no-KYC account can afford to be identity-free. An inbox or a token plus a 12-character password opens the panel; nothing in it opens your volume, and nothing in the company's records could be subpoenaed, sold or leaked into opening it either.

This inverts the usual support experience, and it is worth internalizing before the incident rather than during: the support ticket flow can help with billing, network and panel actions, but a locked LUKS container is outside anyone's reach but yours, and the desk will not pretend otherwise. The minimum-data checkout and crypto checkout pages explain the account design that makes this possible — minimal data, minimal standing, maximal key custody — and the same logic that keeps identifiers out of the account keeps escrow out of the volume.

Where expectations break: people conflate the account credential with the volume key, because on most platforms the provider can indeed reset what it holds. The panel can rebuild a box from scratch; it cannot unlock a container it never saw. Recover the passphrase from your manager, restore the header backup, or accept the loss — those are the three doors, and the third is why the first two are mandatory habits rather than optional hygiene.

The flip side deserves equal billing: nobody else can be compelled, tricked or hacked into opening the volume either, because there is no one to ask. The property cuts in every direction at once, which is what a real boundary looks like, and it is the reason the setup steps above refuse every shortcut.

Custody understood, the last purchase decision is where such volumes belong: a working set wants a fast VPS, but cold archives want a different shape of box entirely, and the catalog has one built for exactly that.

Cold archives want the storage line, not a busy VPS

Encrypted cold storage is the container pattern's best case: data that is written rarely, read rarely, and valuable enough to guard, spending most of its life in the closed state that is the protected state. The storage line exists for exactly that shape — 1–5TB of NVMe, priced from $30 to $70 list and $24 per TB on the annual term. Order Storage Depot at $24 per TB on the annual term, put a LUKS container across the bulk of it, and open the volume only while you are actively writing or reading; the closed hours are the safe hours, and archives live almost entirely in them.

The rhythm differs from a working set, and it is worth scripting once. Open over SSH, synchronize with rsync or your backup tool of choice, verify the transfer, close, done — a session measured in minutes on either side of a week of closure. Snapshots of the storage box inherit the property: an encrypted container snapshot is ciphertext at rest, so platform-side copies do not weaken the design the way unencrypted backups do. The account stays as minimal as ever, settled in any of nineteen coins, with the usual 12-character password as the only credential on the panel side.

Where it breaks: treating an archive box as a working disk. A hot database on cold-storage infrastructure pays archive economics for latency it never gets, and the frequent open-close cycle erases the security benefit the box was chosen for — open volumes are plaintext volumes, and a volume that is always open is not an archive at all. Hot data belongs on the VPS line, encrypted with the same pattern if it is sensitive, and the two boxes complement rather than replace each other.

The second archive-specific discipline is verification: cold data fails silently, so schedule a periodic open-and-checksum pass and actually put it in the calendar. An archive whose integrity has never been re-verified is a guess with a price tag, and the guess gets worse every quiet quarter.

Between the two lines sits one final upgrade, and it is not about size or speed — it is about who touches the boot chain. That question is where virtual encryption honestly ends and metal begins.

When the boot chain itself must hold no third party, that is metal

The container pattern accepts one residual fact: the guest's unencrypted root still boots on a platform you do not administer, and the boot chain's first instructions are not yours. When even that must go — when the initrd carrying the key must be yours from the first instruction the CPU executes — the answer is a dedicated server, where the boot chain runs on hardware you control end to end. You own the initrd, the key never crosses a wire you do not own, and IPMI stands by as the console of last resort when a boot goes sideways at an hour no queue is watching.

Order Shield at $30.80 annual-eff and the argument becomes concrete: an 8-core CPU, 32GB of RAM and two 500GB drives under your exclusive boot control, racked within 2–4 hours of a credited invoice with IPMI handed over last. The list runs upward from there through EPYC and Xeon tiers to a dual-socket flagship, all on the same pricing engine and the same nineteen-coin checkout. The structural comparison is laid out in VPS vs dedicated bare-metal, and the hardware line starts at dedicated.

The trap metal does not remove is the one from earlier sections: a header backup on the same physical machine is still the same single point of failure, and metal gives the failure bigger teeth — bigger disks, more data, the same five minutes of negligence. The off-box rule scales up with the disk sizes, not down, and on metal the second disk is not a backup either; it shares the chassis, the power and the fate.

The honest accounting: metal buys a boundary the container pattern cannot draw, at a price the VPS line cannot match, and most threat models do not need to pay it. Pay it when the boot chain itself is in the threat model, not when the data merely feels important — importance is what the container pattern already covers at a fraction of the cost.

Container or metal, the operating sequence is the same shape — provision, build, gate the reboots, back up the header, verify. The final section runs it start to finish, in the order the steps actually execute on a real box.

The full-disk encryption, in the order to run it

Provision the box first: a VPS for the container pattern, or metal from dedicated when the boot chain itself must hold no third party — either signs up with an inbox or token plus a 12-character password and pays in any of nineteen coins, with a VPS live about 60s after credit. Nothing at provision time involves keys, because nothing at provision time is the provider's business; the boundary starts closed and stays that way from the first minute.

Build the container while the box is fresh: size it with fallocate, attach the loop device, cryptsetup luksFormat inside it, open, make the filesystem, and move the sensitive set in — keys, mail spools, database dumps, secrets. Immediately after the first luksFormat, back up the header off the box and encrypt the backup with GPG; a volume without a surviving header is a volume with a countdown clock on it, and the clock starts at the first power event, not at the first attack.

Wire the boot behavior next: a crypttab prompt that pauses reboots until you arrive, or a manual open over SSH each time — never a keyfile on the unencrypted root, which quietly hands the platform the key it was never supposed to see. Exercise the loop once before real data trusts it: reboot, watch it wait, open, verify the mount, restore the header backup into a scratch container once so the procedure is proven rather than documented. Then establish the rhythm — cold archives on the storage line at $24 per TB annual-eff, opened only while in active use, and hot sensitive data in containers on the VPS tier.

The endpoint is a simple invariant worth restating in one breath: every state except the one you are actively watching is ciphertext, the only key is yours, and the platform can restart, snapshot or decommission the hardware without learning anything. That is full-disk encryption on a root server, honestly bounded, entirely in your hands, and priced from the same $3.00 annual-eff floor as everything else in the catalog.