Pangolin and Pomerium both provide identity-aware access to internal applications. Pomerium is an identity and context-aware reverse proxy focused on HTTP-based services at Layer 7. Pangolin is an identity-based remote access platform built on WireGuard that combines a reverse proxy for web apps with client-based access for databases, SSH, and other non-HTTP resources. This article outlines what each does and where they fit.

What is Pangolin?

Pangolin is an open-source, identity-based remote access platform built on WireGuard. It is resource-centric: you define specific hosts or applications users can reach, not whole networks. You deploy a lightweight connector (a site) on a machine that has access to a network—office LAN, VPS, cloud VPC, or home lab. Anything that site can reach can be defined as a resource (web app, database, SSH host, internal API). You grant users and roles access to specific resources; users see only what you allow. Every request is validated against your rules and user- or role-based access—not just at login. No open ports: sites use outbound-only tunnels, and clients use NAT hole punching for peer to peer connections or relay.

The full stack is open source. You can self-host the entire platform, use Pangolin Cloud, or use the cloud control plane and self-host only relay nodes so traffic stays on your infrastructure. Pangolin combines reverse proxy and VPN: web apps can be reached in the browser with no client; databases and SSH use the Pangolin client. Both paths share the same identity and permissions.

What is Pomerium?

Pomerium is an identity and context-aware reverse proxy that secures access to internal web applications and HTTP-based services. You deploy Pomerium at the edge in front of your apps; every HTTP request is validated against identity and context (user, device, policy) before being proxied to the backend. There is no VPN or overlay: traffic goes directly to Pomerium, which then forwards it to the origin. No client is required for users accessing HTTP services.

Pomerium is open source and can be self-hosted. It integrates with a wide range of identity providers and supports continuous verification—every request is checked, not just the initial login. Because it sits at the edge in front of your services, there is no backhauling of traffic through third-party relays; latency and bandwidth stay under your control. Pomerium is built for Layer 7: it excels at securing web applications and APIs. It does not provide built-in Layer 4 access (e.g. direct SSH or database connections) in the same way a VPN or connector-based system does.

How the two compare

The table below summarizes the main differences. The sections after it walk through each area in order.

Feature	Pangolin	Pomerium
Architecture	Cntrol plane + remote sites; clients or browser connect to resources	Reverse proxy at edge; every HTTP request validated
Layer	Layer 7 (web) and Layer 4 (SSH, DBs, arbitrary TCP)	Layer 7 (HTTP) only
Access model	Resources (web apps, hosts, ports); role-based; deny-by-default	Per-route policy; identity and context-aware; every request verified
Self-hosting	Self-hostable or cloud; full control over data and infrastructure	Self-hostable or cloud; infrastructure under your control
Open source	Open source	Open source
SSO / IdP	Built-in SSO with any IdP that supports OIDC	Supports a wide range of IdPs
Web app exposure	Clientless browser access, identity-aware reverse proxy, custom domains, automatic SSL	Clientless browser access, identity-aware reverse proxy, custom domains, automatic SSL
Non-HTTP access	Yes: SSH, databases, internal APIs, arbitrary TCP via Pangolin client	Not in scope; HTTP-based services only
Client required	Not required for web; For non-web resources (SSH, DBs)	Not required for HTTP-based services

Architecture

Pomerium is a reverse proxy. You put it in front of your web applications and APIs. Users hit Pomerium’s URL; Pomerium authenticates them (e.g. via IdP), applies policy, and proxies the request to the origin. The data path is user → Pomerium → origin. There is no VPN tunnel and no connector in your network for HTTP: the proxy is the only gateway.

Pangolin uses a connector (site) in each network. For web apps, the site runs an outbound tunnel so that browser traffic can reach internal applications without opening ports—similar in spirit to an ingress tunnel (e.g. Cloudflare Tunnel). For SSH, databases, and other non-HTTP resources, the Pangolin client connects to the site and tunnels traffic to the resource. So Pangolin has two data paths: browser → Pangolin (control plane / relay / tunnel) → site → web app, and client → site → resource. Both paths use the same identity and resource-based access control.

