Blackbox: a VPS its operator cannot read

Every VPS you have ever rented had one property nobody puts on the pricing page: the operator could read it. Not "could if they hacked you". Could, trivially, as root on the host, by reading the guest's memory or mounting its disk. Every password, every key, every private repo, one command away from a bored sysadmin, a compromised hypervisor, or a subpoena.

Blackbox is our attempt to build a VPS where that is not true, on hardware we own, sold to people we never identify. This post is what it does, how, and where it stops. The last part is the important one.

Three things the operator normally has, removed

1. Reading your memory

Blackbox machines run under AMD SEV-SNP. The guest's RAM is encrypted with a key generated inside the AMD secure processor that the hypervisor never sees. Reads from outside the VM return ciphertext. SNP adds an integrity table so the host cannot remap or replay pages under you either. The launch policy has the DEBUG bit cleared, which means the secure processor refuses the one instruction that would let us decrypt guest memory for "debugging". Not "we promise not to". Refuses.

2. Reading your disk

Full disk encryption is done inside your VM, by you. On first boot the machine stops in the initramfs, starts a small SSH server there, and you connect and run the LUKS2 encryption of the root filesystem yourself, with a passphrase you type into your own SSH session. We never see it. On every later boot the machine waits in the same place until you unlock it. The disk on our storage is ciphertext; the key exists in your head and, while running, in memory we cannot read.

3. Getting inside

Normal VPS platforms install a guest agent so the panel can reset passwords, inject keys, run commands. That agent is a door for the operator. Blackbox machines have none. Not disabled: absent. There is no virtio channel attached. The panel cannot reset your password because there is nothing in your VM that listens to the panel. If you lose your key, you lose the machine. That is the deal.

And the boring layer underneath

SEV-SNP protects you from the hypervisor. It does not protect the hypervisor from a neighbour. We wrote our own control plane for these machines so that each guest runs as an unprivileged process with an empty capability set, two seccomp filters, a private mount namespace where it cannot see any other guest's sockets or disks, a device allowlist, private PIDs, and no ability to open a network socket of its own. A guest that fully escapes its emulator lands in a box that cannot see the next tenant. We published the whole flag list; the interesting part is that you can check it.

What we can see

Which IP addresses are assigned to your machine, how much traffic it moves, and whether it is powered on. That is what routing and billing need. We cannot read inside it, and we do not know who you are: there is no email, no phone, no KYC. A credential is the whole account and payment is crypto on nodes we run ourselves, or a card.

Where it stops

A confidentiality claim is only worth its limits, so here are ours, unprompted.

• The boot image, and how you check it. This is the big one, so we removed it. SNP attestation proves the hardware is genuine AMD, proves the launch policy, and signs a measurement of exactly what was loaded: firmware, kernel, initramfs and command line. A hostile operator who controlled the image could capture a LUKS passphrase as you type it, which is why the image is not something you take on trust. Blackbox machines boot measured: the firmware, kernel and initramfs are built reproducibly from public source, the expected measurement is published for every release, and a small open-source verifier recomputes it and compares it against the CPU-signed report your own machine hands you over SSH before you type a passphrase. How to verify a Blackbox machine yourself. Anyone selling confidential compute who cannot show you this step is asking you to trust their image.
• Side channels exist. SEV-SNP has had published attacks, patched over time in firmware. We run current firmware. We cannot promise there is no next one.
• The network sees your packets. Encryption of memory and disk does nothing for traffic. Use TLS, WireGuard, Tor, as you would anywhere.
• Availability is not confidentiality. We cannot read your machine, but we can turn it off. A court order can make us do that. It cannot make us hand over what we do not have.

Why "zero-knowledge" is the right word and the wrong word

It is the right word for the intent: the operator ends up knowing nothing about the contents. It is the wrong word in the cryptographic sense, and we would rather be precise. The honest sentence is: a VPS whose operator cannot read its memory or disk, cannot log into it, and does not know who rents it, and whose boot chain you measure yourself against published, reproducible artifacts. If that is what you need, it is $9.99 a month for 2 vCPU, 4 GB and 50 GB of NVMe, on our hardware in Montreal.

Blackbox · Questions we get