Pangolin: a self-hostable SASE stack that puts WireGuard, a reverse proxy and an AI gateway behind one policy model

The problem Pangolin targets is policy fragmentation, not connectivity

Most self-hosted remote access setups solve connectivity and then bolt security on afterwards. A WireGuard server gets you onto the network, then you add a reverse proxy for web apps, a separate bastion for SSH, and a different tool again for auditing. Each of those has its own notion of who a user is. Pangolin's premise, stated in the README, is that sites, reverse proxy, client access, RBAC and the AI gateway "share one identity and policy model", so connecting a user and authorising them are the same operation rather than two systems agreeing by convention. The audience is the administrator who already runs private infrastructure and is tired of that convention. The README frames the comparison directly against Cloudflare One, Zscaler and Prisma, with the differentiator being that Pangolin is open and self-hostable rather than a closed cloud control plane. That framing tells you who it is for: teams that want the SASE shape (per-resource access, identity provider integration, audit logging) without handing the control plane to a vendor.

Sites, connectors and NAT traversal: how resources actually become reachable

The mechanism that matters most is the site connector. According to the README, a site is a gateway into a network, and it works by making outbound tunnels rather than accepting inbound connections. That is what lets it reach networks behind restrictive firewalls without a public IP or an open port, using NAT traversal. The connector is described as a lightweight user-space process deployable as a binary or a container. Two consequences follow from that design. First, the network you are exposing does not need to be routable from the internet at all, which removes a whole class of exposure. Second, the connector itself becomes the thing you must keep alive, and the README notes alerts when a device or network resource goes down, which implies the project treats connector liveness as an operational concern rather than an afterthought. On top of that foundation sit three access paths: browser-based reverse proxy for HTTPS apps plus VNC, RDP and an in-browser SSH terminal; client-based access for private resources like databases and whole CIDRs, with DNS aliases and the option to route through multiple connectors for redundancy; and the AI gateway, which puts an identity-aware proxy in front of both public model APIs (OpenAI, Anthropic, Gemini) and self-hosted servers (Ollama, vLLM, Mistral). The AI gateway is the piece that distinguishes this from a conventional ZTNA product, and the README describes two modes for it: published as a public resource with personal API keys, or kept private on a client tunnel where the connected client is itself the credential.

Getting it running: the install paths the repository actually offers

The README does not inline a docker-compose file or a full environment variable list, so anything beyond the entry points below has to come from the documentation site rather than from this repository's front page. What the README does give is three routes. The managed route is Pangolin Cloud, signup at app.pangolin.net. The self-hosted route is the quick install guide at docs.pangolin.net/self-host/quick-install. The third is a pre-configured one-click installer on the DigitalOcean marketplace. A container image is published at hub.docker.com/r/fosrl/pangolin, referenced in the README badges, so a container-based deployment is clearly the intended shape even though the compose definition lives in the docs. Practically, that means the first real task is reading the quick install guide and treating the README as a feature map rather than a setup manual. If you are evaluating Pangolin for a migration, budget time for the docs rather than assuming the repository is self-describing, because on this evidence it is not.

The licence split is the first decision, not an afterthought

Pangolin ships in two self-hosted editions with different licences, and the repository metadata reports the licence as NOASSERTION, which is consistent with a project that is not under a single uniform licence. The Community Edition is free and, per the README, licensed under AGPL-3. The Enterprise Edition is open-core under the Fossorial Commercial License, and the README states it is free for personal and hobbyist use and for businesses with less than 100,000 USD gross annual revenue. Two things follow. AGPL-3 is a copyleft licence with a network-use clause, so if you modify Pangolin and expose it to users over a network, the obligations differ from a permissive licence; that is a question for your own counsel, not something this article can settle. The revenue threshold on the Enterprise edition is a business-model boundary rather than a technical one, and it means a growing company can cross from free to paid without changing a line of code. The practical implication is that the edition you choose determines both your feature set and your legal posture, and the two are entangled. Decide which edition you are targeting before you build anything on top of it.

Where Pangolin is the wrong tool

The README's own framing exposes the main limitation: this is a platform you run. The managed alternative exists precisely because self-hosting identity, connectors, certificates and reverse proxy configuration is ongoing work, and nothing in the repository suggests that work disappears. The reverse proxy is described as handling routing, load balancing, health checking and automatic SSL certificates, which is a list of things that can fail independently and that you own when you self-host. The second limitation is scope. Pangolin is oriented around accessing resources that already exist inside networks you control. If your requirement is a conventional always-on VPN for a small number of trusted users on a flat network, the per-resource policy model is more machinery than the problem needs. The third is maturity signalling: the release cadence shown here is three releases in roughly two weeks (1.22.0 on 27 August 2026, 1.22.1 on 3 September, 1.22.2 on 4 September 2026), and a fast patch cadence on a platform that terminates your authentication and proxies your traffic is something to plan for, not something to read as either good or bad on its own. You need a maintenance window habit before you adopt it.

How it differs from Tailscale and from plain WireGuard

The closest comparison most engineers will reach for is Tailscale, and the difference is architectural rather than cosmetic. Tailscale's core abstraction is the device and the tailnet: you join machines to a network and then apply ACLs over that membership. Pangolin's core abstraction, as described in the README, is the resource, with access granted "per resource, not per network". That distinction shows up in the feature list: a browser-based reverse proxy that needs no client installed, in-browser SSH with privileged access management, VNC and RDP in the browser, and an AI gateway that fronts model APIs. Those are things a device-mesh VPN does not attempt. Plain WireGuard is the other comparison, and it is the substrate rather than a competitor. Pangolin is built on WireGuard and adds the identity, policy, proxy and audit layers around it. If a WireGuard config file plus a firewall is currently sufficient for your team, Pangolin is a large amount of additional surface area. If you have outgrown that config file because you cannot answer "which user accessed which host, and when", Pangolin's audit logging and per-resource grants are aimed exactly at that gap.

Maintenance, upgrade cost and what to verify before you commit

Upgrade cost is the least documented thing in the supplied material and the thing most likely to bite. The repository shows a steady stream of patch releases, but the README says nothing about database migrations, configuration compatibility between minor versions, or whether connector and server components must be upgraded in lockstep. Since sites rely on connectors running in your private networks, a version skew between a connector and the control plane is a realistic failure mode, and the material does not state whether that is supported. Treat that as an open question to resolve with the docs and the project's Discord or Slack before you deploy connectors into networks you cannot easily reach. On the licence side, the AGPL-3 Community Edition and the Fossorial Commercial License Enterprise Edition impose different obligations, and the revenue threshold is a factual boundary you can check against your own numbers. Verify the edition boundary, verify the upgrade procedure, and verify connector compatibility. The rest of the platform's value depends on those three answers holding.

Editorial conclusion

Self-host the Community Edition if you already run WireGuard-adjacent infrastructure and want per-resource access control instead of a flat VPN subnet, and if AGPL-3 obligations are acceptable to your organisation. Do not pick it if you need a vendor to answer the phone at 3am, or if your users are mostly non-technical and you have no appetite for running identity, connectors and certificates yourself. Before committing, verify three things against the current docs: whether the Enterprise features you actually need are gated behind the Fossorial Commercial License revenue threshold, what the upgrade path between 1.22.x releases looks like for your database, and whether your identity provider's OIDC implementation matches what Pangolin expects for group-to-role mapping.

Official sources

1. fosrl/pangolin on GitHub
2. Issues
3. Project website
4. README
5. Releases