What Is a RAM-Only VPN Server? (And How It Works in 2026)

RAM-only VPN servers wipe all data at every reboot. That is the claim, and on a powered-off server subjected to post-seizure forensic examination, it is accurate. The protection is real, it is enforced by hardware physics rather than policy, and it is independently verifiable in ways that a software-based no-log promise cannot match. A provider whose servers hold no persistent data cannot produce that data under compulsion, regardless of jurisdiction or court order.

Two qualifications apply. The first concerns implementation: three configuration requirements must be met for the architecture to deliver what it promises, and a misconfiguration in any of them partially or entirely undermines the guarantee. The second concerns scope: RAM-only protects against one specific threat model and does not address several others, including one limitation the marketing copy never mentions.

Readers new to VPNs or no-log policies should start with how a VPN actually works or the no-log VPN verification guide before continuing.

What a RAM-only VPN server is

A RAM-only VPN server stores no data on any persistent hardware. The operating system, configuration, and all session data run entirely in volatile memory and are erased the moment the server loses power. There is no hard drive or SSD on which data can accumulate or be imaged by a forensic investigator.

“RAM-only” here describes how a VPN provider builds its servers, not how much memory the VPN app consumes on your own device. It is unrelated to a ramdisk or local tmpfs partition on your machine. The protection at issue is against physical or legal seizure of provider server hardware. On-device threats such as malware, endpoint monitoring, or browser fingerprinting are outside its scope. Self-hosted VPN configurations are out of scope.

Volatile vs. persistent memory

RAM requires continuous electrical power to retain data. Remove that power and all data is gone: not overwritten, simply absent as the charge dissipates. A hard drive or SSD retains data indefinitely after power is removed, until that data is explicitly overwritten. File-system deletion marks storage blocks as available for reuse; it does not erase the underlying data. Forensic tools read the raw storage medium and reconstruct data that has been “deleted” but not yet overwritten.

Residual charge in DRAM persists briefly after power is cut, nearly intact at five seconds at room temperature and degrading across 30 seconds, 60 seconds, and five minutes. Data is unrecoverable under normal conditions.

Why this matters on a VPN server

On a traditional disk-based VPN server, configuration files, temporary OS logs, and session artefacts accumulate through ordinary operating system behaviour, not necessarily through deliberate logging. A provider with genuine no-log intent can still have data land on disk that it never chose to write there: syslog writes, journald entries, VPN daemon temporary files, swap activity. When that server is powered off and forensically imaged, all of it is available to the investigator.

RAM-only removes this failure mode at the hardware level: there is no disk for data to land on, so the protection is not contingent on correct log-deletion configuration.

How it works: the read-only boot image

A RAM-only server boots from a read-only image that loads the entire software stack into volatile memory at startup. Two confirmed implementation approaches exist.

Booting without a disk

The first approach uses a locally stored, cryptographically signed, read-only image loaded into RAM at boot. The server then runs entirely from volatile memory. ExpressVPN’s TrustedServer uses this model; ExpressVPN’s documentation compares the boot process to how Tails OS operates.

The second approach is fully diskless. Mullvad’s infrastructure uses a custom bootloader called stboot, part of the System Transparency project (maintained at Glasklar Teknik). stboot is a UEFI/LinuxBoot bootloader that fetches a cryptographically signed OS package from a provisioning server (over HTTP or HTTPS) at boot time and verifies the package’s signature against a configured trust policy before proceeding. The security guarantee comes from signature verification, not the transport layer. No local disk on which data can persist is present on the machine. (A third class of implementation uses PXE/iPXE network boot — a similar network-provisioning principle through a different mechanism — but no major commercial VPN provider has documented this as their specific approach.)

What “read-only” means for security

In all three approaches, the image cannot be modified by any process running on the server during operation. Changes can only be made to the image source before the next boot.