If you only have HTTP-based internal apps and want a single component (reverse proxy) at the edge with no client and no connector in the private network, Pomerium’s model is a natural fit. If you need both HTTP apps and non-HTTP resources (databases, SSH, legacy TCP services) with one control plane and one identity model, Pangolin covers both.

Layer 7 vs. Layer 4

Pomerium operates at Layer 7. It secures HTTP and HTTPS traffic. It does not provide a general way to reach a database on port 5432, an SSH server on 22, or an internal service on an arbitrary TCP port. Those use cases are outside its design. Documentation and comparisons often note that “application gating” for non-HTTP protocols is not Pomerium’s focus.

Pangolin is built for both. Web applications are exposed through an identity-aware reverse proxy (clientless). Databases, SSH hosts, and other TCP resources are exposed as resources and reached through the Pangolin client. One platform handles “who can open this URL in a browser” and “who can connect to this database or SSH host.” If your environment mixes web apps and non-HTTP services, Pangolin gives you a single place to define resources and grant access.

Web apps and clientless access

Both Pangolin and Pomerium can expose internal web applications without a VPN client. Users open a URL, authenticate (e.g. SSO), and use the app in the browser. In both cases, every request can be validated against identity and policy.

Pomerium is deployed at the edge in front of your services. There is no extra hop through a relay; traffic goes to your proxy and then to the origin. That minimizes latency and keeps the path simple.

Pangolin’s clientless web access uses an outbound tunnel from a site (connector) in your network. You don’t open ports; the tunnel carries traffic from Pangolin to the site and then to the app. You can run the Pangolin control plane and relays yourself so that no traffic goes over third-party infrastructure. Pangolin also supports custom domains and automatic SSL for web resources, plus extra controls (pin codes, passcodes, email whitelists) per resource.

So: for “reverse proxy only, at edge, HTTP only,” Pomerium is a strong fit. For “reverse proxy plus client-based access to everything else, with optional full self-hosting,” Pangolin covers both.

NAT traversal

Pangolin uses NAT traversal in two ways: for the reverse proxy (web access) and for client-based access. The two mechanisms are different but both avoid the need to open ports or have a public IP on your private resources.

Tunneled reverse proxy. Pangolin is a tunneled reverse proxy: the tunnel sits at the end of the reverse proxy, in your network. You run a site (connector) on a machine that has outbound internet access. That site opens an outbound tunnel to Pangolin; it never listens on a public port. So you can expose web apps (and other resources) that live on any network that has an outbound connection—including behind CGNAT, behind a home router, or in a VPC with no public IP. No port forwarding, no public IP, and no inbound firewall rules are required. Browser traffic reaches your app by flowing through that outbound tunnel. The tunnel is what makes the reverse proxy work from behind NAT.

Client: peer-to-peer or relay. When a user connects with the Pangolin client (e.g. to SSH or a database), the client tries to form a direct connection to the site using NAT hole punching. If that succeeds, traffic goes peer-to-peer: client ↔ site ↔ resource, with no relay in the path. If hole punching fails (e.g. symmetric NAT or restrictive corporate firewalls), the connection falls back to relaying through a Pangolin server (or your self-hosted relay). So client traffic either goes direct or via a single relay; the control plane coordinates discovery and helps establish the path.

