The Macro: Remote Access Is a Solved Problem That Nobody Likes the Solution To
I use Cloudflare Tunnels. Most people reading this probably do too. It works. You install cloudflared on a machine behind a firewall, point it at a local service, and Cloudflare handles the rest. The traffic routes through their network, they manage the SSL, and your internal app is accessible from anywhere. The product is free for most use cases and it is genuinely good.
So why are 140,000 people installing an open-source alternative?
The answer is control. Cloudflare Tunnels routes all your traffic through Cloudflare’s network. Every request to your internal service passes through their infrastructure. For a personal Homelab project, that is fine. For a company running internal tools with sensitive data, it is a conversation with the security team that nobody wants to have. Zscaler ZPA solves the same problem at enterprise scale but costs enterprise money and requires enterprise deployment timelines. Ngrok is great for development but thin on access controls for production use. Tailscale built a beautiful mesh VPN but the access model is peer-to-peer, which does not map cleanly to the “expose this one service to these specific people” use case.
The self-hosted remote access space is growing because the centralized options all come with trade-offs that matter to specific groups of users. Homelabbers want full control over their traffic. Small businesses want access controls without a Zscaler contract. Dev teams want something between Ngrok’s simplicity and a full zero-trust deployment. That middle ground is real and it is underserved.
WireGuard changed the calculus here. Before WireGuard, building a self-hosted VPN meant wrestling with OpenVPN or IPsec, both of which are complex, slow, and painful to configure. WireGuard is fast, simple, and well-audited. It turned into a building block that makes projects like this feasible for small teams.
The Micro: Two Brothers and 19,000 GitHub Stars
Pangolin is an open-source, identity-aware remote access platform built on WireGuard. You self-host it on your own server, deploy lightweight connectors behind your firewalls, and manage who can access what through a web-based control panel. It supports user and role-based permissions, PIN codes, temporary share links, and email-based one-time passwords.
Milo Schwartz is CEO and Owen Schwartz is CTO. They are brothers, based in San Francisco, part of Y Combinator’s Summer 2025 batch with a two-person team. Both previously worked as founding engineers on intelligent transportation systems and public works connectivity solutions. That background in infrastructure and networking is directly relevant to building a remote access platform. These are not web developers who decided networking sounded interesting. They have built connectivity systems for physical infrastructure.
The traction numbers are hard to argue with. Over 19,000 GitHub stars. Over 140,000 installs. A Discord community of 2,700 members. Over a million deployments worldwide according to their website. For an open-source infrastructure project from a two-person team, those are exceptional numbers. They indicate genuine organic demand, not marketing spend.
What separates Pangolin from a raw WireGuard setup is the identity layer. WireGuard by itself is a tunnel. It does not know or care who is using it. Pangolin adds identity-based access controls on top, meaning you can define that User A gets access to Service X but not Service Y, and User B gets temporary access that expires in 24 hours. That is the feature gap between “I set up WireGuard on my VPS” and “I have a real access management system.”
The product supports both cloud-hosted and fully self-hosted deployments, which is the right approach. Some users want to run everything on their own hardware. Others want the convenience of a managed service without giving up the open-source foundation. Offering both paths maximizes the addressable market without compromising the self-hosted ethos.
SSL and custom domain support are included, which matters because exposing internal services without proper encryption is a non-starter for any serious use case. The multi-platform support covers macOS, iOS, Windows, Linux, and Android, which means the client-side experience is not limited to people who live in terminals.
The Verdict
Pangolin has already won the organic adoption game. You do not get to 19,000 GitHub stars and 140,000 installs without building something that solves a real problem for a lot of people. The question now is whether they can build a business on top of the community.
The risk is monetization. Open-source infrastructure projects with massive adoption often struggle to convert free users into paying customers. Tailscale navigated this well with a freemium model. Cloudflare gives away tunnels as a gateway to paid products. Pangolin needs to find the premium features that justify a price tag without alienating the community that built their adoption in the first place.
In thirty days, I want to see the pricing model. What does the paid tier include and how does the community react? Sixty days, the question is enterprise adoption. Are companies deploying Pangolin for production workloads, or is the user base primarily homelabbers and small teams? Ninety days, I want to know whether the two-person team can keep up with the support burden that comes with 140,000 installs. Open-source projects at this scale generate a constant stream of issues, feature requests, and security reports. The product is excellent. The adoption is real. The path from open-source project to sustainable business is the hard part, and every infrastructure founder eventually has to walk it.