RAM-Only VPN Servers vs Encrypted Disks: What Actually Changes

Imagine two VPN servers sitting side by side in a commercial datacenter. Without warning, local authorities arrive with a warrant, pull both power cables from the wall, unrack the machines, and carry them out the door.

The first machine is a “RAM-only” or “diskless” node: it contains no hard drive or solid-state drive whatsoever. The second machine is a traditional server equipped with standard enterprise SSDs.

To anyone skimming VPN marketing, the verdict seems obvious. The RAM-only server is hailed as a privacy fortress where all evidence vanished the second the power died, while the traditional server is assumed to be an open book waiting to surrender user logs, encryption keys, and browsing histories.

That conclusion is tidy, intuitive—and largely wrong.

If the traditional server was configured with robust full-disk encryption and stored its decryption keys off-site, an adversary who pulls the plug walks away with an unreadable brick of encrypted noise. In a powered-down seizure, both machines can yield the exact same result: effectively nothing.

The real engineering debate between RAM-only servers and traditional hardware is not about the storage medium inside the chassis. The critical difference is forced ephemerality—what happens to the server when it boots back up, how unauthorized changes are eradicated, and whether anyone has independently verified that the system operates the way the marketing claims.

What RAM-Only Actually Wins: Powered-Off Ephemerality

To evaluate RAM-only architecture fairly, you must first recognize where its genuine advantage lies.

Traditional storage media—hard drives and NVMe SSDs—are non-volatile. They retain their physical magnetic or electronic charges indefinitely after the power cord is cut. Volatile memory (RAM) loses its state once the electrical current ceases.

Industry leaders like ExpressVPN (with its TrustedServer deployment) and Mullvad have built their flagship infrastructure around this property:

[ Traditional Disk Server ]
OS + Apps + Swapfile + Configs ──▶ Written to Local Disk (Non-Volatile)
* Survives unexpected shutdown, retirement, or physical removal.

[ RAM-Only / Diskless Server ]
OS + Apps + Working State       ──▶ Loaded exclusively into RAM (Volatile)
* Power down ──▶ Physical memory clears ──▶ Zero historical state on the machine.

By eliminating local disks entirely, a provider closes a specific set of operational risks:

• Decommissioning and Rental Leases: Commercial VPNs lease thousands of bare-metal servers worldwide. When a lease ends, an unencrypted disk could theoretically retain residual data if not wiped to military standards. On a diskless box, there is simply no physical medium left behind to sanitize.
• Physical Seizure of Idle Hardware: If an unplugged server is confiscated, forensic investigators cannot mount a local drive to hunt for lingering temporary files, forgotten crash dumps, or configuration artifacts.

Removing persistent storage from the shutdown-and-seizure equation is a meaningful design improvement. But it is an improvement over an unprotected disk, not the only way to defend data.

The Parity Check: Encrypted Disks Pass the Same Seizure Test

The common marketing narrative assumes that every traditional server is an unencrypted liability. That creates a false dichotomy.

A well-architected traditional server does not leave plaintext data sitting on bare metal. Serious privacy providers that utilize disks—such as Proton VPN—deploy Full-Disk Encryption (FDE) paired with centralized, remote key management.

[ Powered-Off Seizure Comparison ]

RAM-Only Server:
Power Cut ──▶ Volatile memory drains ──▶ Physical hardware retains NO data.

Encrypted Disk Server (FDE):
Power Cut ──▶ Key in RAM lost; Disk remains locked with AES-256 ──▶
              Decryption key resides on an external, remote authentication server.
              Hardware retains ONLY ciphertext; unreadable without keys.

When an encrypted server is unplugged, the decryption key held in active memory evaporates. The persistent disk remains locked behind strong encryption (such as LUKS/AES-256). Because the decryption keys are held on remote, hardened infrastructure rather than stored locally on the drive, an investigator who seizes the physical machine cannot read a single sector without compromising the remote key authority.

Mullvad pointed out this exact parity when documenting its transition to diskless infrastructure: its earlier disk-based servers were already fully encrypted, meaning physical theft was never a simple matter of mounting a drive.

A diskless architecture is structurally cleaner because it eliminates the storage layer altogether. But you cannot award a VPN a gold star simply because it doesn't have an SSD—an encrypted traditional server survives the powered-down seizure test just as effectively.

The Real Advantage: Immutable Rebuilds and Eradicating Drift

If both architectures survive being pulled from the rack, where does RAM-only actually pull ahead?

The definitive advantage of a diskless architecture is not what happens when the server powers down; it is what happens when the server boots back up.

Traditional servers are typically long-lived pets. They boot, run for months or years, and receive iterative software updates, configuration tweaks, and emergency patches while live. Over time, this leads to two major security headaches:

1. Configuration Drift: Across a global fleet of hundreds of servers, subtle discrepancies creep in. One server might run an outdated package, another might have a diagnostic log left open, and consistency across the network slowly erodes.
2. Persistent Adversary Footholds: If an attacker discovers a zero-day exploit and gains root access to a traditional server, they can modify system binaries, install a hidden rootkit, or configure a persistent backdoor on the disk that quietly survives routine system restarts.

A modern RAM-only deployment solves this by pairing diskless hardware with an immutable, cryptographically signed boot image.

[ The Immutable Boot Cycle (e.g., TrustedServer / stboot) ]

