Ezra's voice cuts in over the call before I've even said hello — "okay, but did you control for time of day" — the same argument we have every time one of us posts new numbers, and today it's about whether my kill switch logs actually prove anything about privacy. I'm mid-loop through Discovery Park, phone wedged against my shoulder, trying to explain that zero leaked packets across three straight days of testing isn't a fluke I got lucky on, and that proving a VPN claim beats trusting a marketing page every time.
Worth saying up front: I use affiliate links on this site, and if you pick up a subscription through one, I earn a commission at no extra cost to you. Every number below came off my own hardware in a Beacon Hill spare room — I can usually tell a fresh batch of results just finished by the drive spinning up out of standby to write the logs — not a spec sheet copied from a press kit.
Open Source vs. the 'Trust Us' Client
Software engineers are natively suspicious of black boxes, and a VPN client is about as black-box as software gets when the vendor won't show you the code. I spent a chunk of a slow weekend going through GitHub repositories from a handful of providers, comparing how each one actually implements its kill switch instead of how the landing page describes it. Reading a marketing page tells you what a company wants you to believe; reading the Go or C++ behind the kill switch tells you what happens the instant your connection actually drops.
Private Internet Access (PIA) is the case study I keep coming back to, because its client is open end to end — not just the desktop app but the connection logic that actually touches your traffic. That matters in the same way it matters when picking a database or a web framework: you're not trusting a brand's promise, you're trusting code that thousands of other paranoid developers have already poked at. When I want to know whether the AES handshake is actually negotiating the way the documentation says, I don't have to take anyone's word for it — I can read the negotiation code myself, or compile the client from source if I want to rule out anything slipped in during a build step.
For a while I assumed enabling DNS-over-HTTPS in Firefox was basically the same privacy win as a VPN, and it isn't — DoH hides your DNS queries from your ISP inside an encrypted browser connection, but it does nothing for the rest of your traffic, and it's a completely different mechanism from the DNS leak protection a VPN client handles at the operating-system level. That distinction, a browser-level proxy versus a full system tunnel, trips up more developers than I'd expect, because both feel like "I fixed my DNS" from the outside looking in.
Does 'Open Source' Actually Mean Anything Here?
I've run PIA's client since last fall, largely because it's the closest thing to a power-user tool for people who actually read the settings menu instead of clicking connect and walking away. Their server network is the largest I've tracked — more than 35,000 servers last time I checked — which helps route around the congestion that smaller providers can't avoid during peak hours, and unlimited simultaneous connections finally stopped my partner's "why did the TV just drop" complaints whenever I'm hammering a container build in the background. What actually sold me was grepping through how they'd implemented the WireGuard handshake, the kind of detail you can only check when the client is open. No-logs audits are their own separate rabbit hole — a third party reviewing a written policy is not the same as reading the connection code yourself — but PIA has cleared both bars, including subpoenas that reportedly turned up nothing worth handing over. Waverly Obasi, a regular in the subreddit I help moderate, runs nearly identical tests on a gigabit line in Chicago and won't touch a client with a GUI wrapper — bare config or nothing.
If you haven't scoped what you're actually defending against, none of this matters as much as it feels like it should. I've written separately about How to Build a Personal Threat Model for Home Network Security, and it's worth reading before you obsess over whose kill switch is marginally better implemented, because the right VPN for someone hiding from a stalker looks nothing like the right VPN for someone who just doesn't want their ISP selling connection metadata.
Self-Hosting Your Own VPN Sounds Smarter Than It Is
There's a common argument in developer circles that spinning up your own WireGuard server on a cheap VPS beats paying anyone for a VPN, and I used to make that argument myself. It falls apart once you think about what a VPN actually hides: not just your traffic, but the fact that you're using a VPN at all. When you own the VPS, that exit IP belongs to exactly one person, and any network engineer curious enough to look can single you out instantly. A dedicated IP from a paid provider has the same "you again" problem in a different form — genuinely useful for a handful of remote-access cases, useless if blending into a crowd is the actual goal. Reputable providers running tens of thousands of shared servers give you a crowd a solo VPS never can.
Running your own gateway also means you're the one variable an ISP's traffic-shaping equipment can flag, instead of disappearing into the same shared pool as thousands of other subscribers on a commercial service. Port forwarding on a self-hosted box is its own deep rabbit hole, worth a dedicated look rather than a paragraph here, and so is the router-level question of tunneling an entire network instead of individual devices. I keep comparing notes with the bigger commercial names too — my NordVPN vs ExpressVPN for Speed testing showed both closed-source clients holding their own on raw throughput, which is the uncomfortable part of this whole argument: closed source isn't automatically slower or worse, it's just unverifiable.
When Self-Hosting Wins (and When It Doesn't)
So where does each approach actually win? Self-hosting makes sense if you already run a home lab and treat a misconfigured firewall rule as a routine Tuesday — you get full control and zero dependence on a third party, at the cost of standing out as a lone IP address. A professional open-source client makes sense for almost everyone else: you get the audit trail without becoming your own systems administrator, and you get to pick a protocol instead of hand-rolling one, which is exactly what my recurring speed tests are built around — WireGuard-based protocols keep winning on raw throughput against older configurations, by a margin wide enough that protocol choice alone can matter more than which logo is on the app. Split tunneling changes the calculus further, letting specific traffic through the tunnel while local devices stay reachable, though that's a comparison for its own piece. Geo-restriction bypassing is a different question entirely, and one I'm intentionally leaving alone here — this is about auditability and speed, not unlocking a library in another country.
Final Verdict for the Dev Stack
None of this is a leap of faith once you frame it the way you'd frame any other stack decision. If code auditability matters to you as much as it does to me, an open-source client like Private Internet Access is the more defensible choice over a closed-source competitor charging a premium for the same promise — you're trading a slightly rougher default-settings menu for the ability to actually verify what happens the moment your connection drops.
If you're still weighing whether that trade-off is worth it, PIA is the one I'd point a fellow engineer toward first, if only because the evidence for its claims sits in a public repository instead of a marketing deck — and that's a sturdier foundation for trust than anything printed on a landing page.