I usually think about remote access as a pile of separate tools. One proxy handles HTTPS, a VPN reaches private addresses, another service handles login, and a remote desktop gateway covers the awkward machines.
Pangolin caught my attention because it puts those jobs behind one resource and access model. The useful part is not the length of its feature list. It is that the proxy, tunnel, identity, and policy layers know about each other.
I have not moved production traffic through it yet. This is a research note on why I think it is worth testing, what its security model gets right, and what I would verify before trusting it with a real network.
The interesting part is the shared policy
A common self-hosted setup grows one tool at a time. Caddy or Traefik terminates TLS. WireGuard connects private networks. Authentik or Authelia protects web dashboards. Apache Guacamole puts remote desktops in a browser.
Each tool is good at its job. The seams are where the work appears: separate user lists, access rules, certificates, logs, and failure modes.
Pangolin collapses much of that into a single concept called a resource. A resource can be an HTTPS app, an SSH host, a database port, a remote desktop, one private host, or a CIDR range. Users receive access to resources through identities, roles, policies, or machine credentials.
That gives Pangolin several distinct access paths:
| Resource path | A good fit for | What the user needs | Pangolin access layer |
|---|---|---|---|
| Public HTTP or HTTPS | Dashboards, APIs, and internal web apps | A browser | SSO, identity providers, users, roles, passcodes, links, and request rules |
| Browser SSH, RDP, or VNC | Server work, support, and remote displays | A browser | Resource policy plus the selected protocol authentication |
| Private host, CIDR, or HTTP | Databases, SSH, internal services, and subnets | A Pangolin client | Explicit user, role, or machine access with optional port restrictions |
| Public TCP or UDP | A service that must listen on a public port | Its normal protocol client | No Pangolin identity or request policy at this layer |
The last row matters. Pangolin can proxy raw TCP and UDP, but its documentation is explicit that these protocol-agnostic pipes do not get Pangolin authentication or access rules. I would use a private resource for SSH, databases, and other sensitive raw traffic whenever possible.
How the pieces fit together
The Pangolin architecture separates coordination from traffic.
The control plane stores organizations, users, roles, sites, resources, and policies. A Pangolin node handles ingress and tunnel traffic. A lightweight connector called Newt runs inside the remote network and makes an outbound connection to that node. End-user clients also connect outward.
This direction is important. A home lab, office network, or edge device can sit behind NAT without a public IP or a new inbound firewall rule. Newt provides the route from the inside, then Pangolin only exposes resources that an administrator defines.
For private access, Pangolin uses WireGuard tunnels. It attempts a direct peer-to-peer path with NAT traversal and can relay through the node when a direct path is unavailable. Version 1.21 also added same-network detection, so a client and site on the same LAN can keep their packets on that LAN instead of bouncing through a relay.
Public web traffic follows a different path. A browser reaches the public node, the reverse proxy terminates HTTPS, the authentication middleware checks the resource policy, and approved traffic crosses the tunnel to the private service.
This is why Pangolin feels bigger than a VPN. The same control plane understands both browser ingress and private client routes.
The security choices I like
Deploying a site does not expose its network. Sites block traffic until a resource exists and access has been granted. Private clients also receive no usable resources by default.
Resource-scoped access matters too. A contractor can reach one staging dashboard without receiving a route to the whole staging subnet. A machine client can reach one database port without inheriting every permission held by a human user.
Encryption and identity handle different jobs. WireGuard protects the network path. Pangolin decides which identity can create that path and which destination it can reach. For web resources, the same policy layer can use Pangolin accounts or an external OIDC provider, then add role, IP, country, path, or passcode rules.
There are also practical controls around the edges: expiring share links, access tokens for automation, connection logs, health checks, and alerting. These are the things that make an access system operable after the first successful connection.
Where the security boundary needs care
No remote access product turns a public server into somebody else’s problem.
A self-hosted Pangolin node becomes part of the network security boundary. The quick install guide expects a Linux server with a public IP and a domain. It also opens TCP 80 and 443, UDP 51820 for site tunnels, and UDP 21820 for client tunnels. Remote sites can stay closed to inbound traffic, but the central node cannot disappear from the threat model.
I would treat the node like any other internet-facing gateway: expose only the documented ports, keep Pangolin and its containers updated, protect the admin account, send logs somewhere useful, and test backups before an upgrade. The 1.21.1 release notes specifically warn that downgrades are difficult without a backup of the configuration and app data.
Access rules deserve the same attention. A rule can bypass authentication for matching requests. Share links and access tokens are bearer credentials, so anyone holding one can use its access until it expires or is revoked. Public TCP and UDP proxies have no Pangolin identity layer at all.
Edition boundaries also affect a security plan. Community Edition supports a global identity provider and one role per user. Multiple roles per user, organization-level identity providers, and device approvals require Cloud or Enterprise. Enforced two-factor authentication is Enterprise-only. Internal users can still enable TOTP without organization-wide enforcement. A team should compare the current edition details before designing policy around a feature.
The source is open, but the licensing still deserves a read. Pangolin uses a dual model: Community Edition is under AGPL-3, while Enterprise Edition uses the Fossorial Commercial License. That is fine for many deployments, but “open source” does not mean every enterprise feature has the same license.
Where I would use it
Pangolin looks especially useful when one environment needs more than a tunnel:
- A home lab with several web dashboards, SSH hosts, and no desire to open a port for every service.
- A small team that needs browser access to admin tools plus client access to databases and internal APIs.
- Branch offices, workshops, or edge devices behind carrier-grade NAT where inbound networking is painful.
- Temporary vendor or customer access to one web resource through an expiring link instead of a full VPN account.
- Remote support through browser-based SSH, RDP, or VNC when installing a native protocol client is inconvenient.
- An IoT fleet where connectors make outbound connections and each device group needs a narrow set of reachable resources.
If I needed only HTTPS for two services on one server, I would keep Caddy or Traefik. If I needed only a private mesh, a focused overlay network might be easier to reason about. Pangolin becomes compelling when browser access, private routes, identity, and policy would otherwise become separate systems.
A small test before a real deployment
The official installer sets up Pangolin, Gerbil, and Traefik with Docker. Its documentation pipes a downloader into a shell. I would split that into inspectable steps:
curl -fsSL https://static.pangolin.net/get-installer.sh -o get-installer.sh
less get-installer.sh
bash get-installer.sh
sudo ./installerMy first test would use a disposable VPS and two low-risk resources. I would publish one internal dashboard through browser authentication, then add one private SSH host through the desktop client.
The test is successful only if the negative cases work too: a new user sees nothing, a revoked user loses an active route, a bypass rule cannot reach an admin path, the site recovers after a connector restart, and the logs explain each decision.
That is the part I like about Pangolin. It gives those tests one place to live. I have added it to my toolkit, and the next step is a small deployment where I can measure the traffic paths and failure modes myself.