All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Blackbox : 2 vCPU / 4 GB / 50 GB NVMe, Encrypted RAM & Disk, 100% Anonymous - $9.99/mo
Matteo again, from Servury. Two weeks ago I posted Blackbox, the VPS whose operator cannot read its memory, cannot read its disk, and cannot run commands inside it. Thread here. Since then we shipped the things people in that thread asked about, and re-specced the entry plan.
What changed since the last thread
Core is now 2 vCPU / 4 GB / 50 GB NVMe, same $9.99. The 1 vCPU / 512 MB Core is gone. If you bought one, your VM already has 4 GB queued: all you have to do is ask us via support to bump your specs up.
Measured boot. In the last thread the honest limit was "you're still trusting our boot image." Not any more. The firmware, kernel and initramfs are built reproducibly from public source, the expected launch measurement is published for every release, and an open verifier recomputes it and checks it against the CPU-signed attestation report your own machine hands you over SSH, before you type a LUKS passphrase. The guide, the source tarball and the verifier: https://servury.com/docs/guides/measured-boot/
Our own control plane. New Blackbox machines run on QEMU/KVM under a wrapper we wrote (Rust, one systemd unit per guest). No Proxmox, Virtualizor or VirtFusion in the path. Every guest is an unprivileged process with an empty capability set, seccomp, a private mount namespace where it cannot see another guest's sockets or disks, a device allowlist, private PIDs, and no ability to open a network socket of its own. SEV-SNP protects you from the host; this is what protects you from a neighbour who escapes QEMU.
Custom ISO from any URL, attached as a CD, boots first when you say so.
Console logging is off by default, and it's a per-VM switch on the Console tab. Nothing your kernel prints to the serial port is written on the host unless you turn it on.
Abuse reports are read by a person before anything happens, on every plan, not just the top one.
Everything from the first thread still holds: no guest agent and no port for one, LUKS you unlock yourself over dropbear, /dev/sev-guest exposed so you pull the attestation report from the silicon, no email, no phone, no KYC, 11 cryptocurrencies through our own processor or Stripe or cash by mail, zero access logs anywhere including the looking glass, and the site works with JavaScript off. BYOIP, self-managed rDNS - I could go on.
Plan
Blackbox Core - $9.99/month, $29.97/quarter (USD). Any term from 7 to 365 days, prorated.
2 vCPU, AMD EPYC 7543 | 4 GB RAM, SEV-SNP encrypted | 50 GB NVMe on a ZFS mirror
1 dedicated IPv4 + routed /64 | 10 Gbps unmetered | KVM, full root, UEFI
Montreal, Cologix MTL2, our hardware, AS395904, 23.155.44.0/24, 2602:f41c::/36
Templates: Debian 12/13, Ubuntu 24.04/26.04, Rocky 9, AlmaLinux 9/10, FreeBSD 14/15, OpenBSD 7.8/7.9
Order: https://servury.com/
Bigger tiers exist on the site (up to 8 vCPU / 32 GB / 400 GB). Stock note, since I'd rather say it here than have you find out at checkout: the node is nearly full, Core and the next tier up are available now, the two larger ones return after the RAM upgrade landing next week, and lots more stock when we'll rack the second node at the end of the month.
Looking glass, test IPs, test files
https://mtl-lg.servury.com
IPv4: 23.155.44.21 | IPv6: 2602:f41c:0:a::1
Test files: 100 MB / 1 GB / 10 GB
iperf3 -c mtl-lg.servury.com -p 5201 -P 4 (add -R for the other direction)
No access log, no visitor IPs recorded, Bootstrap served from our own host.
YABS
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
# Yet-Another-Bench-Script #
# v2026-07-24 #
# https://github.com/masonr/yet-another-bench-script #
# ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## #
Fri Aug 21 01:49:49 AM UTC 2026
Basic System Information:
---------------------------------
Uptime : 0 days, 0 hours, 1 minutes
Processor : AMD EPYC-v4 Processor
CPU cores : 2 @ 2794.748 MHz
AES-NI : ✔ Enabled
VM-x/AMD-V : ❌ Disabled
RAM : 3.8 GiB
Swap : 0.0 KiB
Disk : 49.1 GiB
Distro : Debian GNU/Linux 13 (trixie)
Kernel : 6.12.101+deb13-amd64
VM Type : KVM
IPv4/IPv6 : ✔ Online / ✔ Online
IPv6 Network Information:
---------------------------------
ISP : Servury
ASN : AS395904 Servury
Host : Servury
Location : Montreal, Quebec (QC)
Country : Canada
fio Disk Speed Tests (Mixed R/W 50/50) (Partition /dev/sda3):
---------------------------------
Block Size | 4k (IOPS) | 64k (IOPS)
------ | --- ---- | ---- ----
Read | 281.33 MB/s (68.6k) | 3.68 GB/s (56.1k)
Write | 282.08 MB/s (68.8k) | 3.69 GB/s (56.4k)
Total | 563.42 MB/s (137.5k) | 7.37 GB/s (112.6k)
| |
Block Size | 512k (IOPS) | 1m (IOPS)
------ | --- ---- | ---- ----
Read | 12.83 GB/s (24.4k) | 3.39 GB/s (3.2k)
Write | 13.51 GB/s (25.7k) | 3.62 GB/s (3.4k)
Total | 26.34 GB/s (50.2k) | 7.01 GB/s (6.6k)
iperf3 Network Speed Tests (IPv4):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 2.31 Gbits/sec | 3.11 Gbits/sec | 71.6 ms
Eranium | Amsterdam, NL (100G) | 2.70 Gbits/sec | 3.02 Gbits/sec | 79.7 ms
Uztelecom | Tashkent, UZ (10G) | 1.08 Gbits/sec | 1.12 Gbits/sec | 169 ms
Leaseweb | Singapore, SG (10G) | 643 Mbits/sec | 900 Mbits/sec | 246 ms
Clouvider | Los Angeles, CA, US (10G) | 3.28 Gbits/sec | 3.83 Gbits/sec | 57.8 ms
Leaseweb | NYC, NY, US (10G) | 9.17 Gbits/sec | 8.40 Gbits/sec | 9.92 ms
Edgoo | Sao Paulo, BR (1G) | 1.59 Gbits/sec | 1.99 Gbits/sec | 119 ms
iperf3 Network Speed Tests (IPv6):
---------------------------------
Provider | Location (Link) | Send Speed | Recv Speed | Ping
----- | ----- | ---- | ---- | ----
Clouvider | London, UK (10G) | 2.64 Gbits/sec | 3.03 Gbits/sec | 70.6 ms
Eranium | Amsterdam, NL (100G) | 2.63 Gbits/sec | 3.06 Gbits/sec | 80.3 ms
Uztelecom | Tashkent, UZ (10G) | 1.04 Gbits/sec | 1.26 Gbits/sec | 169 ms
Leaseweb | Singapore, SG (10G) | 694 Mbits/sec | 905 Mbits/sec | 239 ms
Clouvider | Los Angeles, CA, US (10G) | 3.26 Gbits/sec | 3.92 Gbits/sec | 57.8 ms
Leaseweb | NYC, NY, US (10G) | 9.22 Gbits/sec | 9.23 Gbits/sec | 10.0 ms
Edgoo | Sao Paulo, BR (1G) | 1.62 Gbits/sec | 2.00 Gbits/sec | 125 ms
---------------------------------
Test | Value
|
Single Core | 1809
Multi Core | 3316
Full Test | https://browser.geekbench.com/v6/cpu/19039180
YABS completed in 13 min 23 sec
Network summary from that run:
NYC 9.34 / 9.35 Gbit/s, 9.8 ms | Los Angeles 3.33 / 4.15, 57 ms | London 2.19 / 3.00, 71 ms | Amsterdam 2.66 / 3.10, 80 ms | Sao Paulo 1.57 / 2.01, 117 ms
Terms: https://servury.com/terms/ (illegal content, CSAM, fraud, attacks, spam, mining and IP infringement get you suspended without refund; abuse reports from law enforcement with valid process, NCMEC, transit and valid DMCA are handled by a human).
Contact: https://servury.com | [email protected] | here
Feedback is heavily appreciated, chances are - if you have a good idea, we'll make it a thing 
Comments
kinda expensive i must say
and not resistant to dmca
It’s cheaper. Check it again.
GLWS
We re-specced the plans, have you checked again? If so, what do you think would be reasonable?
Yeah - that's more complicated. We're a legal, registered business and ignoring DMCA requests would almost certainly be against the Canadian criminal code.
Why? The DMCA is a US law, and last I checked Canada is not the 51st state.
But in reality you will see zero Canadian DMCA-free hosts. Almost the same with UK.
Why would they need to deal with that? Totally different audience. There are security and privacy minded people with opsec in mind, and there are "DMCA ignor" projects where most content is pirated and even encrypting the disks is barely worth the effort, not even talking about hypervisor isolation or SEV-SNP.
When you need a simple reverse proxy in Romania for your IPTV backend, you don't really care about 99% of what @servury is talking about. No-KYC is the only thing in common.
I highly doubt there's zero. Of course they can enforce whatever they want even if they're not obligated to, even Zimbabwean laws. Note that I'm also speaking about DMCA specifically, which is an American law, of course a lot of other countries (incl. Canada and Romania) have their own copyright laws, but those don't go under DMCA.
Now IANAL but as far as I understand, a Canadian hosting provider is protected (safe harbor) and basically only has to forward notices.
@servury said "would almost certainly be against the Canadian criminal code", that's all I'm contesting.
I'm no lawyer, but there's this:
https://laws.justice.gc.ca/eng/acts/c-42/page-9.html
Which makes it more or less same as DMCA. So they are kind of obligated to.
I can't say I know 100% of the Canadian hosts around there, but if you happen to know one that can tolerate copyright complains, feel free to mention. I'm sure it will be useful for US hosted backends due to latency. Mexico would be a good 2nd choice as well, but the costs are just too damn high.
Looking glass/test IP for other locations?
One thing for sure - you are not paying back the provider tag cost
Too expensive and niche
i can see alexhost.com offering DMCA UK VPS at this moment.
i don't know the details , but i am pretty sure there are some secrets in the DMCA business
Simple he's not registered in the UK, and until his DC get's wind which they won't no reason to care
There is no obligation to take anything down on a bare notice, but our terms go further than the law and treat IP infringement as a suspension offense. That's a choice, not a legal requirement. We are not a DMCA-ignore host, neither are we trying to be one.
Hey cool, I was literally just looking at your service after bailing from NoAck and 1984 - do you guys get impacted by Five Eyes in any way?
Great question.
What a court can make us hand over. Anything we have. We hold no name, email, phone or address (the account is a 32-character credential), no access logs anywhere, no analytics, support messages are deleted after 72 hours. What exists is a credential hash, an IP assignment, a payment record (a crypto address, or a Stripe charge if you paid by card) and the VM's disk image. On a Blackbox with LUKS set up, that image is ciphertext we cannot open and the memory is SEV-SNP encrypted so we can't lift the key from RAM either. A court can make us switch a machine off. It can't make us produce what we never collected.
Network interception. Your traffic crosses Five Eyes cables whether the server is in Montreal or Reykjavik. Use WireGuard or Tor and end-to-end crypto on top; we run .onion and I2P mirrors of the site for the same reason.
Gag orders. Canadian production orders can come with non-disclosure orders. That's what the PGP-signed canary is for: https://servury.com/canary/
Waiting for @forest seal of approval.
Pricing honestly not bad but was this YABS taken w/ SEV-SNP enabled? I'm no expert so I apologize if I'm wrong, but this throughput seems insane for being memory encrypted. Unless y'all doing some voodoo magic--would love to know how.
here is a fresh one from a guest I just spun up, with the kernel's own SEV lines in the same paste:
The encryption is not done by the CPU cores. SEV-SNP encrypts RAM with an AES engine sitting inside the memory controller, inline, with a per-VM key. The cores never touch ciphertext, so memory bandwidth barely moves. What SNP does cost you is that a device cannot DMA straight into encrypted guest memory, so every virtio transfer goes through a shared bounce buffer (the SWIOTLB line above). That is one extra memcpy per I/O: CPU time, not IOPS, and at 4k it does not show.
Any fio on a VPS is partly a cache test. The disk is an NVMe mirror on ZFS and the host has a large ARC, so the large-block numbers say as much about host RAM as about the drives. The August run hit 26 GB/s at 512k on a nearly empty node; today with a bunch of guests on it you get 7. The 4k number is the same as in August.
The encryption costs memory latency, not memory throughput. And of course it only costs latency if you have an LLC cache miss. Regarding the real-world performance impact, modern CPUs are very, very good at finding other work to do while they are waiting on a fetch from DRAM (out-of-order execution, speculative execution, superscalar execution with sophisticated false dependency breaking abilities, simultaneous multithreading, etc.).
Why not get rid of the large ARC and instead just give the VMs extra memory for their own page cache? Let the VMs handle it on their own since they have a better view of their own memory usage situation.
Every country has the equivalent of a DMCA law. It's just always cited because it's the most well-known
the ARC is capped at 16 GB on a 256 GB node (soon to be 512), so the other 94% already is guest memory. Each guest's page cache lives inside its own RAM, which is encrypted, the host can't cache on the guest's behalf. The ARC sits under the zvols and holds ZFS metadata and the hot blocks of all the guests at once (99.7% hit rate at the moment), and it absorbs the read-modify-write on 4k writes into 16K volblocks so the NVMe mirror sees fewer, bigger I/Os. I'm pretty sure dropping it would cost every guest latency.
Ah I was assuming you had the ARC configured much larger than that. Yeah that makes sense.