A VPS we cannot read.

# 1. Memory encryption is active, and the guest is at the highest privilege level
$ dmesg | grep -i "Memory Encryption"
Memory Encryption Features active: AMD SEV SEV-ES SEV-SNP

$ dmesg | grep VMPL
SEV: SNP running at VMPL0.

# 2. The attestation device is yours. This is the interface to the AMD security
#    processor: pull a signed report and verify it against AMD's cert chain.
#    We can neither forge nor intercept it.
$ ls -l /dev/sev-guest
crw------- 1 root root 10, 262 /dev/sev-guest

# 3. There is no host-to-guest command channel. On a normal VPS this directory
#    contains org.qemu.guest_agent.0, and that is what lets a panel run commands
#    as root inside your machine.
$ ls /dev/virtio-ports/
ls: cannot access '/dev/virtio-ports/': No such file or directory

# 4. If you chose encryption, the root partition is LUKS2 and /boot is not.
$ lsblk -o NAME,FSTYPE,MOUNTPOINT
sda
|-sda1  vfat         /boot/efi
|-sda2  ext4         /boot
`-sda3  crypto_LUKS
  `-root ext4        /

$ cryptsetup luksDump /dev/sda3 | head -3
LUKS header information
Version:        2

Both tiers run on the same hardware in the same rack and get the same confidential computing, the same absent agent and the same encryption options. Every machine includes a dedicated IPv4 and a routed /64 IPv6 block, on 10 Gbps unmetered.

The difference is people, not silicon. On Pro, abuse reports are handled by a human rather than an automated suspension, which is what makes a Tor exit relay workable here, and you get a phone number that reaches the founder directly.

Core is 512 MB, which is deliberate. It exists so that running something small and private is not a $40 decision.

Need something larger? The nodes are 32 core, 64 thread EPYC with 250 GB of RAM, so there is a lot of room above Pro. Custom specs are built to order on six months prepaid.

A confidentiality claim is only worth what its limits are worth. These are ours.

• You are still trusting our image. This is the big one. Attestation today proves the hardware is genuine AMD SEV-SNP and proves the guest policy. It does not yet let you check the launch measurement against a build you can reproduce yourself, so you are trusting that the kernel and initramfs we publish are the ones we actually launched. A hostile operator who controlled the image could capture a LUKS passphrase as you type it. Measured boot with published, reproducible measurements is what closes this and it is not shipped yet. Anyone selling confidential compute who does not volunteer this distinction is hoping you will not ask.
• Confidentiality is not availability. We can stop your machine, refuse to run it, or delete it. Encryption stops us reading your data, not withholding your service. Keep backups somewhere that is not us.
• /boot is not encrypted. LUKS covers the root partition. The EFI partition and /boot are readable and writable from the host, which is inherent to unlocking a disk at boot without a TPM. Disk encryption protects data at rest, it does not give you boot chain integrity.
• Your network traffic is whatever you make it. We route your packets, so unencrypted traffic is visible in transit like it is everywhere else. We keep no access logs, but that is a policy commitment, which is a categorically weaker thing than the memory encryption on this page and we will not pretend otherwise.
• Side channels are an open research area. SEV-SNP defends against a hypervisor reading or corrupting guest memory. It does not claim to eliminate every microarchitectural or ciphertext side channel, and published attacks in that space exist. If your threat model includes a determined operator running dedicated side-channel research against your specific VM, no commercial confidential computing product available today is a complete answer.
• We cannot save you from yourself. A weak passphrase, a private key left on the disk, or a compromised application inside the guest are all outside what any of this protects.

• Hardware: AMD EPYC 7543, 32 cores and 64 threads, 250 GB of RAM, NVMe on a ZFS mirror. Owned by us, in a Montreal colocation facility.
• Guest policy: 0x30000. SMT permitted, debugging disallowed, migration disallowed. Bit 19 clear is what stops the hypervisor issuing SNP_DBG_DECRYPT against your memory, and the policy appears in the attestation report you can pull yourself.
• Agent removal: the QEMU virtio-serial and virtserialport devices are absent from the command line, not set to disabled. Provisioning re-reads the config after building and destroys the VM rather than shipping one that still answers on an agent channel.
• Firmware: OVMF, UEFI on q35, with no pre-enrolled Secure Boot keys. All twelve OS templates are UEFI and built by hand.
• Partition layout: sda1 EFI system partition, sda2 /boot (ext4, unencrypted), sda3 root (LUKS2 when encryption is chosen).
• Encryption: cryptsetup reencrypt --encrypt --reduce-device-size 32M --type luks2 --pbkdf argon2id, run once at build time. Unlock is dropbear in the initramfs over SSH, keys only, never passwords.
• Feature support by OS: SEV-SNP on Debian, Ubuntu, Rocky and AlmaLinux. LUKS on Debian and Ubuntu. The guest agent can be declined on every OS except Windows, which has no cloud-init in our template and takes its address from the agent. FreeBSD and OpenBSD support neither SNP nor LUKS but can decline the agent.
• Network: AS395904, our own IPv4 /24 and IPv6 /36, our own switch. Every machine gets a dedicated IPv4 and a routed /64. rDNS and BYOIP announcements are buttons in the panel rather than tickets.
• No JavaScript required. The entire site, ordering included, works with scripting disabled.