First, no data from any session can persist to the image. Second, an attacker who compromises a running RAM-only server cannot install persistent software. Any modification — a backdoor, an altered configuration, an injected logging process — is erased at the next reboot. On a disk-based server, software installed during an intrusion survives every subsequent reboot.

How runtime writes are handled

A running server generates data during operation: temporary logs, daemon state, runtime artefacts. A RAM-only server handles these through an overlay filesystem architecture. The read-only boot image forms a base layer; a writable overlay, typically a RAM-based temporary filesystem such as tmpfs mounted via a union filesystem like OverlayFS, sits on top. Any writes during operation go to the RAM overlay, not to any persistent medium. At reboot, the overlay is discarded along with everything in it. This is the same architecture used by Tails OS and similar live systems. The server behaves normally; nothing from any session survives the reboot.

Configuration consistency as an operational benefit

Because every server in a fleet boots from the same signed image, every server runs identical code. There is no accumulated state or configuration drift between servers. The provider knows exactly what is running on every server at all times, and the attack surface from a server running modified software is eliminated at every reboot.

What RAM-only servers protect against

RAM-only architecture provides three distinct protections, each covering a different failure mode on disk-based infrastructure.

Post-seizure forensics

If a server is powered off before or during seizure, there is nothing on disk to recover. There is no persistent storage medium to image, no deleted files to reconstruct, no session artefacts to subpoena.

Windscribe, June 2021 — outcome: unencrypted disks yielded recoverable material the moment they were seized. Ukrainian authorities seized two Windscribe VPN servers. The servers were disk-based and unencrypted; the disks held an OpenVPN private key that, under narrow conditions (an attacker-controlled network and a target using a custom OpenVPN configuration), could have enabled server impersonation. The risk was impersonation, not exposure of stored user activity data. CEO Yegor Sak acknowledged the operational security failure. The remediation completed in July 2021 included migrating the affected infrastructure to RAM-only: all cryptographic keys now exist in volatile memory and are erased on reboot.

What it proves: disk-based, unencrypted infrastructure produces recoverable material under seizure. The incident is what drove Windscribe to adopt RAM-only infrastructure.

Mullvad VPN, April 2023 — outcome: Swedish police executed a search warrant at Mullvad’s Gothenburg office and left without seizing anything. Officers arrived on 18 April 2023 at the request of German judicial authorities, investigating a blackmail attack against municipal institutions in Mecklenburg-Western Pomerania in October 2021, and intended to take computers containing customer data. Mullvad demonstrated that no such data existed on any of its systems; officers consulted the prosecutor on-site and departed. It was the first time Mullvad’s offices had been visited by police with a search warrant in the company’s history.

What it proves: a genuine no-logs, data-minimising provider has nothing to hand over even under a warrant. Note: Mullvad’s full RAM-only infrastructure migration completed in September 2023, five months after this raid. The raid demonstrates the no-logs policy in operation, not RAM-only server architecture specifically.

Accidental data persistence

Even providers with genuine no-log intent can have data land on disk through standard OS behaviour: syslog writes, journald persistence, swap activity, temporary files created by the VPN daemon. A misconfigured disk-based server can retain session data it was never intended to keep. RAM-only removes this failure mode at the hardware level. There is no disk for data to land on.

Backdoor persistence

An attacker who gains write access to a running disk-based server can install software that survives reboots. On a RAM-only server booting from a read-only image, that foothold cannot survive the next reboot. Persistent compromise requires attacking the image-build or provisioning pipeline rather than the running server, which is a harder and more detectable attack surface.

Where the protection ends

RAM-only architecture does not protect a server that is running.

The live server problem

Investigators can read a running server’s memory directly via a DMA (Direct Memory Access) attack. DMA attacks exploit peripheral interfaces such as PCIe or Thunderbolt to read system memory without requiring any software running on the target; PCILeech is a documented tool that implements this over PCIe. On server hardware, the out-of-band management controller is the more operationally relevant vector: BMC (Baseboard Management Controller) and iLO interfaces provide remote hardware-level access that can be used for memory acquisition. Researchers have demonstrated a PCILeech-based device targeting BMC interfaces (BMCLeech) and have exploited HP iLO 4 for remote memory acquisition.

