fosrl/pangolin: self-hosted SASE with WireGuard, identity-aware proxy and PAM

What Pangolin replaces, and for whom

Most self-hosted remote access setups end up as a VPN that puts a user on a network, plus a reverse proxy that publishes a handful of web apps, plus a separate SSH bastion. Each piece has its own user list. Pangolin's pitch is that connectivity and access decisions share one identity and policy model, so a site connector, a published web app, a database over a client tunnel and an AI endpoint all resolve against the same users, roles and audit log. The README frames this against Cloudflare One, Zscaler and Prisma, with the difference being that Pangolin is open and self-hostable.

The intended operator is a small infrastructure or platform team that has to give contractors, engineers and internal staff access to things that live behind NAT: a NAS, a database, an internal admin panel, a vLLM server. The README describes a lightweight user-space connector that runs as a binary or container and does not need open ports or a public IP, which is the part that matters if your resources sit on residential links or behind carrier NAT. It is not aimed at someone who wants to click through a cloud signup and never see a server.

Sites, connectors and how traffic actually reaches a resource

The architecture has three moving parts visible in the README and the repository layout. Sites are gateways into private networks, deployed as a binary or container; they establish outbound tunnels and use NAT traversal so the network behind a restrictive firewall becomes reachable without inbound rules. Resources are the things you actually want to reach, published either as browser-accessible HTTPS applications through the reverse proxy or as private resources over a client tunnel. The server component is a Next.js application: package.json declares the project as an ESM package and the dev script runs tsx watch server/index.ts, while the Dockerfile builds a standalone Next.js output and copies dist/server.mjs plus a CLI binary.

Access decisions are per resource, not per network, which is the zero-trust claim. The README lists identity provider integration, role-based access control and audit logging, and adds second factors for browser access: PIN codes, passcodes, email OTP, geoblocking and allow-lists. For client-based access, the README describes peer-to-peer connections with NAT traversal, DNS aliases for network addresses, and redundancy by routing traffic through multiple connectors. The AI gateway is the same reverse proxy with an identity check in front: public cloud APIs and self-hosted model servers get published behind one Pangolin URL, with personal API keys for public resources or keyless access where the connected client is the credential.

Installing Pangolin: cloud signup, marketplace image or the quick install guide

The README gives three entry points and no inline commands. The fastest is Pangolin Cloud at app.pangolin.net, which the README describes as a fully managed service with no infrastructure required. The second is the DigitalOcean marketplace listing, which the README calls a one-click pre-configured installer. The third is self-hosting, and for that the README points at the quick install guide at docs.pangolin.net/self-host/quick-install rather than reproducing steps. If you want to run the code from source instead, the repository's own scripts are the reference; package.json defines dev:setup, which copies config/config.example.yml to config/config.yml and then runs set:oss, set:sqlite, db:sqlite:generate and db:sqlite:push.

npm run dev:setup
npm run dev

The first command produces a config/config.yml from the example, pins the build to the open-source variant and the SQLite driver, then generates and pushes the schema. The second starts the dev server with NODE_ENV=development and ENVIRONMENT=dev. The repository also ships compose.yaml for development, which builds Dockerfile.dev and maps ports 3000 through 3003.

docker compose -f compose.yaml up

That compose file mounts src, server, public, messages and config into the container for hot reload, and sets restart: no, so it is a development environment rather than something you leave running. For a production container the Makefile builds images tagged fosrl/pangolin with BUILD=oss and DATABASE set to sqlite or postgresql, across linux/arm64 and linux/amd64. The README does not publish a docker run command or a compose file for production, so treat the image tags as the artefact and the docs site as the deployment instructions.

The database, build and edition switches you have to get right

This is the part of the repository that will bite someone following a blog post. Pangolin is not one build. package.json defines set:oss, set:saas and set:enterprise, each of which overwrites server/build.ts and copies a different tsconfig (tsconfig.oss.json, tsconfig.saas.json, tsconfig.enterprise.json) over tsconfig.json. Separately, set:sqlite and set:pg rewrite server/db/index.ts and swap drizzle.config.ts between drizzle.sqlite.config.ts and drizzle.pg.config.ts. The Dockerfile takes BUILD and DATABASE as build arguments and runs the corresponding set: scripts before generating migrations and building. The Makefile then produces four release targets: oss/sqlite, oss/postgresql, and the two Enterprise variants.

