Ask most engineers what a VPS is and you get some version of “a server that happens to be virtual” – a machine in a rack, just smaller and cheaper. Useful for capacity planning, misleading for threat modelling, because it implies a boundary that does not exist. The line between your VPS and the machine underneath it is enforced by software the provider controls. Knowing what that means is a prerequisite for deciding which workloads belong there.
What the hypervisor can read on an ordinary VPS
On a standard KVM deployment without confidential computing extensions, your guest’s memory is ordinary memory in the host’s address space. The hypervisor allocates it, maps it, and can read it.
This is not an exploit. It is administrative tooling working as designed. virsh dump writes the full memory image of a running guest to a file on the host. The QEMU monitor exposes equivalent primitives for reading guest physical memory directly. Both exist because operators need them for debugging, crash analysis, and migration – and both are available to anyone with root on the host.
What lands in that dump is everything a running system holds in RAM: environment variables, decrypted database contents, session tokens, TLS session keys, SSH agent material, and the contents of any file currently open. Your disk image is a file on the host’s storage, readable with the same privileges.
That is the baseline: on ordinary virtualisation, technical measures do not remove the operator from your threat model – they change cost and effort. Which makes the operator’s own commitments load-bearing rather than reassuring, and is why providers such as PrivateAlps Swiss VPS hosting publish those specifics instead of leaving them assumed.
Does full-disk encryption inside the guest solve it?
Partially. LUKS or equivalent guest-level encryption protects data at rest – a stolen disk image, a decommissioned drive, a backup that leaves the facility. Real risks, correctly addressed.
It does not protect a running system. Once the volume is unlocked, the master key sits in guest kernel memory for as long as it stays mounted, which for a production server means permanently. A host-side memory dump captures the key alongside the data it protects.
Where copies of your data exist that you did not make
Three mechanisms routinely produce copies outside your view.
Snapshots. Snapshot types differ: disk-only snapshots capture the volume, while a full system checkpoint of a running guest also captures RAM. Which one your provider takes, and when, is their operational choice. Either way the file lives on provider infrastructure, often on shared storage, with retention governed by their policy rather than yours.
Live migration. Moving a running guest between physical hosts copies its memory across the network. QEMU and libvirt support TLS, but it is opt-in and non-trivial: nine options in qemu.conf, a pre-configured PKI, version requirements on both ends, and orchestrator fallback to plaintext when either host lacks it. OpenStack carries a case, filed in 2021, where operators configured TLS by the guide and migration still ran over plain TCP with nothing in the logs to indicate it – only packet capture revealed it. That bug may since be fixed; silent fallback as a class of failure is the point. The migration is invisible from inside the guest.
Deletion that isn’t. When you delete a volume, what happens next depends on the storage backend. Thin-provisioned and replicated systems may retain blocks until they are overwritten, and replicas may sit on nodes you never touched. “Deleted” is a control-plane state, not a physical one.
None of the three is visible from inside the guest, so the only way to know how they behave is to read what the operator publishes. Some document snapshot retention, migration transport, and deletion semantics explicitly; PrivateAlps is among them. Most publish nothing, and the absence is itself an answer.
What confidential computing changes, and what it doesn’t
AMD SEV-SNP and Intel TDX exist to remove the hypervisor from the trusted set. Under both, guest memory is encrypted with keys the host cannot reach; TDX returns zeroes when the hypervisor tries to read memory owned by a trust domain. A genuine architectural change, not a policy promise.
It is not absolute. HECKLER, at USENIX Security 2024, showed a hypervisor injecting malicious interrupts could bypass authentication in OpenSSH and sudo on both SEV-SNP and TDX, obtaining root inside the confidential VM. Heracles, at CCS 2025, exploited AMD’s decision to let the hypervisor read guest ciphertext, building a chosen-plaintext side channel out of ciphertext collisions.
The result that matters most for hosting is TEE.fail, disclosed in October 2025 by researchers at Georgia Tech and Purdue. Server TEEs on DDR5 rely on deterministic AES-XTS without integrity or replay protection at the controller level, which makes ciphertext dictionaries practical. The team built a DDR5 memory bus interposer for under a thousand dollars from off-the-shelf and secondhand parts, and extracted cryptographic keys from Intel TDX and from AMD SEV-SNP with Ciphertext Hiding enabled – in some cases attestation keys from fully updated machines in trusted status, enough to sign arbitrary reports with no TEE behind them.
Two things matter more than the attack. It requires physical access – precisely the position a hosting provider occupies. And Intel’s published response states the work does not change its existing position that physical attacks of this kind are out of scope. That is not evasion but the documented boundary of the threat model: confidential computing defends against a compromised hypervisor, not against the party holding the hardware.
What actually reduces exposure
Every technical control rests on an assumption about the party holding the hardware. Encryption at rest handles the offline case; confidential computing raises the cost of the online one substantially. Neither removes the operator from the threat model, because the operator is standing next to the memory bus – and the vendors say so themselves.
What remains is not technical. It is the operator’s posture – what they log, how long they keep it, what happens when a request arrives – and the legal regime binding them, which determines what they can be compelled to do regardless of preference. A provider in one jurisdiction can be ordered to preserve and hand over a snapshot; a provider in another faces meaningfully higher thresholds.
That makes provider selection an architectural decision rather than a procurement one. The questions are the same whoever you pick: what is captured, how long it persists, who can compel its release, and what the operator has committed to in writing. Answer them before the workload lands – operators who treat the question as central have the answers written down already, and the rest improvise under pressure.
Common questions
Can a hosting provider read my VPS memory? On a standard virtualised deployment, yes. Guest memory sits in the host’s address space, and standard tooling such as virsh dump writes a full memory image of a running guest to the host filesystem.
Does encrypting my VPS disk stop the provider from seeing my data? It protects data at rest but not a running system. While the volume is mounted, the master key stays in guest kernel memory and is captured by any host-side memory dump.
Do AMD SEV-SNP or Intel TDX make a VPS fully private? They remove the hypervisor from the trusted set, which is a real improvement. They are not designed to exclude an adversary with physical access: Intel’s response to the TEE.fail research explicitly places physical attacks outside the threat model. Published work – HECKLER, Heracles, TEE.fail – demonstrates residual attacks against both.
