Pangolin and Twingate both provide identity-based, zero-trust remote access. They share a resource-centric model: you define specific hosts or applications users can reach, rather than giving them the run of a network. Under the hood they differ in architecture, how they expose web apps, and where you can run them. This article outlines what each does and where they diverge.
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. No open ports: sites use outbound-only tunnels, and clients use NAT hole punching 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 Twingate?
Twingate is a zero-trust remote access platform that gives users access to specific resources (hosts or applications by FQDN or IP), not whole networks. You deploy connectors in your private networks; they maintain outbound connections only, so no open ports are required. Users connect to resources by FQDN or IP; the system handles routing and encryption over their proprietary TLS-based tunnels, using direct connections when possible and relaying when not. Twingate is closed source and uses a cloud-hosted, multi-tenant control plane.
How the two compare
The table below summarizes the main differences. The sections after it walk through each area in order.
| Feature | Pangolin | Twingate |
|---|---|---|
| Architecture | Hub-and-spoke; control plane + sites; clients connect to sites | Controller + Relays + Connectors + Clients; Controller never touches data |
| Access model | Resources (web apps, hosts, ports); FQDN or IP for client and browser resources; role-based | Resources (FQDN/IP); ACLs for Clients and Connectors |
| Self-hosting | Self-hostable or cloud; full control over data and infrastructure | Controller is cloud-only, multi-tenant |
| Open source | Server and clients fully open source (AGPLv3 or Commercial License) | Closed source; no self-hosted control plane |
| SSO / IdP | Built-in SSO with OIDC and delegated authentication to IdP | Delegates authentication to IdP |
| Web app exposure | Clientless browser access, identity-aware reverse proxy, custom domains, automatic SSL certificates | Private resources only; client required for access |
| Ingress | Clientless tunnel (like Cloudflare Tunnel/ngrok); public ingress behind firewall; load balance and failover across tunnels | Private resource access only; no public ingress tunnel |
| Tenancy | Multiple organizations per account; share users and resources between orgs; suited for MSPs | Single tenant per signup; one tenant for your team |
| Device security | Device posture (encryption, firewall, antivirus, etc.) | Device posture (encryption, firewall, antivirus, etc.) |
| Transport | WireGuard; NAT traversal via Relay or P2P; no open ports | Custom protocol; TLS tunnels; NAT traversal via Relay or P2P; no open ports |
Architecture
In both systems you deploy a connector to a network, define resources behind it, and delegate users access to those resources. Clients connect to connectors (direct or via relay); the control plane handles auth, discovery, and NAT traversal. The model is the same: no device mesh, no open ports—you scale by adding connectors and resources.
The main administrative difference is how connectors are grouped. In Twingate you define logical networks in the dashboard and assign connectors to them. In Pangolin the model is flatter: you define sites in the dashboard and deploy them to your physical networks. That flat structure scales well when you have many sites—for example, IoT deployments where you may have hundreds or thousands of sites with resources.
How clients and access work
In both systems the unit of access is the resource: a specific application, host, or port. Admins grant users (or roles/groups) access to specific resources; users get only what they are allowed. Access is deny-by-default. Users install a client, sign in, and see only their authorized resources. In Pangolin, resources can be identified by FQDN or IP for both client-based and browser-based access. Both support machine clients for servers, CI/CD, and other automated systems—not only interactive user devices.
Access control and security
In both platforms you use the UI to delegate access to users and to roles (Pangolin) or groups (Twingate). Each system generates ACLs behind the scenes and passes them to clients and connectors to enforce; you do not edit ACLs by hand. Both support identity providers for authentication. In Pangolin you can connect any IdP that supports OIDC, whether or not Pangolin has a built-in integration. Both support declarative setup for resources, sites (or connectors), and access policy—so you can manage config via code or automation.
Web apps and clientless access
Pangolin can expose web applications without a VPN client. Users open a URL, sign in (e.g. with SSO), and reach the app in the browser. Pangolin acts as an identity-aware reverse proxy and provisions SSL certificates for you. You can add pin codes, passcodes, user auth, email whitelists, and more per resource. Pangolin supports custom domain names for web resources. That fits contractors, BYOD, or quick access to internal tools when you do not want to install a client everywhere.
Twingate is built around private Resources only whereas Pangolin has both private and public resources. Access to private Resources requires the Twingate client on the user’s device. There is no built-in, clientless browser path for web applications in the same way. If your main need is “someone signs in via the browser and sees only the web apps I allow,” with strong auth and custom domains, Pangolin’s public resources are built for that; with Twingate you would rely on the client for all access to private resources.
Ingress
Pangolin's clientless web access works like a Cloudflare Tunnel or ngrok: an outbound tunnel from your network that can receive public ingress and direct it to resources behind the firewall. You do not open ports. You can load balance and fail over between multiple tunnels for high availability.
Twingate is built for private resource access. It does not offer this style of public ingress tunnel; all access goes through the Twingate client to private Resources.
Deployment and data sovereignty
Pangolin can run fully on your own infrastructure. You can self-host the server and all components, or use Pangolin Cloud and optionally add your own nodes so traffic stays on your side while using the cloud control plane. Self-hosting gives you full control over the control plane and data.
Twingate’s Controller is a hosted, multi-tenant service. You do not self-host the Controller. Connectors and Relays run in your or Twingate’s infrastructure, but the brain of the system—where config and ACLs live—is cloud-only. If you need the control plane and all data on your own infrastructure, Pangolin’s self-hosted option supports that; Twingate does not offer a self-hosted Controller.
Scaling and connector model
Both Pangolin and Twingate use a connector-per-network model. You deploy one connector (site in Pangolin, Connector in Twingate) per network or segment. You then define resources behind that connector. Users can have access to resources on multiple networks at once; they do not need to peer with each other or with every server. The main administrative difference is grouping: Twingate lets you organize connectors into logical networks in the dashboard; Pangolin uses a flatter model where you define sites and deploy them to your physical networks. When you have many sites, that flat structure can scale more easily—for example, IoT deployments with hundreds or thousands of sites and resources.
Pangolin scales by adding sites and defining more resources. You do not maintain a large overlay IP space. You can use the same addresses you use on the LAN (e.g. 192.168.1.210) or friendly aliases like database-east.my-org.internal. Overlapping CIDRs are handled with alias addresses and routing.
Twingate scales in a similar way: more Connectors and more Resources. Users connect to Resources by FQDN or IP; DNS for protected Resources can be resolved via the Connector so that addressing stays local to the resource. The main scaling limit is operational: you depend on Twingate’s Controller and relay infrastructure, whereas with Pangolin you can scale and operate the whole stack yourself if you self-host.
Tenancy
In Pangolin you can define multiple organizations under one account and share or assign users and resources across them. That makes it well suited for managing multiple tenants from a single system—for example, an MSP serving many customers.
Twingate is single-tenant. When you sign up you get one tenant for your team. Managing many separate organizations is less natural than with a multi-org model.
Device security
Both platforms support device posture checks: they gather information about security-related settings on the device, such as whether disk encryption is enabled, the firewall is on, antivirus is present and up to date, OS version, and similar. You can use this data in access policies to allow or deny access based on posture.
Both also support device fingerprinting: collecting device-specific identifying information such as serial numbers and hardware identifiers. That lets you recognize and track devices over time and tie policy to a known device, not just a user account.
Pangolin adds a device approvals feature. When enabled, the system denies all new user devices by default. Admins see a feed of pending devices and can approve or deny each one; only approved devices can connect. That gives you explicit control over which devices are allowed onto the platform before any access is granted.
Open source
Pangolin’s server and clients are open source under the AGPLv3 or a Commercial License. You can run, inspect, and modify the stack.
Twingate is proprietary. You cannot self-host the Controller or run a fully independent Twingate deployment. If transparency and the ability to run and modify the entire system matter to you, Pangolin’s licensing and self-hosting options support that.
Best fit
Choose Pangolin if you want the same connector–client model for private resource access, with the option to add a tunneled reverse proxy for clientless web access. Pangolin is open source and self-hostable if you want full control over the stack, and it is built on the WireGuard protocol.
Choose Twingate if you are focused on private resource access and are comfortable with a cloud-only Controller. Twingate fits if you mainly need client-based access to internal hosts and applications and do not need built-in clientless web app exposure or an optional self-hosted control plane.
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.
