Home / Servers / Blackbox

Blackbox:
a zero‑knowledge
encrypted VPS.

A server we cannot read. Its memory is encrypted by the CPU. There is no agent inside it and no port for one. The disk key is yours alone. The boot chain is measured, and the kernel and the disk can be yours too. Every one of those claims can be checked from inside your own machine, and this page shows you how.

Deploy a Blackbox from $9.99 / month
Sceptical? Good. Verify one before you type a passphrase.
The boundary

Outside

The host. That is us.
  • 01Power. Whether the machine is on, and the buttons to stop, start or delete it.
  • 02Traffic. How much moves, and the packet headers on the wire, like any network in the path.
  • 03Addresses. The IPv4 and IPv6 we route to the machine, and nothing about who is behind them.
  • 04Ciphertext. Guest RAM as the hypervisor sees it: encrypted under a key that never leaves the security processor.

Inside

Your machine. Only yours.
  • 01Memory. Encrypted by the CPU with the debug bit clear, so the hypervisor cannot ask for plaintext. The policy is in the report you pull yourself.
  • 02Commands. No guest agent and no virtio port for one. A password reset is a feature we do not have.
  • 03Disk. LUKS2 on the root partition; the passphrase is typed into your own initramfs over SSH and never reaches us.
  • 04Boot. Firmware, kernel, initramfs and command line are part of the launch measurement the CPU signs. Bring your own UKI and disk, and nothing of ours runs at all.

Four things
every host can do.
Removed.

Not "we promise not to". The capability is gone.
01

Read your memory

Any VPSThe hypervisor can dump guest RAM at will. Keys, sessions, everything in plaintext. BlackboxAMD SEV-SNP encrypts guest memory under a key generated inside the CPU's security processor. The detail almost nobody publishes is the guest policy: bit 19 lets the hypervisor issue debug decrypt calls, and it defaults to permitted. Ours launches at policy 0x30000, bit clear. The policy is a field in the signed attestation report, so you do not take our word for it.
02

Run commands inside

Any VPSA guest agent on a virtio serial port lets the panel run anything as root: reset passwords, read files, plant things. BlackboxThe virtio-serial device is absent from the QEMU command line, not disabled somewhere it could be switched back on. Provisioning reads the config back after the build and destroys any machine that still has a channel. The panel says "not available" and means it.
03

Read your disk

Any VPSMount the volume from the host, or take the drive out of the rack. Encryption at rest with a provider-held key changes nothing. BlackboxLUKS2 with argon2id on the root partition, encrypted in place at build time. Every boot stops in an initramfs running dropbear; you SSH in and type the passphrase there. It exists in your terminal and in memory we cannot read. No escrow, no recovery, no master key, which also means losing it is final.
04

Swap what you boot

Any VPSThe initramfs that asks for your passphrase sits on an unencrypted /boot the host can rewrite. A patient operator captures the passphrase as you type it. BlackboxWith measured boot the machine never boots from its own disk: the firmware loads a kernel, initramfs and command line whose hashes are part of the launch measurement. Change a byte and the CPU-signed number changes. Every artifact is reproducible from published sources, and a verifier checks the report before you type anything.

Yours,
all the way down.

Rebuilding our release proves our sources are honest. Booting your own removes the question. On a measured Blackbox you can replace everything we would otherwise run inside your machine, and the CPU measures your bytes instead of ours.

Boot image

Bring your own kernel

Hand the node a UKI you built, or a bzImage with your own initramfs and command line, by URL and SHA-256. The node refuses it if the hash differs, re-hashes it at every start, and boots it under the same public firmware. The expected measurement becomes a function of that firmware, your bytes and your command line. Nothing of ours runs inside the guest.

How to build and verify one
Disk image

Bring your own disk

Build the disk at home, pre-installed and pre-encrypted, and have it written over the machine's volume: raw or qcow2, up to the plan's size. The old contents are discarded first, the write rolls back on any failure, and neither our template nor the console is ever involved. Pair it with your own UKI and the firmware's hash is the one number left that is ours. You can rebuild that too.

How the write works

Check it
yourself.

Run these inside your own VM. Nothing here depends on trusting us, and the last one is a report signed by the CPU that you verify against AMD's own certificate chain.

The verifier SEV-SNP, explained 
# Memory encryption is active, and the guest runs 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.

# The attestation device is yours: a signed report straight from the security processor
$ ls -l /dev/sev-guest
crw------- 1 root root 10, 262 /dev/sev-guest

# No host-to-guest command channel. A normal VPS lists org.qemu.guest_agent.0 here.
$ ls /dev/virtio-ports/
ls: cannot access '/dev/virtio-ports/': No such file or directory

# 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        /

# With measured boot, the CPU-signed report and the release it was measured against
$ python3 -c "import json;d=json.load(open('/run/blackbox/attest.json'));print(d['release'],d['status'])"
2026.09 ok

One treatment.
Four sizes.

