Confidential computing on a VPS

What confidential computing on a VPS actually means

Confidential computing on a VPS means the processor encrypts your virtual machine's memory with a key the hypervisor never holds, so the operator of the physical machine cannot read what your server is working on. Almost no VPS sold today works this way. On an ordinary VPS the provider's hypervisor can read every byte of your guest's memory, and encrypting the disk does not change that.

The published guidance is written for two audiences, and a VPS tenant is neither of them. Canonical's confidential computing material is either an image you launch on a hyperscaler (a specific Azure size, or a Google Confidential VM) or a how-to for turning hardware you own into a confidential VM host. Both assume you are the hyperscaler or you are the host. Neither tells the person renting a 4 GB VPS whether any of it reaches the box they are already paying for. Start with the threat model, because every practical answer follows from it.

Who can read the memory of your VPS right now

Your VPS is a guest. Something else creates it, gives it memory, and schedules it on a physical core. Most Linux VPS hosting runs on KVM, where a guest's RAM is ordinary anonymous memory belonging to a QEMU process on the host. A root user on the host can read that process's memory the same way they could read any other process, through /proc/<pid>/mem or with a virsh dump that writes the guest's whole memory image to a file. Nothing inside your VM can prevent this, and nothing inside your VM can detect it, because the party doing it controls the layer that would have to do the detecting.

This is not a flaw in one provider. It is what virtualisation is. The hypervisor's job is to own the guest's memory, so the ability to read that memory falls out of the design. That is why whether VPS hosting is safe for real workloads turns on operator practice and staff access control rather than on technology: the technology by itself does not constrain the operator at all. The boundary is thinner still on container-based plans, where an LXC or OpenVZ guest shares the host kernel and the host can read your processes without needing a dump at all. That difference is worth understanding before you compare prices, and the split between KVM, Xen and LXC virtualisation is where it lives.

Why full disk encryption does not fix this

Full disk encryption on a VPS is worth having, and it does not touch this problem. LUKS (Linux unified key setup) encrypts blocks on the way to the disk and decrypts them on the way back. To do that, the volume key has to sit in kernel memory for as long as the volume is mounted. So the key is in memory, the decrypted data passing through is in memory, and memory is exactly what the host can read.

What encryption at rest does buy you is real: a disk that leaves the building stays unreadable. A failed drive returned to the vendor is covered. A detached backup volume that someone forgets about is covered. Those are different risks from a live host reading a live guest, and both get sold under the same word, which is why "all our storage is encrypted at rest" is a true statement that answers a different question.

There is a second trap specific to rented machines. Encrypting the root filesystem means something has to supply the passphrase at every boot. Store it on the same box, in a keyfile or an unencrypted initramfs, and the host can read it. Type it into a console the provider operates, and the host can read it. Fetch it at boot from somewhere else and you have moved the trust rather than removed it, because the service handing out the key now needs a way to know that the machine asking is the machine you think it is. That last requirement is the exact problem attestation was built to solve.

What AMD SEV-SNP and Intel TDX actually do

Two separate things, and keeping them apart is most of the battle: memory encryption, and remote attestation.

Memory encryption first. AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging) gives each guest its own memory encryption key. The key lives in the AMD Secure Processor, a separate core on the same chip, and the hypervisor never sees it. The memory controller encrypts on write and decrypts on read for the owning guest only. The host can still take a dump of that memory. What it gets back is ciphertext.

Intel TDX (Trust Domain Extensions) arrives at the same place by another route. Your guest becomes a trust domain, its memory is tagged with a private key identifier, and every transition in and out is policed by the TDX module, a piece of signed Intel code running in a processor mode the hypervisor cannot enter. From the tenant's point of view the result matches: the hypervisor allocates your memory and schedules your CPU without being able to read your memory.

The SNP half of SEV-SNP is the part people skip, and it carries the weight. Encryption stops the host reading pages. It does not stop the host moving them. A hypervisor that can remap a guest's physical pages can replay old contents, alias two guest addresses onto one page, or return a page it swapped underneath you, and each of those can be turned into a working attack without decrypting anything. SNP adds the Reverse Map Table, a structure the CPU consults on access, recording which guest owns which page. A remap the guest did not ask for faults instead of succeeding. TDX has its own equivalent. Without that integrity layer you have privacy against a passive host and nothing against an active one.

