WireGuard's performance advantages over legacy VPN protocols (OpenVPN, IPsec) have made it the foundation for modern Zero Trust networking platforms. Its lightweight codebase, cryptographic simplicity, and kernel-level performance deliver secure connectivity without the configuration complexity and throughput bottlenecks that characterized earlier protocols. This technical superiority explains WireGuard's rapid adoption across the infrastructure security landscape and creates a new challenge: evaluating the growing number of WireGuard-based platforms competing for your attention.
NetBird and Pangolin represent two architectural approaches to WireGuard-based Zero Trust networking, both offering open source implementations, self-hosting capabilities, and identity-aware access control. This comparison examines how each platform implements core capabilities: architectural flexibility, access control granularity, network resource access, and operational deployment. Understanding these implementation differences will help you match platform capabilities to your specific infrastructure requirements and team operational preferences.
What is NetBird?
NetBird is an open-source Zero Trust networking platform that combines peer-to-peer mesh connectivity with network-level resource access. Devices connect directly to each other via encrypted WireGuard tunnels for low-latency communication, while routing peers and Networks enable access to entire subnets and resources without requiring agents on every target machine.
NetBird's flexibility means you don't have to choose between direct device connectivity and network access; it provides both models within a single platform. When you need sub-10ms latency for developer-to-developer connections, peer-to-peer mesh delivers direct encrypted paths. When you need to reach database clusters, Kubernetes services, or legacy infrastructure that can't run agents, routing peers act as secure gateways to defined network ranges. When you need to expose internal services to the public internet, NetBird's Reverse Proxy handles TLS termination and optional authentication, routing traffic through the WireGuard mesh without opening ports or configuring firewalls on target machines.
What is Pangolin?
Unlike NetBird, Pangolin is built around a central reverse proxy server that routes all traffic through Sites deployed to remote networks. A Site runs Pangolin's Wireguard-based Newt connector software, establishing a secure tunnel back to the Pangolin server in a hub-and-spoke topology. User devices run Pangolin clients that connect to the server, which coordinates access to Resources defined on Sites across your infrastructure.
This Site-based model eliminates the need to install agents on target resources. You deploy a Site to each network segment requiring protection, define which Resources exist behind that Site, and configure access policies through your identity provider. Users authenticate via the Pangolin client, and the server routes their connections through the appropriate Site to reach authorized resources. Pangolin also provides clientless web access for public resources, allowing browser-based access without installing client software. The platform is built on WireGuard and available as open source for both client and server components.
NetBird and Pangolin Capability Overview
The following table compares both platforms by capability rather than architectural approach, revealing how each addresses common Zero Trust networking requirements.
| Capability | NetBird | Pangolin |
|---|---|---|
| Direct device connectivity | ✓ | Via relay only |
| Network/resource access | ✓ (Networks, routing peers) | ✓ (Sites) |
| Web app exposure (clientless) | ✓ ( Reverse Proxy ) | ✓ |
| ACL-based access control | ✓ | ✓ |
| Posture checks | ✓ | ✓ |
| Full self-hosting | ✓ (all components) | ✓ |
| Open source | ✓ (client + server) | ✓ (client + server) |
| Identity-aware SSH | ✓ | — |
| Real-time topology view | ✓ (Control Center) | — |
This capability view demonstrates that NetBird covers both direct peer connectivity and network-level resource access, rather than forcing a choice between architectural models. The real differentiator is not which architecture each platform uses, but which platform provides flexibility to match your specific connectivity requirements.
Architecture: Flexibility, Not Trade-offs
| Dimension | NetBird | Pangolin |
|---|---|---|
| Connectivity Models | P2P mesh + routing peers/networks | Hub-and-spoke via central server |
| Latency Optimization | Direct tunnels when beneficial | All traffic coordinated through server |
| Scale Management | Group-based policies, automatic distribution | Resource-to-Site policies, server coordination |
| Architecture Decision | Per-workload optimization | Single hub-and-spoke model |
Zero Trust networking platforms often present architecture as a binary decision: choose a connector-based hub-and-spoke for resource access, or choose peer-to-peer mesh for device connectivity. This framing assumes you must select one model and accept its inherent trade-offs. As explained, NetBird eliminates this false choice by providing both connectivity patterns within a single platform.
NetBird's Architectural Implementation
NetBird's dual-mode architecture relies on three core components that work together to support both connectivity models. Networks define internal resources (IP ranges, domains, wildcard domains) and map them to routing peers , designated machines that gateway traffic between your NetBird mesh and private networks. This eliminates agent installation on every database, Kubernetes service, or legacy application while maintaining secure access through WireGuard tunnels. High availability for routing peers prevents single points of failure.
Groups organize peers into logical collections, functioning like tags within Access Control Policies . A peer can belong to multiple groups, and Access Control Policies define bidirectional or unidirectional rules based on source/destination groups, protocols (TCP, UDP, ICMP), and specific ports. The control plane distributes policies automatically; adding 50 engineers to your "DevOps" group grants immediate access to production resources without manual peer configuration.
The Control Center provides real-time topological visualization of your entire network, showing peer connections, group memberships, and network mappings. Administrators troubleshoot connectivity issues and audit access policies ("Who can reach which resources?") through a centralized dashboard that updates as peers join or leave the network.
Pangolin's Architectural Implementation
Pangolin's architecture centralizes traffic routing through a hub-and-spoke model where the Pangolin server acts as the coordination hub. Sites (running Newt connector) maintain outbound tunnels to the server from remote networks, while clients on user devices connect to the server for authentication and access coordination. This eliminates direct peer relationships; all connectivity flows through the central server.
Sites function as stateful gateways deployed within your infrastructure, typically one Site per network segment, cloud VPC, or data center location. Users install the Pangolin client, authenticate through your identity provider, and the server coordinates access to resources defined on Sites. By default, Sites block all traffic until administrators explicitly define resources and grant access permissions.
This centralized approach provides a single control point for traffic inspection and policy enforcement. The Pangolin server coordinates user authentication, policy evaluation, and routing decisions. When a user requests access to an internal application, the server evaluates policies, identifies the appropriate Site, and coordinates the encrypted connection between the client and the target resource through that Site.
The hub-and-spoke topology simplifies network visibility since all traffic coordination occurs at the server. Administrators deploy Sites as lightweight services (containers or virtual machines) and define resource-to-Site mappings through the management interface. Pangolin's Site-based architecture excels when you need centralized traffic coordination and prefer reasoning about network topology through a single server rather than distributed peer relationships.
Access Control: Granularity Matters
| Access Control Aspect | NetBird | Pangolin |
|---|---|---|
| Policy Granularity | Group + protocol + port level | Resource + user/group mapping |
| SSH Access | Identity-aware, IdP-authenticated | Resource policies via Sites |
| Posture Enforcement | Pre-connection device compliance checks | Server-based compliance validation |
| IdP Integration | Automatic group sync, OIDC/JWT auth | User/group mapping, OIDC auth |
| Enforcement Model | Distributed peer policies | Centralized server evaluation |
Access control implementations determine how precisely you can restrict network access and what administrative overhead that precision requires. Both platforms provide policy-based access control, but they differ in their enforcement models and the granularity available to administrators.
NetBird's Access Control Model
NetBird's access control operates at multiple layers. Policies define rules between source and destination groups with protocol-level granularity (TCP, UDP, ICMP) and port-level restrictions for specific services. This eliminates broad "network-level only" access; you grant the DevOps group TCP access to port 5432 on the database group, not unrestricted access to an entire network segment.
Identity-aware SSH replaces traditional key management by authenticating users through your identity provider. Engineers use standard SSH clients (), and NetBird handles authentication via OIDC/JWT tokens behind the scenes. Access policies govern SSH connectivity just like any other protocol, and offboarding a user from your IdP automatically revokes their SSH access across your entire fleet without manual key rotation.
Posture checks add device compliance requirements before granting access. You verify NetBird client versions, restrict access by geographic location or OS version, block specific peer network ranges, or examine running processes. This ensures that even authenticated users on compliant groups cannot connect from compromised or non-compliant devices.
IdP synchronization automates group membership by mirroring your existing organizational structure from Google Workspace, Microsoft Entra ID, Okta, or Keycloak. Onboarding adds users to NetBird groups automatically based on their IdP group memberships; offboarding removes access immediately when they leave your identity provider.
Pangolin's Access Control Model
Pangolin implements resource-level access control through Site-based policies that map users and groups to specific applications and services. Rather than defining network-wide policies, administrators create resource definitions for each application, database, or service they want to protect. Users authenticate through the identity provider, and the Pangolin server evaluates policies to determine which specific resources they can access on which Sites.
This resource-centric model means access grants target individual applications rather than network segments or peer groups. You define a policy that grants the Engineering team access to the staging API server, and the Pangolin server evaluates authentication and policies before coordinating connections through the appropriate Site to that specific resource. The server provides a centralized enforcement point for all resource access decisions.
Pangolin's posture checks validate device compliance (OS version, location, client version) before allowing connections. Resource policies can include additional conditions based on user attributes from your identity provider, time-based restrictions, or network origin constraints. The centralized server architecture means all policy evaluation occurs at the Pangolin server rather than being distributed across peer relationships.
Reaching Networks Without Agent Sprawl
| Network Access Aspect | NetBird | Pangolin |
|---|---|---|
| Resource Definition | IP ranges, IPs, FQDNs, wildcard domains | Individual resource mappings per Site |
| Gateway Role | Routing peers (mesh participants + gateways) | Sites (dedicated tunnels only) |
| High Availability | Multiple routing peers, automatic failover | Multiple Sites, server-coordinated failover |
| Dynamic Infrastructure | Wildcard domain support for changing IPs | Resource-specific definitions per Site |
| Gateway Dual-Purpose | Yes (P2P + gateway simultaneously) | No (tunnel role only) |
Both platforms solve the agent sprawl problem by introducing gateway nodes that bridge secure tunnels to internal networks, eliminating the need to install client software on every database, container, or legacy system. The implementations differ in how these gateways integrate with each platform's broader architecture and what types of network resources they can expose.
NetBird's Network Access Implementation
NetBird's Networks feature defines resources as IP ranges (10.0.2.0/24), specific IP addresses (10.0.2.15), fully qualified domains (), or wildcard domains (). You create a Network, specify which resources it contains, and assign routing peers to gateway traffic. Multiple routing peers for a single Network provide automatic high availability; if one routing peer fails, traffic is redistributed to surviving peers without manual intervention.
This approach handles dynamic infrastructure where services frequently change IP addresses behind load balancers or DNS records. Wildcard domain support means you define once rather than maintaining individual entries for every service in your Kubernetes cluster. Access policies apply at the Network level; granting a group access to the "Production Database Network" covers all resources within that definition without individual resource configuration.
NetBird's nameservers feature enables split-horizon DNS through match domains. You define which nameservers handle specific domains (e.g., routes to your internal DNS, while public domains use standard resolvers). This automatic routing means authenticated peers resolve internal domains correctly without manual DNS configuration, supporting multi-cloud and hybrid infrastructure.
Routing peers remain standard NetBird peers that also forward packets, meaning they participate in the mesh for direct connectivity while simultaneously gatewaying traffic to non-mesh resources. A routing peer in your AWS VPC can receive direct peer-to-peer connections from developer workstations while also routing traffic to RDS instances that cannot run the NetBird client.
NetBird's exit nodes provide internet gateway functionality, routing a peer's internet traffic through a designated peer rather than their local connection. Unlike routing peers that gateway to private networks, exit nodes forward internet-bound traffic through specific locations. This supports remote work scenarios requiring specific geographic IPs, bypasses restrictive networks, or provides consistent public IP addresses for external services that whitelist by IP.
Pangolin's Network Access Implementation
Pangolin's Sites serve exclusively as tunnels to remote networks; they do not establish peer relationships outside their hub-and-spoke role. You deploy a Site to each network segment requiring protection, define which specific resources (applications, services, IP addresses, or network ranges) exist behind that Site, and create policies mapping users to those resources. The Pangolin server coordinates all traffic routing decisions, directing authenticated clients through the appropriate Site to reach target resources.
Sites support high availability through deployment redundancy. Multiple Sites in the same network segment provide failover; the Pangolin server routes connections to available Sites if one becomes unreachable. This centralized coordination model means administrators configure network access by defining resource-to-Site mappings rather than managing peer groups and routing configurations.
Self-Hosting and Open Source Depth
| Self-Hosting Aspect | NetBird | Pangolin |
|---|---|---|
| Core Components | Management, signal, relay servers | Server, Sites (Newt connectors), clients |
| Community Features | SSO, MFA, posture checks, IdP sync included | Full Site and policy features |
| Deployment Options | Docker, Kubernetes, binaries | Containers, traditional installations |
| Data Residency | Berlin HQ, GDPR-first design | Self-hosted control over data location |
| License Model | Open source (BSD-3-Clause) | Open source |
Open source licensing and self-hosting capabilities determine whether organizations can maintain complete control over their network infrastructure and data sovereignty. NetBird and Pangolin share this commitment to transparency and operational independence, though they differ in component architecture, feature availability in self-hosted deployments, and licensing specifics.
NetBird's Self-Hosting Model
NetBird's self-hosted deployment includes three core components: the management server (coordinates policies, groups, and network state), the signal server (facilitates peer discovery and connection negotiation), and relay servers (provide fallback connectivity when direct peer-to-peer tunnels cannot be established). All components run on your infrastructure with no external dependencies for core functionality.
The community edition includes enterprise features like SSO integration, MFA, posture checks, and IdP synchronization without licensing restrictions. Docker Compose, Kubernetes Helm charts, and binary installations support various deployment environments. NetBird's company headquarters in Berlin means GDPR compliance is foundational to platform design, providing built-in data sovereignty for organizations with European regulatory requirements.
Pangolin's Self-Hosting Model
Pangolin's self-hosted architecture includes the Pangolin server (manages authentication, policies, and Site coordination), Sites (deployed per network segment), and client applications. Organizations deploy the server within their infrastructure and distribute Sites to each location requiring secure access. The server coordinates all policy evaluation and routing decisions without relying on external services.
Both client and server components are available as open source, supporting container-based deployments and traditional installations. Self-hosted instances provide the same Site-based architecture and policy management available in Pangolin's cloud offering, allowing organizations to maintain complete operational control while leveraging the centralized hub-and-spoke model.
When Each Fits Best
Choosing between Zero Trust networking platforms depends on matching architectural capabilities to your infrastructure requirements. NetBird provides peer-to-peer mesh connectivity, network-level resource access through routing peers, and clientless web application exposure through its Reverse Proxy, while Pangolin focuses exclusively on centralized server-coordinated access through Sites. Your decision centers on which connectivity patterns your infrastructure requires and how your team prefers to reason about network topology.
NetBird fits best when:
- Architectural flexibility matters. You need direct peer-to-peer connectivity for some workloads (developer machines, remote desktops) and network-level gateway access for others (databases, legacy systems, Kubernetes clusters). NetBird provides both without forcing architectural compromises.
- Latency optimization is important. Direct encrypted tunnels between peers eliminate intermediary hops for workloads where sub-millisecond latency differences impact user experience or application performance.
- Identity-aware SSH simplifies operations. Eliminating SSH key management across your fleet, authenticating through your existing IdP, and automatically revoking access on offboarding reduces operational overhead.
- Real-time network visibility aids troubleshooting. The Control Center's topological view helps you understand peer connections, group memberships, and policy enforcement without piecing together logs from distributed components.
- EU data residency is a compliance requirement. Berlin headquarters and GDPR-first design provide built-in data sovereignty for organizations with European regulatory obligations.
- Clientless web application access without architectural trade-offs. NetBird's Reverse Proxy exposes internal web applications to the browser without client software, handling TLS termination and optional authentication through the WireGuard mesh — while also providing peer-to-peer connectivity and network-level access that a pure reverse proxy platform cannot.
Pangolin fits best when:
- Simplicity over flexibility is your priority. If your use case is exclusively web application access through a central gateway and you don't need peer-to-peer connectivity, identity-aware SSH, or real-time topology views, Pangolin's focused feature set means fewer moving parts to manage.
- Hub-and-spoke aligns with your network mental model. If you prefer reasoning about network architecture through centralized server coordination rather than distributed peer relationships, Pangolin's Site-based model matches that operational preference.
- Centralized server coordination simplifies compliance. All policy evaluation and traffic routing coordination occurs at the Pangolin server, providing a single audit point for network access decisions rather than distributed policy enforcement across peers.
Neither platform forces you to compromise on open source licensing, self-hosting capabilities, identity provider integration, or posture-based compliance checks. Both now offer clientless web application access, removing what was previously Pangolin's primary differentiator. The remaining distinction is architectural: NetBird's dual-mode flexibility versus Pangolin's focused hub-and-spoke model. Your decision comes down to whether you need the broader connectivity patterns NetBird provides or prefer Pangolin's simpler, single-purpose approach.
