Saved in this browser and reused when you open other posts.
I recently stumbled on a GitHub issue where someone was trying to encrypt root disks of cloud VMs to protect them from the cloud provider itself. They were wrestling with a real chicken-and-egg problem: if Tang runs inside the provider's network, the provider can reach it. If it runs outside, how do your VMs reach it without storing credentials that the provider can also read?
It's a fair question and it got me thinking about a bigger one, what can a VPS provider actually see, and what can you realistically do about it?
The uncomfortable truth about shared infrastructure
Here's the thing nobody likes to talk about. Your VPS runs on a hypervisor that your provider controls. They have root on the host machine. That means they can, technically, dump the entire RAM of your instance at any time. Your LUKS passphrase, your database credentials, your private keys, all of it sits in memory while your system is running. A determined provider with hypervisor access can read it.
Does that mean encryption is pointless? No. But it means you need to be honest about what you're defending against and pick the right tools for each layer.
Protecting data at rest with Clevis and Tang
For data at rest, LUKS with Clevis and Tang is still one of the best setups you can run nowadays. I've been using it on my own servers and the concept is straightforward, your server auto-unlocks its encrypted disk at boot, but only when it can reach your Tang key server. No Tang, no unlock. Someone walks off with the physical disk or your provider decommissions the hardware? The data is garbage without the key exchange.
The trick for cloud/VPS setups is where you put the Tang server. My approach: grab a cheap AWS Lightsail instance and run Tang there. It's outside your VPS provider's infrastructure, it costs almost nothing, and you can lock down its firewall to only respond to your VPS IP addresses. Your LUKS keys never get transmitted over the wire and Tang just participates in a cryptographic key exchange using JOSE/JWK. The derived secret exists in RAM only long enough to unlock the volume.
And please, don't forget to add a backup LUKS keyslot with a regular passphrase. Store it somewhere safe. If your Tang server ever dies permanently, that backup keyslot is the only way back in.
I wrote a full walkthrough on setting this up: How to Auto-Unlock LUKS2 Encrypted Disks at Boot with Clevis and Tang
But what about live server memory?
This is where it gets harder. LUKS protects the disk when the system is off or the disk is pulled. But while the system is running, encryption keys sit in RAM. A malicious provider with hypervisor access can snapshot your VM's memory and extract whatever is in there. No amount of disk encryption helps against that.
So what do you do? Common ways to be protected.
Disable or encrypt swap.
Swap writes memory pages to disk in plaintext. That's your credentials, session tokens, whatever was in memory, now sitting on a disk the provider fully controls. Either turn it off completely or encrypt it.
# kill it swapoff -a sed -i '/swap/d' /etc/fstab
If you actually need swap (low-memory VPS), use encrypted swap so at least the written pages aren't readable after a reboot.
Disable core dumps.
When a process crashes, the kernel can write its entire memory space to a core dump file. That file might contain passwords, keys, tokens, anything the process had loaded. On a VPS, those dumps land on storage the provider controls.
echo '* hard core 0' >> /etc/security/limits.conf echo 'kernel.core_pattern=|/bin/false' >> /etc/sysctl.conf sysctl -p
Turn on kernel lockdown mode.
This prevents even root from reading raw memory through `/dev/mem` or `/dev/kmem`, and blocks `kexec` which could be used to load a new kernel that bypasses security. It won't stop the hypervisor, the hypervisor operates below the kernel. However, it closes a class of attacks from inside the guest.
# check current status cat /sys/kernel/security/lockdown # enable via GRUB # add lockdown=confidentiality to GRUB_CMDLINE_LINUX
Restrict ptrace.
By default, any process running as root can attach to another process and read its memory. Tightening `ptrace_scope` prevents this.
echo 'kernel.yama.ptrace_scope=2' >> /etc/sysctl.conf sysctl -p
Hardware-level memory encryption
This is the real answer if you want protection against a provider dumping your RAM: AMD SEV (Secure Encrypted Virtualization) and Intel TDX (Trust Domain Extensions). These technologies encrypt the VM's memory with keys that the hypervisor cannot access. The provider can still take a memory snapshot, but they get ciphertext.
AMD SEV has been around since the EPYC Naples generation. The newer SEV-SNP variant adds integrity protection on top of encryption, so the hypervisor can't tamper with memory contents either.
Some cloud providers already offer this:
- Azure VMs with AMD SEV-SNP
- GCP offers VMs with AMD SEV
- AWS Nitro Enclaves provide partial isolation
If your current VPS provider runs on AMD EPYC hardware, ask them about SEV support. Many providers have the hardware but haven't enabled the feature. It doesn't hurt to ask, you might be surprised.
When none of this is enough
Let's be real. If your data is truly sensitive, financial records, medical data, stuff that falls under KVKK or GDPR, all these mitigations are layers of defense but none of them eliminate the fundamental problem. You're running on someone else's machine.
The options at that point:
Dedicated bare-metal servers.
No hypervisor layer, no shared hardware. You rent the physical machine and you're the only tenant. Many hosting companies offer this ,Hetzner, OVH, Leaseweb, various Turkish and European providers. You get full control including BIOS settings, TPM if the hardware has one, and the peace of mind that nobody else's code is running on your CPU.
Colocation.
You buy your own hardware, ship it to a datacenter, and they provide power, cooling, and network. You hold the keys, literally and figuratively. The DC staff can pull the power cable but they can't easily read your encrypted disks without your keys.
Self-hosting with virtualization.
If you have the space and the internet connection, run your own Proxmox or ESXi host. You control everything down to the firmware. This is what I do for workloads where I need to be absolutely sure about the trust chain.
The tradeoff (Adam Smith :)) is obvious, more control means more operational burden. Hardware failures, UPS batteries, cooling, ISP outages, all your problem now. But for the right workloads, it's worth it.
My setup
I run a hybrid approach. Public-facing stuff like WordPress sites sits behind Cloudflare on shared hosting, I don't care if the hosting provider can theoretically read the PHP files serving a public blog. But infrastructure that handles credentials, CI/CD pipelines, private Git repos, database backups, that runs on hardware I control, with LUKS encryption, Clevis/Tang for automated unlock, and WireGuard tunnels connecting everything.
Is it perfect? No setup is. But it forces me to think about what actually needs protection versus what I can afford to expose. That distinction matters more than any single technology choice.