[Home](https://servhidden.com/) / [Privacy Hosting Guides](https://servhidden.com/guides) / Full-Disk Encryption on a VPS: LUKS Setup and What It Really Protects Operations # Full-Disk Encryption on a VPS Disk encryption answers one question well and several others not at all. Here is how to set up LUKS on a rented server — an encrypted data volume, full-root encryption with dropbear remote unlock, or bare metal encrypted at install — and how to tell which of your threats it actually removes. [Read the guide](#guide-body) [FAQ](#guide-faq) ## On this page - [Guide](#guide-body) - [FAQ](#guide-faq) - [Related guides](#guide-related) - [Recommended pages](#guide-cta) No KYC Crypto Only No Logs DMCA Ignored Full Root NVMe SSD 17 min read Updated Aug 2026 On this page [01What encryption at rest actually protects against](#what-encryption-at-rest-actually-protects-against) [02Why a VPS is not a laptop](#why-a-vps-is-not-a-laptop) [03The three arrangements worth deploying](#the-three-arrangements-worth-deploying) [04Encrypting a data volume on a running VPS](#encrypting-a-data-volume-on-a-running-vps) [05Full-root encryption with remote unlock over SSH](#full-root-encryption-with-remote-unlock-over-ssh) [06The two settings that matter, and the small-VPS trap](#the-two-settings-that-matter-and-the-small-vps-trap) [07Swap, logs, snapshots — the parts people forget](#swap-logs-snapshots-the-parts-people-forget) [08Where the key lives is the whole design](#where-the-key-lives-is-the-whole-design) [09What your host can see, and where jurisdiction takes over](#what-your-host-can-see-and-where-jurisdiction-takes-over) [10Nine mistakes that turn encryption into decoration](#nine-mistakes-that-turn-encryption-into-decoration) [11So is it worth doing on a VPS?](#so-is-it-worth-doing-on-a-vps) [FAQCommon questions](#guide-faq) [→Recommended pages](#guide-cta) 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](https://servhidden.com/anonymous-hosting). 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. | Situation | Does LUKS help? | | --- | --- | | A drive is decommissioned, returned under warranty or resold at end of life | **Yes** — the textbook case, and far more common than any dramatic one | | The machine is seized powered off, or storage is pulled from the rack | **Yes**, provided the key is not sitting on the machine | | The provider copies your virtual disk while the server is running | The copy is ciphertext — but the key is in RAM on the same physical host | | A hypervisor-level adversary dumps guest memory | **No.** An unlocked volume's key lives in kernel memory | | Someone gets root on your running server | **No.** The filesystem is mounted; they read it exactly as you do | | Your backups leave the box in plaintext | **No.** That is solved at the source, not at the destination | | You are ordered to produce the passphrase | Not a technical question — covered further down | 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. Encryption at rest answers one question well: what a closed volume is worth to whoever is holding it. Where the key lives decides everything else. ## 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](https://servhidden.com/guides/vps-vs-dedicated-for-privacy) walks the same trust boundary from the hardware side, and [our honest answer on offshore anonymity](https://servhidden.com/guides/is-offshore-hosting-truly-anonymous) 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. | Arrangement | What it covers | Cost of a reboot | Lock-out risk | | --- | --- | --- | --- | | **1.** Encrypted data volume, opened by hand after boot | The data that matters — database, mail store, documents, keys | Server returns on its own; the vault waits for you | Very low | | **2.** Full-root LUKS with dropbear remote unlock | Everything: system logs, configuration, swap, the lot | Every reboot needs you, over SSH, before boot completes | Real — a broken initramfs network config strands the box | | **3.** Bare metal encrypted at install, passphrase typed over IPMI | Everything, with no hypervisor underneath the key | Every reboot needs you, at the out-of-band console | Low — IPMI is an independent path in | 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](https://servhidden.com/dedicated) 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. **The migration trap.** Copying plaintext into an encrypted vault does not unwrite it from where it came. On virtualised storage shred is unreliable by design — the layer you are overwriting is not the layer that stores the data. If the material is genuinely sensitive, start encrypted on a fresh server rather than migrating into encryption on the old one. ## 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](https://servhidden.com/vps) 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. **Do not deploy this without an out-of-band console.** If dropbear fails to come up, SSH cannot help you — the only way back is a console that works before the operating system does. Every ServHidden VPS ships VNC console access and every dedicated server has full IPMI/KVM, so the recovery path exists. On a provider without one, arrangement one is the only responsible choice. ## 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](https://servhidden.com/use-cases/backup-server-hosting) 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](https://servhidden.com/guides/choosing-an-offshore-jurisdiction), or in shorter form through the [jurisdiction selector](https://servhidden.com/jurisdiction-selector) and the [locations page](https://servhidden.com/locations). 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](https://servhidden.com/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](https://servhidden.com/guides/server-opsec-staying-anonymous) 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](https://servhidden.com/guides/first-hour-vps-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](https://servhidden.com/dedicated) 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. FAQ ## Encrypting a server — common questions ### 01 Does full-disk encryption protect my VPS from the hosting provider? Not while the server is running. Once you unlock the volume the key is in kernel memory on the physical host, and a hypervisor-level adversary can reach memory. What encryption does protect against is anyone holding your storage while it is closed: decommissioned or resold drives, a re-issued volume, a machine seized powered off. If your threat model genuinely includes the host, the answer is dedicated bare metal encrypted at install with a passphrase the host never receives, not a different cipher on a VPS. ### 02 Can I encrypt an existing VPS without reinstalling it? You can encrypt your data without reinstalling: create a LUKS container file with fallocate, format it with cryptsetup luksFormat, open it, put a filesystem on it and move your database, mail store and keys inside. That takes about fifteen minutes and no downtime beyond restarting the affected services. Encrypting the root filesystem in place is a different matter — it is possible, it is fragile, and reinstalling from a custom ISO with encrypted LVM is both faster and safer. ### 03 How does remote unlock work if nobody is at the console? A small SSH server, dropbear, is embedded in the initramfs and starts before the encrypted root is opened. You install dropbear-initramfs, add a public key, give the initramfs a static IP, rebuild it, and on every boot you connect on the dropbear port and run cryptroot-unlock. The passphrase is typed by you and never stored on the server. Do not deploy it without an out-of-band console — VNC on a VPS, IPMI on a dedicated server — because if dropbear fails to come up, SSH cannot rescue you. ### 04 Does LUKS slow a server down? On any CPU with AES-NI hardware acceleration, effectively no. AES-XTS runs at several gigabytes per second per core, which is above what a single virtual disk delivers, so the practical cost is a few percent of CPU under heavy I/O and a small increase in latency. Run cryptsetup benchmark on your own machine to see real numbers. Without AES-NI the overhead becomes significant, and that is the only situation where an alternative cipher is worth considering. ### 05 What happens if I lose the passphrase? The data is gone. There is no recovery mechanism, no provider-side reset and no back door — that is the property you were buying. Two things reduce the risk: LUKS2 supports multiple key slots, so add a second long passphrase or a key file kept somewhere else, and back up the LUKS header with cryptsetup luksHeaderBackup and store it off the server. A damaged header destroys the volume just as thoroughly as a forgotten passphrase. ### 06 Is disk encryption legal, and can I be forced to hand over the key? Using disk encryption is legal in all seven jurisdictions we operate in, and it is ordinary practice rather than a suspicious act. Compelled disclosure is a separate question and it follows the person, not the hardware: the United Kingdom, France and Australia are among the countries whose law can require someone to produce a decryption key or face a penalty for refusing. That is determined by where you are and which court has reach over you, and no server configuration changes it. ### 07 Does encryption help if the server is seized while it is running? No. A running server has the volume mounted and the key in memory, so anyone with access reads the filesystem exactly as you do — and equipment is normally taken powered on for that reason. Encryption at rest is protection for a closed volume. If sudden loss of custody is part of your threat model, what helps is keeping less on the machine, holding backups elsewhere encrypted at the source, and choosing a jurisdiction where the legal process to reach the machine is slow and narrow. ### 08 Is a LUKS container file as secure as encrypting a whole block device? Cryptographically, yes — the same LUKS2 header, cipher and key derivation apply either way, and the container behaves as a block device once opened. A separate disk is marginally tidier and avoids fragmentation on the host filesystem, but on a single-disk VPS the container file is the standard approach and gives up nothing that matters. What changes security is not the container format, it is where the key lives and which data you actually put inside. Related guides ## Keep reading [### How to Choose an Offshore Hosting Jurisdiction in 2026 Buying A practical decision framework for picking an offshore jurisdiction: data-retention law, MLAT exposure, DMCA stance, court speed and real-world enforcement — country by country. 6-question FAQ](https://servhidden.com/guides/choosing-an-offshore-jurisdiction) [### VPS vs Dedicated Server for Privacy-Critical Workloads Buying When a VPS is fine, when shared tenancy is a liability, and when bare metal is the only honest answer. Hardware isolation, hypervisor risk, and cost vs threat model. 6-question FAQ](https://servhidden.com/guides/vps-vs-dedicated-for-privacy) [### Self-Hosted VPN on a No-KYC VPS: WireGuard vs OpenVPN Operations Why a self-hosted VPN beats commercial providers, and how WireGuard and OpenVPN really compare on privacy, performance and operational risk in 2026. 6-question FAQ](https://servhidden.com/guides/self-hosted-vpn-wireguard-vs-openvpn) [### RTX 4090 vs H100 SXM5 for AI Inference (and Where the RTX 5090 Fits) Buying Buying guide: which NVIDIA GPU for self-hosted LLM, image, video, speech, and fine-tuning workloads in 2026. RTX 4090 vs RTX 5090 vs H100 SXM5 vs dual H100 — VRAM, throughput, $/token, when each wins. 6-question FAQ](https://servhidden.com/guides/rtx-4090-vs-h100-for-ai-inference) [### Offshore Windows RDP for MT4 / MT5 / cTrader Forex Trading Operations Complete guide: why a Windows RDP for Forex trading, how to choose a low-latency offshore jurisdiction, MT4 / MT5 / cTrader / Expert Advisor setup, latency to broker servers, and the no-KYC checkout path. 6-question FAQ](https://servhidden.com/guides/offshore-windows-rdp-for-forex-trading) [### DMCA-Ignored Hosting Explained: What It Really Means in 2026 Buying What "DMCA ignored" hosting genuinely buys you, which jurisdictions actually back it up, the workloads that need it, and the copyright traps the term doesn't cover. 6-question FAQ](https://servhidden.com/guides/dmca-ignored-hosting-explained) [### Anonymous Domain Registration with Crypto: WHOIS Privacy in 2026 Privacy A practical 2026 guide to registering domains without revealing your identity: WHOIS regimes by TLD, registrar choice, crypto payment options, and the operational mistakes that leak you anyway. 6-question FAQ](https://servhidden.com/guides/anonymous-domain-registration-with-crypto) [### Crypto Payments for Hosting: Monero vs Bitcoin vs USDT Privacy How payment coin affects what your host learns about you. Privacy, fees, finality and chain analysis exposure for XMR, BTC and USDT — with a clear recommendation. 6-question FAQ](https://servhidden.com/guides/crypto-payments-monero-vs-bitcoin-vs-usdt) [### Is Offshore Hosting Truly Anonymous? An Honest Answer Privacy Offshore, no-KYC hosting removes the identity a normal host collects — but "anonymous" depends on payment, provider logging and your own opsec. Here is what is really traceable. 6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-truly-anonymous) [### The First Hour of VPS Hardening: A Checklist Operations A concrete, ordered checklist to secure a new VPS in under an hour: SSH keys, a firewall, fail2ban, automatic updates, and the attack-surface reduction that stops most opportunistic attacks. 6-question FAQ](https://servhidden.com/guides/first-hour-vps-hardening-checklist) [### What Is No-KYC Hosting? Definition, Legality & How It Works Privacy No-KYC hosting lets you rent a server with zero identity verification — no name, no email, no ID. Here is exactly what it means, how it works technically, whether it is legal, and how to pick a genuine provider. 6-question FAQ](https://servhidden.com/guides/what-is-no-kyc-hosting) [### Is Offshore Hosting Legal? The Honest 2026 Answer Buying Offshore hosting is legal — for you and for the provider. Here is what the term really means, where the legal line actually sits, the myths worth dropping, and how to use it responsibly. 6-question FAQ](https://servhidden.com/guides/is-offshore-hosting-legal) [### How to Pay for Hosting with Monero (XMR) — Step by Step Privacy A step-by-step guide to paying for a VPS or dedicated server with Monero (XMR): why XMR is the most private option, how to get it, and how the checkout works — from invoice to a running server in minutes. 6-question FAQ](https://servhidden.com/guides/how-to-pay-for-hosting-with-monero) [### How to Host a Website Anonymously — A Practical 2026 Guide Privacy A practical, layered guide to hosting a website with no identity attached: the account, the payment, the domain, the jurisdiction, your connection and the content — each layer explained. 6-question FAQ](https://servhidden.com/guides/how-to-host-a-website-anonymously) [### How to Set Up a WireGuard VPN on a VPS — Step-by-Step Guide Operations Build your own private VPN on a VPS with WireGuard: why a self-hosted VPN beats a commercial one, the full setup from install to a connected client, and how to harden it. 6-question FAQ](https://servhidden.com/guides/how-to-set-up-wireguard-vpn-on-a-vps) [### How to Self-Host an LLM on a GPU Server — 2026 Guide Operations Run your own large language model on a rented GPU server: why self-hosting beats an API, which GPU and model to choose, the setup with Ollama or vLLM, and what it costs. 6-question FAQ](https://servhidden.com/guides/self-host-an-llm-on-a-gpu-server) [### Bulletproof Hosting vs Offshore Hosting — What Is the Difference? Buying Bulletproof hosting and offshore hosting are constantly confused — and they are not the same thing. Here is the real difference, why it matters, and which one you actually want. 6-question FAQ](https://servhidden.com/guides/bulletproof-vs-offshore-hosting) [### How to Buy a VPS with Bitcoin — Step-by-Step (2026) Buying A beginner-friendly walkthrough of buying a VPS with Bitcoin: getting BTC, choosing a plan, paying the invoice, and what you get — a running server with no card and no name attached. 6-question FAQ](https://servhidden.com/guides/how-to-buy-a-vps-with-bitcoin) [### Best Countries for DMCA-Ignored Hosting in 2026 Buying Where to host when you want servers beyond the easy reach of US-style takedowns: the jurisdictions that work, what DMCA-ignored really means, and how to choose. 6-question FAQ](https://servhidden.com/guides/best-countries-for-dmca-ignored-hosting) [### How to Host a Tor Hidden Service (.onion Site) — 2026 Guide Operations Set up a Tor onion service on a VPS: what a hidden service is, why it is the strongest form of anonymous hosting, the full setup, and how to keep it actually anonymous. 6-question FAQ](https://servhidden.com/guides/how-to-host-a-tor-hidden-service) [### Offshore Mail Server Setup — Self-Host Private Email in 2026 Operations Run your own private email server on an offshore VPS: why self-host email, what you need, the realistic setup with an all-in-one mail stack, and how to get deliverability right. 6-question FAQ](https://servhidden.com/guides/offshore-mail-server-setup) [### Crypto Node Hosting Guide — Run a Blockchain Node on a VPS Operations How to host a blockchain node on a server: why run your own node, sizing the server for Bitcoin, Ethereum, Monero and more, the setup, and keeping it private. 6-question FAQ](https://servhidden.com/guides/crypto-node-hosting-guide) [### GPU Hosting for Stable Diffusion — Run Your Own Image Server Operations Run Stable Diffusion on your own GPU server: why self-host image generation, which GPU to pick, the setup with a web UI, and what it costs versus a hosted service. 6-question FAQ](https://servhidden.com/guides/gpu-hosting-for-stable-diffusion) [### Server OpSec — Staying Anonymous When You Run a Server Privacy Operational security for anyone running an anonymous server: the mistakes that deanonymise people, the habits that prevent them, and how to keep identities truly separate. 6-question FAQ](https://servhidden.com/guides/server-opsec-staying-anonymous) [### Seedbox Setup Guide — Build Your Own Private Seedbox in 2026 Operations How to build your own seedbox on a server: what a seedbox is, sizing it, installing a torrent client with a web UI, and keeping it private and secure. 6-question FAQ](https://servhidden.com/guides/seedbox-setup-guide) [### How to Bypass DPI Censorship with Your Own VPS (2026 Guide) Privacy Your VPN stopped working? How to bypass DPI censorship with your own VPS: what deep packet inspection actually detects, which of the five 2026 protocols beats which block, and a full VLESS+REALITY walkthrough. 6-question FAQ](https://servhidden.com/guides/bypass-dpi-censorship-with-your-own-vps) [### Hiding Your Origin Server IP: CDNs, Reverse Proxies and What Still Leaks Privacy Whether to put a CDN in front of an offshore server: what it hides, the abuse desk you inherit, the six ways an origin IP leaks anyway, and how to audit yours. 8-question FAQ](https://servhidden.com/guides/hiding-your-origin-server-ip) [### VPS Backup Strategy: Encrypted, Off-Site and Actually Restorable Operations Your host keeps no backups. What really destroys servers, why push backups die with them, restic vs Borg, the keys everyone forgets, and how to test a restore. 8-question FAQ](https://servhidden.com/guides/vps-backup-strategy) [### Self-Hosting Matrix: Federation, Metadata and What E2EE Doesn’t Hide Operations What a Matrix homeserver really gives you: Synapse vs Conduit, the server_name you can never change, media that eats the disk, and what federation still reveals. 8-question FAQ](https://servhidden.com/guides/self-host-a-matrix-server) [### How to Migrate a Website to Offshore Hosting Without Downtime Operations The order that makes a host migration boring: lower the DNS TTL days ahead, run both servers in parallel, freeze writes for minutes rather than hours — and clean up the passive-DNS, Certificate Transparency and WHOIS trail the move leaves behind. 8-question FAQ](https://servhidden.com/guides/migrate-website-to-offshore-hosting) [### How to Self-Host a Crypto Payment Gateway with BTCPay Server Operations Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out. 8-question FAQ](https://servhidden.com/guides/self-host-a-crypto-payment-gateway) ## Encrypt it on hardware chosen for the purpose KVM VPS with VNC console and custom ISO upload, or bare-metal dedicated servers with IPMI and LUKS at install — across seven offshore jurisdictions, no KYC, crypto only. Your passphrase, your key, no identity attached. [View VPS Plans](https://servhidden.com/vps) [Dedicated Servers](https://servhidden.com/dedicated) [Private Hosting](https://servhidden.com/anonymous-hosting) ## Structured data (JSON-LD) ```json { "@context": "https://schema.org", "@type": "Organization", "@id": "https://servhidden.com/#organization", "name": "ServHidden", "url": "https://servhidden.com", "description": "Offshore VPS & dedicated servers in 7 offshore jurisdictions. No KYC, no logs, crypto only. Privacy by architecture.", "logo": { "@type": "ImageObject", "url": "https://servhidden.com/ServHidden.webp", "width": 512, "height": 512 }, "foundingDate": "2025", "areaServed": [ { "@type": "Country", "name": "Iceland" }, { "@type": "Country", "name": "Panama" }, { "@type": "Country", "name": "Moldova" }, { "@type": "Country", "name": "Romania" }, { "@type": "Country", "name": "Switzerland" }, { "@type": "Country", "name": "Netherlands" }, { "@type": "Country", "name": "Russia" } ], "knowsAbout": [ "Offshore hosting", "Offshore VPS", "Bare-metal dedicated servers", "DMCA-ignored hosting", "No KYC hosting", "Cryptocurrency payments", "Privacy engineering", "Token-based authentication", "Anonymous domain name registration", "No-KYC domain registrar", "WHOIS privacy", "Cheap .com domains", "Crypto-paid domain names", "NVIDIA GPU compute", "Windows RDP hosting", "Agentic commerce" ], "contactPoint": { "@type": "ContactPoint", "contactType": "customer support", "url": "https://servhidden.com/contact", "availableLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] }, "sameAs": [ "https://servhidden.com/canary", "https://servhidden.com/press" ] } ``` ```json { "@context": "https://schema.org", "@type": "WebSite", "@id": "https://servhidden.com/#website", "url": "https://servhidden.com", "name": "ServHidden", "publisher": { "@id": "https://servhidden.com/#organization" }, "inLanguage": [ "en", "ru", "zh", "es", "fr", "de", "pt", "ar", "ja", "ko", "hi", "id", "it", "tr", "fa", "vi" ] } ``` ```json { "@context": "https://schema.org", "@type": "Article", "headline": "Full-Disk Encryption on a VPS: LUKS Setup and What It Really Protects", "description": "How to encrypt a VPS with LUKS: encrypted data volumes, full-root encryption with remote unlock over SSH, the settings that matter on a small server, and an honest account of what disk encryption stops.", "image": "https://servhidden.com/assets/img/guides/full-disk-encryption-on-a-vps.webp?v=1787136235", "author": { "@type": "Organization", "@id": "https://servhidden.com/#editorial", "name": "ServHidden Editorial", "url": "https://servhidden.com/about", "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.", "knowsAbout": [ "Offshore hosting jurisdictions", "Data retention law", "MLAT and judicial cooperation", "WireGuard and OpenVPN deployment", "Tor relay operation", "Monero and Bitcoin payment privacy", "KVM virtualization and bare-metal hosting", "DMCA-ignored hosting" ], "parentOrganization": { "@id": "https://servhidden.com/#organization" } }, "publisher": { "@id": "https://servhidden.com/#organization" }, "datePublished": "2026-08-19T00:00:00+00:00", "dateModified": "2026-08-19T00:00:00+00:00", "mainEntityOfPage": "https://servhidden.com/guides/full-disk-encryption-on-a-vps", "inLanguage": "en", "keywords": "VPS full disk encryption, encrypt VPS with LUKS, LUKS remote unlock dropbear, encrypted VPS hosting, cryptsetup LUKS2 setup, encryption at rest server, protect data if server is seized, dedicated server disk encryption", "articleSection": "Operations", "wordCount": 3330 } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "Does full-disk encryption protect my VPS from the hosting provider?", "acceptedAnswer": { "@type": "Answer", "text": "Not while the server is running. Once you unlock the volume the key is in kernel memory on the physical host, and a hypervisor-level adversary can reach memory. What encryption does protect against is anyone holding your storage while it is closed: decommissioned or resold drives, a re-issued volume, a machine seized powered off. If your threat model genuinely includes the host, the answer is dedicated bare metal encrypted at install with a passphrase the host never receives, not a different cipher on a VPS." } }, { "@type": "Question", "name": "Can I encrypt an existing VPS without reinstalling it?", "acceptedAnswer": { "@type": "Answer", "text": "You can encrypt your data without reinstalling: create a LUKS container file with fallocate, format it with cryptsetup luksFormat, open it, put a filesystem on it and move your database, mail store and keys inside. That takes about fifteen minutes and no downtime beyond restarting the affected services. Encrypting the root filesystem in place is a different matter — it is possible, it is fragile, and reinstalling from a custom ISO with encrypted LVM is both faster and safer." } }, { "@type": "Question", "name": "How does remote unlock work if nobody is at the console?", "acceptedAnswer": { "@type": "Answer", "text": "A small SSH server, dropbear, is embedded in the initramfs and starts before the encrypted root is opened. You install dropbear-initramfs, add a public key, give the initramfs a static IP, rebuild it, and on every boot you connect on the dropbear port and run cryptroot-unlock. The passphrase is typed by you and never stored on the server. Do not deploy it without an out-of-band console — VNC on a VPS, IPMI on a dedicated server — because if dropbear fails to come up, SSH cannot rescue you." } }, { "@type": "Question", "name": "Does LUKS slow a server down?", "acceptedAnswer": { "@type": "Answer", "text": "On any CPU with AES-NI hardware acceleration, effectively no. AES-XTS runs at several gigabytes per second per core, which is above what a single virtual disk delivers, so the practical cost is a few percent of CPU under heavy I/O and a small increase in latency. Run cryptsetup benchmark on your own machine to see real numbers. Without AES-NI the overhead becomes significant, and that is the only situation where an alternative cipher is worth considering." } }, { "@type": "Question", "name": "What happens if I lose the passphrase?", "acceptedAnswer": { "@type": "Answer", "text": "The data is gone. There is no recovery mechanism, no provider-side reset and no back door — that is the property you were buying. Two things reduce the risk: LUKS2 supports multiple key slots, so add a second long passphrase or a key file kept somewhere else, and back up the LUKS header with cryptsetup luksHeaderBackup and store it off the server. A damaged header destroys the volume just as thoroughly as a forgotten passphrase." } }, { "@type": "Question", "name": "Is disk encryption legal, and can I be forced to hand over the key?", "acceptedAnswer": { "@type": "Answer", "text": "Using disk encryption is legal in all seven jurisdictions we operate in, and it is ordinary practice rather than a suspicious act. Compelled disclosure is a separate question and it follows the person, not the hardware: the United Kingdom, France and Australia are among the countries whose law can require someone to produce a decryption key or face a penalty for refusing. That is determined by where you are and which court has reach over you, and no server configuration changes it." } }, { "@type": "Question", "name": "Does encryption help if the server is seized while it is running?", "acceptedAnswer": { "@type": "Answer", "text": "No. A running server has the volume mounted and the key in memory, so anyone with access reads the filesystem exactly as you do — and equipment is normally taken powered on for that reason. Encryption at rest is protection for a closed volume. If sudden loss of custody is part of your threat model, what helps is keeping less on the machine, holding backups elsewhere encrypted at the source, and choosing a jurisdiction where the legal process to reach the machine is slow and narrow." } }, { "@type": "Question", "name": "Is a LUKS container file as secure as encrypting a whole block device?", "acceptedAnswer": { "@type": "Answer", "text": "Cryptographically, yes — the same LUKS2 header, cipher and key derivation apply either way, and the container behaves as a block device once opened. A separate disk is marginally tidier and avoids fragmentation on the host filesystem, but on a single-disk VPS the container file is the standard approach and gives up nothing that matters. What changes security is not the container format, it is where the key lives and which data you actually put inside." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://servhidden.com/" }, { "@type": "ListItem", "position": 2, "name": "Privacy Hosting Guides", "item": "https://servhidden.com/guides" }, { "@type": "ListItem", "position": 3, "name": "Full-Disk Encryption on a VPS: LUKS Setup and What It Really Protects", "item": "https://servhidden.com/guides/full-disk-encryption-on-a-vps" } ] } ``` ```json { "@context": "https://schema.org", "@type": "HowTo", "name": "Full-Disk Encryption on a VPS", "description": "How to encrypt a VPS with LUKS: encrypted data volumes, full-root encryption with remote unlock over SSH, the settings that matter on a small server, and an honest account of what disk encryption stops.", "image": "https://servhidden.com/assets/img/guides/full-disk-encryption-on-a-vps.webp?v=1787136235", "inLanguage": "en", "totalTime": "PT1H", "step": [ { "@type": "HowToStep", "position": 1, "name": "What encryption at rest actually protects against", "text": "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. SituationDoes LUKS help? A drive is decommissioned, returned under warra…", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#what-encryption-at-rest-actually-protects-against" }, { "@type": "HowToStep", "position": 2, "name": "Why a VPS is not a laptop", "text": "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 availabilit…", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#why-a-vps-is-not-a-laptop" }, { "@type": "HowToStep", "position": 3, "name": "The three arrangements worth deploying", "text": "There is no single correct setup — there is the one whose failure mode you can live with. These three cover essentially every real case. ArrangementWhat it coversCost of a rebootLock-out risk 1. Encrypted data volume, opened by hand after bootThe data that matters — database, mail store, document…", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#the-three-arrangements-worth-deploying" }, { "@type": "HowToStep", "position": 4, "name": "Encrypting a data volume on a running VPS", "text": "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 …", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#encrypting-a-data-volume-on-a-running-vps" }, { "@type": "HowToStep", "position": 5, "name": "Full-root encryption with remote unlock over SSH", "text": "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 answ…", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#full-root-encryption-with-remote-unlock-over-ssh" }, { "@type": "HowToStep", "position": 6, "name": "The two settings that matter, and the small-VPS trap", "text": "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 …", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#the-two-settings-that-matter-and-the-small-vps-trap" }, { "@type": "HowToStep", "position": 7, "name": "Swap, logs, snapshots — the parts people forget", "text": "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 /e…", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#swap-logs-snapshots-the-parts-people-forget" }, { "@type": "HowToStep", "position": 8, "name": "Where the key lives is the whole design", "text": "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 …", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#where-the-key-lives-is-the-whole-design" }, { "@type": "HowToStep", "position": 9, "name": "What your host can see, and where jurisdiction takes over", "text": "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: fu…", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#what-your-host-can-see-and-where-jurisdiction-takes-over" }, { "@type": "HowToStep", "position": 10, "name": "Nine mistakes that turn encryption into decoration", "text": "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 …", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#nine-mistakes-that-turn-encryption-into-decoration" }, { "@type": "HowToStep", "position": 11, "name": "So is it worth doing on a VPS?", "text": "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 th…", "url": "https://servhidden.com/guides/full-disk-encryption-on-a-vps#so-is-it-worth-doing-on-a-vps" } ] } ```