RAM-Only VPN Servers: Diskless Boot, What a Reboot Erases and What Survives
Of 543 consumer VPNs in our data, 6 say they do not offer it. Below: the services that rank highest for it.
A RAM-only VPN server runs without any disk: its OS, VPN software, keys and session state exist only in volatile memory, so everything written since boot is lost when power drops. A machine seized while switched off is therefore useless for forensics. The design does not stop logs kept in memory or shipped elsewhere, and it cannot replace a no-logs policy.
How a diskless server boots and runs
RAM is volatile: it needs constant power, unlike a hard drive or SSD. A diskless server rebuilds itself on every boot: the hardware loads a signed, read-only system image over the network (PXE or iPXE from a provisioning host) or reads it from a write-protected local medium, and the signature is verified before anything runs.
Temporary files, daemon state and logs land in a memory file system, typically an OverlayFS layer on top of the read-only image, and vanish at the next restart. Two settings decide whether the design holds. Swap must be disabled, otherwise the kernel pages memory onto a disk that should not exist. System logging has to stay in memory or be turned off; a default journald or rsyslog setup pointed at a drive defeats the whole point. Every node boots the same image, so configuration drift disappears, and an update means building one new image and rebooting the fleet.
What a reboot or a seizure leaves behind
A seized, powered-down server is blank hardware with nothing to image. Stray files that a misconfigured disk server writes have nowhere to land. An intruder who plants code on a running node loses it at the next restart; to persist, they would have to compromise the image source and its build pipeline.
The June 2021 seizure of two Windscribe servers in Ukraine shows the opposite case: the machines ran on unencrypted disks, and one held an OpenVPN server private key that could, under narrow conditions, let an attacker impersonate a server. The risk was impersonation, not stored user activity, yet the provider switched to RAM-only machines afterwards.
| Setup | Seized while off | Planted code after reboot | Old drive resold |
|---|---|---|---|
| Plain disk | Readable | Survives | May hold data |
| Encrypted disk, keys held elsewhere | Unreadable | Survives | Unreadable |
| RAM-only | Nothing on it | Gone | No drive |
While a server runs, an encrypted-disk machine and a RAM-only machine are equally exposed to anyone with live access: the encrypted disk is decrypted anyway, and the memory is readable. The difference appears after a break-in: code planted on a disk survives reboots, while on a RAM-only node it is gone at restart. Some providers keep encrypted disks because diagnostics and updates are simpler.
Where the protection stops
RAM-only limits what stays on the server's own hardware; it has no say over what the software records or sends. A connection logger can hold records in memory for weeks between reboots. The server can stream connection data in real time to a separate machine with a disk. A running node can be copied by an administrator, through the hardware management controller, or under a court order served on the data centre before anyone touches the power switch. Account, payment and support records live on the provider's central systems anyway, outside the VPN fleet.
Memory does not go blank instantly. Halderman et al. showed in the 2008 cold boot paper that DRAM keeps much of its contents for seconds after power-off at room temperature, and far longer when chilled, enough to extract encryption keys. The attack needs physical access within moments of power-off, so for data-centre servers it sits at the edge of the threat model.
How to check a provider's RAM-only claim
Read the audit scope first. If a report covers only the privacy policy and never names the server architecture, it confirms nothing about diskless operation; the glossary entry on no-logs audits explains what such reports can and cannot prove. Look for technical documentation of the boot model: signed images, swap off, logging in memory. Treat hedges like "where possible" as a partial rollout, and weigh any history of seizures or court requests that produced no data.
RAM-only servers and a no-logs policy
A no-logs policy decides what the provider collects; RAM-only decides how long anything stored on a VPN server can survive. RAM-only backs up a no-logs promise against seizures and accidental leftovers but cannot prove it, because logs can still sit in memory or be sent to another machine. In the main ranking of 377 services, 24 state RAM-only servers, 3 partially, 3 say they do not use them, and 347 do not publish this information. For a shortlist, see the RAM-only VPN ranking.
FAQ
Does "RAM-only" describe the VPN app on my phone?
No. The term is about where the provider's servers keep their data and says nothing about the app or the phone.
Can data be recovered from RAM after the power is cut?
For seconds, sometimes longer with chilled chips. The attack needs physical access within moments of power-off and has mostly been shown in lab conditions.
Is an encrypted disk as safe as a RAM-only server?
Against a seizure of a switched-off server, roughly yes. While the server runs, both are equally exposed. The encrypted disk loses on planted malware, because it survives a reboot there.
RAM-only servers in short
A diskless VPN server boots a signed read-only image, writes runtime data to tmpfs, keeps swap off and logging in memory, and forgets everything at reboot. It defeats cold seizures, stray files and persistent malware, but live logging and forwarding remain possible, so pair the claim with an audited no-logs policy.
Top services: RAM-only servers
- CitadelVPN8.87
- X-VPN6.47
- LunoVPN5.98
- NordVPN5.74
- Private Internet Access5.39