A running RAM-only server and a running disk-based server with full-disk encryption are equally vulnerable to live access. The post-seizure protection does not exist while the server has power.

On rack-mounted data-centre servers, the realistic forensic scenario is on-site live memory acquisition via software capture or DMA/BMC access. Physically transporting a still-powered rack-mounted server to preserve RAM contents is not a practical procedure for data-centre hardware. Standard law enforcement seizure procedure involves powering hardware down before forensic examination: exactly the scenario RAM-only is designed for. The live-access vulnerability is real; it is not the common operational threat model for VPN server seizures.

Cold boot attacks

After power is removed, RAM chips retain residual electrical charge for a brief period during which data may be partially recoverable. Research by Halderman et al. (USENIX Security 2008) measured DRAM content as nearly intact five seconds after power-off at room temperature, degrading across 30 seconds, 60 seconds, and five minutes. In a cold boot attack, an investigator applies freeze spray or cryogenic cooling to RAM chips immediately after power-off to slow charge decay. The researchers measured fewer than 1% of bits decayed after 10 minutes of freeze-spray cooling, and approximately 0.17% bit decay after 60 minutes of liquid-nitrogen submersion.

The simplest variant reboots the target into a small custom kernel to read residual memory in-place, without removing any hardware. The most involved variant transplants DRAM modules to an attacker’s machine.

Documented cold boot research and forensic applications have focused on endpoints (laptops and desktops running full-disk encryption) rather than rack-mounted data-centre hardware. Server DIMMs, data-centre physical access controls, and the act-within-moments-of-power-off constraint all differ materially from the endpoint scenarios. Cold boot is a real and documented capability; for VPN server infrastructure it sits at the outer edge of the threat model.

Remote logging: the threat RAM-only does not address

RAM-only prevents data from persisting on the local server. It does not prevent a provider from transmitting logs in real time to a separate, disk-based server elsewhere. A RAM-only server that streams connection metadata to a remote database the moment each session begins provides no protection from that data.

RAM-only is a hardware constraint on local persistence. It is not a constraint on what the server software transmits over the network. RAM-only must therefore be evaluated alongside an independently verified no-log policy and a substantive audit of what the server software does. It is not a substitute for either.

RAM-only vs. full-disk encryption: an honest comparison

RAM-only and full-disk encryption are the two dominant approaches to server-side privacy in commercial VPNs. They converge on one protection and diverge on two others. The converging protection is post-seizure forensics on a powered-off server; the two divergences are accidental data retention and auditability. ProtonVPN, which uses LUKS full-disk encryption (AES-256) across all its servers and has published a formal explanation of its position, makes a substantive case for FDE. That case is correct in the specific scenario where it applies.

Where they converge

On a powered-off server, a correctly implemented FDE disk with keys stored off the server yields nothing readable to an investigator without the decryption keys. A powered-off RAM-only server also yields nothing.

ProtonVPN’s stated operational reasons for preferring FDE are local storage of no-PII system logs, simpler feature rollouts that do not require full server reboots, and cleaner diagnostic access during incidents.

Where RAM-only differs

Accidental retention. FDE protects data that reaches disk by encrypting it at rest, but it does not prevent data from being written to disk in the first place. A misconfigured FDE server can accumulate session data it was never supposed to keep. That data, while encrypted at rest, is in decrypted form during normal server operation. RAM-only prevents the write entirely: there is no disk, so the failure mode of unintended data persistence is eliminated at the hardware level.

Auditability. Verifying that an FDE server genuinely retains no user data requires confirming that logging processes are correctly suppressed across the full software stack — a software-layer claim with surface area between what a point-in-time audit captures and what the running system does between audit cycles. A RAM-only implementation can be assessed at the architecture and boot-configuration level: auditors examine how the server boots, confirm the boot image is signed and the implementation is diskless, and verify the swap configuration.