What neither one changes: the host still starts your VM, stops it, decides when it gets a core, and can throw it away. Confidential computing covers confidentiality and integrity. Availability and performance stay entirely with the host, which is why CPU steal time from a noisy neighbour is untouched by any of this.

What remote attestation proves that encryption alone does not

Here is the hole that encryption on its own leaves open. You ask your provider for a confidential VM. They give you a VM. How do you know the memory encryption is switched on? You cannot settle it by asking the guest, because the guest's entire view of the world is supplied by the hypervisor, and the hypervisor is the thing you are checking. A dishonest host, or simply a misconfigured one, can hand you a completely ordinary VM, and every command you run inside it is answered by the layer you do not trust.

Remote attestation closes that loop. The CPU itself produces a signed report. On SEV-SNP the report is signed by a key unique to that physical chip and certified by AMD's own chain, which you fetch from AMD rather than from your provider. TDX produces a quote backed by an Intel-issued attestation key. The report carries a launch measurement: a hash of the exact memory the VM started with, covering the firmware, the kernel, the initrd and the kernel command line. You verify the signature away from the machine, against the silicon vendor's root, and you compare the measurement against what you expected to boot.

Say the payoff plainly. Attestation lets a party who is not on the machine decide whether to trust the machine. The pattern that makes it useful is release on attestation: your database password and your decryption keys never live in the image at all. They sit with a service somewhere else, and that service hands them over only after it has checked a fresh report and seen the measurement it expects. If the host boots a modified kernel, or runs the VM with no SEV-SNP at all, the measurement changes or no valid report arrives, and the secret is never released. Encryption without attestation protects data from a host you have already chosen to trust. Attestation is what lets you stop choosing.

The tooling is open and you can read it. The snpguest command line tool talks to the /dev/sev-guest device inside an AMD guest, requests a report, and verifies it against the certificate chain. Platform detail matters here: on Azure confidential VMs that device is not exposed to the guest in the usual way, and the tool needs a different build and a different flag. Attestation works, and it does not yet work identically everywhere.

What confidential computing does not protect you from

A compromised guest. SEV-SNP protects your VM from the outside. It has nothing to say about an attacker already inside, because to the CPU that attacker is you. An unpatched web application or a container escape into your own kernel works exactly as well on a confidential VM. The encryption is now working for the intruder, since the host cannot inspect that memory to help you either. Recovering a VPS after a compromise gets no easier because the RAM was encrypted.

Your own application. The boundary stops at the edge of the VM. Data your code writes to a log file, or posts to a third-party API, has left the TEE (trusted execution environment), which is the name for the protected region. Encrypted memory does not audit your code.

A stolen credential. An attestation report states which software booted. It states nothing about who logged in afterwards. A leaked SSH key opens a confidential VM as quickly as any other, so hardening SSH access on a VPS remains the higher-value work for nearly everyone reading this.

Everything that is not memory. SEV-SNP and TDX encrypt RAM. Your virtual disk, your network traffic, your snapshots and your backups are not covered unless you encrypt them yourself. On the hyperscaler confidential VM products the OS disk is handled by separate machinery with its own key management, precisely because the CPU feature does not reach it.

Physical attacks, which is the awkward one. A run of published research has shown the memory bus is a soft edge. BadRAM (CVE-2024-21944, 2024) tampered with the SPD chip on a memory module to make the CPU alias physical addresses, using roughly ten dollars of parts. Battering RAM (2025) placed an interposer costing about fifty dollars between the CPU and the DRAM and defeated the boot-time alias checks added in response. TEE.fail (2025) carried the idea onto DDR5 and reported ciphertext extraction against current Intel and AMD confidential computing on server hardware. Deterministic memory encryption contributes here too: identical plaintext at the same address produces identical ciphertext, which academic work has turned into a side channel by itself. Every one of these attacks needs physical access to the machine and time alone with it. Notice who that describes. Confidential computing moves the host from reading your memory with one command to reading your memory with hardware, physical access and effort. That is a genuine and large improvement, and it is a smaller claim than saying the host cannot.

Can you buy a confidential VPS today

