Pangolin and Tailscale both use WireGuard to give you secure remote access. They solve related problems in different ways. This post explains what each one is and how they differ so you can see which fits your case.
What is Pangolin?
Pangolin is an open-source, identity-based remote access platform built on WireGuard. You think in terms of networks, not nodes on a network. You install a lightweight connector (Pangolin calls it a site) on a machine that already has access to a network: your office LAN, a VPS, a cloud VPC, or a home lab.
That connector is the entry point. Anything it can see on the network can be turned into a resource. A resource might be a web app, a database, an SSH host, or an internal API. You grant users and roles access to specific resources. You do not necessarily grant access to the whole network. Users get only the resources you allow, and you never expose the underlying network or open ports.
Pangolin combines reverse proxy and VPN in one system. For web apps you can give users browser-based access: they sign in and reach the app without installing a client. For things like databases and SSH you give them access through the Pangolin client, which tunnels traffic to the right resource. Both paths use the same identity and permissions, so you manage users and access in one place.
You never open ports. Sites create outbound-only tunnels for web access. Clients form direct connections and use NAT hole punching when they can, falling back to relaying through the Pangolin server when they cannot.
What is Tailscale?
Tailscale is a mesh-based, overlay VPN service built on WireGuard. It creates a private network, called a tailnet, where your devices can talk to each other over the internet.
Devices join the tailnet by running the Tailscale client. Each device gets an IP on the overlay network. Once connected, devices can reach each other directly. You never open ports. Tailscale uses NAT hole punching and key exchange so devices can form direct links through firewalls; when hole punching fails, traffic relays through Tailscale’s infrastructure.
Tailscale is built for device-to-device and server-to-server connectivity. You add devices to the tailnet and then control who can reach what using ACLs (access control lists) written in JSON. The model is “devices on a shared network” rather than “users and resources.”
Tailscale runs as a cloud-only service. You use their control plane and relay infrastructure. A community project called Headscale reimplements the control plane for self-hosting, but it is not an official Tailscale product.
How the two compare
The table below summarizes the main differences. The sections after it walk through each area in order.
| Feature | Pangolin | Tailscale |
|---|---|---|
| Architecture | Networks and resource access via connectors; clients connect directly to sites | Mesh-based VPN with overlay network; devices peer directly |
| Access Control | Granular, role-based access and posture checks | JSON-based ACLs at layer 4 |
| Self-Hosting | Self-hostable or cloud; full control over data and infrastructure | Cloud only; Headscale is community-supported |
| Open Source | Server and clients fully open source under AGPLv3 or Commercial License | Only part of clients open source; server closed source |
| SSO Integration | Built-in SSO with OIDC | Built-in SSO with OIDC |
| Web App Exposure | Secure web access without a client and custom domains | Tailscale Funnel exists but authentication options are limited and custom domains are not allowed |
| Transport & NATs | WireGuard NAT traversal; no open ports | WireGuard NAT traversal; no open ports |
| Magic DNS | Custom internal DNS names for resources | Custom internal DNS names for nodes |
Architecture
Pangolin uses a hub-and-spoke style. The Pangolin server is the control plane: it handles auth, keys, and coordination. Sites (connectors) in your networks connect outbound to that server. For private access, clients connect directly to sites: the server helps with discovery and NAT traversal (or relays when a direct link is not possible), but the data path is client to site to resource. Clients do not talk to each other. They only reach the resources you grant them. This keeps the model simple and scales by adding sites and resources, not by growing a mesh. This avoids the "N-squared" complexity of mesh networks, where managing peer-to-peer ACLs and large overlay IP spaces becomes exponentially harder as you scale. By keeping the underlying network hidden, Pangolin ensures that users only ever see the specific applications they are authorized to use.
Tailscale uses a mesh. Every device in the tailnet can form direct WireGuard links to other devices. The Tailscale control plane coordinates keys and discovery; data can go peer-to-peer when NAT allows it, or through Tailscale’s relays when it does not. The network is “every device sees every other device” (subject to ACLs). That works well for small to medium sets of devices that need to talk to each other. At large scale, the mesh and ACL complexity grow.
How clients and access work
In Pangolin you think in terms of resources: apps, servers, databases. Admins grant users or roles access to specific resources. A user installs the Pangolin client, signs in, and sees only the resources they are allowed to use. Sessions are per resource. Access is deny-by-default. No resource is reachable until you grant it.
In Tailscale you think in terms of devices (nodes) on a tailnet. You install the client on each device that should be on the network. ACLs define which nodes (or tags) can reach which other nodes, subnets, or ports. The unit of access is the device, not a named application or resource. You get fine-grained networking, but you express it in JSON and in terms of IPs, ports, and tags.
Access control and security
Pangolin gives you a UI, API, and YAML to define who can access which resources. You use roles, groups, and optional device posture (OS version, disk encryption, and similar). SSO and identity providers plug in. You do not write low-level ACLs. Policies are resource-centric: “this group can use this database” or “this role can reach this SSH host.”
Tailscale uses JSON ACLs. You write rules that allow or deny traffic between nodes, by tag, or to certain ports. Tailscale has some device posture and SSO, but the main lever is the ACL file. It is powerful for network-level policy. It is less direct for “grant this person access to this one app or server” without thinking in terms of device IPs and ports.
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. You can layer on pin codes, passcodes, user auth, email whitelists, and more per resource. Pangolin also lets you use custom domain names for web resources. Access is deny-by-default and tied to identity. This fits contractors, BYOD, or quick access to internal tools when you do not want to install a client everywhere.
Tailscale has Funnel for public ingress to services. Funnel offers weaker authentication options than Pangolin. Auth methods are limited, and all Funnel resources share the same base domain (e.g. *.ts.net); you only control the subdomain. It is not built as a full identity-based reverse proxy for internal web apps. If your main need is “someone signs in and sees only the web apps I allow,” with strong auth and custom domains, Pangolin’s model fits that.
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 private while using the cloud control plane. Self-hosting gives you full control over the control plane and data. Cloud reduces operational load while still letting you keep traffic on your own node if you want.
Tailscale is offered only as a managed cloud service. You depend on their control plane and relay infrastructure. Headscale is an open-source, community-built control plane that speaks the Tailscale protocol. Some teams use it to self-host, but you maintain and operate it yourself; it is not Tailscale’s product. Users can self host relay nodes to keep traffic off Tailscale’s infrastructure, but the control plane remains cloud-only.
Scaling and IP management
Pangolin scales by adding sites and defining more resources. Clients do not need to peer with each other. You do not maintain a large overlay IP space. On your LAN you might reach a resource at 192.168.1.210. When connected with Pangolin you use the same address, or give it a friendly alias like database-east.my-org.internal. You can reach resources on entirely different subnets and stay connected to more than one at the same time. Overlapping CIDRs are handled with alias addresses and intelligent routing.
Tailscale’s mesh grows with every device. Each device gets an overlay IP. You manage that address space and keep ACLs in sync as the tailnet grows. For big fleets, the mesh and ACL complexity can become a real concern. DNS in Tailscale is node-oriented: names point at devices on the tailnet, rather than resources on the remote network.
Sites vs. nodes: Scaling connector-based vs. device-based networks
Pangolin and Tailscale take fundamentally different approaches to connecting remote resources. Pangolin uses a connector-per-network model (sites), while Tailscale uses a device-per-node model.
With Pangolin, you deploy one lightweight connector per network. For example, if you have two cloud VPCs - one with production databases and one with staging virtual machines - you would deploy two connectors (sites), one in each VPC. You then define resources for each database, VM, or service you want to access. Users can be connected to both VPCs simultaneously and access authorized resources in each. If you have a Grafana dashboard in one VPC, you can access it through your browser using the same authentication as your private VPN resources.
With Tailscale, you need to install the client on each device you want to access, or use subnet routers. In the same two-VPC scenario, you would either need to set up subnet routers in each VPC (which route traffic to entire subnets rather than specific resources), or install the Tailscale client on every database server and virtual machine you want to access. This becomes more complex in large deployments with many resources, especially when the resources cannot run the Tailscale client (like managed databases or appliances).
The connector model scales by adding sites and defining resources. The device model scales by adding more nodes to the mesh, which increases overlay IP management and peer-to-peer coordination complexity.
Open source
Pangolin’s server and clients are open source under the AGPLv3 or a Commercial License. You can run, inspect, and modify the full stack.
Tailscale’s client daemon (tailscaled) is partially open source. Full client apps (e.g. mobile) and the control plane are proprietary. You cannot self-host the official Tailscale backend; Headscale is a separate, community implementation.
Best fit
Choose Pangolin if you think in terms of networks and resource access rather than server-to-server or device-to-device connectivity. You want a zero-trust remote access platform that focuses on identity and resources: granular “who can reach which app or host,” optional clientless web access, and the option to self-host the whole thing. Pangolin fits replacing a traditional VPN or reverse proxy with one system that does both.
Choose Tailscale if you want a simple mesh VPN so devices and servers can talk to each other. You are fine with a cloud-only control plane and expressing policy in JSON ACLs. Tailscale fits small to medium tailnets where device-to-device connectivity is the main goal.
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.