Contrast with Pomerium. Pomerium is a reverse proxy that receives inbound traffic. You deploy it at the edge—in front of your apps—where users (or the internet) can reach it. Pomerium does not initiate an outbound tunnel from behind your firewall; it is the endpoint that users hit. So Pomerium (or the load balancer in front of it) must be reachable: it needs a public address or at least internal reachability from your users. That typically means deploying it in a DMZ, a cloud VPC with a public LB, or similar. NAT traversal in the "no open ports, works behind CGNAT" sense is not part of Pomerium's model—the proxy is the thing that is reached, not a process behind NAT opening a tunnel. If your apps are behind CGNAT or a home connection with no way to expose a public endpoint, Pomerium cannot sit there; you'd need some other way to get traffic to Pomerium (e.g. another tunnel or VPN to a reachable network). Pangolin's tunneled reverse proxy is built for exactly that case: the resource can be on any network with outbound internet, and the tunnel makes it reachable without opening ports.

Deployment and data sovereignty

Both Pangolin and Pomerium can be self-hosted. You run the components on your own infrastructure and keep the control plane and data under your control.

Pangolin offers flexibility: fully self-hosted (server, sites, and optionally your own relay nodes) or Pangolin Cloud with optional self-hosted relays so traffic never leaves your side. Pomerium is typically self-hosted at the edge; there is no separate “relay” layer because the proxy is the gateway. If your main concern is “no third-party in the data path,” both can achieve that when self-hosted; Pomerium does it by design for HTTP (no relay at all), and Pangolin does it when you self-host the control plane and relays.

Relays and availability

Pomerium’s architecture does not rely on a third-party relay. The proxy runs in your environment; availability depends on your deployment.

Pangolin can run without any third-party relay: you self-host the server and your own relay nodes. In that setup, connection establishment and data flow stay on your infrastructure. If you use Pangolin Cloud and its relays, then availability of new connections depends on that service; existing connections can still use direct or self-hosted relay paths depending on configuration. So “no dependency on someone else’s relay” is achievable with Pangolin by self-hosting.

Identity providers and access control

Both platforms integrate with identity providers and support fine-grained access policy. Pomerium is known for supporting a wide variety of IdPs and for validating every request (continuous verification). Pangolin uses OIDC for SSO and works with any IdP that supports it; you manage access to resources via roles and optional device posture, and the same identity applies to both web and client-based access.

Neither requires you to hand-edit low-level ACLs; both offer a higher-level model (routes/policies in Pomerium, resources and roles in Pangolin).

Use cases

Pomerium is a good fit when:

• You need to secure internal web applications and HTTP APIs.
• You want a reverse proxy at the edge with no client and no connector in the private network.
• You are comfortable with Layer 7 only and will use other tools (or no access) for SSH, databases, and other non-HTTP services.

Pangolin is a good fit when:

• You need both web applications and non-HTTP resources (databases, SSH, internal APIs) behind one identity and one control plane.
• You want optional clientless web access plus client-based access for everything else.
• You want to self-host the full stack (control plane and relays) or keep traffic on your own relay nodes while using the cloud control plane.

A common recommendation in the space is to use a tool like Pomerium for HTTP-based services and a Layer 4 or VPN-style tool for backend infrastructure and servers. Pangolin is designed to cover both in one system: identity-aware reverse proxy for web apps and resource-based access (via client) for Layer 4, so you can consolidate if that simplifies your architecture.

Open source

Both Pangolin and Pomerium are open source. You can run, inspect, and modify the code. Pangolin’s server and clients are under AGPLv3 or a Commercial License; you can self-host the entire platform. Pomerium’s proxy and related components are open source and self-hosted at the edge.

Best fit

Choose Pangolin if you want one platform for both web applications and non-HTTP resources (SSH, databases, internal APIs). You get clientless web access and client-based access with the same identity and permissions, and you can self-host the full stack or keep traffic on your own relays.

Choose Pomerium if you only need to secure HTTP-based internal applications and want a reverse proxy at the edge with no client and no relay dependency. Pomerium is a strong fit when Layer 7 is the only concern and you prefer a single-purpose proxy.

Try Pangolin

Get started with Pangolin. You can self-host the server or sign up for the cloud and try it with no commitment.

Get in touch

If you want more detail on how Pangolin can fit your setup, reach out.