As of August 2026, confidential VMs are a hyperscaler product line. Microsoft Azure sells SEV-SNP sizes and TDX sizes. Google Cloud sells Confidential VM. AWS exposes an AmdSevSnp CPU option on a short list of instance families in a short list of regions. Independent VPS hosts rarely list it. A few do advertise SEV-SNP, and the number is small enough that the only sound move is to ask rather than assume.

The reasons are structural, and knowing them tells you how to read the answer you get.

• The silicon is specific. SEV-SNP needs third generation AMD EPYC or newer, TDX needs a recent Intel Xeon Scalable. A fleet bought over years on price per core is a mixed fleet, so the feature would exist on some nodes and not others.
• The host software is recent. Ubuntu has supported SEV-SNP guests since 24.04 LTS, while the host side (the QEMU and OVMF firmware enablement) landed later, in 25.04. That is newer than the stack a stable hosting platform runs.
• Live migration gets hard. Moving a running guest between hosts means copying its memory, and the host cannot read the memory. Providers use live migration to drain a node for maintenance, so losing it changes how the whole platform is operated.
• Density drops. The number of confidential guests one host can run at once is capped in hardware, well below the number of ordinary guests a large node will hold. Low VPS pricing is built on that density.
• Attestation is an ongoing support burden. A report is worthless unless the tenant can obtain the certificate chain and knows which measurement to expect, so the provider has to publish and maintain something that changes with every firmware update.

None of that is a complaint about any provider. It explains why the feature sits where it does.

How to ask a host whether SEV-SNP or TDX is available

Support desks answer the question you asked, and the vague question earns a reassuring answer that means nothing. Ask whether your data is encrypted and you will hear that all storage is encrypted at rest, which is true and is about disks. Ask the narrow version instead. These five questions are worth sending as they are written.

1. Do you offer instances with AMD SEV-SNP or Intel TDX enabled for the guest, and on which plans?
2. Is it selected per instance at creation time, or is it a property of the host that I cannot choose?
3. From inside the guest, can I fetch a hardware attestation report, and is /dev/sev-guest present?
4. Do you provide or pass through the certificate chain needed to verify that report against the CPU vendor?
5. Which regions and host generations, and does it restrict resizing or migration?

Read the replies this way. Yes to question 1 with no to questions 3 and 4 means you have memory encryption you cannot verify. That is worth something against a resold memory module and little against the host, because you are trusting the operator's word about a feature whose purpose is to remove the need to trust the operator's word. An answer that talks about compliance or about encryption in general is a no. Silence on question 5 usually means one instance family in one region.

On price and instance choice, expect a narrower menu rather than a simple surcharge. Confidential sizes tend to form a separate family with fewer sizes and fewer regions, and the real cost is often that constraint rather than the hourly rate. Price the specific size you would actually run.

How to check the VPS you already have

These run inside the guest and take a minute. Read what they tell you as a strong hint rather than as proof, because everything a guest sees is mediated by the hypervisor.

systemd-detect-virt
systemd-detect-virt --cvm

The first prints the virtualisation technology the kernel detected. The second reports confidential VM technology, with values such as sev, sev-es, sev-snp and tdx. --cvm is a newer option, so run systemctl --version first if your system does not recognise it.

sudo dmesg | grep -i -E 'sev|tdx|memory encryption'
sudo journalctl -k | grep -i -E 'sev|tdx|memory encryption'

A guest running with AMD memory encryption active prints a boot line that begins Memory Encryption Features active:, and the technologies in use are listed after it. A trust domain prints its own TDX lines during early boot. Run the journalctl form as well, because on a long-running server the dmesg ring buffer may have wrapped and discarded the boot messages.

grep -m1 ^flags /proc/cpuinfo | tr ' ' '\n' | grep -i -E 'sev|tdx'
ls -l /dev/sev-guest /dev/tdx-guest

Treat the CPU flags carefully. /proc/cpuinfo shows the CPU model the hypervisor chose to present, so a sev flag can mean the silicon supports the feature while your VM makes no use of it. tdx_guest is the more direct signal, because that flag describes the guest itself. The device files are what an attestation tool needs, /dev/sev-guest on AMD and the TDX guest device on Intel, and ls will report plainly that there is no such file when there is not. On some platforms the device is deliberately hidden from the guest even though the VM is confidential, so this check confirms rather than refutes.

If none of it finds anything, the answer for your server is no. That is the expected result on ordinary VPS hosting and it is not a sign that something is broken.

