Don’t trust the claim. Grep it.
A VPN sees everything you do, which makes it the software with the most to gain from lying to you. Almost nothing a provider says about logging can be checked from the outside — so we publish the client code on every platform, and this page walks you through what to look for, including the search that comes back with something awkward.
The diff above is a simplified illustration of the pattern rather than a verbatim excerpt — real code has error handling and rather less dramatic formatting. The point it makes is structural and it is checkable: in a design that never persists session data, there is no insert to find, so the absence is visible in the code rather than promised in a policy.
Five greps, one uncomfortable answer
If you cloned the repository tomorrow, these are the searches a reviewer would actually run. Four of them come back the way we would like. One does not, and we would rather you found it here with an explanation than found it yourself and assumed we were hiding it.
Representative results shown for explanation, not live output from a repository — clone it and run these for real, which is rather the point. Findings and their remediation status are documented in the independent audit report.
Every client, every platform
Source and build configuration for each application we ship. Start with the platform you use rather than trying to read all of them.
What’s open, and what isn’t
“Open source” is used loosely enough in this industry to be nearly meaningless, so here is the specific split rather than the adjective.
| Component | Status | Notes |
|---|---|---|
| Android, iOS, macOS, Windows and Linux clients | OPEN | Published in full, including build scripts |
| The tunnel implementation in our apps | OPEN | The code that actually moves your traffic |
| Local storage and cache handling | OPEN | What the app writes to your device, and when |
| Client-side DNS and kill-switch logic | OPEN | Where leaks would happen if they happened |
| Build and release pipeline configuration | OPEN | So builds can be reproduced independently |
| Server provisioning and orchestration | NOT PUBLISHED | Not published — covered by the independent audit instead |
| Backend API and billing services | NOT PUBLISHED | Not published — contains payment integrations |
| Infrastructure secrets and signing keys | NOT PUBLISHED | Never published by anyone, for obvious reasons |
Every VPN that calls itself open source has this same boundary, including Mullvad and Proton VPN — client code is publishable, server infrastructure effectively is not, because you have no way to confirm what is actually running on a machine you do not control. That gap is what independent auditing covers, which is why we do both rather than treating either as sufficient. Our comparison page ranks Proton VPN above us on verifiability for exactly this kind of reason.
Why this matters more for a VPN than for anything else
Most software you install can only betray you in narrow ways. A photo editor sees your photos, a note app sees your notes. A VPN sees the entire shape of your life online: every service you connect to, at what times, from where, for how long. It is the one category where the gap between what a company promises and what its software does is both enormous and, from the outside, invisible.
That invisibility is the actual problem. You cannot tell from using a VPN whether it writes your IP address to a database, because a client that logs everything and a client that logs nothing behave identically from the user’s side. Connection works either way. Speed is the same either way. There is no symptom.
What publishing actually changes
Open code does not make a company trustworthy. What it does is change the cost of dishonesty. A provider that publishes its clients has to keep any deception out of the part everyone can read, which pushes it into the server side where an auditor is looking, or into the build pipeline where reproducible builds catch it. None of those doors is impossible to get through, but each one adds people who would have to stay quiet and evidence that would have to be maintained.
It also changes who can hold us to account. A journalist does not have to take our word for what the app collects; a security researcher can read the storage layer directly; a competitor can check whether our marketing matches our code, and would very much enjoy telling everyone if it did not. Openness is less a guarantee than an arrangement where quite a lot of people have both the means and the motive to catch us.
Reproducible builds: the part that closes the loop
There is one obvious hole in all of this, and it is worth naming plainly: reading source code tells you nothing about the binary sitting on your phone. Publishing clean code while shipping something else is the easiest deception in the category, and it would be invisible to anyone reviewing the repository.
The answer is reproducible builds. Build the app from published source on your own machine, and the result should hash identically to the release we publish. If the hashes match, the code you read is the code you are running. That is why our build configuration is published alongside the source rather than kept as an internal detail — without it, open source is a gesture rather than a verification.
What open source does not prove
Our own industry oversells this badge constantly. Four things it genuinely does not give you, stated by the company that benefits from you not knowing them.
Anyone can publish clean code and ship a different binary. The only real answer is reproducible builds — building from source yourself and confirming the hash matches the release. That is why the build configuration is published alongside the code and not treated as an implementation detail.
This is true of every VPN, including the ones that market themselves hardest on openness. Server infrastructure cannot be meaningfully verified by publishing configuration files, because you have no way to confirm what is actually running. That gap is what independent auditing exists to cover, which is why we do both rather than either.
Code being public only helps if somebody competent has actually read it. Most open-source projects are read far less than their users assume. If you have the skills, reading ours is genuinely more useful than trusting this page — and our bug bounty exists to make that worth your time.
Serious weaknesses hide in subtlety rather than in a function named `send_everything`. They look like an off-by-one in a buffer or an ordering mistake in a handshake. Openness raises the cost of hiding something; it does not make hiding impossible.
Verify us in five steps
Clone the repository
Every client is published in full, including the build scripts. Start with the platform you actually use rather than trying to read everything.
Run the searches that matter
Look for persistence rather than for the word ‘log’: storage calls, database inserts, network requests to anything that is not a VPN server, and anything touching an identity field.
Build it yourself
Follow the build instructions in the repository to produce a binary from source on your own machine, so you are testing the code rather than trusting a description of it.
Compare the hashes
Check the hash of your build against the published hash for the same release. If they match, the app you can install is the code you just read.
Tell us what you found
If something looks wrong, our bug bounty programme pays for security findings and we would rather hear it from you than read about it later.
Open source questions
Is LunoVPN really open source?
Why does open source matter for a VPN specifically?
Can I build the apps myself and check they match?
What licence is the code released under?
Does open source mean the apps are audited?
What if I find a vulnerability?
Do you accept outside contributions?
The claim is only worth what you can check.
Open clients, a published audit, and no email address collected in the first place.