Cybersecurity · Educational Resource

How Mullvad Built
RAM-Only Servers

An interactive exploration of diskless VPN infrastructure, the stboot bootloader, and what "volatile by design" means for privacy.

↓ SCROLL TO EXPLORE
01 — The Problem

Why go diskless in the first place?

Traditional VPN servers store their operating system, configuration, logs, and encryption keys on physical hard drives or SSDs. Even with full-disk encryption, this creates a tangible attack surface: if a server is physically seized, powered down, and analyzed, forensic investigators may recover data remnants — IP addresses, timestamps, connection logs — that could compromise user privacy.

Mullvad's answer is radical simplicity: remove the disk entirely. When the only storage medium is volatile RAM, every byte of operational data vanishes the moment electrical current stops flowing. There is nothing to image, nothing to decrypt, nothing to reconstruct.

Key insight: RAM (Random Access Memory) is volatile — it requires continuous power to retain data. Unlike SSDs or HDDs, it does not persist information after shutdown. Mullvad exploits this physical property to make forensic data recovery effectively impossible after a power loss.

It's worth noting: RAM-only infrastructure doesn't make logging impossible in an absolute sense — a running server could theoretically still log to RAM during an active session. What it guarantees is that no persistent record survives a reboot or power interruption. Mullvad combines this with a strict no-logs policy and independent audits (conducted in 2022 and 2023 by Cure53) to provide defense in depth.


02 — The Mechanism

System Transparency & the stboot bootloader

The technical backbone of Mullvad's diskless infrastructure is a project called System Transparency, centered around a custom bootloader named stboot. This is a LinuxBoot distribution built on top of u-root, a Go-based toolkit for creating minimal Linux initramfs environments.

stboot is the System Transparency Project's official bootloader. It functions as an init program inside an initramfs, combined with a Linux kernel to form a complete LinuxBoot distribution. When a Mullvad server powers on, stboot is the first software that executes.

Rather than reading an OS from a local disk, stboot downloads a signed OS package from a separate provisioning server over the network. This means the VPN server itself has no permanent storage media whatsoever — not even a small boot partition.

The OS package is a bundled archive containing everything the server needs: the userspace, system libraries, VPN software (WireGuard), and configuration. All artifacts are cryptographically signed by authorized Mullvad staff.

The entire operating system image weighs in at just over 200 MB — a testament to how aggressively Mullvad has stripped out unnecessary components. Once loaded into RAM, the server runs entirely from memory. No swap partitions, no temp files on disk, no persistent journals.

Mullvad maintains a custom, heavily slimmed-down Linux kernel that follows the mainline branch of kernel development. By tracking mainline, they pull in the latest security patches and performance improvements promptly.

The kernel is tuned to remove all unnecessary modules and bloat. This minimizes the attack surface and keeps the memory footprint small enough to run a production VPN server entirely from RAM without performance degradation.

Before booting the downloaded OS package, stboot performs cryptographic signature verification. It checks that the package was signed by authorized Mullvad staff using pre-configured signing keys. If the signature doesn't match, the boot process halts — the server refuses to run unverified code.

Mullvad's long-term vision includes TPM-based remote attestation, reproducible builds, and a transparency log — enabling users to independently verify which exact code is running on any given VPN server they connect to.


03 — Interactive Simulation

Watch a simulated boot sequence

Click "Start Boot" to step through a simplified simulation of how a Mullvad RAM-only server initializes, loads its OS into memory, and begins serving VPN connections.

mullvad-se-got-wg-001 — boot console

04 — Architecture Overview

How the pieces connect

The diskless infrastructure relies on a clear separation between provisioning servers (which hold the signed OS images on disk) and VPN servers (which run entirely from RAM).

📦
Provisioning Server
Stores signed OS packages on encrypted disks. Serves images over the network to booting VPN servers.
→→→ signed OS pkg
🖥️
VPN Server (RAM-only)
No disks. Boots stboot from firmware, downloads & verifies OS, runs entirely in volatile RAM.

What about the provisioning servers? They do use disks, but contain only the signed OS images and base configuration data — no user traffic, no connection metadata, no VPN keys. The VPN servers that handle your actual traffic are the ones running diskless.


05 — Project Timeline

From beta to full deployment

January 2022
Beta launch — 2 servers in Sweden
Mullvad introduced the first two stboot VPN servers in Gothenburg and Stockholm, running entirely from RAM. WireGuard keys were wiped on every restart during this phase.
August 2022
Global expansion begins
More RAM-only servers deployed worldwide. WireGuard keys were now persisted across controlled reboots for better user experience, while remaining in RAM only.
2022 – 2023
Independent audits by Cure53
The RAM-only infrastructure was audited twice by the security firm Cure53, focusing on the diskless configuration and no-logs claims.
September 2023
Migration complete — 100% diskless
Mullvad announced the complete removal of all disks from their VPN infrastructure. Every server in the network now runs exclusively from RAM.
November 2023
Encrypted DNS servers go RAM-only
Mullvad extended the diskless approach to their DNS-over-TLS and DNS-over-HTTPS servers, using the same custom kernel and stboot infrastructure.

06 — Disk vs. RAM

What changes with diskless infrastructure?

Property Disk-based Server RAM-only Server
Data persistence Survives reboot & power loss Lost immediately on power loss
Forensic recovery Possible (even with encryption) Physically impossible after shutdown
Physical seizure risk Disk can be imaged Unplugging destroys all data
OS update process In-place updates, potential drift Fresh verified image every boot
Log file accumulation Logs can persist indefinitely No logs survive a reboot cycle
Hardware failure points Disk failure is common cause Fewer moving parts / failure modes
Tamper evidence Harder to detect modifications Signature verification each boot

07 — Visual Demonstration

What happens when power is cut?

Each bar below represents a segment of RAM holding operational data: WireGuard keys, connection state, OS code. Press the button to simulate a power interruption.

Server running — 64 RAM segments active

08 — Test Your Understanding

Knowledge check

See how well you've absorbed the material. Click an answer to check.