What to do when the answer is no

Which it will be. The useful response is not to abandon the question but to shrink what the answer costs you. A few habits do most of the work and none of them need special hardware.

Encrypt what leaves the box, on the box. Backups matter most. Tools like restic and age encrypt on the client before anything reaches the destination, so the storage provider holds ciphertext and never holds a key. Use TLS (transport layer security) for traffic between your own servers too, including across a provider's private network, because a private network is still a network you do not administer.

Keep secrets out of images and out of git. A secret baked into a VM image or committed to a repository is exposed to everyone who can read either, a much larger group than the people who operate a hypervisor. Keep them in an encrypted store that is decrypted at deploy time. Encrypting secrets with Ansible Vault is the low-ceremony version and it is enough for most small fleets.

Scope what each server is trusted with. This is the habit that changes outcomes. Ask what an attacker who read this machine's entire memory would walk away with. If the answer includes a key that decrypts ten years of customer records, the hypervisor is the smaller half of your problem: that key is sitting on a public-facing web server. Give each box the narrowest credential that lets it do its job, with a short lifetime and a rotation procedure you have practised. Then a host reading your memory costs you only what that one box could already do.

Do not put a key on a VPS you cannot rotate. Rotation is the control that survives contact with reality. Everything else on this page assumes you find out. Rotation is what you do when you do not.

Fix what is actually attacking you. For nearly every reader the realistic path to a breach is an unpatched service or a stolen credential, not an engineer at a data centre reading RAM. Checking your server for known CVEs and what Ubuntu Pro adds to a server's patch coverage move your risk further than any CPU feature will. On a fresh machine, the first ten minutes on a new VPS is the cheapest work you will ever do.

And if you have one workload that genuinely needs a hardware trust boundary, treat it as one workload. Run that piece on a confidential VM at a provider who sells one, or on hardware you control, and leave the rest where it is affordable. Splitting a system by sensitivity is a normal architecture, and it is available today, which is more than can be said for a confidential VPS.

FAQ

Can my VPS provider read the memory of my server?

On ordinary VPS hosting, yes. The hypervisor allocates and maps your guest's RAM, so a root user on the host can read it, for example through the QEMU process at /proc/<pid>/mem or by dumping the guest's memory to a file. Nothing inside the guest can block that or detect it. AMD SEV-SNP and Intel TDX exist to remove the capability, and they are not offered on most VPS plans. What limits provider access on a normal VPS is the provider's own controls and staff policy rather than the technology.

Does full disk encryption protect my VPS data from the hosting provider?

Not while the server is running. The volume key has to stay in kernel memory for the filesystem to be readable, so both the key and the data passing through it sit in memory the host can read. Disk encryption protects data at rest, such as a drive that fails and is returned to the vendor, or a backup volume that is detached and forgotten. Those risks are worth covering. They are a different risk from a live host reading a live guest.

How do I check whether my VPS uses AMD SEV-SNP or Intel TDX?

Run systemd-detect-virt --cvm inside the guest, then sudo dmesg | grep -i -E 'sev|tdx' and ls -l /dev/sev-guest. A guest with AMD memory encryption active prints a boot line beginning Memory Encryption Features active:, and an Intel trust domain carries the tdx_guest flag in /proc/cpuinfo. Every one of those answers reaches you through the hypervisor, so they are indicative. The only proof is a signed attestation report that you verify against the CPU vendor's certificate chain from outside the machine.

What does attestation add on top of memory encryption?

Proof that the encryption is really active and that the machine booted the software you expected. Memory encryption you cannot verify still asks you to trust the operator's word. An attestation report is signed by the CPU, carries a measurement of the VM's initial memory covering firmware, kernel, initrd and kernel command line, and is checked against the silicon vendor's root certificate away from the machine. That is what enables the pattern worth having: a secret held elsewhere is released to the VM only after its report verifies.

Is confidential computing worth paying extra for?

It depends on whether the infrastructure operator belongs in your threat model. For regulated data, or for keys that protect other people's data, it is the only technical answer available, and the price of a hyperscaler confidential instance is small next to the alternative. For a personal site or a small service, the same money buys more security when spent on patching and credential hygiene. Decide honestly which one you are running before you go shopping for hardware features.