01Pick a plan and an operating system
The OS picker shows which images support confidential computing, which support LUKS, and where the guest agent is optional, before you choose rather than after.
A VPS we cannot read.
Every hosting provider without confidential computing can dump your RAM from the hypervisor, run commands inside your guest without your SSH key, and read your disk by mounting it from the host. That is not a criticism of anyone, it is how virtualisation works. On a Blackbox machine all three capabilities are removed, and you can check each one from inside your own VM.
AMD SEV-SNP
Measured boot
No guest agent
LUKS2, your key only
Montreal, owned hardware
No KYC
Three capabilities, removed
Memory01
Guest RAM is encrypted by the CPU with a key held in the AMD security processor. The hypervisor sees ciphertext.
Command channel02
The virtio-serial port a guest agent would use is absent from the QEMU command line. There is no port to re-enable.
Disk03
Optional LUKS2 on the root partition. You set the passphrase in the initramfs over SSH, and it never reaches us.
Identity04
No email, no phone, no KYC. A credential is the whole account, and crypto payments run on our own nodes.
What we removed, and how
Not "we promise not to". The capability is gone.Encrypted memory, with the debug bit off01
AMD SEV-SNP encrypts guest memory with a key generated in and never leaving the CPU security processor. The detail that matters and that almost nobody publishes is the guest policy. Bit 19 permits the hypervisor to issue debug decrypt calls and read your memory in plaintext, and it defaults to permitted. Ours launches at policy 0x30000, which leaves it clear. The policy is a field in the signed attestation report, so you do not have to take our word for it.
No guest agent, and no port for one02
Nearly every VPS runs an agent inside the guest listening on a virtio serial port, which lets the host run commands as root, read files and reset passwords. It is how a control panel resets your root password. On Blackbox the device is absent from the QEMU command line entirely, not disabled in software where it could be switched back on. Provisioning reads the config back after building and destroys the machine if a channel is present.
A disk key we never hold03
LUKS2 with argon2id on the root partition, encrypted in place at build time. On every boot the machine stops in an initramfs running dropbear, you SSH in, and you type the passphrase there. It exists in your terminal and in guest memory we cannot read. There is no escrow, no recovery and no master key, which also means losing it is final.
Chosen when the machine is built04
Confidential mode, the guest agent, encryption and measured boot are properties of how a VM is created, not switches on a running one. SEV-SNP is fixed at launch, an agent lives inside the guest image, and encryption has to happen before there is data to lose. Changing any of them is a reinstall, and the panel says so instead of offering a toggle that quietly rebuilds your machine.
A boot chain you can measure05
On an ordinary confidential VM the initramfs that asks for your passphrase sits on an unencrypted /boot the host can rewrite. With measured boot the machine never boots from its own disk: the AmdSevX64 firmware loads a kernel, an initramfs and a command line whose hashes are part of the launch measurement. Swap any of them and the CPU-signed measurement changes. Every one of those artifacts is reproducible from published sources, and a verifier checks the signature on the report, the measurement and the SSH host key before you type a thing.
Check it yourself
Run these inside your own VM. Nothing here depends on trusting us.# 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
# 5. With measured boot, the report from the initramfs is kept for you, and a
# fresh one can be requested at any time. Verify it against the published
# release: see /docs/guides/measured-boot/
$ python3 -c "import json;d=json.load(open('/run/blackbox/attest.json'));print(d['release'],d['status'])"The plan
| Tier | vCPU | RAM | Disk | Network | Price |
|---|---|---|---|---|---|
| Blackbox Core | 2x EPYC 7543 | 4 GB DDR4 | 50 GB NVMe | 10 Gbps, Unmetered | $9.99/mo |
| Blackbox Plus | 4x EPYC 7543 | 8 GB DDR4 | 100 GB NVMe | 10 Gbps, Unmetered | $19.99/mo |
| Blackbox Max | 6x EPYC 7543 | 16 GB DDR4 | 200 GB NVMe | 10 Gbps, Unmetered | $34.99/mo |
| Blackbox Ultra | 8x EPYC 7543 | 32 GB DDR4 | 400 GB NVMe | 10 Gbps, Unmetered | $59.99/mo |
One treatment, no tiers. Every Blackbox machine runs on hardware we own in our own rack in Montreal, with 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.
Abuse reports are read by a person before anything is actioned. That is not a premium feature; it is how we already handled them, and it is what makes a Tor relay or a mail server workable here. There is no automated suspension.
Need more than the table shows? The nodes are 32 core, 64 thread EPYC with 250 GB of RAM. Larger builds are made to order on six months prepaid; ask.
What Blackbox does not protect against
A confidentiality claim is only worth what its limits are worth. These are ours.
- Without measured boot, you are trusting our image. On a Blackbox built without it, attestation proves the hardware is genuine AMD SEV-SNP and proves the guest policy, but the kernel and initramfs come off an unencrypted /boot the host can rewrite, so a hostile operator could capture a LUKS passphrase as you type it. Measured boot closes this: the boot chain comes from a published, reproducible release and is part of the measurement you verify. It is on by default for new Linux Blackbox orders; an existing machine gets it through a reinstall. Anyone selling confidential compute who does not volunteer this distinction is hoping you will not ask.
- The template before you encrypt it. Even with measured boot, your root filesystem starts as our stock image and is readable by the host until you run the encrypt step at first boot. Encrypt before anything on the disk has run, and audit the image afterwards; it is a plain Debian or Ubuntu cloud image plus a listed set of packages.
- 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, and on a measured machine it is not used. LUKS covers the root partition. Without measured boot 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, not boot chain integrity. With measured boot the disk is never consulted at boot, so what sits on /boot no longer matters.
- 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.
Technical details
- 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 issuingSNP_DBG_DECRYPTagainst your memory, and the policy appears in the attestation report you can pull yourself. - Agent removal: the QEMU
virtio-serialandvirtserialportdevices 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. - Measured boot: QEMU
sev-snp-guest,kernel-hashes=onwith the edk2AmdSevX64firmware (BlobVerifierLibSevHashes, PcdBootRestrictToFirmware), a Debian signed kernel and a reproducible initramfs built from a pinned snapshot.debian.org timestamp. Your SSH key, addresses and instance id travel on the measured command line instead of a seed ISO. The initramfs generates a fresh SSH host key per boot and binds its SHA-256 into REPORT_DATA of the attestation report. Recipe, sources, hashes and the verifier: measured boot. - 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.
How a Blackbox gets built
No email, no verification, no waiting on a human.02Leave the defaults alone
Confidential computing on, encryption on, guest agent off. That is the default configuration, because a machine sold as one we cannot look inside should arrive that way without you having to know which boxes to tick.
03Add an SSH key and pay
Encryption needs a key, since the unlock shell in the initramfs accepts keys only. Pay with crypto through our own nodes, by card, or by cash in the mail.
04Verify, then set your passphrase on first boot
The machine stops in the initramfs. Run the verifier against it: it checks the CPU-signed report, recomputes the launch measurement from the published release, and confirms the SSH host key on the wire is the one bound in the report. Then SSH in, run encrypt, set the passphrase, and it continues booting. It never reaches us, and every boot after that asks you again.
Fair questions
What can Servury actually see on a Blackbox machine?
Metadata we need to route and bill: which IP addresses are assigned to your VM, how much traffic it moves, and whether it is powered on. We cannot read its memory, cannot execute anything inside it, and cannot read an encrypted disk. Those three are removed at the hardware and hypervisor level, not by policy.
Can you reset my root password?
No, and that is the point. Password and key resets work by having a guest agent inside your VM that the host can send commands to. Blackbox machines are built without that channel, so the feature genuinely does not exist for us. If you lose access, a reinstall is the only route back in, and it erases the disk.
Can I verify SEV-SNP is really on?
Yes, from inside your own VM. dmesg reports the active memory encryption features, and /dev/sev-guest is the interface to the AMD security processor. You can pull a signed attestation report from the silicon and verify it against AMD's certificate chain yourself. We cannot forge it and cannot intercept it.
Can I verify which image I booted?
Yes, with measured boot. The firmware, the kernel, the initramfs and the command line carrying your SSH key are supplied from a published release and folded into the SEV-SNP launch measurement; swapping any of them changes the number the CPU signs, and the firmware never touches the guest disk. Every artifact is rebuilt byte for byte from public sources, so you recompute the expected measurement yourself and compare it with the signed report your VM produces before you type a passphrase. The verifier and the recipe are on the measured boot page.
What happens if I forget the LUKS passphrase?
The data is gone. There is no recovery, no backdoor and no escrow. The passphrase is set by you inside the initramfs over SSH and never reaches us. You can reinstall the machine, but the previous contents are unrecoverable.
Which operating systems support which features?
SEV-SNP needs a guest kernel that understands it, which means Debian, Ubuntu, Rocky and AlmaLinux. LUKS is a stricter set, Debian and Ubuntu only, because the flow shrinks the root filesystem and unlocks from an initramfs carrying dropbear. The BSDs and Windows support neither. The order page shows the full matrix before you choose.
Is this available outside Montreal?
No. Blackbox runs only on hardware we own and operate ourselves in a Montreal colocation facility, because the product depends on controlling the hypervisor configuration.
Do I need an account?
You need a credential, not an identity. No email, no phone, no KYC. Signup hands you a login and that is the entire account. Payment is crypto, card, or cash by mail.
Deploy one and try to catch us out
Every hardware claim on this page (encrypted memory, no agent, encrypted disk, measured boot) is checkable from inside the machine. If something here does not hold up, we want to hear about it.
Guides on this
Blackbox: a VPS its operator cannot read
We built a VPS where the host cannot read your RAM or your disk, cannot log into your machine, and does not know who you are. Here is exactly how, and
Best Confidential VPS Providers (2026): Encrypted Memory, Attestation, and Who Still Needs Your Name
Seven ways to rent a virtual machine whose memory the operator cannot read, from a no-KYC host with reproducible measured boot to the three hyperscale
Privacy is Marketing. Anonymity is Architecture.
Privacy is when they promise to protect your data. Anonymity is when they never had your data to begin with.
Offshore VPS Hosting: How It Works and Who It's For
Offshore VPS just means your server is in a different country. The reasons range from privacy to performance. Here's how it actually works, who needs
Debian 13
YunoHost 12
Ubuntu 26.04 LTS
Rocky Linux 9
AlmaLinux 10
FreeBSD 15
OpenBSD 7.9
Windows Server 2025