The honest conclusion

RAM-only and FDE are equivalent on post-seizure forensics for a powered-off, correctly configured server (with decryption keys stored off the server on the FDE side). RAM-only adds structural advantages on accidental retention and auditability. An FDE implementation with strong key management, a verified no-log policy, and regular independent audits is a coherent and defensible privacy posture; it is not the same as RAM-only across all three dimensions. Neither approach prevents remote logging by the provider, and neither protects a running server against live memory access.

Whose threat model RAM-only actually fits

RAM-only is a provider infrastructure decision, not a user setting.

RAM-only eliminates the risk of post-seizure forensic recovery from powered-off server hardware. That risk is material for users whose adversary can compel physical server access through law enforcement. Journalists protecting source communications, activists operating under governments with aggressive legal reach, and anyone whose traffic is the target of a formal investigation directed at the provider are the users for whom this architectural choice changes something concrete. For those users, a provider operating RAM-only infrastructure presents investigators with nothing recoverable when they arrive with a warrant, regardless of the provider’s legal obligations.

For the majority of users, the operative threat model is passive: ISP tracking, advertising profiling, and opportunistic surveillance on public networks. Transport encryption and a verified no-log policy already address those threats. RAM-only adds a marginal improvement in those contexts but does not change the protection a properly configured VPN already provides.

RAM-only is a hardware constraint on local data persistence, not on what the server software transmits over the network. A provider that streams connection logs to a remote system in real time defeats RAM-only’s protection entirely. The architecture is necessary but not sufficient: it must be paired with an independently audited no-log policy that covers what the software does, not only what the hardware can store.

Implementation requirements

Three configuration requirements must be met for RAM-only architecture to deliver what it promises.

Swap must be disabled

If the operating system has swap enabled, the kernel can write RAM contents to a swap partition on disk during memory pressure events. The written content can include session data, connection state, or cryptographic material that should exist only in volatile memory. Swap is commonly present on Linux installations and, where enabled, creates this exposure. A properly configured RAM-only server must have swap disabled at the OS level. This must be explicitly verified, not assumed from the hardware architecture.

Kernel-level logging must be suppressed

Standard Linux configurations write system logs to persistent storage by default. rsyslog writes to /var/log on disk; journald persists to /var/log/journal where that directory exists. A RAM-only implementation must redirect all logging to memory-only destinations or suppress it entirely. Logs that reach persistent storage survive a reboot even when the rest of the server’s runtime data does not. The guarantee is only as complete as the logging configuration.

Boot image integrity must be maintained

The read-only image from which the server boots is the trust anchor for the entire architecture. If that image is compromised, whether through a supply chain attack, an infrastructure breach at the provisioning level, or inadequate access controls over who can authorise image changes, every server booting from it is affected. The immutability of the running server does not protect the image source itself.

TPM (Trusted Platform Module) remote attestation measures each component of the boot chain into tamper-evident registers and produces a signed attestation a remote verifier can check against known-good values. Reproducible builds, where a server image binary can be independently verified against published open-source code, are a stated design goal of the System Transparency project that stboot belongs to. Neither is confirmed current practice across the industry. Boot image integrity is the implementation requirement most scrutinised in any audit engagement.

The auditability advantage

RAM-only architecture can be assessed at the hardware and boot-configuration level. That is not possible for a software-based no-log claim, which requires auditors to verify that logging processes are correctly suppressed across a running software stack, a more complex and gap-prone verification target.

The PwC Switzerland engagement of ExpressVPN’s TrustedServer (June 2019) was conducted under ISAE 3000 (Revised); the KPMG engagement (February 2025) was conducted under ISAE (UK) 3000 Type 1 — KPMG’s own label for a point-in-time snapshot of whether the architecture matches the claim, as opposed to a continuous operational guarantee. The hardware-level nature of the RAM-only claim means the architecture is harder to misrepresent in an audit: confirming a server has no writable storage is a different class of evidence from confirming that software log-deletion is correctly configured and not bypassed.

