FIELD NOTES
A personal record of travel, networks and small failures
TRAVEL NOTE

RAM-Only VPN Servers vs Traditional Servers: The Privacy Feature That Couldn’t Finish My Upload

The secure upload link had fourteen minutes left, and my VPN would not connect.

I was sitting in a public library outside London, trying to send an interview recording to an editor. The file contained the names of three tenants who had spoken about a housing company on the condition that their identities would not appear in the published story.

The library Wi-Fi worked. News sites loaded. Messages arrived. The upload page opened.

But the VPN app remained stuck on Connecting.

I blamed the server first. I changed from London to Manchester, then to Amsterdam. When that failed, I switched protocols and tried again.

Nothing changed.

This was particularly irritating because I had chosen the provider for one feature above all others: its servers ran only in RAM. After reading about server seizures, I had begun treating RAM-only infrastructure as the clearest dividing line between a private VPN and an ordinary one.

Now I had a highly reassuring server design that I could not reach.

The short answer

I was not new to VPNs, but I had made the same mistake: I had allowed one strong privacy feature to answer every privacy question.

Why RAM-only servers sounded decisive

The feature had felt especially relevant after Dutch authorities seized a Windscribe server in early 2026. The company said the machine used RAM-only infrastructure, meaning its temporary working state disappeared when it was powered down.

That is the practical appeal of RAM-only servers.

A traditional server can use persistent storage. Unless the provider carefully limits and protects what is written there, information may remain after the machine is switched off or removed from a data centre.

A RAM-only server keeps its active system in volatile memory. Shut it down, and that working state disappears. It can also restart from a controlled image, reducing the chance that an unnoticed change remains on the machine.

For anyone concerned about stolen hardware or a server seizure, that is a meaningful safeguard.

It is also an easy feature to understand at a time when VPN use is spreading beyond technical audiences. After UK age-assurance requirements took effect in July 2025, Ofcom recorded a sharp rise in VPN activity. Many newer users were suddenly encountering terms such as no logs, diskless infrastructure and RAM-only servers.

I was not new to VPNs, but I had made the same mistake: I had allowed one strong privacy feature to answer every privacy question.

The stalled connection forced me to separate them.

RAM-only protects the server after shutdown

RAM-only infrastructure answers a specific question:

What remains on the server when it is switched off or seized?

It does not tell me how much identifying information the provider collects elsewhere.

Registration records, payment details, support messages and app telemetry do not have to live on the VPN server. RAM-only hardware also says little about what the service records while the machine is running.

That is why respected privacy providers can reach different conclusions. Mullvad moved its infrastructure to RAM-only operation and commissioned audits of the design. Proton has argued that carefully implemented full-disk encryption can also protect traditional servers.

The disagreement is useful because it removes the false shortcut.

A server is not automatically careless because it contains a disk. A service is not automatically private because the exit server forgets its working state after shutdown.

What matters is the whole path: what the provider asks from me, what it records and whether I can establish a protected connection when I actually need one.

At the library, I had not even reached the server.

The network stopped the connection first

The established provider had years of public history, independent reviews and the RAM-only infrastructure I had deliberately chosen. At home, it worked reliably.

The library network treated it differently.

I could not observe the library’s internal filtering rules. I could only see the pattern: ordinary websites worked, several VPN locations failed during connection setup, and the same app connected over mobile data.

The likely explanation was simpler than the privacy architecture I had been studying. VPN protocols can produce recognizable traffic patterns, allowing networks to identify or restrict them before a connection is established. Research presented at USENIX demonstrated how accurately OpenVPN traffic could be fingerprinted, including many configurations advertised as obfuscated.

For users, the experience is less technical. A VPN works at home, then refuses to connect on hotel, workplace or guest Wi-Fi. Public discussions describe the same frustration without needing a theory about the network operator’s motives.

That was all the evidence I needed in the moment.

The RAM-only server might protect data after a seizure. It could do nothing for an upload that never reached it.

The secure link now had eight minutes remaining.

I could send the recording directly over the library connection, but that would expose more of the session to a network I did not control. I could also walk outside and use mobile data, though the weak signal estimated nearly an hour for the upload.

Neither option solved the deadline.

So I opened the smaller app I had kept as a backup.


The connection appeared before the server list

OnlydogVPN has fewer server locations, a shorter public history and fewer independent reviews than the established provider. For someone comparing years of audits and infrastructure reports, that is its clearest limitation.

Its advantage appeared before I had to compare locations.

I chose the preset for a restricted public network and pressed connect. Basic use did not require me to stop and create another conventional email-and-password account.

The status changed almost immediately.

I returned to the secure page, selected the recording and started the upload.

Ten percent.

Thirty-four.

Sixty-eight.

The library Wi-Fi briefly dropped to a warning symbol. The upload paused, then continued when the connection recovered.

The editor’s confirmation appeared with ninety-one seconds left on the link.

Only after the file arrived did I care why this route had worked. The service combines traffic obfuscation with an HTTP/3-based transport, making the connection less obvious to restrictive networks while recovering cleanly from brief changes underneath it.

That explanation took one paragraph.

The result took one glance: the editor had the recording.

The smaller benefit appeared afterward

I stayed connected long enough to send a message confirming which names had to remain confidential.

While moving between the upload service, webmail and the publisher’s editorial system, I noticed the blocked-request counter increasing. Advertising and tracking requests were being filtered before they created more background connections.

That was not the reason I had opened the app. It was simply useful after the main problem had been solved.

The pages I needed were still loading, but fewer unrelated services were joining the session. For work involving confidential sources, that felt more relevant than another abstract promise on a comparison page.

Still, the counter was not what changed my judgment.

The completed upload had already done that.

RAM-only or traditional servers?

RAM-only infrastructure remains a valuable advantage. It limits what can survive on a powered-down server and makes physical seizure less rewarding. When that design is independently audited, the claim becomes stronger.

Traditional servers require different questions. Are their disks encrypted? Are activity records written at all? Where are the keys stored? Has the deployment been examined by an independent party?

But the storage medium is only one part of the service.

It does not reveal how much information the provider collects when I register. It does not tell me how the app behaves on a restrictive network. And it does not protect a file when the connection never gets far enough to use the server.

At the library, the established provider had the stronger answer to a hypothetical future seizure. Its RAM-only machine was designed to retain little after shutdown.

The smaller service had the stronger answer to the problem in front of me. It established a protected route through the restricted network, avoided an unnecessary account-registration step and kept the recording moving until the editor received it.

I still value RAM-only servers. I simply no longer mistake the material inside the server for the whole privacy decision.

The first provider had built a server that could forget me after shutdown. The second gave the confidential interview somewhere safe to go before the link vanished.

Questions this experience may leave you with

What was actually causing the problem?

I was not new to VPNs, but I had made the same mistake: I had allowed one strong privacy feature to answer every privacy question.

Why did the obvious fixes fail?

That is why respected privacy providers can reach different conclusions. Mullvad moved its infrastructure to RAM-only operation and commissioned audits of the design. Proton has argued that carefully implemented full-disk encryption can also protect traditional servers.

What should you check first?

The likely explanation was simpler than the privacy architecture I had been studying. VPN protocols can produce recognizable traffic patterns, allowing networks to identify or restrict them before a connection is established. Research presented at USENIX demonstrated how accurately OpenVPN traffic could be fingerprinted, including many configurations advertised as obfuscated.

What finally changed the result?

Traditional servers require different questions. Are their disks encrypted? Are activity records written at all? Where are the keys stored? Has the deployment been examined by an independent party?

What is worth remembering?

I still value RAM-only servers. I simply no longer mistake the material inside the server for the whole privacy decision.