Both Pangolin and NetBird leverage WireGuard to provide secure remote access. While they address similar challenges, their approaches differ significantly. This article outlines what each solution offers and where they diverge, helping you determine which one best suits your needs.
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 NetBird?
NetBird is a zero-trust, peer-to-peer overlay VPN built on WireGuard. It creates a private network where your devices can talk to each other over the internet using direct, encrypted connections.
Devices join the network by running the NetBird client. Each device gets an IP on the overlay network. Once connected, devices can reach each other directly. You never open ports. NetBird uses NAT hole punching and key exchange so devices can form direct WireGuard links through firewalls; when hole punching fails, traffic relays through NetBird's infrastructure.
NetBird is built for device-to-device and server-to-server connectivity. You add devices to the network and control access using group-based policies managed through a UI with buttons and dropdowns, rather than editing complex configuration files. The model is "devices on a shared network" rather than "users and resources."
NetBird offers both a fully managed cloud service and a self-hosted option. Both the client agent (including mobile apps) and the coordination server are fully open source.
How the two compare
The table below summarizes the main differences. The sections after it walk through each area in order.
| Feature | Pangolin | NetBird |
|---|---|---|
| Architecture | Networks and resource access via connectors; clients connect directly to sites | Peer-to-peer VPN with; devices connect directly to each other |
| Access Control | Granular, role-based access and posture checks | Groups and policies; supports device posture checks |
| Self-Hosting | Self-hostable or cloud; full control over data and infrastructure | Both SaaS and self-hosted options; full control if self-hosting |
| Open Source | Fully open source: client agents and coordination server | Fully open source: client agents and coordination server |
| SSO Integration | Built-in SSO with OIDC; advanced identity providers in Enterprise Edition | Built-in SSO with OIDC free plan; advanced identity providers from Team plan |
| Web App Exposure | Secure web access without a client and custom domains | Only peer-to-peer connectivity |
| 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.
NetBird uses a peer-to-peer architecture. Every device forms direct WireGuard links to other devices. The NetBird control plane coordinates keys and discovery; data goes peer-to-peer when NAT allows it, or through NetBird's relays when it does not. Access is managed through distribution groups and peer groups. 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 NetBird you think in terms of devices (peers) on a network. You install the client on each device that should be on the network. Access is managed through distribution groups and peer groups, which can be configured via a UI. Distribution groups automate the application of configurations (routing, DNS, etc.) to groups of peers, while peer groups automate routing configuration. The unit of access is the device.
Access control and security
Pangolin uses UI control to define who can access which specific resources. Admins manage everything from the admin console. You use roles, groups, and optional device posture (OS version, disk encryption, and similar) to segment access. SSO and identity providers plug in. Policies are resource-centric: "this group can use this database" or "this role can reach this SSH host" and can also be configured from the API or YAML declaration config.
NetBird uses UI controls for access management through groups and policies. Admins manage everything from the admin console. NetBird supports device security posture checks. SSO with popular identity providers and MFA is available in the free plan, with advanced identity providers supported from the Team plan onwards. The focus is on network-level connectivity between devices with user-friendly policy management.
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.
NetBird focuses primarily on peer-to-peer device connectivity rather than web application exposure. It is not designed as an identity-based reverse proxy for web applications. If your main need is clientless web access with strong authentication and custom domains, Pangolin's model is purpose-built for that use case.
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. 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.
NetBird also offers both a fully managed cloud service and a self-hosted option. NetBird does not currently support hybrid deployments where you use the cloud control plane but host your own relay nodes.
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.
NetBird’s mesh grows with every device. Each device gets an overlay IP. You manage that address space and keep your groups and policies in sync as the network grows. For big fleets, the mesh network complexity can become a real concern. DNS in NetBird is node-oriented: names point at devices on the network, rather than resources on the remote network.
Sites vs. nodes: Scaling connector-based vs. device-based networks
Pangolin and NetBird take fundamentally different approaches to connecting remote resources. Pangolin uses a connector-per-network model (sites), while NetBird uses a node-per-device 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 NetBird, you need a node on each device or use exit nodes. In the same two-VPC scenario, you would either need to set up exit nodes in each VPC and switch between them, or install a NetBird client on every database server and virtual machine you want to access. This becomes more complex and potentially more expensive in large deployments with many resources or difficult when the resources cannot run the NetBird client like a database.
The connector model scales by adding sites and defining resources. The node model scales by adding more devices to the mesh, which increases overlay IP management and peer-to-peer coordination complexity.
Open source
Both Pangolin and NetBird are fully open source. Pangolin's server and all clients are available under the AGPLv3 or a Commercial License. NetBird's client agent and coordination server are also fully open source. Both projects allow you to run, inspect, and modify the full stack.
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" and optional clientless web access. Pangolin fits replacing a traditional VPN or reverse proxy with one system that does both.
Choose NetBird if you want a peer-to-peer VPN focused on device-to-device and server-to-server connectivity network building. NetBird fits small to medium overlay networks 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.