Because stboot downloads a signed OS package and verifies its cryptographic signature against a configured trust policy before booting, the boot process is verifiable without scheduled auditor visits. stboot’s signature verification is separate from TPM remote attestation, which measures boot chain components into hardware registers and produces a remotely verifiable signed quote. The System Transparency design incorporates TPM attestation as a design goal, but whether the full user-verifiable attestation layer is deployed in production has not been confirmed; stboot’s signature verification itself is.

Who has it and when it started

RAM-only infrastructure in commercial VPNs dates to April 2019. It was not a founding feature of the industry; it emerged as an architectural upgrade that one provider introduced and others adopted over the following four years.

ProtonVPN does not use RAM-only servers on any part of its infrastructure, including Secure Core. It uses LUKS full-disk encryption (AES-256) across all servers and has published a formal explanation of this choice.

How to verify a RAM-only claim

Four signals indicate whether a RAM-only claim is real:

Independent audit explicitly covering server architecture. A no-log audit that does not address the RAM-only implementation does not confirm it. The audit report must name the server architecture in its scope, not only the logging policy. ISAE 3000-style architecture and controls assessments from named firms, with the RAM-only implementation explicitly within scope, are the reference standard. An audit from four years ago or one that reviewed only a mobile application does not confirm current server-side behaviour.

Technical documentation describing the boot model. A provider with a genuine RAM-only implementation can describe how its servers boot, what the image contains, how updates are deployed, and how swap and kernel-level logging are handled. Named technologies with described behaviour (stboot, TrustedServer, UEFI image signing, tmpfs overlay, disabled swap configuration) are documentation. A marketing page that uses the phrase “RAM-only servers” without describing the implementation is not.

Cryptographic verification of boot state. Providers that publish their boot process through cryptographic signature verification, as in Mullvad’s stboot approach, allow independent confirmation of what software a server booted without depending on scheduled auditor visits.

Real-world legal test with no data produced. A law enforcement request, physical server seizure, or court order that returned nothing is the strongest operational validation available. The closest real-world test to date is the February 2026 seizure of a Windscribe RAM-only server by Dutch authorities, which Windscribe says yielded nothing but a stock OS install. That outcome rests on the provider’s own account: there is no published forensic report, it is unclear whether the machine was powered off before capture, and the seizure’s legality is disputed.

A cleanly documented, independently verified seizure of a powered-off RAM-only server yielding nothing has not been publicly documented — the physics are clear, the confirmed field test is not. Mullvad’s April 2023 warrant demonstrates a genuine no-logs policy withstanding police pressure; the Windscribe case (June 2021) demonstrates what happens without proper architecture on unencrypted disk-based hardware. 

Frequently asked questions

What is a RAM-only VPN server?

A RAM-only VPN server runs its entire operating system, configuration, and session data in volatile memory (RAM) rather than on a hard drive or SSD. When the server loses power, all data is gone and cannot be forensically recovered under normal conditions. The server boots fresh from a read-only image at every restart. There is no persistent storage medium for an investigator to image.

What is a read-only boot image and why does it matter?

A read-only boot image is a fixed, cryptographically signed snapshot of the server’s complete software stack (operating system, VPN software, configuration) that the server loads into RAM at startup. No process running on the server during operation can modify it, so neither session data nor any attacker-installed software can survive a reboot.

Does RAM-only mean my data is never stored at all?

No. RAM-only constrains what persists on the local server — it has no effect on what the server software transmits over the network. A provider can run RAM-only hardware and still log every session to a remote disk-based system in real time. Evaluating RAM-only requires evaluating the no-log policy alongside it.

What happens if a RAM-only server is seized while it is still running?