So "which Pangolin am I running" has two answers, and both are baked in at build time, not chosen at runtime. If you build your own image and forget the DATABASE argument, the Dockerfile default is sqlite. If you are migrating from a test deployment to production and change the driver, the schema generation step differs, because drizzle-kit is invoked against a different config file. The practical consequence: decide the edition and the database before you build anything, and keep the build arguments in whatever pipeline produces your image.

Where Pangolin is the wrong tool

Pangolin does a lot, and the breadth is the risk. The README itself describes the whole platform as built to stay small, but the same repository carries a Next.js dashboard, a CLI, a server, Drizzle migrations for two database engines, three build variants and a MaxMind geolocation dependency. That is a real operational surface for a team that just wants to expose three internal web apps. If your requirement is "publish an HTTPS service and terminate TLS", a single reverse proxy plus an identity provider does that with far fewer moving parts, and you will not have to reason about connector tunnels or a control plane.

The second boundary is the licence. The repository's LICENSE is not machine-classified on GitHub, and package.json says "SEE LICENSE IN LICENSE AND README.md". The README states the Community Edition is AGPL-3 and the Enterprise Edition is under the Fossorial Commercial License, free for personal and hobbyist use and for businesses making less than $100K USD gross annual revenue. If you are a company above that line and you want the Enterprise features, this is a paid product, not a free one, and the README does not enumerate which features sit behind the line. A third limitation is documentation depth in the README itself: it markets capabilities but does not document rollback, upgrade procedures or the Enterprise feature split, so those answers have to come from the docs site.

Compared with running Tailscale plus a reverse proxy

The obvious alternative for the same job is a mesh VPN such as Tailscale or plain WireGuard for the tunnel, paired with Caddy, Traefik or Nginx Proxy Manager for the web side. The difference is where the policy lives. With a mesh VPN, joining the tailnet usually means reaching everything the ACLs permit, and the reverse proxy is a separate system with its own auth. Pangolin inverts that: the README states access is granted per resource, not per network, and the same identity and policy model covers sites, the reverse proxy, client access, RBAC and the AI gateway. You also get privileged access management for SSH and browser-based VNC and RDP, which a plain proxy does not offer.

The cost of that unification is that you are adopting a platform. A mesh VPN plus Caddy is two well-understood daemons with small configs; Pangolin is an application with a database, migrations, an admin UI and a licence tier. If your access model genuinely is "these five people can reach the whole lab network", the mesh approach is simpler and Pangolin adds a control plane you do not need. If your model is "this contractor gets this one database for 30 days, with an audit trail", Pangolin's per-resource model is the closer fit.

Maintenance, releases and what the licence means in practice

The last push to the default branch was on 2026-09-10, and releases 1.22.0, 1.22.1 and 1.22.2 landed between 2026-08-27 and 2026-09-04. That is a fast cadence: three patch and minor releases in roughly a week. For an operator this cuts both ways. Security fixes arrive quickly, but so does churn, and the build-variant mechanism means a release can change what a self-built image contains. The Makefile's release targets are the authoritative description of what gets published, and it builds four combinations per tag, so pin an explicit tag rather than latest and re-read the release notes before moving.

On licensing, the split is stated plainly in the README and nowhere more precisely. The Community Edition is AGPL-3. The Enterprise Edition uses the Fossorial Commercial License and is free for personal and hobbyist use and for businesses under $100K USD gross annual revenue. If you self-host the Community Edition inside a company, AGPL-3 obligations apply to the software and to modifications you distribute; that is a question for your own counsel, not something this article can settle. The practical point is that the free tier and the paid tier are different licences with different obligations, and the README does not list which features move you across the line.

Editorial conclusion

Adopt Pangolin if you need per-resource access rather than network-level VPN access, and you are willing to run the control plane yourself; the AGPL-3 community edition is the free path, and the Enterprise Edition is free only for personal use or businesses under $100K USD gross annual revenue. Do not adopt it if you want a managed service with no infrastructure, or if you need a support contract and the open-core licence terms are not acceptable. Before committing, verify three things: which database driver your build targets, since the repository ships both SQLite and PostgreSQL paths; whether the SSO provider you use is covered by the documented identity provider integration; and what the Enterprise Edition adds, because the README does not enumerate the split.

Frequently asked questions

Official sources

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