Why our VPN servers run from RAM only, and what happens in a seizure.
State of things on 19 October 2026: Pevnost is in private beta. The first server, prg1 in Hluboká nad Vltavou (WEDOS data centre), has been live since 18 October; a first short test measured around 300 Mbit/s. Every new account gets two free hours (one trial per connection, one device), then 120 CZK / €5 for 30 days or 1 200 CZK / €50 a year. Pay with Bitcoin on-chain (preferred), by card through Stripe or by bank transfer; Lightning is planned and Monero is coming. Windows app 0.3.1 beta, Android app 0.1.0 beta. Last reviewed 19 October 2026.
“Our VPN servers run from RAM only” is easy to write. This post explains what it means on our first node, prg1, in the WEDOS data centre in Hluboká nad Vltavou: how it boots, what is on its disk, where its keys come from, what the hash on our status page does and does not prove, and what a seizure would yield. The threat model behind it is in what a VPN server seizure actually yields.
How the node boots
The bootloader on the disk loads a kernel, an initramfs and a compressed filesystem image of about 260 MB, built from Debian. With the toram parameter the whole image is copied into memory; the root filesystem, including its writable layer, lives in RAM. From then on the system neither needs the disk nor writes to it. There is no swap, the system journal is volatile, our DNS resolver keeps no query log, there is no SSH server and the root account is locked.
What is on the disk
The bootloader, the kernel, the initramfs and the image. One more thing, in honesty: a small carrier system from the original installation, which we boot only to replace the image. It does not run in normal operation and holds no VPN keys or customer data; we plan to remove it once images can be replaced another way. The node writes to the disk in one case only: when we trigger an image replacement, it sets a one-time flag in the bootloader environment so that the next boot goes to the carrier system.
Where the keys come from
The image contains no secrets: only the public keys of our control server, its certificate authority and addresses. After boot the node creates a temporary management key in memory, registers with the control server, which runs in a different data centre, and reports which image it booted. We approve it by hand, after every boot. Only then does it receive its WireGuard key and the list of device public keys. An approval request we did not expect is an incident, not a restart: we do not approve it, and a node without keys carries no traffic.
The published hash, and its limits
The status page, refreshed every five minutes, shows which nodes are online and the ID and SHA-256 of the published image. Every change of image shows up as a new hash. What this proves: which build we say is deployed, and that we cannot quietly swap it without the page changing. What it does not prove: that the machine in the rack runs exactly that build. From outside you cannot verify that today. Reproducible builds, so you can compute the hash yourself, are planned; remote attestation through a TPM, where the hardware itself vouches for what booted, is planned for our own hardware. Until then the hash is a public commitment, not a proof.
What you can check yourself
Look at the status page now and then: the hash should change only with an announced image replacement. Your configuration file carries our server’s public key in the [Peer] section; if a fresh download shows a different key without an announced rotation, tell us.
What a seizure yields
- Switched off: a disk with the public image and the carrier system. RAM loses its contents within seconds to minutes. Nothing about past sessions. Booted elsewhere, the node asks for approval, does not get it, and never receives a key.
- Running: memory holds the server key, device public keys with tunnel addresses, and for each connected device its current address and last handshake time. A prepared attacker could try a cold-boot attack. Our rented hardware has no memory encryption; AMD SME/TSME or equivalent is planned for our own machines. That would reveal a moment, who was connected right then, not history.
- Our response: if we suspect memory of a running node was read, we replace the server key. Our apps fetch the new signed server list; with the official WireGuard app you download a new configuration file.
A production order to us returns the short list in the privacy policy: account ID, expiry, device public keys, payment record, aggregate load. And the data centre, like any carrier, can see which addresses connect to the node and sample flows; no RAM-only design changes that.
Why bother
“We promise not to log” depends on our behaviour. “The machine has nowhere to keep a log” depends on its design, which you can read about and partly check. We would rather spend the effort there, and tell you where the checking stops. Mullvad and other providers run diskless servers too; what we add is a short list of what exists and the honesty about the parts we cannot yet prove.