1. Server Boots ──▶ Fetches read-only, cryptographically signed OS image via network.
2. Verification  ──▶ Cryptographic signatures verified against master root keys.
3. Execution     ──▶ Entire operating system loads into volatile memory.
4. Operation     ──▶ System runs without persistent disk access.
5. Reboot        ──▶ Complete wipe. Server downloads a fresh, identical image.

In systems like ExpressVPN’s TrustedServer and Mullvad’s diskless stboot deployment, the server does not retain local modifications. Every time the machine reboots:

• The entire operating system, kernel, VPN software stack, and configuration are deployed fresh from a standardized, read-only master image.
• Any unauthorized change, lingering diagnostic file, or attacker implant running in memory is completely vaporized.
• Configuration drift is mathematically eliminated because every node in the fleet boots from the exact same signed manifest.

This is the true engineering victory of RAM-only infrastructure: it forces ephemerality across the server's entire operational lifecycle.

The Hard Limit: RAM Does Not Stop a Live Attack

While forced ephemerality is powerful, the marketing surrounding RAM-only servers often promotes a dangerous myth: that a RAM-only server "cannot log" or is somehow immune to compromise while running.

That claim defies basic computer science.

A VPN server cannot forward packets if its memory is empty. While powered on and servicing traffic, a RAM-only server must hold:

• Active user connection states and virtual IP assignments
• Operational cryptographic session keys
• Live routing tables
• Executing software code in active memory

As Proton has pointed out in critiques of diskless marketing, if an adversary achieves administrative or kernel-level compromise on a server while it is running, they have access to everything currently passing through volatile memory:

| Adversary Scenario | RAM-Only Server | Encrypted Traditional Server | | Server unplugged and seized | Protected (memory wiped) | Protected (disk encrypted, keys off-site) | | Retired drive sold/scrapped | Protected (no media exists) | Vulnerable if poorly sanitized; protected if FDE | | Live administrative compromise | Vulnerable (memory is readable) | Vulnerable (memory is readable) | | Malicious insider orders live wiretap | Vulnerable (traffic inspectable) | Vulnerable (traffic inspectable) |

Furthermore, running in RAM does not prevent a rogue or dishonest provider from enabling logging. An application can collect connection metadata in memory and continuously transmit those logs over the network to an external logging bucket.

RAM-only architecture dictates where local data can be written. It does not dictate what the operating system chooses to send over the wire.

This is why public claims about hardware mean very little without independent, third-party infrastructure audits. Mullvad did not simply tell the public it was diskless; it commissioned independent security firms like Radically Open Security to audit its live server infrastructure and verify that customer activity was not being logged. ExpressVPN subjected its TrustedServer deployment to similar external technical scrutiny.

The hardware architecture limits accidental persistence; independent audits verify active operational integrity.

The Buyer's Rule: Focus on Verified Architecture

When shopping for a privacy-focused VPN, stop treating "RAM-only" as a binary checklist item that instantly crowns a winner.

Use this clear evaluation criteria instead:

If You Demand Maximum Infrastructure Verifiability

If your personal threat model prioritizes resilience against persistent compromises, fleet-wide consistency, and defense against physical datacenter tampering, choose a provider with a publicly documented, audited diskless rebuild model.

• Look for explicit technical documentation detailing signed, read-only boot images (such as ExpressVPN’s TrustedServer or Mullvad’s stboot).
• Verify that independent auditors have inspected the live infrastructure to confirm the absence of persistent logs.

If the Provider Uses Encrypted Traditional Servers

Do not write off a provider simply because its infrastructure uses local storage drives.

• Demand proof of full-disk encryption with centralized, off-site key management (such as Proton VPN's documented deployment).
• Look for an established, legally tested, and independently audited no-logs track record. A hardened, encrypted disk-based fleet with zero-log auditing is vastly superior to an unaudited "RAM-only" marketing claim.

Where Alternative Privacy Models Fit (e.g., OnlydogVPN)

Not every privacy challenge happens in the server rack. While infrastructure architecture governs data retention on the network side, user privacy often breaks down much earlier: at the account and identity layer.

If an audited RAM-only infrastructure is your strict, non-negotiable requirement, an established diskless provider like Mullvad or ExpressVPN remains the appropriate architectural choice.

However, if your primary everyday concern is eliminating identity trails before your packets ever reach a datacenter, OnlydogVPN^↗ approaches the problem from the credential side. Rather than requiring users to maintain a traditional, persistent user account tied to a reusable password and personal profile, OnlydogVPN utilizes a streamlined verification flow designed to minimize upfront customer metadata.

It pairs that low-account-data footprint with an advanced HTTP/3-based transport layer and automated route discovery across mobile and desktop.

The distinction should be kept clear: minimizing account data is a client-side identity safeguard; it is not a substitute for audited RAM-only server engineering. Both represent legitimate, distinct layers of a thoughtful privacy posture.

The Working Rule

The next time a VPN provider boasts that its servers run entirely in RAM, look past the headline.

Don't ask: "Does this server use RAM?" (Every computer uses RAM).

Ask the questions that actually matter to your security:

1. What survives when the machine is rebooted?
2. Does the server reload an immutable, cryptographically signed image, or does it accumulate unvetted changes over time?
3. Has an independent cybersecurity firm verified that the live infrastructure leaves no trace?

Judge the server by its operational lifecycle and verified integrity—not by the storage material inside the box.