Preamble
Running your own VPN might seem like a formidable task, but deployed with basic best-practices in place, and with a little understanding as to computer networking fundamentals, there are few services so easy to maintain that provide such utility and privacy.
Most think of Virtual Private Networking as a technology to conceal and protect traffic along a route to a remote location, where they then exit the VPN to reach content on the Internet. This need has never been more pronounced than today, where VPNs provide a vital tool for evading state-wide censorship.
However, VPN technology had a different beginning. It was created as a means to implement private network infrastructure over the top of other networks. It allowed devices to address and connect to each other on the same network regardless of which physical local network they were on. When sufficiently secured, that LAN-like layer effectively implements a ‘darknet’. This lesser-known use case of VPNs offers a new way of using networks, whereby communities can share a safe network to work regardless of where they are.
Today, most commercial VPN providers prioritise the popular former use-case of securing a route to the Internet, itself a response to market demand. A self-hosted VPN however provides for both needs, and a variety of other configurations and topologies typically unavailable in commercial offerings, especially in the lower-price tiers.
Running your own VPN might seem like a formidable task, but deployed with basic best-practices in place, and with a little understanding as to computer networking fundamentals, there are few services so easy to maintain that provide such utility and privacy. Anyone can learn to do it.
Today, most users of VPNs are via a third-party provider, and on a plan paid out monthly. Given the use-cases of censorship resistance, protecting the route from prying eyes and attack, commercial providers generally do quite well, with the most popular providers, like Proton, Mullvad, NordVPN and CyberGhost, offering what appears to be a strongly secured route.
But security ‘along the wire’ is not everything. Below I’ll break down where it starts to make sense to run your own, above and beyond what these companies offer.
Activism
[…] when meeting the specific needs of an at-risk group, self-hosted VPNs can provide an operational agility unmatched by commercial offerings.
Firstly, while VPN technology is often positioned as a tool for liberation, the tool itself need not be captive.
Developing the skills and knowledge to deploy free and open source VPN technology, and then offer that as a low-cost or no-cost service for those in need, helps to de-center expertise and control away from companies. It puts the technology in the hands of people, investing in their independence, such that they can then meet their own needs, on their own terms. Further, it helps nourish a world where networked technology is grounded in community, rather than one where individuals are forced to fit within the discrete and rigid product offerings of companies.
Because many of the big providers provide routes for 100’s of 1000’s of endpoints, each have a lot of visibility to regimes engaging in censorship. Not only do they stand out, but they have many eyes on them. As the stakes rise, this could become a critical single-point-of-failure (SPoF).
Smaller ad-hoc VPNs on the other hand, set up in suitable jurisdictions to meet the needs of smaller groups, are inherently more private and very difficult to keep track of. As such, when meeting the specific needs of an at-risk group, self-hosted VPNs can provide an operational agility unmatched by commercial offerings.
Cost
For the cost of a single EUR5/month Mullvad account, a tiny server in Germany, Singapore or Finland suitable for a VPN project can be rented, itself capable of providing for dozens of users.
With Proton VPN’s bottom tier offering being ‘free’, it can seem like there is little advantage to running your own VPN. For those simply wanting a secure route over the border, free-tier VPN offerings like those of Proton’s are naturally quite attractive.
However, it is important to understand that any free-tier offering is rarely gregarious. It is a market mechanism designed to hook customers to upgrade to a paid tier service. As such, free-tier services are so often the seed stage in a process of degrading the quality of a platform to pressure the user into upgrading their subscription plan, eventually only serving those customers that can afford to pay at all. This strategy and process, as applied to platforms and services, has been called enshittification.
With a free-tier VPN service, deliberate platform degradation is as simple as reducing available bandwidth and VPN location options.
Even looking at the lowest-cost paid offerings, running one’s own VPN can result in far improved cost/performance ratio when used by more than one person. For the cost of a single EUR5/month Mullvad account, a tiny server in Germany, Singapore or Finland suitable for a VPN project can be rented, itself capable of providing for dozens of users.
In fact, a VPS with a single virtual CPU core (vCPU) and 1GB of virtual RAM (vRAM) is more than sufficient to accommodate a busy VPN with numerous concurrent endpoints. Such a VPS can be rented for very little, even in jurisdictions well known for their strong data protection laws.
By example, a VPS at the datacenter FlokiNet in Iceland, a country well known for its extremely strict data protection laws, costs just EUR11/month at the time of writing. A server of this size is able to provide a fast, private and very secure route for friends, family and colleagues – even a mid-sized NGO.
EUR5/month for VPN access might not seem a lot for many in the rich countries, but for those in less fortunate economies or economic circumstances it can be prohibitively expensive. Putting that money into the monthly cost of a VPS, deploying a VPN atop it, and then generating many client configs for it, makes good economic sense.
Trust
While the VPN provider may claim they do not keep logs, they may be compelled to start doing so, by law. This is a jurisdictional and operational security detail often overlooked.
When using a VPN provider you inevitably generate metadata. This includes (and is not limited) to the following:
- Originating IP (say, your home or workplace)
- Time of use (timestamps)
- Servers and services visited
- App version
And, if built into the app and collected server-side, it could also include:
- Data downloaded
- Any application-specific usage data (gestures, usage patterns, local settings)
- OS version
- OS language settings
To mitigate for this trust issue, CyberGhost, NordVPN, Express and Surfshark have made a point of all passing various privately-contracted ‘no-logging’ audits. It is worth mentioning however their client applications are not free and open source.
ProtonVPN or Mullvad have also passed no-logs audits, while publishing the source code of their client applications alongside. This means their client-side applications can be publicly audited to ensure they are meeting their claims there.
Regardless, on the serverside, a lot of trust is still asked of their users. While the VPN provider may claim they do not keep logs, they may be compelled to start doing so, by law. This is a jurisdictional and operational security detail often overlooked.
We saw this play out in the 2021 case of a trusting ProtonMail user whom was part of the Youth for Climate movement. At the time, Proton was active in claiming that they do not keep IP activity logs of their users. For the privacy community, and clearly much of their user-base, this was also the assumption, and yet in 2021 French authorities demanded the Swiss High Court press Proton for identifying details (including the activist’s IP when using the service), which they then activated and supplied, resulting in the arrest of the activist in France.
In 2023, Proton quietly removed the ‘no logs’ claim pertaining to their ProtonMail offering.
More recently, Proton was found to have handed over payment data to the FBI, in compliance with an investigation into an activist based in Atlanta, Georgia, USA.
And these are just the cases that had a strong presence in the press. In 2025 alone, Proton has complied with over 8300 orders for information on their users, according to their own Transparency Report.
This same legal mechanism, of escalating warrants for user data via the high court, enabling logging for endpoints, is just as applicable to their VPN offering, which they claim at present runs entirely log-less. Will Proton’s own VPN offering eventually go the same way as their email offering?
This same Achille’s Heel afflicts every commercial VPN offering, no matter their pledges. No company is immune to extreme legal pressure escalated to the highest authority within their operating jurisdiction, especially if threatened to be shut down for non-compliance. Indeed they may fight that authority, presumably at great expense, but their success cannot be relied upon.
Trust in a self-hosted VPN context
Back to activism as a use-case for the moment, consider frontliners relying instead on a self-hosted VPN, on a VPS or dedicated server in the same jurisdiction as Proton: Switzerland. Here, there are important legal, operational and forensic advantages for activists.
Firstly, the only metadata that might be collected by the datacenter itself is of traffic to/fro that server. They do not and can not know whom specifically is using the VPN, nor (on a busy VPN) specifically which remote sites are resourced by which VPN endpoints. This knowledge is solely available to the system administrator of that service.
Here, the self-hosted VPN service itself is metadata-hermetic, an operational security affordance that can be taken even further by running the VPN server log-less. Thus, in the unlikely event a warrant is escalated to seize the server, it contains nothing of value to the adversary. Further, the person or organisation that has rented the server on which to deploy the VPN can claim plausible-deniability, as, in reality, unless detailed logs are generated, they cannot know which of their VPN users generated the traffic.
With far lower stakes, the worst outcome for the server is that it is shut down, encrypted data partition locked, and little is lost. A new VPN can be setup somewhere else, even restored from offsite encrypted backups.
Flexibility
When self-hosting your own VPN infrastructure you can create networked relationships between devices specific to projects and needs, finely tuned to meet privacy and security requirements.
As mentioned in the introduction, a VPN is not just a ‘routing gateway’. It is first and foremost a powerful tool for abstracting private networking infrastructure over a public wide area network (WAN) like the Internet. When self-hosting your own VPN infrastructure you can create networked relationships between devices specific to projects and needs, finely tuned to meet privacy and security requirements.
A few examples follow:
- A robotics artist has their artwork connected to the museum’s WiFi access point. The artwork is then run on the artist’s own VPN. The artist can then administer and tune the work over the VPN from the comfort of their studio oceans away, accessing sensors, cameras, changing configurations and updating code.
- A US-based Human Rights collective has a self-hosted team chat platform in Switzerland that they use for all their org work. They also have a self-hosted VPN in Iceland. The collective generate VPN configs for all their phones, tablets and laptops, and change a simple firewall rule on their team chat server such that it can only be reached when on the VPN, making it ‘invisible’ to the WWW. This also ensures there is no way of adversaries tracing individuals in the US to IPs connecting to the team chat server.
- A family traveling has a security camera in their home, alongside a PC with important personal documents they do not want to upload to a cloud service nor take with them. With the camera and PC on the VPN, they can access the camera and also the files they need, when they need them, from wherever they are.
- A software studio with distributed staff are working on a complex network application. With each member’s development laptop on the VPN, and the network port of with the network port of their project exposed to it, the team can sketch and quickly share ideas by connecting to each other’s projects across the VPN, rather than each pulling, configuring and running a branch of each sketch locally. Graphical interfaces can be reached in the browser, or using a service like VNC across the VPN.
While most VPN providers only expect you to use their VPN to reach content on the Internet, some do allow for more diverse and/or complex setups, often in a more expensive tier of offering. None however will ever afford the flexibility and privacy a self-hosted VPN can offer.
An often overlooked advantage to hosting your own VPN is that you can run more than one VPN service on the same server. This keeps network segments nicely isolated and manageable. One VPN network could be for system administration needs, another for family, another for friends, perhaps even another for a game server. Each could host dozens of endpoints. On a server with plenty of bandwidth, a few GB of RAM and a few dedicated CPU cores? Hundreds.
Decentralise!
Decentralisation isn’t just a topological expression, it also expresses techno-politically, economically and culturally. When we deploy and run our own private networking infrastructure atop the public Internet we are helping keep the Internet diverse and net-neutral – healthy. It shows ISPs and service operators that we are not just consumers, but asserting our rights on our own terms, with the protocols and standards we wish to use, and with the needs of our own communities in mind.
And, by reclaiming the power to be producers of infrastructure, we act as a sort of generalised competition for the commercial VPN providers such that it is harder for them to monopolise the technology and access to it. After all, power ultimately tends toward serving itself.
What are some self-hosted VPNs to look at?
The two dominant VPN solutions, and atop which almost all the commercial providers either directly implement or fork for their own implementations, are OpenVPN and Wireguard.
They are two very different solutions to the same problem, and each have their talents.
OpenVPN
OpenVPN has been around since 2001, and was the de facto for VPN infrastructure for a great many years, more recently unseated by Wireguard in many settings.
While it cannot compete with the raw performance of Wireguard, OpenVPN encrypts the transport layer with SSL, so affording it a far broader and established cipher suite. This gives OpenVPN more flexibility for those needing to meet particular certain security and compliance standards. As such, it remains popular in enterprise and NGO settings.
OpenVPN also has sophisticated monitoring and management tooling that abstracts over the running network, alongside powerful tools for generating, managing and revoking client configs and their keys
The file-based configuration interface of OpenVPN is rich with options, providing great flexibility. It allows for the deft enabling of modes like client-to-client (any client can reach another on the VPN, so implementing a darknet) and even a setting allowing for using a single shared VPN config across multiple endpoints (‘duplicate Common Name’).
The OpenVPN codebase is however enormous, and while it has no known vulnerabilities at the time of writing, it is a lot of code to audit and so innately at more risk of issues. OpenVPN has a reasonably colourful history of vulnerabilities.
Wireguard
Wireguard emerged almost 15 years after OpenVPN, and came out fighting. It was built first and foremost with performance in mind, and in that respect it surely delivers. Raw bandwidth over the VPN is often more than double that of OpenVPN, even when OpenVPN is using the same protocol (UDP).
Wireguard took the interesting direction of designing their project such that it could be integrated into an operating system kernel itself. This step was finally completed in 2020, with Wireguard now incorporated into Linux kernel.
Wireguard provide minimal tooling to do all the basics, from generating key pairs, to managing the route and tunnel network interfaces. However, it lacks the higher-level management that OpenVPN offers. Rather, it is assumed that such management is done by the network administrator operating upon the network directly.
Network relationships in Wireguard are built up as peers, point-to-point connections, each a tunnel. A Wireguard server is thus just a central peer to which other peers connect, typically providing routing out to the WAN (usually the Internet). This elegant approach to building up a VPN is great for small projects and keeps the network topology especially legible. More complex networks can be built up in peer configs and with routing rules at the firewall.
For the more complex projects however, Wireguard may feel cumbersome without sufficient network engineering skills and bespoke tooling.
Wireguard’s cipher suite is minimal but provably very secure, with ChaCha20 chosen for symmetric encryption. Interestingly, Wireguard uses public key encryption for identification and encryption, with each peer having its own key-pair. This is an elegant alternative to the more complex certificate-based model OpenVPN uses.
Finally, at just over 4000 lines of code, Wireguard is readily auditable. Being so small, it is statistically far less prone to security vulnerabilities. This is perhaps reflected in the very short list of vulnerabilities discovered in Wireguard to date.
Ready to deploy your own?
If this all sounds quite good, but you presently lack the skills to deploy, we (Nīkau) offer complete zero-to-server, AI-free, live and coached training to do exactly this.
Tunnel, from the Tunnel and Fortress series, is an excellent first-step into the worlds of system administration, server security and network engineering all at once. At the conclusion of the training, each participant has their very own, tightly secured VPN server, able to protect dozens of family, friends and colleagues in their day-to-day use of the Internet.
See the Tunnel training page below for training dates and more information:
No AI was used at any point in the researching, writing or editing of this post.