RAM-only provides no additional protection for a running server. Investigators can access the memory of a running server via DMA attacks over interfaces such as PCIe or Thunderbolt, or through the server’s out-of-band management controller (BMC/iLO). A running RAM-only server and a running disk-based server with full-disk encryption are equally vulnerable: both have active data in volatile memory accessible to someone with the right tools and access to the hardware.

Can investigators recover data from RAM after power is cut?

Under normal conditions, no. Residual charge in DRAM fades within seconds to minutes at room temperature. A cold boot attack can extend this window by cooling RAM chips with freeze spray or liquid nitrogen immediately after power-off; researchers measured fewer than 1% bit decay after 10 minutes of freeze-spray cooling and approximately 0.17% bit decay after 60 minutes of liquid-nitrogen submersion (Halderman et al., USENIX Security 2008). The technique requires physical access to the hardware within moments of power-off. Documented applications have focused on endpoints rather than rack-mounted data-centre servers, where physical access controls and server memory architectures differ materially.

Is RAM-only better than full-disk encryption?

On post-seizure forensics for a powered-off server with decryption keys stored off the server, the two approaches are equivalent: neither yields readable data to an investigator. RAM-only adds two structural advantages: it prevents accidental data persistence (FDE encrypts data that reaches disk but does not prevent it being written there; a misconfigured FDE server can accumulate data RAM-only cannot), and it is more tractable to audit at the hardware and architecture level rather than requiring confirmation that software logging is correctly suppressed. Neither approach prevents remote logging by the provider, and neither protects a running server against live memory access.

Does every server reboot wipe the server completely?

Yes. On a correctly configured RAM-only server, a reboot returns the server to the clean boot image state. All data generated during the previous session (runtime logs, session artefacts, any data held in the RAM overlay) is discarded.

Can a VPN provider still log my activity on a RAM-only server?

Yes. RAM-only constrains local disk persistence, not network behaviour. Software running on a RAM-only server can transmit data over the network to any remote system. A provider that streams connection logs to a separate server in real time retains those logs regardless of whether the originating server is RAM-only. This is why RAM-only must be evaluated alongside an independently audited no-log policy, not used as a substitute for one.

Which VPN providers use RAM-only servers?

ExpressVPN (TrustedServer, launched April 2019), Surfshark (full migration July 2020), NordVPN (standard servers, migration announced October 2020), Private Internet Access (NextGen/Gen4 network, out of beta June 2020), Mullvad (full migration completed September 2023 via stboot), and IPVanish (phased rollout from June 2025, full migration targeted 2027) have all adopted RAM-only infrastructure.

How can I verify that a provider’s RAM-only claim is real?

An independent audit (ISAE 3000 or equivalent) that explicitly names the RAM-only architecture in its scope, completed within the last 18 months. Technical documentation describing the boot model: how the image is signed, how it is loaded, how swap is disabled, and how kernel logging is handled; named technologies with described behaviour are documentation, a marketing page is not. Cryptographic boot-state verification, such as signed image verification through stboot, allowing independent confirmation of what software the server booted without depending solely on periodic auditor access. And a documented real-world legal test where a law enforcement request or server seizure returned no user data. 

Does “RAM-only” describe how much memory the VPN app uses on my device?

No. “RAM-only” in the VPN context describes how the provider’s servers are built, not anything about the VPN client running on your device. The two uses of the word “RAM” are coincidental. RAM-only is also unrelated to a ramdisk or tmpfs partition on your own machine.

Does RAM-only matter for everyday privacy use?

For most everyday use cases (protecting browsing from ISP tracking, securing traffic on public Wi-Fi, accessing geo-restricted content), RAM-only is not the feature that changes your privacy outcome. The protection RAM-only adds is primarily relevant when the threat includes a law enforcement action directly targeting the provider’s hardware. If that scenario is not in your threat model, a provider with a strong audit record and a verified no-log policy gives you the protections that matter, regardless of whether it runs RAM-only or full-disk encryption.