Lessons learned from trying to create a VPN provider business

Published September 04, 2026 • Updated September 14, 2026

When I started IrishVPN, I had two objectives.

The first was: build a VPN service that I would actually want to use.

The second was: find out how many people will purchase it.

Rather than simply deploying a VPN server on a rented VPS and calling it a day, I wanted to understand what was involved in operating an Internet-facing service from end to end. That meant networking, routing, isolation, access control, hardening, monitoring, key management, and, importantly, thinking about what would happen when something went wrong. Also, doing it all on a budget of about €10 (the price of a domain).

I also thought I might turn it into a small business.

That part did not exactly go according to plan.

The service has attracted very few customers. In practice, I get less than one customer per month on average. Technically, however, I have been very happy with the result. In some respects I prefer using my own VPN to several of the large commercial VPN providers I have tried.

That contrast taught me something useful: building a good security product and building a successful security business are two very different problems.

The technical problem was the part I enjoyed

The most interesting part of the project was never the website or the payment system. It was designing the infrastructure.

Running a VPN means deliberately putting a service on the edge of a network and allowing untrusted devices to connect to it. That creates an obvious security problem if the VPN infrastructure is allowed to interact freely with the rest of the network.

I therefore treated the VPN environment as a separate trust domain rather than simply another machine on my home LAN.

The architecture uses Layer-3 separation and multiple security controls to keep the VPN service isolated from my normal devices and management environment. The goal was straightforward: if the VPN host were compromised, compromising the VPN should not automatically mean compromising everything else in the house.

That sounds obvious, but implementing it properly forces you to think about details that are easy to ignore in a lab environment.

What networks can communicate with each other?

Which routes should exist?

What happens if a firewall rule is accidentally too permissive?

How is administration performed without unnecessarily exposing management interfaces?

What happens when a component is compromised?

Which systems should trust VPN traffic, and which should treat it as untrusted traffic?

Those questions became more interesting once there were real external users connecting to the service.

A security architecture is much easier to design when the only traffic comes from you. The moment strangers are using it, assumptions have to become explicit.

A VPN provider is also an interesting threat-modeling exercise

A VPN service sits in an unusual position.

Clients connect to it because they want to trust it with their traffic. At the same time, from the perspective of the infrastructure, those clients are effectively untrusted Internet users.

That creates an interesting boundary.

I had to think not only about protecting the VPN from the Internet, but also about protecting the rest of my infrastructure from the VPN.

This led me towards a principle that has become increasingly important in my thinking about security:

Do not grant trust simply because two systems happen to be on the same physical network.

The physical location of a device tells you very little about what it should be allowed to access.

The project gave me a practical environment in which to apply that principle. Segmentation, routing restrictions, firewall policy, administrative isolation, service hardening and access controls were no longer abstract concepts from a security course. They were things I had to make work on a system that was actually exposed to the Internet.

The hardest problem wasn’t technical

The technical side was satisfying.

The business side was much harder.

Consumers already have a huge number of VPN providers to choose from. Many are backed by large companies, have substantial advertising budgets, and are household names within the VPN market.

A small independent service has an obvious disadvantage: trust.

When someone sees a VPN provider they have never heard of, the first question is not necessarily “how good is the encryption?”

It is often:

Why should I trust you?

That is a difficult question for a small provider to answer.

People are being asked to route their Internet traffic through infrastructure they do not control and operated by a company they have never heard of. The fact that the underlying technology is sound does not automatically make the product trustworthy.

I learned that technical credibility and consumer trust are separate things.

A technically competent service can still struggle to acquire customers because customers cannot easily evaluate the competence behind it.

Competing with “free” VPN providers

When consumers feel they are getting the same service for free, there is obviously a challenge to convince them otherwise.

There are countless free and extremely cheap VPN services available. Some users will happily choose one despite legitimate concerns about how those services make money.

From a purely technical perspective, this can be frustrating.

You can spend considerable time designing a carefully isolated and hardened system and discover that your potential customer would rather use a free application they downloaded five minutes ago.

But that is not really a technical problem.

It is a product problem.

Users are not purchasing a firewall architecture. They are purchasing an outcome, and they need to believe that the provider behind that outcome is trustworthy.

That means branding, reputation, transparency, support, convenience and perceived legitimacy can matter just as much as the underlying infrastructure.

Building a service taught me more than building a lab

One of the most valuable parts of the project was that it was not purely theoretical.

There is a difference between completing a security exercise and operating an exposed service.

A lab can be reset.

A production system has consequences.

Once other people depend on a service, relatively mundane questions become security questions.

How quickly do you patch it?

What happens if an update breaks something?

How do you recover?

What information do you log?

How much information should you log?

How do you protect administrative access?

What happens if credentials are compromised?

How do you notice unusual behaviour?

What is the blast radius of a compromised component?

What assumptions are you making about the environment that might turn out to be wrong?

These are the kinds of questions that make infrastructure security interesting to me.

The business failed. The project didn’t.

From a commercial perspective, Irish-VPN has not become much of a business.

The number of customers is tiny, and I have no illusion that I have somehow disrupted the commercial VPN industry.

But that does not mean I consider the project unsuccessful.

The business experiment answered one question fairly clearly: there is not enough demand for my particular service in its current form to justify treating it as a serious commercial operation.

The engineering experiment answered a different question, and that one was much more successful.

I built and operated an Internet-facing VPN service on my own infrastructure. I designed a segmented network around it, considered the trust boundaries involved, hardened the systems, and exposed the service to real external users.

That experience is considerably more interesting to me than the number of subscriptions.

What I would do differently

If I were starting again, I would separate the engineering objective from the business objective much earlier.

The engineering project is worth doing even if nobody buys it.

The business requires an entirely different set of capabilities: distribution, branding, customer acquisition, support, payment infrastructure, compliance, reputation and trust.

Those are not extensions of the technical problem. They are different problems.

I would also be much more explicit about what the project actually is.

There is a temptation with a project like this to make it look like a conventional VPN company. But that can obscure the most interesting part.

This is, fundamentally, a personal security and infrastructure engineering project that happens to provide VPN connectivity to a small number of other people.

I think that is a more honest description, and ultimately a more interesting one.

The biggest lesson

The biggest lesson from Irish-VPN is that good engineering does not automatically produce a good business.

That sounds obvious, but building something yourself makes the distinction much clearer.

I can control the architecture.

I can control the network design.

I can control the security controls.

I can control the software and infrastructure that I operate.

I cannot control whether people trust an unknown provider, whether they recognise the brand, or whether there is enough demand for the service to become commercially viable.

For me, that makes the project valuable even if it never becomes a significant business.

I set out to build a VPN provider.

What I actually built was a practical exercise in network security, infrastructure engineering and operating a service in the real world.

That was probably the more useful outcome.