Every tier gets every protection
Core Sold out
$9.99/ month
vCPU
2
RAM
4 GB DDR4
Disk
50 GB NVMe
Port
10 Gbps
Transfer
4 TB / 31 days
Sold out
Plus Sold out
$19.99/ month
vCPU
4
RAM
8 GB DDR4
Disk
100 GB NVMe
Port
10 Gbps
Transfer
8 TB / 31 days
Sold out
Max Sold out
$39.99/ month
vCPU
6
RAM
16 GB DDR4
Disk
200 GB NVMe
Port
10 Gbps
Transfer
16 TB / 31 days
Sold out
Ultra Sold out
$89.99/ month
vCPU
8
RAM
32 GB DDR4
Disk
400 GB NVMe
Port
10 Gbps
Transfer
32 TB / 31 days
Sold out
Dedicated IPv4 and a routed /64 IPv6 NVMe storage on hardware we own, in Montreal Test the path before you buy: Montreal looking glass Transfer counted as the larger of in and out, never both; 10 Mbps past it, nothing billed rDNS, BYOIP and your own ASN are panel buttons, not tickets Abuse reports read by a person before anything happens

What we see.
What we cannot.

Still visible to us
  • •Availability. We can stop, refuse to run, or delete the machine. Encryption stops us reading your data, not withholding service. Keep backups somewhere that is not us.
  • •Traffic in transit. We route your packets. Unencrypted traffic is visible on the wire here like everywhere else; we keep no access logs, and that is a policy, which is a weaker thing than the CPU.
  • •The template before you encrypt it. Unless you bring your own disk, the root filesystem starts as our stock image and is readable until you run the encrypt step at first boot. Do it before anything on the disk has run.
  • •Side channels. SEV-SNP stops a hypervisor reading or corrupting guest memory. It does not claim to close every microarchitectural or ciphertext side channel; published attacks exist, and no commercial confidential computing product is a complete answer to a determined operator running research against one VM.
Gone, in hardware
  • •Your memory. Ciphertext to the hypervisor, debug decrypt disallowed by the launch policy in the signed report.
  • •Your processes. No agent, no port, no way to run anything inside. A reinstall erases the disk; that is the only path back in.
  • •Your disk. LUKS2 under a passphrase that never reaches us, on a boot chain the CPU measured, or one you supplied yourself.
  • •Your identity. No email, no phone, no documents. A credential is the whole account, and crypto payments run on our own nodes.
The fine print, in full
  • Without measured boot, you are trusting our image. Attestation on a plain confidential VM proves the hardware is genuine SEV-SNP and proves the guest policy, but the kernel and initramfs come off an unencrypted /boot the host can rewrite. Measured boot closes this and is on by default for new Linux orders; an existing machine gets it through a reinstall.
  • /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. With measured boot the disk is never consulted at boot, so what sits on /boot no longer matters.
  • Disk integrity. LUKS2 with XTS hides your data but does not authenticate it; a host can corrupt ciphertext blindly. It cannot read or forge it meaningfully.
  • Metadata. Traffic volume, packet headers, CPU usage and the fact that the machine exists are visible to us as to any transit provider. Encrypted memory is not anonymity; that is what the rest of Servury is for.
  • Kernel updates are ours, unless you bring your own. On a measured machine the kernel comes from the release, so apt upgrade inside the guest does not change what boots. New releases are published with their hashes; your own UKI is the way out of even that.
  • We cannot save you from yourself. A weak passphrase, a private key left on the disk, or a compromised application inside the guest are outside what any of this protects.
  • Where it runs. Montreal only, on hardware we own, because the product depends on controlling the hypervisor. Guest policy 0x30000; OVMF on q35 without pre-enrolled Secure Boot keys; SEV-SNP on Debian, Ubuntu, Rocky and AlmaLinux; LUKS on Debian and Ubuntu; the guest agent can be declined on every OS except Windows; FreeBSD and OpenBSD run without SNP or LUKS. AS395904, our own IPv4 /24 and IPv6 /36, our own switch. The whole site, ordering included, works without JavaScript.

How one
gets built.

01

Pick a size and an OS

The picker shows which images support confidential computing, which support LUKS, and where the guest agent is optional, before you choose rather than after.

02

Leave the defaults alone

Confidential computing on, encryption on, measured boot on. There is no guest agent to turn off: none exists on a Blackbox, not even as an option. A machine sold as one we cannot look inside arrives that way without you knowing which boxes to tick.

03

Add an SSH key and pay

Encryption needs a key, since the unlock shell accepts keys only. Pay with crypto through our own nodes, by card, or by cash in the mail. The machine is up in about a minute.

04

Verify, then set your passphrase

The machine waits in its initramfs. Run the verifier: it checks the CPU-signed report, recomputes the launch measurement, and confirms the SSH host key on the wire is the one in the report. Then SSH in, run encrypt, and set the passphrase that never reaches us.

Fair
questions.

What can Servury actually see on a Blackbox machine?

What routing and billing need: which addresses are assigned to your VM, how much traffic it moves, packet headers on the wire, 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. 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. Or skip our image entirely and boot a UKI you built.

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: 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, and a disk image you bring can be anything that boots.

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.

Stop trusting
your host.
Including us.

A Blackbox keeps its secrets from the people who run it. Deploy one, verify it from the inside, and keep the passphrase to yourself.

Deploy a Blackbox
Measured boot guide Bring your own image SEV-SNP explained Montreal looking glass Compared with providers that sell privacy as a policy Documentation