# Pangolin
> Built for IT/OT, IoT, and engineering, provide your users with secure, identity-based remote access to applications and infrastructure. Easy to deploy and scale. Better than your existing VPN.
Link index: https://pangolin.net/llms.txt
## Marketing
### Home
URL: https://pangolin.net/
# The All-in-One Remote Access Platform
The best identity-based remote access, management, and monitoring platform for infrastructure.
## About
Open-source and based on WireGuard®, Pangolin provides unified access to your entire infrastructure. Connect via peer-to-peer tunnels or clientless browser access across on-prem, cloud, and edge environments.
By verifying identity and context at every step, Pangolin delivers secure, zero-trust remote access without the friction of a traditional VPN.
## Features
1. Easy to deploy connector behind any firewall
2. Users connect with their existing identity
3. Zero trust access to specific applications
4. Enforce identity and context aware rules
---
### Product
URL: https://pangolin.net/product
# The Zero Trust Access Platform
Replace your VPN with one fast, secure, and easy to use WireGuard® based solution.
## Your network is complex. Your access shouldn't be.
Deploy zero trust access across your entire stack without touching a single firewall rule.
### Peer-to-peer connections to critical infrastructure
Replace bastions and jump-boxes with simple connections to critical backend infra across cloud VPC, CI/CD, IoT, OT networks and more.
### Seamless web access to internal tools and secure SaaS
Protect your internal dashboards, self-hosted tools, and SaaS apps by keeping them private and off the public internet.
### Granular control and real-time activity auditing
Get a unified view of your security posture, allowing you to enforce strict policies and instantly audit why access was granted or denied.
## Pangolin is better than a VPN.
Organizations of every scale use Pangolin to unify and secure their distributed workforce, devices, and cloud workloads.
- **Identity-based access**: Integrates with your existing identity provider to enable SSO and easy MFA.
- **Direct connectivity**: Peer-to-peer connections between your users and your sites for better performance and reduced latency.
- **App & service exposure**: Expose HTTP apps, TCP services, SSH, databases, and internal APIs with fine-grained controls.
- **Policy & visibility**: Simple, human readable, and context-aware policies you can manage in one place.
## A secure connection users don't hate.
Traditional VPNs and jump-box cause friction for users. Pangolin stays out of the way by automating the identity-connection handshake.
### Sign in with identity
Users authenticate through your IdP with SSO and MFA.
### Connect to resources
Peer-to-peer tunnels reach apps and infra without opening ports.
### Enforce zero trust
Policies decide access in real time with full audit visibility.
## Stop managing networks. Start managing access.
---
### Pricing
URL: https://pangolin.net/pricing
# Pricing
Select Pangolin cloud or self-hosted. Upgrade for more sites, users, enhanced security, and additional features.
## Cloud plans
#### Basic
Free
- Basic Pangolin features
- Up to 5 users
- Custom domains
- Web-based proxy resources
- Private resources and clients
- Peer-to-peer connections
No credit card required.
#### Team
$4/user/mo
- All Basic features +
- External identity providers (IDPs)
- Multiple roles per user (RBAC)
- Audit logging
- Device posture
- Security policy enforcement
Start 10 day free trial.
#### Business
$9/user/mo
- All Team features +
- Multiple organizations
- IDP user auto provisioning
- SSH management
- Device approvals
- Custom branding
Start 10 day free trial.
#### Enterprise
Custom pricing
- All Business features +
- Custom limits
- Log streaming (SIEM)
- User lifecycle management (SCIM)
- Premium relay nodes
- Priority support and SLA
## Self-hosted plans
#### Community
Free (AGPLv3 · community support)
- Open-source Pangolin
- Self-host on your infrastructure
- Community support
#### Starter
$449/yr (that's $37/mo)
- Unlock enterprise features
- Up to 25 users
- Up to 25 sites
- Community support
- Fossorial commercial license
#### Scale
$1249/yr (that's $104/mo)
- All in Starter +
- Up to 50 users
- Up to 100 sites
- Ticket based support
- Fossorial commercial license
#### Enterprise
Custom
- All in Scale +
- Custom limits
- High availability
- Signed priority SLA
- Custom contracts and billing
---
### Contact
URL: https://pangolin.net/contact
# Contact
We'd love to hear from you! Please fill out the form and we'll get back to you as soon as possible.
## Talk to an engineer
Talk to an engineer. Book a call and ask us anything.
---
### Partner With Us — MSP and Reseller Program
URL: https://pangolin.net/partners
Partners
# Unlock new opportunities with Pangolin partnerships
Leverage Pangolin's identity-based remote access platform to enhance your service portfolio and drive significant value for your clients. Built for MSPs, resellers, and technology partners.
## Why partner with Pangolin
MSPs, resellers, and integrators choose Pangolin to deliver zero trust access, grow recurring revenue, and simplify how they serve customers.
### Migrate to zero trust progressively
Start small and scale out. Implement identity-based access iteratively across every customer environment — without a rip-and-replace VPN project.
### Gain advanced security
Connect users to private resources securely. Built on WireGuard, Pangolin brings identity and encryption to the networking layer your clients already need.
### Enjoy seamless integration
Make deployment and management seamless for you and your clients. Pangolin integrates into existing IT environments without heavy infrastructure changes.
### Adopt scalable solutions
Gain consistent performance and reliability whether you manage a growing MSP practice or large enterprise accounts — one platform across your portfolio.
## The partner portal
Manage customers, your brand, and account health from one place — built for how MSPs and resellers run their business.
### Manage every customer organization
Create customer organizations and manage your full portfolio from one portal. Onboard tenants, separate users and policies, and scale without juggling multiple dashboards.
### White-label your offering
Apply your brand colors and upload a custom logo so Pangolin feels like part of your service — not another vendor login your customers have to learn.
### Visibility across your portfolio
See billing status, plan types, and account health at a glance for every customer you manage — so you can stay ahead of renewals and expansion opportunities.
## Partner benefits
What you get when you join the Pangolin partner program.
### Gain additional revenue streams
Drive additional revenue by reselling, referring, and helping customers implement and manage Pangolin.
### Stand out in competitive markets
Elevate your services with a next-generation zero trust access platform that's easy to deploy, use, and manage.
### Access technical resources and support
Get documentation, training, and partner engineering support to deploy Pangolin confidently across customer environments.
### Leverage marketing co-branding
Use Pangolin brand and marketing materials to enhance your credibility and attract new clients.
### Deal registration and protection
Register opportunities to protect your pipeline and receive partner support through the sales cycle.
### Partner portal access
Manage customers, branding, and account visibility from a dedicated portal built for channel partners.
## How to get started
A straightforward path from first conversation to delivering Pangolin to your customers.
### Contact us
Share your goals with our team and learn how Pangolin can enhance your service offerings.
### Review agreement
Review the Pangolin Partner Agreement, then contact us to apply. Fossorial will provide a signing form if approved.
### Train and onboard
Access training resources and hands-on support to ensure you're ready to offer Pangolin solutions.
### Launch and grow
Start delivering Pangolin to your clients and leverage our ongoing support to grow your business.
# Contact the Partner Team
Interested in becoming a Pangolin partner? We would like to hear from you. Please complete our Partner Program application form and we will be in touch.
## Already a partner?
Partner portal
---
### Register a Deal — Partner Program
URL: https://pangolin.net/partners/register-deal
# Register a deal
Submit your opportunity to protect your deal and receive partner support. We'll review your registration and follow up shortly.
Back link: Partner program (/partners)
## Form fields
- Partner company
- Your name
- Work email
- Phone number
- Customer company
- Customer contact email
- Deal description
- Estimated value (optional)
- Expected close date (optional)
## Manage your account in the partner portal
Partner portal
---
## News & Articles
### News & Articles
URL: https://pangolin.net/news
Stay up to date with the latest product updates, guides, and insights in the zero trust remote access space by reading Pangolin's articles.
---
### Pangolin 1.21: Same Network Detection
URL: https://pangolin.net/news/1-21-release
Published: 2026-07-20
Summary: Pangolin 1.21 adds same-network detection for clients and sites, improves share links and access tokens, and tightens the pending sites provisioning workflow.
Category: Product
Pangolin 1.21 is here. This is a smaller release, but it ships a few changes that matter day to day: clients and sites can connect directly when they share a local network, share links and access tokens pick up identity and session options, and the pending sites provisioning flow is more complete. Let's walk through it.
## Release Highlights
### Same Network Detection
When a Pangolin client and a site are already on the same local network, there is little reason for that traffic to leave the LAN and bounce through a relay. 1.21 adds same-network detection so those peers find each other on the LAN and form a direct peer-to-peer connection.
Packets stay on the local network. They are not routed out through the internet or your Pangolin server, and the connection skips the relay path. That usually means lower latency and less unnecessary egress through your router or ISP, which is especially useful when someone is on-site with the client while the site connector is already on that same network.
This requires updated clients and sites. Older versions will keep using the previous connection behavior.
Read more about [same-network detection and NAT traversal](https://docs.pangolin.net/manage/clients/nat-traversal) in the docs.
### Pending Sites and Provisioning
Site provisioning keys already let you ship connectors into a pending state for admin review before they go live. 1.21 extends that workflow to the resources those sites create.
When a site is pending, resources created for it from a provisioning blueprint are pending too. Pending resources stay hidden from the main resources table and are disabled by default, so end users cannot reach them while the site is still waiting for approval. Admins can still inspect and edit those resources from the site itself: open Resources on the site row, or use the site edit page. That makes it possible to review configuration, temporarily enable a resource, and verify access before promoting the whole setup.
Approving a pending site clears the pending state on its associated resources and enables them together. Rejecting a pending site deletes those pending resources along with the site, so a rejected provisioning run does not leave orphaned resource records behind.
Read more about [site provisioning and pending sites](https://docs.pangolin.net/manage/sites/site-provisioning) in the docs.
### Share Links and Access Tokens
Share links have always had a quieter counterpart: access tokens. Every share link is backed by an access token under the hood. When you create a share link, you can see the access token ID and value and pass them via a query parameter or headers for programmatic access to a resource. That pattern has been available for a while.
1.21 adds two improvements on top of that.
First, a share link can now be associated with a specific account user. When that link or access token is used, the associated user shows up in the logs, and Pangolin attaches the `Remote-*` user headers with that identity so upstream apps can treat the request as coming from a real user.
Second, you can enable persistent sessions on an access token. When the token is passed via a query parameter or header, Pangolin can exchange it for a session cookie so you do not have to attach the token on every subsequent request. Previously, access tokens behaved more like API keys and had to be included on each call.
Read more about [shareable links and access tokens](https://docs.pangolin.net/manage/access-control/links) in the docs.
### General Improvements and Bug Fixes
A few smaller additions made it into 1.21 as well:
1. **Enabled toggle for private resources**. Private resources can now be enabled or disabled without deleting them, including via blueprints.
2. **Remember last used identity provider**. Pangolin remembers the last IdP you used and marks it accordingly on the login page.
As always, this release also includes various UI improvements and bug fixes throughout the product.
---
### Pangolin 1.20: Resource Launcher & Global Command Palette
URL: https://pangolin.net/news/1-20-release
Published: 2026-07-08
Summary: Pangolin 1.20 rebuilds the Resource Launcher with saved views, grouping, and filtering, and adds a global command palette for administrators.
Category: Product
Pangolin 1.20 is here. This release focuses on how people actually find and reach their resources: a rebuilt Resource Launcher for everyday users, a command palette for administrators, and a cleaner private resource workflow across the dashboard. Let's walk through it.
## Release Highlights
### Resource Launcher
The Resource Launcher is the landing page non-administrators see when they sign in. It was always meant to be a quick way to find and open the resources you have access to, but the old version was limited. You could see what was available, but not much beyond that.
The new Resource Launcher is available to both non-administrators and administrators, and it's built to scale with how your organization actually works. Resources are grouped by site or label, searchable, and filterable. Switch between grid and list view depending on what you're looking at. Collapse site sections you don't need and focus on the ones that matter.
Saved views are the other big piece. A saved view captures your full launcher configuration: which filters are active, how resources are grouped, whether you're in grid or list mode, and anything else you've set on the page. Save it as your personal default, or save it as a named view you can switch between from the tabs at the top.
Administrators can save views for everyone in the organization, set the organization-wide default, and still maintain their own personal views on top of that. Non-administrators can save views for themselves. The result is a launcher that works as a reusable starting point, whether you're an admin curating a page for a team or an end user who wants a quick way back to the same handful of sites every morning.
### Command Palette
Administrators now get a global command palette. Press **⌘K** (or **Ctrl+K** on Windows) from anywhere in the dashboard to open it.
The palette is a single search surface for navigation and discovery. Type a page name to jump straight to Sites, Users, Roles, or anywhere else in the dashboard. Search for a resource or site by name and the palette surfaces matching public resources, private resources, and sites. Select a result and you're there.
If you manage a large deployment, this cuts down on clicking through the sidebar to find the thing you already know the name of. Need the Atlanta retail POS resource? Search for it. Need to get to the Sites page? Same palette.
### Private Resource Pages
Private resources now follow the same page-based patterns as the rest of the dashboard. Previously, creating and editing a private resource happened in a pop-up modal. That worked at small scale, but it felt out of step with how public resources, sites, and other entities are managed elsewhere.
Create and edit private resources on dedicated pages now, with the same layout and navigation you're used to from other parts of Pangolin. No screenshot for this one, but if you've been managing private resources for a while, you'll notice the difference immediately.
### General Improvements and Bug Fixes
As always, 1.20 also includes various UI improvements and bug fixes throughout the product.
### Community Edition & VNC
[Labels](/news/1-19-release), introduced in Pangolin 1.19, have moved from Enterprise Edition to Community Edition.
VNC connections now include a username field in addition to the password. Previously, only a password was required. That improves compatibility with a wider range of VNC servers, including the built-in macOS VNC server.
---
### RDP in the Browser: Remote Desktop Without Installing a Client
URL: https://pangolin.net/news/browser-based-rdp-remote-access
Published: 2026-06-14
Summary: Access Windows desktops through a full RDP session rendered in the browser, with clipboard, file transfer, and standard RDP features. Users need only a web browser on their side.
Category: Guides
Remote desktop access usually means installing something. Microsoft Remote Desktop on macOS, a third-party tool for cross-platform support, or a managed client pushed through IT. Contractors on personal laptops, helpdesk staff on shared machines, and anyone working from a browser-only environment hit the same wall. You need software before you can see the desktop.
In-browser RDP removes that step. The user opens a URL, authenticates, and gets a full Windows session rendered in the tab, with clipboard, file transfers, and the rest of standard RDP behavior included. A modern web browser is the only thing required on their side.
## What You Get
Pangolin lets you publish Windows desktops as **public resources**: URLs that render a complete Remote Desktop Protocol client in the browser. Users visit the address, sign in, and connect to a Windows host on your network. The session supports interactive desktop control, clipboard copy and paste, and file transfer.
## Why Tunneling Matters
Windows machines on a private network are not directly reachable from a user's browser on the internet. Traditional approaches expose RDP through a VPN, a jump host, or open firewall rules. Each adds operational overhead and widens the attack surface.
Pangolin uses **outbound tunneling** to reach private desktops safely. A **site connector** runs on a machine inside your network and maintains an outbound tunnel to Pangolin. When a user opens the RDP URL, their browser session travels through that tunnel to the Windows host. The desktop stays on the private network; nothing needs a public IP or an open inbound port.
The connector only needs outbound internet access, which is why this pattern works from cloud VPCs, office networks, and environments behind NAT. It does not need to run on the Windows machine itself. As long as it is on the same network and can reach the desktop, one connector can serve many machines. Install a second connector on the same network if you want a redundant route for high availability. Read more about [sites and connectors](https://docs.pangolin.net/manage/sites/understanding-sites) and [installing a site connector](https://docs.pangolin.net/manage/sites/install-site).
## How a Session Works
1. You assign a URL to the RDP resource in the Pangolin dashboard.
2. The user completes [public resource authentication](https://docs.pangolin.net/manage/resources/public/authentication) in the browser.
3. Pangolin renders the RDP session and sends traffic through the site connector tunnel to the Windows host on port 3389 (or the port you configure).
You specify which Windows machine to connect to (host and port).
## Authentication and Identity Providers
Access is gated in two stages. First, Pangolin verifies the user at the URL: platform login, SSO through an [identity provider](https://docs.pangolin.net/manage/identity-providers/add-an-idp) like Google Workspace or Microsoft Entra ID, geo-blocking, role assignments, or other [access rules](https://docs.pangolin.net/manage/resources/public/authentication) you configure.
Second, after passing that check, the user enters their Windows username and password in the browser-rendered RDP client. Pangolin controls who can reach the URL; Windows credentials control what they can do on the desktop.
Connecting your existing IdP means helpdesk staff and contractors sign in with the same accounts they already use elsewhere in the organization.
## When Browser-Based RDP Fits
This pattern works well when you need to give someone desktop access without pushing client software. Helpdesk troubleshooting a user's machine, a vendor supporting an application on a Windows server, or a contractor who cannot install Remote Desktop on a corporate-managed laptop are all common cases where a URL is easier than a client deployment.
For organizations that have relied on standalone remote-desktop tools for occasional access, clientless RDP through a managed HTTPS endpoint is a practical [TeamViewer alternative](https://docs.pangolin.net/manage/resources/public/rdp): browser-based remote desktop with outbound tunneling and identity-aware access rules, rather than a separate agent on every machine.
## FAQ
**What is browser-based RDP?**
*Browser-based RDP renders a full Windows remote desktop session inside a web browser. Users visit a URL, authenticate, and interact with the desktop directly in the tab. Clipboard, file transfer, and standard RDP features work without installing Microsoft Remote Desktop or another client.*
**Do users need Microsoft Remote Desktop or another RDP client installed?**
*Users only need a modern web browser. Pangolin renders a full RDP session in the tab, including clipboard support and file transfer. Windows credentials are entered in the browser-rendered client after Pangolin authentication.*
**Do I need to expose RDP port 3389 to the internet?**
*The Windows desktop stays on your private network. A site connector inside that network maintains an outbound tunnel to Pangolin, so inbound firewall rules and a public IP on the desktop are unnecessary.*
**How does authentication work for browser-based RDP?**
*Pangolin verifies the user at the URL first through platform login, SSO via an [identity provider](https://docs.pangolin.net/manage/identity-providers/add-an-idp), or other [access rules](https://docs.pangolin.net/manage/resources/public/authentication). After that check passes, the user enters their Windows username and password in the browser-rendered RDP client.*
**Does browser-based RDP support clipboard and file transfer?**
*Yes. Pangolin renders a full RDP client in the browser with interactive desktop control, clipboard copy and paste, and file transfer, matching the features you would expect from a native Remote Desktop client.*
**Can contractors use browser-based RDP on locked-down laptops?**
*Yes. Because the session runs entirely in a browser, contractors and vendors do not need to install Remote Desktop or receive admin rights on their machine. You control access through Pangolin authentication, identity providers, and access rules at the URL layer.*
**Is Pangolin open source?**
*Yes. Pangolin is open source and self-hostable. You can deploy the entire platform yourself, use [Pangolin Cloud](https://app.pangolin.net/auth/signup), or mix hosted and self-hosted components. Browser-based RDP is available in Pangolin Cloud and Enterprise Edition.*
**How does browser-based RDP compare to TeamViewer?**
*TeamViewer installs an agent on the remote machine and a client on the user's device. Pangolin takes a different approach: users open a URL, authenticate through your identity layer, and get a desktop session in the browser. The Windows host stays on your private network, reached through an outbound tunnel from a site connector rather than a persistent third-party agent.*
## See Also
- [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin): browser and private CLI access, PAM provisioning, and getting started
- [SSH in the Browser](/news/browser-based-ssh-remote-access): web-based terminal access without an SSH client
- [VNC in the Browser](/news/browser-based-vnc-remote-access): remote display access without a viewer
- [How Pangolin Works](/news/how-pangolin-works): architecture overview for sites, resources, and policy
- [Pangolin 1.19 release](/news/1-19-release): where browser-based SSH, RDP, and VNC shipped
- [RDP public resource documentation](https://docs.pangolin.net/manage/resources/public/rdp)
---
### SSH in the Browser: Web-Based Terminal Access Without a Client
URL: https://pangolin.net/news/browser-based-ssh-remote-access
Published: 2026-06-14
Summary: Run a full SSH session in any modern browser. Users connect with a URL and authentication, without installing an SSH client, VPN, or desktop app.
Category: Guides
Most teams still reach servers the old-fashioned way: install an SSH client, distribute keys, maybe route through a bastion, and hope the person connecting has the right config on their laptop. That works fine for engineers who live in a terminal. It is less ideal for occasional access, contractors on locked-down machines, or anyone who just needs to run a few commands without setting up tooling first.
Browser-based SSH sidesteps that friction. Instead of opening PuTTY or a local terminal, the user visits a URL, completes authentication, and gets a full interactive shell rendered in the tab. Everything happens in the browser, so there is nothing to install on the user's side.
## What You Get
With Pangolin, you publish SSH as a **public resource**: a URL that renders a real terminal in the browser. Users visit that address, sign in, and land in a session on a host in your network. Depending on configuration, they may enter a second set of credentials (password, key, or platform identity) or proceed directly into the shell.
## Why Tunneling Matters
Private servers are not usually reachable from the public internet. Opening SSH to the world creates an attack surface most teams want to avoid.
Pangolin uses **outbound tunneling** instead. You install a lightweight **site connector** on a machine inside your network (an office LAN, cloud VPC, data center, or home lab). The connector initiates an outbound tunnel to Pangolin and stays connected. When a user opens the SSH URL in their browser, Pangolin routes the session through that tunnel to the target host.
The target machine stays private. You do not need to open inbound firewall ports or assign it a public IP. The site connector only needs outbound internet access, which makes this work from behind NAT and typical corporate firewalls.
The connector does not need to run on every server you want to reach. As long as it sits on the same network and can route to your SSH hosts, one connector can serve many machines. For high availability, install a second connector on the same network as a redundant path. Learn more about [how sites and connectors work](https://docs.pangolin.net/manage/sites/understanding-sites).
## How a Session Works
1. You assign a URL to the SSH resource in the Pangolin dashboard.
2. The user opens that URL and completes [public resource authentication](https://docs.pangolin.net/manage/resources/public/authentication).
3. Pangolin renders the terminal and sends traffic through the site connector tunnel to the backend host.
You point the resource at the SSH server you want to reach (host and port).
## Authentication and Identity Providers
Before the terminal loads, Pangolin checks who is connecting. You can require a platform login, connect an [identity provider](https://docs.pangolin.net/manage/identity-providers/add-an-idp) such as Google Workspace or Microsoft Entra ID for SSO, and apply access rules based on user, role, or context (geo-blocking, time windows, and more). These checks happen at the URL layer, before any SSH session begins.
If you already use an IdP for workforce access, the same identity store can gate your SSH URLs. See [public resource authentication](https://docs.pangolin.net/manage/resources/public/authentication) for the full set of options.
## Setup in Brief
Install a [site connector](https://docs.pangolin.net/manage/sites/install-site) on a host that can reach your network, create the SSH public resource, and assign it a URL. Pangolin can run sessions directly on the connector host or route to another SSH server on the network. Configuration options for both paths are covered in the [how to SSH with Pangolin guide](/news/how-to-ssh-with-pangolin) and the [SSH access docs](https://docs.pangolin.net/manage/ssh).
## Practical Notes
Browser-based SSH uses the same identity and policy framework as other public resources, so you manage access consistently across web apps, terminals, and remote desktops.
It also works on phones and tablets. A web-based terminal in mobile Safari or Chrome is enough to check logs, restart a service, or run `htop` from the couch. A dedicated SSH app is not required.
If you have been evaluating standalone web gateways for terminal access, Pangolin covers similar ground as an [Apache Guacamole alternative](https://docs.pangolin.net/manage/resources/public/ssh): in-browser SSH with outbound tunneling and identity-aware access rules, rather than a separate gateway to deploy and maintain.
## FAQ
**What is browser-based SSH?**
*Browser-based SSH renders a full interactive terminal in a web browser. Instead of installing an SSH client, users visit a URL, authenticate, and get a shell session on a remote host. The session is proxied through an outbound tunnel from a site connector on your network.*
**Do I need an SSH client like PuTTY or OpenSSH to connect through the browser?**
*Users only need a modern web browser. Pangolin renders a full interactive terminal at a public URL after authentication. The SSH session is proxied through a site connector to the backend host.*
**Do I need to open SSH ports on my firewall for browser-based access?**
*The SSH host stays on your private network. A site connector inside that network maintains an outbound tunnel to Pangolin, so you do not need to expose port 22 to the internet or assign the server a public IP.*
**How does authentication work for browser-based SSH?**
*Access is checked in two stages depending on configuration. First, the user passes Pangolin authentication at the URL: platform login, SSO through an [identity provider](https://docs.pangolin.net/manage/identity-providers/add-an-idp), or other [access rules](https://docs.pangolin.net/manage/resources/public/authentication). Second, they may enter SSH credentials (password, key, or platform identity) before the terminal loads.*
**Can one site connector reach multiple SSH servers?**
*Yes. The site connector only needs to sit on the same network as the servers you want to reach. One connector can serve many hosts. Install a second connector on the same network for a redundant path.*
**Can I use browser-based SSH on a phone or tablet?**
*Yes. Any modern mobile browser can render the terminal. This is useful for quick checks like reading logs, restarting a service, or running monitoring tools from a phone.*
**Is Pangolin open source?**
*Yes. Pangolin is open source and self-hostable. You can run the full platform yourself, use [Pangolin Cloud](https://app.pangolin.net/auth/signup), or combine a hosted control plane with self-hosted components. Browser-based SSH is available in Pangolin Cloud and Enterprise Edition.*
**What is a good Apache Guacamole alternative for browser-based SSH?**
*Apache Guacamole provides in-browser access to SSH, RDP, and VNC through a standalone gateway. Pangolin offers similar clientless terminal access as part of a broader remote access platform, with outbound tunneling through site connectors, identity provider integration, and unified management alongside web apps and other protocols.*
## See Also
- [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin): browser and private CLI access, PAM provisioning, and getting started
- [RDP in the Browser](/news/browser-based-rdp-remote-access): remote desktop without installing a client
- [VNC in the Browser](/news/browser-based-vnc-remote-access): remote display access without a viewer
- [How Pangolin Works](/news/how-pangolin-works): architecture overview for sites, resources, and policy
- [Pangolin 1.19 release](/news/1-19-release): where browser-based SSH, RDP, and VNC shipped
- [SSH public resource documentation](https://docs.pangolin.net/manage/resources/public/ssh)
---
### VNC in the Browser: Remote Display Access Without a Viewer
URL: https://pangolin.net/news/browser-based-vnc-remote-access
Published: 2026-06-14
Summary: View and control remote displays through a VNC session in your browser. Users connect with a URL instead of installing a standalone VNC viewer or VPN client.
Category: Guides
VNC has been around long enough that most people assume you need a viewer. RealVNC, TigerVNC, TightVNC: pick one, install it, configure the connection, and hope the firewall rules cooperate. That is manageable for a team that lives with VNC daily. It is less manageable when the person connecting is a contractor, a field technician, or someone who needs to reach a headless box or industrial UI once and move on.
Web-based VNC changes the starting point. Instead of distributing viewer software, you give the user a URL. They authenticate, and the remote display renders in the browser. The user's machine only needs a web browser.
## What You Get
Pangolin lets you publish VNC displays as **public resources**: URLs that render a full VNC client in the browser. Users visit the address, sign in, and get an interactive remote display session on a host in your network.
## Why Tunneling Matters
VNC servers typically listen on a private network. Exposing them directly to the internet is risky, and many environments simply cannot open the required ports.
Pangolin uses **outbound tunneling** to bridge that gap. A **site connector** installed on a machine inside your network maintains an outbound tunnel to Pangolin. When a user opens the VNC URL, their browser session travels through that tunnel to the VNC server. The display stays on the private network without inbound firewall rules or a public IP.
The connector only needs outbound internet access, which makes this workable from industrial networks, cloud environments, and sites behind NAT. It does not need to run on the same machine as the VNC server. As long as it is on the same network and can reach the display, one connector can serve many hosts. A second connector on the same network gives you a redundant path for high availability. Learn more in the [sites overview](https://docs.pangolin.net/manage/sites/understanding-sites).
## How a Session Works
1. You assign a URL to the VNC resource in the Pangolin dashboard.
2. The user completes [public resource authentication](https://docs.pangolin.net/manage/resources/public/authentication) in the browser.
3. Pangolin renders the VNC session and sends traffic through the site connector tunnel to the VNC server.
You specify the VNC server host and port (commonly `5900`, or `5900 + display number` for multi-display setups).
If the VNC server requires credentials, the user enters them in the browser-rendered client after passing Pangolin authentication.
## Authentication and Identity Providers
VNC public resources support the same [authentication and access rules](https://docs.pangolin.net/manage/resources/public/authentication) as other public resources. You can require platform login, connect an [identity provider](https://docs.pangolin.net/manage/identity-providers/add-an-idp) for SSO with Google Workspace, Microsoft Entra ID, or any OAuth2/OIDC system, and apply rules based on user, role, or context.
That means a contractor who should only reach one display gets a URL with rules attached, rather than broad network access. The identity layer that protects your web apps and SSH terminals applies to VNC as well.
## Unified Protocol Management
One practical advantage of running VNC alongside SSH and RDP as public resources is that everything lives in the same dashboard. You manage your VNC resources next to your SSH terminals and RDP desktops in one place. For a full overview of SSH setup, including browser and private CLI paths, see [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin).
If you have been running a separate web gateway for protocol access, Pangolin handles SSH, RDP, and VNC together. That is an alternative to RealVNC or TigerVNC viewers for day-to-day access, and a simpler operational model than maintaining a dedicated [Guacamole alternative](https://docs.pangolin.net/manage/resources/public/vnc) as a standalone deployment. To get started, [install a site connector](https://docs.pangolin.net/manage/sites/install-site) on a host that can reach your VNC server.
## FAQ
**What is browser-based VNC?**
*Browser-based VNC renders a remote display inside a web browser. Instead of installing a VNC viewer, users visit a URL, authenticate, and view and control the remote screen directly in the tab. The session is proxied through an outbound tunnel from a site connector on your network.*
**Do I need a VNC viewer like RealVNC or TigerVNC to connect through the browser?**
*Users only need a modern web browser. Pangolin renders a full VNC client at a public URL. If the VNC server requires credentials, the user enters them in the browser after passing Pangolin authentication.*
**What port does VNC typically use?**
*VNC servers commonly listen on port 5900, or 5900 plus the display number for multi-display setups (5901 for display :1, and so on). You configure the host and port when creating the VNC public resource in Pangolin.*
**Do I need to expose VNC to the internet for remote access?**
*The VNC server stays on your private network. A site connector inside that network maintains an outbound tunnel to Pangolin, so you do not need to open inbound firewall ports or assign the server a public IP.*
**When is browser-based VNC a better fit than SSH?**
*SSH gives you a text terminal, which is ideal for servers and command-line work. VNC gives you a graphical remote display, which is better for headless boxes with a desktop environment, industrial HMIs, legacy applications with a GUI, or any system where you need to see and interact with a screen rather than a shell.*
**Does the site connector need to run on the same machine as the VNC server?**
*The site connector only needs to be on the same network and able to reach the VNC server. One connector can serve many hosts on that network. Install a second connector on the same network if you want a redundant path for high availability.*
**Can I manage SSH, RDP, and VNC resources in one dashboard?**
*Yes. Pangolin treats SSH, RDP, and VNC as public resources alongside your web applications. You manage them in the same dashboard, apply shared access policies, and monitor health from one place.*
**Is Pangolin open source?**
*Yes. Pangolin is open source and self-hostable. You can run the full platform on your own infrastructure, use [Pangolin Cloud](https://app.pangolin.net/auth/signup), or combine both. Browser-based VNC is available in Pangolin Cloud and Enterprise Edition.*
**What is a good Apache Guacamole alternative for browser-based VNC?**
*Apache Guacamole provides in-browser VNC, SSH, and RDP through a dedicated gateway you deploy and manage. Pangolin offers clientless VNC access as part of a unified platform with site connectors, identity provider integration, and shared access policies across web apps, terminals, and remote desktops.*
## See Also
- [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin): browser and private CLI access, PAM provisioning, and getting started
- [SSH in the Browser](/news/browser-based-ssh-remote-access): web-based terminal access without an SSH client
- [RDP in the Browser](/news/browser-based-rdp-remote-access): remote desktop without installing a client
- [How Pangolin Works](/news/how-pangolin-works): architecture overview for sites, resources, and policy
- [Pangolin 1.19 release](/news/1-19-release): where browser-based SSH, RDP, and VNC shipped
- [VNC public resource documentation](https://docs.pangolin.net/manage/resources/public/vnc)
---
### How to SSH with Pangolin: Browser Access and Private CLI
URL: https://pangolin.net/news/how-to-ssh-with-pangolin
Published: 2026-06-14
Summary: SSH to private servers through Pangolin with a browser terminal or private CLI over a scoped tunnel. Automatic user provisioning via PAM, without opening port 22 or distributing static keys.
Category: Guides
SSH is still how most teams reach servers, but the workflow around it has not kept up. You install a client, distribute keys, maybe route through a bastion, or connect a VPN that reaches far beyond the one host you need. Pangolin offers a different path: reach private infrastructure without exposing SSH publicly, with identity and policy enforced before anyone gets a shell.
You can connect in two ways. Use a **browser terminal** at a URL for clientless access, or use the **Pangolin CLI** over a peer-to-peer connection for a VPN-style workflow scoped to specific hosts. Both paths use the same site connector and policy model. The difference is how traffic flows and how users authenticate on the way in.
## Two Ways to Connect
| | In the Browser | Private CLI (VPN-Style) |
| --- | --- | --- |
| **Who it's for** | Contractors, on-call from any device, locked-down laptops | Engineers who live in a terminal |
| **How users connect** | Visit a URL, sign in, get a web terminal | Install the Pangolin client, run `pangolin ssh ` |
| **Client required** | Web browser only | Pangolin client and CLI |
| **Access layer** | Login page, SSO, and access rules at the URL | Identity from the peer-to-peer connection plus resource policy |
**In the browser:** Pangolin renders a full interactive terminal at a public URL. Users complete authentication in the tab and land in a session on a host in your network. See the [public SSH documentation](https://docs.pangolin.net/manage/resources/public/ssh) for configuration details.
**Private CLI:** Users connect with the Pangolin client, then run `pangolin ssh ` to open a session over a peer-to-peer WireGuard path to the site. Access is scoped to authorized resources rather than the whole network. See the [private SSH documentation](https://docs.pangolin.net/manage/resources/private/ssh).
## How Pangolin Reaches Your Servers
Private servers are usually unreachable from the public internet. Opening SSH to the world creates an attack surface most teams want to avoid. Pangolin keeps hosts on your private network and uses two different connectivity models depending on how users connect.
**Public resources (browser SSH)** use **outbound tunneling**. You install a lightweight **site connector** on a machine inside your network. The connector initiates an outbound tunnel to Pangolin and stays connected. When a user opens a browser terminal, Pangolin routes the session through that tunnel to the target host. The connector only needs outbound internet access, which makes this work from behind NAT and typical corporate firewalls.
**Private resources (CLI SSH)** use a **peer-to-peer connection**. The user runs the Pangolin client, which establishes a direct WireGuard path to the site connector on the network. Pangolin [punches through NATs and firewalls](/news/nat-holepunching) to build that link without opening inbound ports. SSH traffic travels over the peer-to-peer path to authorized hosts. It works like a scoped VPN: users reach only the resources they are allowed to access, not the full corporate network.
In both cases, the target machine stays private. You do not need to open inbound firewall ports on the SSH host or assign it a public IP.
One connector on a network can reach many SSH hosts, as long as it can route to them. For high availability, install a second connector on the same network as a redundant path.
## Getting Started: The Default Path
Pangolin 1.19 made SSH dramatically easier to set up. The dashboard now defaults to **Pangolin SSH** mode with **manual authentication**, which works out of the box for most teams.
1. Create a [Pangolin Cloud](https://app.pangolin.net/auth/signup) account or use your self-hosted control plane.
2. [Install a site connector](https://docs.pangolin.net/manage/sites/install-site) on the machine you want to reach. For Pangolin SSH mode, run the connector as root on that host.
3. Create an SSH resource in the dashboard. Choose a **public resource** for browser access or a **private resource** for CLI access.
4. Connect. For browser access, visit the resource URL. For CLI access, run `pangolin up` and then `pangolin ssh `.
With these defaults, users authenticate with credentials that already exist on the host. There is nothing to change in `sshd_config` and nothing extra to install beyond the site connector.
For private CLI access, the workflow looks like this:
```shell
pangolin ssh prod-app.internal
```
You can also copy files over the same peer-to-peer connection:
```shell
pangolin scp ./config.yml prod-app.internal:/etc/app/
```
## Automatic User Provisioning with PAM
Manual credentials work for many setups, but teams managing dozens of servers often want something better: access tied to organization identity, with accounts created on demand instead of pre-staged on every machine.
When you enable **automated provisioning**, Pangolin creates or updates the Linux user account just before the session starts. Your organization identity maps to a local username, derived from the part of your email before the `@`. If that name is already taken, Pangolin adds a numeric suffix until it is unique. Roles control sudo level, Unix groups, and home directory setup, so permissions follow the same lifecycle as your workforce identity.
This happens automatically through **PAM** (Privileged Access Management). PAM is the mechanism that **pushes the user onto the host at login time**. Pangolin provisions the account, home directory, and group membership before the shell opens. You skip manual account creation across a fleet of servers.
With **Pangolin SSH** and automated provisioning, this works without reconfiguring OpenSSH. Run the site connector as root and switch authentication to automated provisioning in the dashboard.
With **Standard SSH Server** mode, which routes to an existing OpenSSH host on the network, provisioning still uses PAM but requires additional host setup. That path is common when the site connector sits on a bastion and reaches multiple servers behind it. The [SSH access documentation](https://docs.pangolin.net/manage/ssh) covers each configuration combination.
For Standard SSH Server mode with automated provisioning, Pangolin also issues **short-lived SSH certificates** valid for five minutes. That window is enough to establish the session, but short enough that a compromised credential has limited value. Once the session is open, it can stay connected. Access revocation happens through Pangolin policy rather than hunting down static keys on individual servers.
## Browser SSH in Practice
Browser SSH is built for people who need shell access without installing anything. A contractor on a managed laptop, an operator checking logs from a phone, or an admin running a quick command from a machine where they cannot install PuTTY or OpenSSH.
The user visits the resource URL, passes Pangolin authentication (platform login, SSO, or access rules), and may enter a second set of host credentials depending on configuration. Pangolin renders a full terminal in the tab and routes the session through the site connector's outbound tunnel.
For a deeper look at browser-based terminal access, including mobile use and identity provider integration, see [SSH in the Browser](/news/browser-based-ssh-remote-access).
## Private CLI in Practice
Private CLI access works like a scoped VPN for SSH. The user installs the Pangolin client, connects with `pangolin up`, and establishes a peer-to-peer WireGuard path to the site. From there, they reach only the hosts they are authorized to access. SSH traffic travels over that direct connection, not across the full corporate network.
This fits engineers who prefer a local terminal, use SSH daily, and want file transfer with `pangolin scp`. The Pangolin desktop app can provide the tunnel while the CLI handles the SSH session itself.
Grant access through resource policy and ensure TCP 22 is allowed in port restrictions for private resources. Pangolin checks identity from the active client connection before the session starts.
## When You Need the Advanced Path
**Standard SSH Server** mode is there when Pangolin SSH mode is not the right fit. Use it to reach an existing OpenSSH host elsewhere on the network, connect to legacy infrastructure that already runs its own SSH server, or set up a bastion pattern where one site connector reaches many target machines.
That path can involve certificate authorities, auth daemon placement, and `sshd_config` changes on target hosts. It is powerful for multi-server environments, but it is also more setup than the default. The [SSH access documentation](https://docs.pangolin.net/manage/ssh) walks through each valid configuration.
## Why Teams Choose This Over Traditional SSH
* **Identity-tied access.** Permissions follow organization identity and resource policy, not scattered static keys that outlive the people who issued them.
* **Scoped connectivity.** Browser SSH routes through an outbound tunnel; private CLI connects peer-to-peer to the site. Users reach specific authorized hosts instead of inheriting broad network access from a VPN.
* **Just-in-time users.** PAM pushes accounts onto hosts at login time, so you are not pre-provisioning users across every server in the fleet.
* **Browser option for occasional access.** Engineers use the CLI; everyone else gets a URL and a terminal in the tab.
For the broader case for modernizing SSH across an organization, see [Modernizing Enterprise SSH Access](/news/modernizing-enterprise-ssh-access).
## FAQ
**How do I SSH with Pangolin?**
*Install a site connector on a host inside your network, create an SSH resource in the Pangolin dashboard, and connect. For browser access, visit the resource URL and sign in. For CLI access, connect with the Pangolin client and run `pangolin ssh `.*
**Can I SSH from a browser without installing an SSH client?**
*Yes. Pangolin renders a full interactive terminal at a public URL. Users visit the address, complete authentication, and get a shell session on a remote host. Only a modern web browser is required on the user's machine.*
**Do I need a VPN to SSH with Pangolin?**
*A traditional VPN is not required. Public SSH routes through an outbound tunnel from a site connector inside your network. Private CLI access uses the Pangolin client to establish a peer-to-peer WireGuard path to the site, scoped to authorized hosts rather than the full network.*
**What is the difference between public and private SSH in Pangolin?**
*Public SSH renders a terminal in the browser at a URL and routes traffic through the site connector's outbound tunnel. Users authenticate at the URL layer with login, SSO, or access rules. Private SSH uses the Pangolin CLI over a peer-to-peer WireGuard connection: users run `pangolin ssh ` after connecting with the Pangolin client. Both use the same SSH configuration in the dashboard; the difference is connectivity model, how users connect, and which authentication layer gates access first.*
**How does Pangolin automatically create users on Linux servers?**
*When automated provisioning is enabled, Pangolin maps your organization identity to a local Linux username and creates or updates the account just before the session starts. Roles control sudo level, Unix groups, and home directory setup. With Pangolin SSH mode, this works through the site connector without reconfiguring OpenSSH.*
**What is PAM in Pangolin SSH?**
*PAM stands for Privileged Access Management. Pangolin uses PAM to push users onto the host at login time: creating the account, home directory, and group membership before the shell opens. This is how just-in-time user provisioning works across your fleet.*
**Do I need to open port 22 on my firewall?**
*For browser SSH, a site connector maintains an outbound tunnel to Pangolin, so you do not need to expose port 22 to the internet or assign the server a public IP. For private CLI access, the Pangolin client connects peer-to-peer to the site over WireGuard. TCP 22 must be allowed in the resource's port restrictions so SSH can reach the target host over that path.*
**Do I need to edit sshd_config to use Pangolin SSH?**
*Not for the default setup. Pangolin SSH mode with manual authentication works without OpenSSH reconfiguration. If you use Standard SSH Server mode with automated provisioning, the target host's SSH server needs additional configuration. See the [SSH access documentation](https://docs.pangolin.net/manage/ssh) for that path.*
**How long are Pangolin SSH credentials valid?**
*In Standard SSH Server mode with automated provisioning, SSH certificates are valid for five minutes from the moment they are issued. That is enough time to establish the connection. Once the session is open, it can stay connected. Pangolin SSH mode uses its own authentication layer rather than short-lived SSH certificates.*
**Can I copy files over Pangolin SSH?**
*Yes. The Pangolin CLI supports `pangolin scp` for copying files over the same peer-to-peer connection used by `pangolin ssh`. For example: `pangolin scp ./config.yml prod-app.internal:/etc/app/`.*
## See Also
- [How Pangolin Punches Through NATs and Firewalls](/news/nat-holepunching): how peer-to-peer connections work across NAT and firewalls
- [SSH in the Browser](/news/browser-based-ssh-remote-access): web-based terminal access without a client
- [Pangolin 1.19 release](/news/1-19-release): where browser SSH and simplified Pangolin SSH mode shipped
- [How Pangolin Works](/news/how-pangolin-works): architecture overview for sites, resources, and policy
- [SSH access documentation](https://docs.pangolin.net/manage/ssh): full configuration reference
---
### Pangolin 1.19: Browser Remote Access — SSH, RDP, VNC & More
URL: https://pangolin.net/news/1-19-release
Published: 2026-06-11
Summary: Pangolin 1.19 adds browser-based remote access with SSH, RDP, and VNC in the browser, a simpler Pangolin SSH mode, automatic site updates, labels, and resource policies.
Category: Product
Pangolin 1.19 is here. This release brings browser-based remote access to SSH, RDP, and VNC, makes Pangolin SSH dramatically easier to set up, adds automatic updates for site connectors, and ships a handful of organizational improvements that make large deployments easier to manage. Let's walk through it.
## Release highlights
### SSH, RDP, and VNC in the Browser
You no longer need a separate SSH client, remote desktop app, or VNC viewer to reach your infrastructure. Pangolin now supports web-based remote access over SSH, RDP, and VNC as first-class public resource protocols. Assign a domain, point it at a site connector, and users get a full interactive session in any modern browser after completing Pangolin authentication.
For SSH in the browser, that means a real web-based terminal with password, key, or Pangolin identity authentication, depending on how you configure the resource. For RDP in the browser, users get a full Windows remote desktop with clipboard support and file transfers. No Remote Desktop client to install. For browser-based VNC, a remote display rendered right in the tab. No Pangolin client or VPN is required on the user's machine.
This uses the same site-resource model as your HTTP resources. You don't need to run a Pangolin site connector on the target machine. Install Newt on a host that can reach your network, select which sites can route to the resource, and point it at any SSH server, Windows box, or VNC display on that network, just like you've always done with HTTPS.
Each protocol gets its own public FQDN, and you manage your SSH, RDP, and VNC remote access resources alongside your other public resources in one place. Identity-aware access rules, SSO, and geo-blocking apply the same way they do for HTTP.
This makes Pangolin an **Apache Guacamole alternative** for browser-based remote access over SSH, RDP, and VNC with site tunneling built in and stronger authentication support through SSO, identity providers, and granular access rules.
Read more about [SSH](https://docs.pangolin.net/manage/resources/public/ssh), [RDP](https://docs.pangolin.net/manage/resources/public/rdp), and [VNC](https://docs.pangolin.net/manage/resources/public/vnc) in the docs.
### Improved Pangolin SSH
When we shipped native SSH in [Pangolin 1.16](/news/1-16-0-release), the focus was certificate-based authentication, just-in-time user provisioning, and tight integration with OpenSSH. It worked well, but getting there meant configuring an auth daemon, editing `sshd_config`, trusting a certificate authority, and in many cases standing up a bastion pattern for multi-server environments. Powerful, yes, but a fair bit of host setup before your first connection.
Pangolin SSH mode changes that entirely. Instead of routing commands over the network to an OpenSSH server, Pangolin SSH executes sessions directly on the host through the site connector. There's no SSH server to install, no auth daemon to configure, and no `sshd_config` to touch. Select **Pangolin SSH** in the dashboard, make sure Newt runs as root on the machine you want to access, and you're done.
This is now the default when you create an SSH resource. Manual authentication works out of the box with existing host credentials. If you want Pangolin identities provisioned automatically, switch to automated provisioning, still without touching OpenSSH.
Pangolin SSH works on both public and private SSH resources. On a public resource, users get a browser-based terminal at the resource FQDN. On a private resource, connect with the Pangolin client and SSH over the private tunnel:
```shell
$ pangolin ssh prod-app.internal
```
The CLI also now supports SCP for copying files over the same private tunnel:
```shell
$ pangolin scp ./config.yml prod-app.internal:/etc/app/
```
Same mode, same setup—whether users reach the session through a browser or the CLI.
Standard SSH Server mode is still there when you need it, like reaching a legacy OpenSSH host on the network or running the bastion-and-auth-daemon setup from 1.16. But for the common case, SSH into the machine running your site connector, Pangolin SSH is the path of least resistance.
Read more about [SSH access](https://docs.pangolin.net/manage/ssh) in the docs, or see the [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin) guide for browser and private CLI setup.
### Automatic Site Updates
Keeping site connectors up to date across a fleet is tedious. You ship a new Pangolin release, then you SSH into each edge device, pull the latest binary, restart Newt, and hope you didn't miss one.
Automatic updates handle that for you. When enabled, Newt periodically checks for a newer version, downloads it, and restarts itself. The site reconnects on the new version without manual intervention. Pangolin waits 24 hours after a release is published before sites pull it, giving early issues time to surface before your whole fleet updates.
You can enable automatic updates at the organization level for all sites, or toggle it per site. Turn it on globally and disable it on specific sites that need to stay pinned. Turn it off globally and enable it only where you want hands-off updates.
Automatic updates work with binary installations. If you run Newt in Docker or Kubernetes, updates are handled by your orchestration platform as usual.
Read more about [automatic site updates](https://docs.pangolin.net/manage/sites/auto-update) in the docs.
### Labels
As your Pangolin deployment grows, finding the right site or resource in a long table gets old fast. Labels fix that.
Labels are plain string tags you attach to sites, machine clients, and resources. Tag a production site with `prod`, a resource with `customer-1`, a client with `warehouse-1`. Use whatever naming convention fits your workflow. Once attached, you can search and filter by label in the table views for each entity type.
Labels are shared across entity types, which makes cross-referencing easy. Tag the site, the clients, and the resources for a location with the same label and you can filter each table to see everything related to that location.
Add labels inline from any entity table, or manage them organization-wide from the labels page.
Read more about [labels](https://docs.pangolin.net/manage/labels) in the docs.
### Resource Policies
If you've configured public resources before, you know the drill: set up authentication, assign users and roles, configure geo-blocking, repeat for every resource. Resource policies let you define those settings once and attach them to multiple public resources.
A resource policy holds the same authentication and access rule settings you'd configure on an individual resource: SSO, identity providers, PIN codes, user and role assignments, geo-blocking, ASN blocking, IP allow lists, and more. Attach a policy to a resource and it inherits the baseline. Multiple resources can share the same policy, so a team-wide login requirement or geo-block applies everywhere with a single edit.
Policies are additive. A shared policy provides the base layer, and individual resources can add settings on top. Deny all countries in the policy, then add an allow rule for a specific country on one resource. The resource-specific rule sits on top without replacing the shared baseline.
Read more about [resource policies](https://docs.pangolin.net/manage/resources/public/resource-policies) in the docs.
### General Improvements and Bug Fixes
As always, 1.19 also includes various UI improvements and bug fixes throughout the product.
## Documentation & Community
### Helm Chart Documentation
We've added docs for deploying Pangolin and Newt on Kubernetes with Helm, covering repository setup, values files, upgrades, rollbacks, and OCI-based chart installs.
Read more about [Helm installation](https://docs.pangolin.net/self-host/manual/kubernetes/helm) in the docs.
### Community Blueprints
The Community Blueprints repository is a shared library of ready-to-use Docker Compose templates for popular self-hosted apps—Grafana, Jellyfin, Immich, and more—already wired to expose services through Pangolin.
Read more about [Community Blueprints](https://docs.pangolin.net/manage/community-blueprints-repo) in the docs.
## Looking Forward
Browser-based remote access over SSH, RDP, and VNC closes a long-standing gap between public HTTP resources and private terminal access. Whether you need a web-based SSH terminal, remote desktop in the browser, or VNC remote access without a viewer, Pangolin handles it in one platform. Combined with the simpler Pangolin SSH setup path, we're making it easier than ever to get people into their infrastructure without juggling clients, VPNs, and configs. See [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin) for a getting-started walkthrough.
---
### What Are MCP Tunnels? Secure Private MCP Servers Explained
URL: https://pangolin.net/news/what-are-mcp-tunnels
Published: 2026-06-03
Summary: Learn what MCP tunnels are, how they connect AI agents to private Model Context Protocol servers over outbound-only connections, and why they matter for enterprise security.
Category: Engineering
AI assistants are only as useful as the systems they can reach. For most enterprises, the valuable data and tools live on private networks: internal APIs, ticketing systems, runbooks, configuration databases, and custom automation endpoints. Those services were never meant to sit on the public internet.
The [Model Context Protocol (MCP)](https://modelcontextprotocol.io/) gives agents a standard way to call tools and read context from those systems. The hard part is connectivity. Opening inbound firewall ports, publishing internal MCP servers behind a public load balancer, or allowlisting a vendor's IP ranges on every origin conflicts with how modern security teams want to operate.
**MCP tunnels** address that gap. They let a hosted agent platform or your own agent backend reach MCP servers inside your private network over an **outbound-only** connection. Traffic is encrypted end to end, routed by hostname inside your environment, and layered with authentication on each upstream server. You do not expose MCP listeners to the internet, and you do not depend on users or agents sitting on the corporate LAN.
This article explains what MCP tunnels are, how they differ from ordinary remote MCP hosting, how the architecture works, what the security model assumes, and where they fit next to patterns like tunneled reverse proxies and zero trust remote access.
## MCP tunnel definition
An **MCP tunnel** is a managed connectivity path between a backend. This could be your own backend servers running agent infrastructure, or an AI provider's backend like Anthropic or OpenAI. It connects to one or more **upstream MCP servers** running inside a private network. A small **tunnel stack** you deploy initiates connections outward to a **tunnel edge**, typically managed by the backend side. A **proxy** terminates TLS, validates that traffic originated from the backend, and forwards requests to the correct MCP server based on hostname.
Each exposed server gets a hostname under your tunnel domain (for example, `docs.your-tunnel-domain.example`). The AI session or API request targets that hostname; the proxy routes to the real MCP process on your LAN, VPC, or cluster.
The defining property is **connection direction**: your infrastructure calls out. Inbound firewall rules for MCP are not required, and you avoid pinning access to a shifting set of vendor egress IPs at every internal service.
## MCP servers and MCP tunnels
Remote agents typically call MCP **servers** over **HTTP** (Streamable HTTP at paths such as `/mcp` is common). The protocol defines tool discovery and invocation; it does not solve network reachability.
An **MCP tunnel** is separate infrastructure: outbound connectivity, TLS, and hostname routing so an external MCP **client** can reach a private HTTP listener. The tunnel carries the same MCP traffic your server would accept on the LAN; it does not replace the protocol or implement your tools.
## Why MCP tunnels matter
### Private tools without public exposure
Agents need the same systems your engineers use: Grafana, Jira, internal CRMs, fleet APIs, or bespoke Python FastMCP services. Publishing those endpoints to the public internet or punching holes in perimeter firewalls increases blast radius. MCP tunnels keep listeners on private addresses while still allowing governed access from managed AI sessions.
### Outbound-only aligns with zero trust
[Zero Trust](https://www.nist.gov/publications/zero-trust-architecture) assumes no implicit trust based on network location. Outbound-initiated connectivity matches how ZTNA connectors, site-based remote access, and tunneled reverse proxies work: the protected environment establishes the path, not the internet at large. MCP tunnels apply that same inversion to AI tool traffic.
### Compliance and data boundaries
Regulated environments often require that payloads stay encrypted in transit, that third-party networks cannot read content, and that access is scoped per application. Tunnel setups combined with strong per-application authentication, such as **OAuth** or **bearer tokens** on each MCP server, help meet these requirements more robustly than solutions like flat VPNs or a single shared API key on a public URL.
## How MCP tunnels work
### Components
A typical deployment runs a lightweight **tunnel connector** inside your network:
| Component | Role |
| --- | --- |
| **Tunnel connector** | Initiates outbound encrypted connections to the tunnel edge, accepts tunneled traffic from the provider, and forwards requests to your internal MCP server. Sometimes, the connector also contains the proxy, so everything is handled within a single component. |
| **Proxy (optional)** | Terminates TLS, validates that traffic originated from the backend, and routes requests to the correct MCP server by hostname. In some deployments, this function is integrated into the tunnel connector itself rather than running as a separate component. |
On the provider side, the **tunnel edge** receives traffic from the AI backend. The **setup** component (often run once at deploy time) talks to the Tunnels API for tokens, certificate registration, and rotation.
You also run one or more **upstream MCP servers**, for example FastMCP, a custom Node service, or an internal gateway, that speak MCP over HTTP at paths such as `/mcp` or `/`.
The stack layers look like this: an external access gateway reaches your network only over an outbound secure tunnel; a connector (often containerized) and optional internal proxy route traffic to MCP tools behind the firewall without opening inbound ports.
### Request flow
At a high level, a request crosses from the agent or API client in the cloud through policy checks, down the encrypted tunnel, and into a private MCP server on your LAN or VPC:
The numbered steps below follow the same path in more detail:
1. An operator starts an **agent session** in a vendor console, or an **API integration** issues a request that references an MCP server URL on your tunnel domain.
2. The provider's cloud gateway applies policy, including **IP allowlists** where configured, then sends the MCP request through **outer mTLS** to the tunnel edge (transport over the connector's outbound path).
3. Traffic reaches your **proxy**, which completes **inner TLS** using a certificate signed by a CA you registered with the provider.
4. The proxy forwards the HTTP request to the upstream MCP server matching the hostname (path is passed through unchanged).
5. The MCP server handles tool calls; responses return along the same encrypted path.
### Hostname routing
Each logical MCP service maps to a **subdomain** of your tunnel domain. The proxy configuration ties `echo.your-tunnel-domain` to `http://echo-svc.internal:8080/mcp`, and `docs.your-tunnel-domain` to another upstream. That mirrors how reverse proxies use virtual hosts, but the client on the internet is the AI platform rather than a browser tab on a user laptop.
### Credential provisioning
Before a tunnel carries traffic, you provision your stack so the provider trusts your connector. The provider gives you a tunnel **ID and token** (from their console or API). You pass that pair to the setup component or connector on boot; it registers with the provider, pulls certificates, and completes the TLS handshake.
For example:
```bash
./tunnel --id tun_7xk2m9p4 --secret 3f8a1b2c9d0e4f7a6b5c2d1e0f9a8b7c
```
This is a generic example. Flag names, binary names, and formats vary by vendor; the ID and secret are always provider-issued credentials.
The provider cannot connect to your proxy until provisioning finishes, so no tunneled MCP traffic flows until you have explicitly completed trust setup.
## Security model
MCP tunnel security combines **several controls at different layers**, not a single switch. Some run on the provider's cloud gateway before traffic enters the tunnel; others protect the path over the transport network and at each MCP server inside your edge. Understanding where each applies clarifies what the tunnel does and does not guarantee.
| Layer | What it protects |
| --- | --- |
| **IP allowlists at the cloud access gateway** | Random internet hosts attempting the first connection to your tunnel endpoint |
| **Outer mTLS (provider to transport edge, with IP validation)** | Unauthorized clients impersonating the tunnel path |
| **Inner TLS (provider backend to your proxy)** | Payload inspection by the transport provider or intermediaries |
| **OAuth or tokens on each MCP server** | Unauthorized use of tools even when tunnel traffic is legitimate |
### IP allowlists at the cloud gateway
Alongside certificate-based tunnel auth and per-server OAuth or bearer tokens, many setups add **IP allowlists** on the **cloud access gateway**, enforced before traffic enters the tunnel toward your edge. Traffic from anything not on the list is dropped; it never hits your connector or MCP servers.
Rules are usually built from the provider's published egress, your own agent cloud, or broad cloud nets, for example a single host `203.0.113.42/32`, a vendor prefix like `198.41.192.0/19`, your agent egress `52.94.1.0/24`, or ASN filters such as `AS16509` (AWS), `AS15169` (Google), or `AS13335` (Cloudflare). Use the ranges your vendor documents; these are illustrative anchors, not a universal checklist.
ASN rules trade precision for maintainability when IPs churn. They complement, not replace, mTLS and application auth. The gateway also spares you from pinning the same vendor IPs on every internal MCP server separately.
### Shared responsibility
**The provider** typically controls tunnel access in your organization, validates your CA before connecting, and restricts which tunnels a workspace can use.
**Your organization** owns everything inside the boundary: tunnel tokens, TLS private keys, proxy hardening, network segmentation for MCP servers, OAuth configuration, certificate renewal, and incident response if credentials leak.
If an attacker obtains both your **tunnel token** and a **TLS private key**, they could impersonate your proxy and read MCP payloads. Treat those secrets like cluster-admin kubeconfig or VPN private keys.
### What the transport provider can see
When the tunnel uses a third-party transport network, that provider **cannot read MCP request or response bodies** if inner TLS is terminated only on your proxy. It may still observe **connection metadata**: egress IP of the host running the connector, timing, byte volume, and the assigned tunnel subdomain. Architecture reviews should document that telemetry for subprocessors and acceptable-use policies.
### MCP tunnel vs. tunnel authentication vs. server authentication
**IP allowlists** (cloud gateway), **tunnel authentication** (certificates and mTLS on the path), and **server authentication** (OAuth, tokens, headers on the MCP process) answer different questions. The first limits which networks can open a conversation with your tunnel domain. The second proves the traffic path and encrypts payloads across the transport layer. The third decides whether a given caller may use specific tools once the request arrives upstream.
The tunnel secures **reachability** and **transport integrity**; it does **not** log users into your MCP server. If the upstream requires OAuth, API keys, or mutual TLS, configure that on the server the same way you would for any other remote MCP deployment. The agent runtime—whether a console session or an API client—supplies those credentials according to your MCP server documentation.
## Prerequisites and network requirements
Before deploying, teams usually need:
- A **deployment target**: Kubernetes (Helm chart) or a VM with Docker Compose.
- A **tunnel** created in the provider console, with API access for the workspace that will call MCP tools.
- **Outbound connectivity** from the setup component to the provider's control-plane API (hostname and port in vendor docs, commonly 443 TCP), from the connector to tunnel edge addresses (for example `198.41.192.0/19` on port 7844 TCP and UDP), and from the proxy to internal MCP listeners on your chosen ports.
- One or more **MCP servers** already running and reachable from the proxy host or pod network.
Vendor-managed tunnels usually pair with that vendor's **hosted agent console** and **HTTP APIs** for attaching remote MCP servers. They are not a substitute for every local MCP integration (stdio, IDE plugins); product boundaries change as vendors ship updates.
## Common use cases
- **On-prem files and records**: MCP server on the LAN queries file shares, SharePoint Server, or internal doc repos; the tunnel lets outside agents search without exporting the corpus.
- **Private databases**: MCP server beside SQL Server, Oracle, or Postgres runs governed queries; the tunnel reaches in without opening the database to the internet.
- **On-prem ERP and LOB apps**: MCP server wraps SAP, CRM, or HR APIs on internal hostnames; agents read and write through scoped tools, not a public URL.
- **On-site ops automation**: MCP server drives backup, patching, or facility tools that cannot leave the building; the tunnel replaces VPN-wide LAN access.
- **Pre-production labs**: MCP server on sanitized clones in a test VLAN; tunnel only from non-production agent workspaces.
In each case, security review should cover **which tools** are exposed, **which identities** may invoke them, and **what data** can leave the environment in tool responses.
## Limitations and product reality
Tunnels solve **connectivity**, not **governance** by themselves. You still need tool allowlists, logging, PII review, and human approval workflows for high-risk actions. Zero Data Retention and HIPAA BAA eligibility depend on the provider's feature matrix, not on the tunnel alone.
## How MCP tunnels relate to tunneled reverse proxies
Both patterns share the same architectural idea: **publish capability through an outbound-initiated encrypted path** instead of opening the private network inbound.
A **tunneled reverse proxy** targets human or machine HTTP clients reaching internal web applications: browsers, mobile apps, or service meshes. An **MCP tunnel** targets **MCP clients** embedded in AI runtimes reaching **tool servers**. The payload shape differs (MCP JSON-RPC and tool schemas vs. HTML and REST), but the security story (connector, proxy, hostname routing, deny-by-default at the edge) is familiar to platform engineers.
Organizations already using outbound connectors for ZTNA or tunneled app access can treat MCP tunnels as just **another private upstream**, not an entirely new security paradigm. Pangolin's identity-aware access model fits the same environments where MCP servers are commonly deployed.
## Final thoughts
MCP tunnels exist because AI agents need the same private systems as your staff, and those systems cannot move to the public internet without unacceptable risk. The pattern combines outbound connectivity, layered TLS, and per-server authentication so external agent backends can invoke tools on your terms.
For architects, the decisive questions are who can open a tunnel, which hostnames map to which tools, how credentials rotate, what the transport provider can observe, and what happens when secrets leak. Clear answers there beat any vendor checklist.
Start in a sandbox with one low-risk MCP server; prove tunnel auth, logging, and OAuth before you widen scope.
## Related reading
* [What Is a Tunneled Reverse Proxy? Architecture & Uses](/news/tunneled-reverse-proxy)
* [What is an Identity-Aware Proxy (IAP)?](/news/what-is-an-identity-aware-proxy)
* [How Does ZTNA Work?](/news/how-ztna-works)
* [How Pangolin Works](/news/how-pangolin-works)
## FAQ
**What is an MCP tunnel?**
*An MCP tunnel is an outbound-only encrypted path that lets an AI provider reach Model Context Protocol servers inside your private network without opening inbound firewall ports or publishing those servers on the public internet.*
**Do MCP tunnels replace authentication on my MCP server?**
*No. The tunnel provides secure connectivity and routing. Each upstream MCP server should still enforce its own OAuth, API keys, or other auth as you would for any remote MCP deployment.*
**Can I use MCP tunnels with any AI product?**
*Major model providers often ship managed MCP tunnels so their hosted AI backends can reach your private MCP servers, see [Anthropic's MCP tunnels](https://platform.claude.com/docs/en/agents-and-tools/mcp-tunnels/overview) and [OpenAI's Secure MCP tunnels](https://developers.openai.com/api/docs/guides/secure-mcp-tunnels); availability and beta headers vary by vendor. That is one deployment shape, not the whole idea. An MCP tunnel is fundamentally a way to give any agentic system, a provider cloud or agents you run yourself, outbound access to tools and data on a private network without inbound firewall holes.*
*If you deploy your own agents in your own cloud against custom tools on private networks, or prefer not to rely on a provider's tunnel infrastructure, you can run your own tunnel stack and route your runtime to the same hostname-scoped MCP endpoints. Check vendor docs for managed options; for self-hosted agents, you own tunnel auth, CA registration, and routing end to end.*
**How is an MCP tunnel different from a VPN for AI tools?**
*A VPN often grants broad network access. An MCP tunnel exposes specific hostname-routed MCP servers to the AI backend, which aligns better with least-privilege tool access.*
**Is the transport provider able to read MCP tool payloads?**
*In designs that terminate inner TLS on your proxy with keys only you hold, the transport layer should not decrypt MCP bodies. Connection metadata such as IPs, timing, and subdomain may still be visible to the transport operator.*
**What do I need before production use?**
*A deployment environment, registered tunnel and CA, outbound network rules, hardened proxy and MCP servers, credential rotation, and governance over which tools and data agents may touch.*
---
### 5 Remote Access Policy Examples for Secure Teams
URL: https://pangolin.net/news/remote-access-policy-examples
Published: 2026-06-02
Summary: Use these remote access policy examples to scope access for admins, contractors, OT systems, internal web apps, and emergency workflows.
Category: Guides
Remote access policy is where secure access becomes operational. It turns broad goals like "protect internal systems" and "require MFA" into enforceable rules about who can connect, what they can reach, when access is allowed, and what evidence is logged.
That matters because modern remote access is no longer just an employee VPN problem. Teams need to support administrators, developers, vendors, MSPs, industrial operators, and device fleets across cloud, on-prem, and edge environments. A single broad network access rule rarely fits all of those cases.
The broader strategy is covered in our [secure remote access implementation guide](/news/secure-remote-access). This article goes one level deeper with practical remote access policy examples you can adapt into roles, resources, and access rules.
## What should a remote access policy include?
A useful remote access policy should be specific enough to enforce. If it only says "use MFA" or "connect securely," it will not help an administrator decide whether a real request should be approved.
At minimum, each policy should define:
* **Subject:** the user, group, role, service account, or vendor identity requesting access.
* **Resource:** the exact application, server, subnet, device, or admin interface being accessed.
* **Authentication requirement:** SSO, MFA, device approval, or step-up authentication.
* **Scope:** whether access is browser-based, client-based, protocol-specific, time-limited, or restricted to a site.
* **Logging requirement:** what must be recorded for audit and incident response.
* **Review cycle:** how often the policy and assigned users should be reviewed.
This maps closely to Zero Trust guidance from [NIST SP 800-207](https://www.nist.gov/publications/zero-trust-architecture), where access decisions are based on policy and evaluated around subjects, assets, and resources. It also aligns with the [CISA Zero Trust Maturity Model](https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model), which emphasizes identity, devices, networks, applications, workloads, and data as separate control areas.
In Pangolin terms, this usually means translating policy into **Sites**, **Resources**, **Roles**, and **Policies**. A site describes where the resource lives, a resource describes what is protected, a role describes who can request access, and a policy defines the conditions under which access is allowed.
## Example 1: Production admin access policy
Production infrastructure access should be the strictest policy in most environments. These systems often include [SSH hosts](/news/how-to-ssh-with-pangolin), databases, Kubernetes control planes, cloud consoles, observability tools, and deployment systems.
### Policy goal
Allow approved engineering and operations users to access production resources only when needed, with strong identity checks and full auditability.
### Example policy
**Users:** Engineering and operations users assigned to the `Production Admins` role.
**Resources:** [Production SSH hosts](/news/how-to-ssh-with-pangolin), production databases, infrastructure dashboards, and deployment systems.
**Access requirements:**
* SSO required.
* MFA required on every session or after a short reauthentication window.
* Device approval required for privileged access.
* Access limited to explicitly assigned production resources.
* No broad network-level access by default.
**Logging requirements:**
* User identity.
* Target resource.
* Access result: approved or denied.
* Time and source context.
* Policy or role used to grant access.
**Review cycle:** monthly for privileged users, immediately after role changes or offboarding.
### Why this policy works
The important shift is that the user is not placed onto a full production network. The policy is tied to the resource. That reduces lateral movement risk and makes access reviews easier because the security team can see which people can reach which production systems.
**Legacy approach:** give production admins a VPN profile, rely on internal segmentation, and audit activity across several systems.
**Better approach:** grant named users access to specific production resources, require strong authentication, and log the user-resource-policy decision in one access layer.
In Pangolin, this can be modeled with production Resources assigned only to production Roles, with separate Policies for high-risk systems that require stronger authentication or tighter review.
For the broader model behind this, read [How ZTNA Works](/news/how-ztna-works).
## Example 2: Vendor and contractor remote access policy
Vendor access is risky because external users often need temporary access to a small set of systems, but organizations sometimes grant them long-lived VPN accounts or shared credentials.
### Policy goal
Allow third-party users to reach only the resources required for their contract, without shared accounts or persistent broad network access.
### Example policy
**Users:** Named contractor or vendor identities assigned to a vendor-specific role.
**Resources:** Only the application, site, device, or support portal required for the vendor's work.
**Access requirements:**
* Individual identity required for every vendor user.
* Shared accounts prohibited.
* MFA required.
* Access expiration date required.
* Access limited to specific resources, not entire subnets.
* Vendor access disabled automatically when the contract ends.
**Logging requirements:**
* Vendor user identity.
* Sponsoring internal owner.
* Resource accessed.
* Session timestamp.
* Policy used to approve the request.
**Review cycle:** before each renewal, monthly for active vendor groups, and immediately at contract termination.
### Why this policy works
This policy creates accountability. If a vendor does something risky, you can trace it to an individual identity rather than a generic external account. It also prevents a temporary support need from becoming permanent unmanaged access.
**Legacy approach:** issue a shared vendor VPN account or reuse a generic support login.
**Better approach:** create named vendor identities, assign them to the smallest possible role, set an access end date, and review the role before renewal.
In Pangolin, vendor access should usually be represented as a narrow Role that maps to one customer, site, or resource set. That keeps vendor access separate from employee access and makes offboarding cleaner.
## Example 3: OT and industrial remote access policy
Operational technology environments need remote access, but the risk profile is different from ordinary IT systems. PLCs, SCADA interfaces, HMIs, building systems, and remote industrial devices often sit behind NAT, live at physical sites, and cannot tolerate unnecessary exposure.
### Policy goal
Give approved operators, engineers, and support users access to specific OT systems without exposing industrial interfaces to the public internet.
### Example policy
**Users:** OT engineers, site operators, approved vendors, and emergency support users.
**Resources:** Specific PLC interfaces, SCADA tools, HMIs, building management systems, or engineering workstations.
**Access requirements:**
* SSO and MFA required.
* Resource-level access required.
* Access separated by site.
* No public inbound ports for OT resources.
* Vendor access must be time-limited and tied to a named internal sponsor.
* Emergency access must be logged and reviewed after use.
**Logging requirements:**
* User identity.
* Site name.
* Target resource.
* Access window.
* Vendor or internal owner.
**Review cycle:** monthly for vendor access, quarterly for internal operator access, and after every emergency access event.
### Why this policy works
OT access should be narrow and site-aware. The user should not receive a general path into every device on an industrial network. They should reach the approved resource at the approved site through an authenticated access layer.
**Legacy approach:** expose a remote desktop host, open a firewall path, or put users onto the plant network through a VPN.
**Better approach:** keep OT systems private, connect the site through an outbound connector, and grant access to specific resources by site and role.
In Pangolin, this pattern maps naturally to Sites and Resources. Each plant, customer location, or remote environment can be modeled separately so access is scoped to the actual operational boundary.
For more on this use case, see [Remote PLC/SCADA Access Without Open Ports](/news/remote-plc-scada-access-without-open-ports).
## Example 4: Internal web application access policy
Many organizations have internal dashboards, admin panels, documentation portals, staging apps, analytics tools, and support systems that need remote access. These are often exposed through VPNs, IP allowlists, or public login pages.
### Policy goal
Allow employees to access internal web applications from a browser without exposing the application publicly or requiring broad client-based network access.
### Example policy
**Users:** Employees assigned to the correct department or role.
**Resources:** Internal web apps, dashboards, admin panels, support tools, and development portals.
**Access requirements:**
* SSO required.
* MFA required for sensitive apps.
* Access scoped by app, not network.
* Admin apps separated from read-only dashboards.
* Public internet exposure removed where possible.
**Logging requirements:**
* User identity.
* Application accessed.
* Authentication status.
* Access decision.
* Policy matched.
**Review cycle:** quarterly for normal apps, monthly for administrative apps.
### Why this policy works
This is a strong fit for identity-aware proxy patterns. Users get browser-based access to the approved app, but they do not need to join the private network first.
**Legacy approach:** expose the app behind a public login page, allowlist office IPs, or require a VPN just to open a web dashboard.
**Better approach:** put identity and policy in front of the app, remove direct public exposure, and let users reach only the approved application.
In Pangolin, browser-based private app access can be handled as a resource protected by identity-aware policy, while deeper private access can remain client-based where needed.
For related background, read [What is an Identity-Aware Proxy?](/news/what-is-an-identity-aware-proxy).
## Example 5: Emergency break-glass access policy
Every access strategy needs an emergency path. The mistake is treating emergency access as an excuse for permanent, unmanaged admin accounts.
### Policy goal
Provide a controlled emergency access path for outages and incidents while keeping usage rare, visible, and reviewable.
### Example policy
**Users:** A small group of approved senior operators or incident responders.
**Resources:** Critical production systems, site connectors, recovery tooling, and incident response dashboards.
**Access requirements:**
* Break-glass role must be separate from normal admin roles.
* MFA required.
* Access time-limited.
* Business justification required.
* Automatic alert sent when break-glass access is used.
* Post-incident review required.
**Logging requirements:**
* User identity.
* Reason for access.
* Resource accessed.
* Duration.
* Incident or ticket reference.
* Reviewer name after the event.
**Review cycle:** after every use, plus scheduled quarterly validation that break-glass users are still appropriate.
### Why this policy works
Emergency access is not the problem. Unreviewed emergency access is the problem. A good break-glass policy gives teams a way to recover systems quickly without creating a permanent bypass around the normal access model.
**Legacy approach:** keep a standing emergency admin account and hope it is only used during incidents.
**Better approach:** separate emergency access from daily access, require justification, alert on use, and review every session after the incident.
In Pangolin, this should be a distinct Role or Policy path, not a hidden exception inside normal admin access. The goal is to make emergency use fast but visible.
## Turning policy examples into enforceable access controls
Remote access policies should not live only in a document. They should become configuration that your access platform can enforce.
In Pangolin, a practical model is to map policy concepts into:
* **Sites:** where the resource lives.
* **Resources:** the application, service, device, host, or network range being protected.
* **Roles:** the users or groups that need access.
* **Policies:** the rules that decide whether access should be allowed.
* **Blueprints:** repeatable configuration that can be managed through GitOps.
This is especially useful when your organization has many sites, repeated customer environments, or remote edge devices. Instead of manually recreating access rules, teams can use a consistent template and review changes before rollout.
For a deeper implementation pattern, see [GitOps Workflow for Pangolin Blueprints](/news/gitops-pangolin-blueprints-ci-cd) and [How Pangolin Works](/news/how-pangolin-works).
## Remote access policy checklist
Use this checklist before approving a new remote access path:
* [ ] Is the request tied to a named user, group, or service identity?
* [ ] Is the target resource clearly defined?
* [ ] Is access scoped to the minimum resource set required?
* [ ] Is MFA required?
* [ ] Is the device or endpoint posture requirement clear?
* [ ] Is vendor access time-limited?
* [ ] Is emergency access separated from normal access?
* [ ] Are access logs detailed enough for an audit?
* [ ] Is there a review schedule?
* [ ] Can the policy be enforced automatically?
## Related secure access guides
[How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
[Secure Remote Access: Enterprise ZTNA Implementation Guide](/news/secure-remote-access)
[How ZTNA Works](/news/how-ztna-works)
[How Pangolin Works](/news/how-pangolin-works)
[GitOps Workflow for Pangolin Blueprints](/news/gitops-pangolin-blueprints-ci-cd)
## FAQ
**What is a remote access policy?**
*A remote access policy defines who can access private systems remotely, which resources they can reach, how identity is verified, and what activity must be logged.*
**What is the most important remote access policy rule?**
*The most important rule is least privilege. Users should receive access to the specific resource they need, not broad network access by default.*
**Should vendors get VPN access?**
*Vendors should not receive broad VPN access unless there is no narrower option. A better model is named vendor identities, MFA, resource-level access, expiration dates, and detailed logging.*
**How often should remote access policies be reviewed?**
*Normal employee access can often be reviewed quarterly. Privileged access, vendor access, and production access should be reviewed monthly or whenever roles, contracts, or incidents change.*
---
### Secure Remote Access: Enterprise ZTNA Implementation Guide
URL: https://pangolin.net/news/secure-remote-access
Published: 2026-05-29
Summary: Learn how to modernize secure remote access with identity-driven ZTNA, resource-level policy, and reduced public exposure.
Category: Guides
Secure remote access is now a core business need. Engineering teams, hybrid employees, and third party vendors all need a way to reach private apps, production systems, and edge devices from outside the office.
Legacy VPNs often grant too much access. Once a user connects, they may be able to see large parts of the private network. If that account is compromised, the attacker gets a wider path for lateral movement.
Modern secure remote access starts with identity, policy, and least privilege. This guide explains how to move away from broad network access and toward a Zero Trust Network Access (ZTNA) model.
## **What is Secure Remote Access? (Access vs. Remote Control)**
Secure remote access lets approved users reach private systems from outside the network. It should protect each connection with identity checks, policy, encryption, and logging.
Common examples include:
* Employees accessing internal corporate web applications.
* Engineers connecting directly to private cloud infrastructure.
* External vendors managing specific enterprise portals.
### **Remote Access vs. Secure Remote Control**
The terms are often mixed together, but they are not the same.
* **Secure remote access:** lets a user reach a specific app or service, such as an internal analytics dashboard.
* **Secure remote control:** lets a user manage a system directly, such as administering a server, troubleshooting a device, or changing infrastructure settings.
Remote control carries more risk. It should require stronger authentication, shorter access windows, and detailed audit logs.
An enterprise remote access model should answer three questions for every request:
1. **Who** is the user requesting entry?
2. **What** exact resource or application are they attempting to reach?
3. **Should** this specific transaction be permitted based on identity, context, and real time policy?
## **The Risk of Legacy Architecture: Why Modernizing Matters**
Remote access often grows without a clear plan. One team opens a firewall port. Another creates a VPN profile. A vendor gets a shared account. Over time, these shortcuts create risk.
The most common problems are:
* **Broad network visibility:** VPN users can often see more systems than they need.
* **Lateral movement:** A compromised device can scan and attack nearby private assets.
* **Public internet exposure:** Internal admin dashboards, staging sites, and IoT interfaces become easy targets when they are open to the web.
* **Weak authentication:** Shared accounts and single factor login make access harder to trust.
* **Poor audit trails:** Security teams may not know which person accessed which system.
Modern secure remote access reduces these risks. It puts identity, policy, encryption, and logging in front of private infrastructure.
## **5 Core Pillars of a Zero Trust Remote Access Strategy**
Strong remote access depends on five core controls. These controls work together. Identity tells you who is connecting, policy decides what they can reach, and logging gives you evidence after the fact.
### **1\. Identity Based Access Control**
Every request should map to a known user or service account. Connect remote access to a trusted Identity Provider (IdP). Enforce Multi Factor Authentication (MFA) for external access, privileged accounts, and sensitive systems.
Central identity also makes offboarding easier. When a user leaves or changes roles, you can remove access from one directory.
### **2\. Strict Enforceability of Least Privilege**
Users should only see the systems they need.
For example:
* A support user may need one customer dashboard.
* A DevOps engineer may need one backend server.
* A vendor may need one support portal.
Resource level access avoids broad network privileges.
### **3\. Resource Level Micro Segmentation Policies**
Traditional access often depends on network location. For example, a user may be allowed because they are on a certain subnet.
ZTNA moves the decision closer to the resource. Access is evaluated for the app, database, server, or device being requested. This keeps high value systems separate from routine business apps.
### **4\. End to End Encrypted Connectivity**
Remote traffic must be encrypted in transit. Encryption helps protect data as it moves across public networks.
Encryption alone is not enough. It should work with identity checks, policy, and session logging.
### **5\. Centralized Logging, Monitoring, and Alerting**
Security teams need clear answers:
* Who accessed the resource?
* What did they access?
* When did access happen?
* Was the request approved or denied?
* Which policy allowed it?
Monitoring should also track tunnel and site health. If a remote site goes offline, operations teams need an alert.
## **Comparing Remote Access Solutions**
The right tool depends on the resource, the user, and the workflow. Most teams use more than one access method. The goal is to keep identity and policy consistent, even when the connection method changes.
| Access Method | Best Used For | Primary Strengths | Core Limitations |
| --- | --- | --- | --- |
| **VPN (Virtual Private Network)** | Network level access across legacy systems. | Deep protocol support; familiar deployment model. | Often grants too much access; higher risk of lateral movement. |
| **Remote Desktop Tools (RDP)** | Interactive workstation control and helpdesk troubleshooting. | Excellent for direct, visual desktop and server administration. | High risk if exposed to the public internet; requires strong MFA. |
| **SD-WAN and Network Overlays** | Resilience and site to site connectivity for branch offices. | Advanced routing, high availability, and network resilience. | Does not solve user identity or resource level access by itself. |
| **Identity Aware Proxy (IAP)** | Browser based connection to internal web tools. | No client required; good user experience; limits network exposure. | Usually limited to HTTP/HTTPS web applications. |
| **ZTNA (Zero Trust Network Access)** | Protecting private applications, cloud infrastructure, and vendor portals. | Identity driven policies and least privilege by design. | Requires a current resource inventory and clear policies. |
| **Tunnel Based Private Access** | Edge devices, remote physical sites, and NAT isolated servers. | Reduces inbound firewall exposure with secure outbound connections. | Requires monitoring for tunnel and edge health. |
## **Step by Step Secure Remote Access Implementation Framework**
Move to identity aware, resource level access in clear phases. This keeps the migration manageable and gives users time to adapt.
### **Phase 1: Build a Definitive Remote Access Inventory**
You cannot secure what you cannot see. Start with an inventory of every resource that needs remote access.
For each asset, document:
* Resource name, technical owner, and business purpose.
* Physical or cloud location, plus current internet exposure.
* Authorized user groups and legacy authentication types.
* Current logging status and compliance sensitivity.
### **Phase 2: Categorize Corporate Assets by Risk**
Not every resource needs the same controls. Group assets by risk so you can focus first on the highest impact systems.
* **Low risk:** read only metrics tools or internal documentation.
* **Medium risk:** corporate apps, development portals, or IT helpdesk tools.
* **High risk:** production databases, customer deployments, cloud consoles, and [SSH endpoints](/news/how-to-ssh-with-pangolin).
High risk assets should require MFA, short lived access, and tighter review.
### **Phase 3: Define Granular Role Based Profiles**
Create roles that match real job duties. Avoid broad, generic permissions.
Common roles include:
* Employee
* Engineering
* Operations
* Third Party Vendor
* Read Only Support
Clear roles make access easier to review as the company grows.
### **Phase 4: Establish Clear, Auditable Access Policies**
Write the policy before you configure the platform.
For each resource, define:
* Which groups can access it.
* Whether MFA or device approval is required.
* Whether access is ongoing or time bound.
* How often access should be reviewed.
For concrete templates you can adapt, see [5 Essential Remote Access Policy Examples for Secure Work Environments](/news/remote-access-policy-examples).
**Operational Tip:** Use a **GitOps workflow** to reduce drift. Managing policies through CI/CD makes each change reviewed, tracked, and repeatable.
### **Phase 5: Minimize Public Ingress and Internet Exposure**
Hide private systems from the open internet. Admin consoles, production databases, and internal dashboards should not have public IPs or open inbound ports.
Use secure outbound tunnels or identity aware proxies instead. This keeps origin servers hidden from public scanners while still allowing approved users to connect.
### **Phase 6: Execute a Staged Rollout**
Avoid a big bang migration. Start with one low risk, visible use case.
Good first targets include:
* One internal web app.
* One engineering resource group.
* One vendor portal.
Test login speed, policy behavior, log quality, and user friction. Once the flow works, expand to more resources.
## **Operational Best Practices for Security Leaders**
Secure remote access needs ongoing maintenance. Use these practices to keep risk low:
* **Review access often:** Standard access can be reviewed quarterly. Privileged and vendor access should be reviewed monthly or after role changes.
* **Watch for unusual behavior:** Alert on unexpected locations, repeated failed logins, off hours admin access, stale accounts, and policy changes.
* **Remove shared accounts:** Every user, including vendors, should have an individual identity.
* **Check device posture:** Verify device approval, patch level, and security settings before granting access.
## **Technical Spotlight: Transitioning Your Enterprise with Pangolin**
Teams that want a modern ZTNA model can use **Pangolin**, an open source, WireGuard powered Zero Trust Access Platform. Pangolin helps teams reach private resources without exposing them directly to the public web.
### **Key Capabilities of the Pangolin Platform**
* **Resource level access:** Pangolin organizes access around Sites, Resources, Roles, and Policies.
* **Clientless browser access:** Pangolin supports HTTPS private resources, so users can reach internal web apps without public exposure.
* **Endpoint protection:** Device approvals and posture checks help limit access to trusted devices.
* **GitOps configuration:** Pangolin Blueprints can be managed through CI/CD repositories for version control and review.
* **Automated edge provisioning:** Templates help teams roll out access across IoT networks, branch sites, and edge fleets.
## **Checklist: Evaluating Your Current Remote Access Security**
Use this checklist to audit your current remote access setup:
* [ ] **Inventory:** Do you have a current list of every server, app, and device interface that needs remote access?
* [ ] **Ownership:** Does each resource have a technical owner and a business owner?
* [ ] **Identity:** Is every access request tied to an individual user instead of a shared login?
* [ ] **MFA:** Is multi factor authentication required for external access and privileged actions?
* [ ] **Least privilege:** Are users limited to the apps and systems they need?
* [ ] **Public exposure:** Are admin portals and staging environments hidden from public scanning?
* [ ] **Auditing:** Can your team see who accessed what, from where, and under which policy?
* [ ] **Offboarding:** When an employee or vendor leaves, is their access removed from one central identity provider?
## Further reading
[How ZTNA Works](/news/how-ztna-works)
[How Pangolin Works](/news/how-pangolin-works)
[5 Essential Remote Access Policy Examples for Secure Work Environments](/news/remote-access-policy-examples)
[What is an Identity-Aware Proxy (IAP)?](/news/what-is-an-identity-aware-proxy)
[GitOps Workflow for Pangolin Blueprints](/news/gitops-pangolin-blueprints-ci-cd)
[Pangolin Clients Documentation](https://docs.pangolin.net/manage/clients/understanding-clients)
[Templated Provisioning and Rollouts for the Edge](/news/templated-provisioning-and-rollouts-for-the-edge)
[Pangolin Documentation](https://docs.pangolin.net/)
## Related reading
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [How ZTNA Works](/news/how-ztna-works)
* [What is an Identity-Aware Proxy?](/news/what-is-an-identity-aware-proxy)
* [How Pangolin Works](/news/how-pangolin-works)
## FAQ
**Is a traditional VPN sufficient for modern remote access security?**
*A VPN can still be useful, but it is often too broad for modern teams. Once users connect, they may be placed on a large network segment. ZTNA reduces this risk by limiting each user to specific apps or resources.*
**What is the most secure strategy for managing third party vendor access?**
*Give each vendor an individual identity. Require MFA. Limit access to the exact app or resource they need. Set an expiration date, log each session, and review vendor access every month.*
**How does Zero Trust Network Access (ZTNA) protect against automated cyber attacks?**
*ZTNA removes trust based on network location. A user is not trusted just because they are on a VPN or known IP range. Each request is checked against identity, device posture, and policy. ZTNA can also keep origin systems private, which reduces exposure to internet scanning.*
**What specific logs are required for remote access compliance auditing?**
*Access logs should capture user identity, login time, logout time, target resource, approval status, device context, IP address, and the policy used. Monitoring should also track tunnel and site health.*
---
### Peer-to-Peer Alternative to Cloudflare Tunnels with Edge TLS Termination
URL: https://pangolin.net/news/building-a-peer-to-edge-peer-reverse-proxy
Published: 2026-05-27
Summary: How Pangolin built a peer-to-edge reverse proxy that keeps TLS termination and private application traffic on infrastructure you control.
Category: Engineering
## The Two Tradeoffs of Reverse Proxies
When you deploy a standard reverse proxy, you typically opt into two things: terminating SSL at the server level, and exposing your service to the public internet. Generally speaking, there is nothing wrong with this.
The first major tradeoff emerges with cloud-brokered reverse proxies like Cloudflare Tunnels or Ngrok. Because they intercept your traffic in the cloud, they act as a mandatory man-in-the-middle decrypting your SSL before passing it down a tunnel to your network edge. While this allows them to inspect and block bad traffic, it breaks strict compliance rules like HIPAA, where sensitive data must remain completely unreadable by third parties between the client and the destination.
The second tradeoff is exposure. If you are hosting a sensitive internal site, like a password manager or a web panel for a legacy hardware controller, a standard reverse proxy leaves it discoverable to anyone with a web browser. Modern tools can throw an authentication page in front of it, but your resource is never truly "cloaked" from the public internet. Undetected vulnerabilities remain exploitable.
To solve both issues simultaneously, we have to flip the architecture: combine peer-to-peer networking with an edge reverse proxy. Instead of relying on public DNS and a cloud server to terminate connections, the client connects to a virtual private network (VPN) and resolves DNS entirely over the tunnels. The HTTPS traffic travels over a blind transport layer and decrypts all the way down at the local network edge. The result is a service that is fully functional with valid SSL, yet entirely cloaked and untraceable from the public internet.
All code is available on GitHub: [https://github.com/fosrl/pangolin](https://github.com/fosrl/pangolin)
## Key details
### Cloud-Terminated vs. Edge-Terminated
Briefly, to understand the difference, look at how the lifecycle changes in these two diagrams.
Traditional Cloud-based Tunneled Reverse Proxy:
Peer-to-Peer Tunneled Edge Reverse Proxy:
### How Did We Build It?
A quick background on our architecture: Pangolin natively provides two core capabilities. First, a server-terminated, cloud-based reverse proxy (our direct alternative to Cloudflare Tunnels). Second, a client-to-site peer-to-peer VPN. In both setups, you deploy a lightweight site connector (which we sometimes nickname a Newt) on your local network to facilitate access.
To deliver this new "private HTTPS" modality, we smashed components from both products together.
Here is exactly how the layers come together under the hood to make the system work. (And yes, if you want to skip straight to the implementation, the code is all [available on GitHub](https://github.com/fosrl/pangolin)).
### Hijack the OS DNS
To get traffic into a private tunnel without forcing the user to type in a raw IP address you have to capture their web traffic at the very beginning of its lifecycle: the DNS request.
If a user types `https://vault.pangolin.net` into their web browser, we cannot let that request escape to a public DNS server like `1.1.1.1` or `8.8.8.8`. If it leaks, the request fails, or worse, reveals internal domain topography to the public internet. First, we had to build a mechanism that hijacks the operating system’s DNS routing without breaking the user’s normal internet traffic.
This is easily the most brittle and complex part of the codebase because every operating system handles DNS configuration differently. To make this seamless, we built native clients for macOS, Windows, Linux, iOS, and Android to tap into platform-specific networking APIs. For example, on macOS, we leverage the native System Extensions combined with `scutil` to dynamically set our private DNS server at the top of the network interface resolution order.
### Local DNS Resolution and Logical Mapping
Once the OS-level hook is established, the Pangolin client starts a tiny local DNS server listening directly inside our virtual network interface (usually at `100.96.128.1`). Because it lives right on the interface, the traffic never leaves your machine
When the OS pipes a private domain query to this interface resolver, we don’t resolve it to a physical IP on the local network. Instead, the local resolver maps that friendly domain to a unique, logical overlay address (within the `100.96.128.0/18` range) assigned to that resource. This is all under the hood and you never have to think about the overlay address space.
To the browser and the operating system, this looks like a completely standard networking event. The browser receives the logical IP, assumes it’s talking to a normal web server and initiates a standard TCP handshake. Behind the scenes, the Pangolin client intercepts those TCP packets destined to `100.96.128.20` and preps them to be shot across our virtual private network.
### Smart P2P Routing & Anycast-style Site Selection
The core peer-to-peer transport and NAT traversal are already standard features of the primary Pangolin VPN. We can treat the connection itself as a black box, but to learn more about how that works, checkout our [explanation on how Pangolin punches through NATs and firewalls](/news/nat-holepunching). Part of the magic for our private HTTPS modality lies in how the client chooses where to send traffic.
For high availability, a private resource can be fronted by multiple site connectors deployed across different physical offices or regions.
Before firing packets to a site, the client first sends small health probes to all sites that you configure that are available as routable for this resource. Based on uptime status and round-trip time, the client chooses to send the packets to the most ideal site.
For example, a user in New York automatically routes through the New York site connector instead of the Los Angeles connector due to the lower latency. If a connector drops offline, the client detects the failure, and fails over to the next best path.
### Push Automated Certificates to the Edge
Once the client selects the optimal site, the encrypted packets travel over the peer-to-peer tunnel to the site and land directly at your local perimeter.
To prevent browsers from throwing certificate warnings, the edge needs a valid SSL cert. However, we cannot run a standard HTTP-01 challenge at the edge because they are completely hidden from the public internet with zero inbound open ports.
How do we automatically generate valid LetsEncrypt certs and get them to the edge?
The central Pangolin control server already manages certs on behalf of your domains using standard LetsEncrypt DNS or HTTP challenges. We need these for the cloud brokered reverse proxy.
Therefore, we can issue certs at the control server level, then use a websocket to push these valid certs down to the on-prem site connectors. The edge infrastructure never faces the public internet or runs its own ACME client. It simply receives its valid certs from the cloud control plane and stores them in its memory.
### Embedded Micro-Proxy at the Perimeter
This is where everything we’ve built comes to a head. The encrypted packets have now arrived over a blind peer-to-peer tunnel, jumped over any firewalls, and landed on the site sitting in your network. Now, we have to turn that raw network stream back into a secure web session. To do that, we embedded our own, highly optimized, tiny, reverse proxy directly into the site binary itself. We built the proxy using basic Go standard library networking tools.
In the traditional reverse proxy setup, the proxy sits on the public internet, accepts connections, terminates SSL, and passes traffic inward. In our model, the tunnel terminates first, then the reverse proxy handles the payload.
Because our local client-side DNS server preserved the original domain request, the browser initiates a standard TLS handshake over the P2P connection. When those packets hit the site, the embedded proxy intercepts them, reads the incoming HTTP host header or SNI, matches it against the propagated certificates, and completes the TLS handshake. SSL terminates at the edge.
Once the traffic is safely decrypted inside your network, the small micro-proxy forwards the plain HTTP request to the downstream target resource you configured in Pangolin.
### Auditing and Logging
The micro-proxy at the edge can still log HTTP requests and enforce rules and authentication – all the same things the cloud broker reverse proxy can do. The difference is, the site collects this data, cleans it, bundles it, and pushes it back up to the cloud for auditing and analytics purposes. This way you can centralize all your edge reverse proxies under one platform.
### One Small Edge Case
Browsers like Chrome maintain internal DNS caches that completely bypass the OS routing table. If a user tries to visit `vault.pangolin.internal` before starting the client, the browser might query public DNS, get an NXDOMAIN, and aggressively cache it. This only ocurrsif the domain already exists on a public DNS server.
When the tunnel boots a second later, the browser completely ignores our local DNS server and keeps trying to hit the public internet. Because browsers don't expose an external API to force-flush this cache, there is no clean programmatic fix. The user simply has to wait out the TTL, open a new tab or session, or manually restart the browser to force it to see the new DNS hooks.
## Conclusion
Ultimately, shifting the reverse proxy from a centralized cloud data center directly to the local network edge proves that zero-trust convenience doesn't require sacrificing data transport privacy. By combining platform-native DNS manipulation, automated wildcard certificate orchestration, and localized perimeter decryption, we can completely cloak critical infrastructure at the edge from the public internet while ensuring end-to-end regulatory compliance for sensitive payloads. Security should protect your data, not act as a mandatory third-party intermediary and by reversing the traditional proxy architecture, you get the absolute best of both worlds.
---
### GitOps for Pangolin Blueprints: Access Control via CI/CD
URL: https://pangolin.net/news/gitops-pangolin-blueprints-ci-cd
Published: 2026-05-06
Summary: Manage Pangolin Blueprints with GitOps using declarative YAML, pull request review, and GitHub Actions automation.
Category: Guides
As Pangolin environments grow, managing resource and access changes only in the dashboard can add operational overhead. New environments get added, existing ones change direction, and policies can drift from the original intent.
GitOps is the practice of keeping operational state in version control and applying that state through automation. For Pangolin, that means storing blueprints in Git and letting CI apply them instead of treating the dashboard as the source of truth.
That gives teams a few practical benefits immediately:
* version history for every exposure and access change
* pull request review before changes reach Pangolin
* cleaner rollback when a hostname, target, or policy change needs to be reversed
* easy ability to apply changes in bulk for large-scale management and rapid provisioning
* less dashboard drift between intended state and live state
## GitOps implementation flow
### Keep blueprint.yaml in a GitOps repo
The important pattern is simple:
1. The blueprint lives in a Git-managed operations repo.
2. Pull requests update the Pangolin definition together with the rest of the environment change.
3. GitHub Actions applies the blueprint from that repo.
That turns Git into the source of truth for exposure intent and access state.
If a target changes, a domain changes, or a user list changes, the reviewer can see that change in the same pull request as the rest of the operational change. That is a much better model than changing infrastructure in one place and fixing Pangolin later in a dashboard.
One common layout looks like this:
```plaintext
pangolin-gitops/
├─ blueprints/
│ ├─ customer-a.yaml
│ └─ customer-b.yaml
└─ .github/workflows/apply-blueprints.yml
```
That is only one way to structure it. Some teams keep blueprints with application code, but a separate GitOps repo is often cleaner when Pangolin definitions are shared operational state managed by platform or infrastructure teams.
### What a Pangolin blueprint controls
In Pangolin, a blueprint is a declarative definition for resources and their settings. For this workflow, YAML is the useful format because it sits naturally in Git and can be applied from CI. For the broader feature, see [Blueprints](https://docs.pangolin.net/manage/blueprints).
The important part is not that the file is YAML. The important part is that it captures the intended state:
* what resource should exist
* where it should point
* which site it belongs to
* who should be allowed to reach it
That is the information teams often leave split across deployment notes, dashboard settings, and memory. A blueprint pulls it back into one reviewable file.
### Example blueprint.yaml
Suppose one customer environment needs both a private connectivity path and a published web service. The same blueprint can define both.
```yaml
private-resources:
ssh-resource:
name: SSH Server
mode: host
destination: localhost
site: customer-a
tcp-ports: "22"
disable-icmp: false
alias: ssh.example.local
roles:
- Customer1
- DevOps
users:
- user@example.com
public-resources:
secure-resource:
name: Web Resource
protocol: http
full-domain: secure-resource.example.com
auth:
sso-enabled: true
sso-roles:
- Member
sso-users:
- user@example.com
targets:
- site: customer-a
hostname: localhost
method: http
port: 8080
```
This file is doing real work:
* it defines a private resource for host-level access
* it defines a public web resource on the same site
* it scopes private access by roles and users
* it scopes public access through SSO roles and users
Without a blueprint, teams usually make those changes directly in the dashboard. With a blueprint, the same changes live in version control and move through review first.
### How to use Pangolin in CI with GitHub Actions
Once blueprint.yaml is in a GitOps repo, GitHub Actions becomes the apply step that keeps Pangolin aligned with the reviewed state.
The sequence is straightforward:
1. An operator updates the blueprint or related environment definition.
2. The change goes through pull request review.
3. GitHub Actions applies blueprint.yaml.
4. Pangolin updates the resource state to match Git.
That means Pangolin stops being a manual follow-up step after an environment change. It becomes part of the CI workflow itself.
### GitHub Actions example
At a minimum, the workflow needs to check out the repo and apply the blueprint with the new non-interactive CLI flags.
```yaml
name: Apply Pangolin blueprint
on:
push:
branches:
- main
jobs:
apply:
runs-on: ubuntu-latest
steps:
- name: Check out repository
uses: actions/checkout@v4
- name: Install Pangolin CLI
run: curl -fsSL https://static.pangolin.net/get-cli.sh | bash
- name: Apply Pangolin blueprint
env:
PANGOLIN_INTEGRATION_API_KEY: ${{ secrets.PANGOLIN_INTEGRATION_API_KEY }}
PANGOLIN_ENDPOINT: ${{ secrets.PANGOLIN_ENDPOINT }}
PANGOLIN_ORG_ID: ${{ secrets.PANGOLIN_ORG_ID }}
run: |
pangolin apply blueprint \
--api-key "$PANGOLIN_INTEGRATION_API_KEY" \
--endpoint "$PANGOLIN_ENDPOINT" \
--org "$PANGOLIN_ORG_ID" \
--file ./blueprints/customer-a.yaml
```
The rest of the infrastructure workflow will vary by team. The useful boundary is that the blueprint gets applied from the same reviewed Git state that approved the access change.
Keep the secret-handling boring:
* store Pangolin credentials in GitHub Secrets
* do not hardcode credentials in the workflow
* do not make blueprint apply a separate manual runbook
* keep the API key, endpoint, and org ID in CI secrets, not in the repo
### Why CI beats dashboard-only changes
The dashboard is useful, but it is a weak source of truth for Git-managed environment and access changes.
If environment changes happen in Git while Pangolin changes happen somewhere else, reviewers do not get one clear picture of intent. A hostname change, target change, or access-list change is not cosmetic. It changes what is exposed and who can reach it.
Putting that in a blueprint gives you a cleaner workflow:
* access changes get code review
* version history stays in Git instead of disappearing into the dashboard
* exposure changes show up in Git history
* rollback is easier to reason about
* drift is easier to spot
* the access layer stops becoming a hidden manual system
If changing access means editing one file in the GitOps repo and letting CI apply it, precise resource changes stay realistic. If the alternative is another set of manual dashboard steps every time a target or user list changes, drift keeps growing.
## Conclusion
Pangolin is easier to review at scale when blueprint state lives in Git and CI applies it consistently.
Blueprints and GitHub Actions give you a cleaner path. Keep blueprint.yaml in a GitOps repo. Review the environment and exposure changes together. Apply them together.
That does not eliminate access management work. It does put that work back inside a normal Git-managed workflow, which is usually where it belonged all along.
## FAQ
**What is a Pangolin blueprint?**
*A Pangolin blueprint is a declarative configuration for resources and their settings. In practice, it lets you manage exposure and access settings as code instead of only through the dashboard.*
**Should blueprint.yaml live in a dedicated GitOps repo?**
*Usually yes, if Pangolin state is owned by platform or infrastructure workflows. The important part is that it lives in version control and moves through the same review and CI path as the change it belongs to. Some teams still keep it with application code, but that is an implementation choice, not the core requirement.*
**Can GitHub Actions apply Pangolin blueprints automatically?**
*Yes. Pangolin supports applying blueprints through the CLI with non-interactive flags for API key, endpoint, and org ID, which makes the workflow a good fit for CI/CD.*
**Are blueprints better than managing everything in the dashboard?**
*For teams that want reviewability, version history, and automation, usually yes. The dashboard still has value, but blueprints are the better fit when Git should be the source of truth.*
**Can I keep Pangolin blueprints outside the app repo?**
*Yes. This guide assumes a dedicated GitOps repo because that is often the cleaner model for platform and infrastructure teams. Keeping the blueprint with application code is also possible if that matches your operating model better.*
**Do blueprints replace access design?**
*No. They make access design easier to preserve operationally. Teams still need to decide what should be exposed and who should be allowed to reach it.*
---
### Templated Provisioning and Rollouts for the Edge
URL: https://pangolin.net/news/templated-provisioning-and-rollouts-for-the-edge
Published: 2026-05-01
Summary: Automate edge device rollouts with Pangolin provisioning keys, declarative blueprints, and golden-image workflows.
Category: Guides
Pangolin is a remote access and management solution designed for the edge. Its site- and resource-based architecture is purpose-built for servicing large fleets of IoT devices. This guide demonstrates how Pangolin can be deployed in an automated, templated, and consistent manner across a global fleet.
## **Why Is Device Provisioning Difficult?**
Provisioning remote access to edge devices is traditionally a complex, manual process. Standard workflows often require writing intricate scripts to interact with APIs, generating unique credentials or certificates for every individual device, and securely distributing those keys to remote hardware.
Once an agent is running on the device, you typically face a second hurdle: configuring the service. This involves either more API scripting or manually clicking through a dashboard to define [SSH access](/news/how-to-ssh-with-pangolin), IP addresses, users, and Role-Based Access Control (RBAC).
For hundreds or thousands of devices this is brittle and hard to scale. Even worse, there isn’t a single source of truth.
## **The Power of Automated Rollouts and Templated Deployments**
When managing edge devices at scale, a consistent rollout is essential. Manual configurations lead to configuration drift, increased operational costs, and security gaps. Templated deployments ensure every device is provisioned with a verified and uniform configuration.
A single image with templated variables enables you to create a “golden image” so new deployments are predictable and don’t require manual setup. Changes to edge configurations can be pushed and applied automatically and declaratively, ensuring the local configuration remains the source of truth.
Pangolin simplifies this through Provisioning Keys and Declarative Blueprints. These tools allow you to use existing orchestration pipelines (like Ansible or Puppet) to deploy identical configuration files across your fleet without custom scripting.
## Provisioning workflow
### **Create the Provisioning Key**
Typically, a Pangolin site connector (known as Newt) requires a unique ID and Secret to authenticate. Generating these individually for thousands of devices is inefficient.
Provisioning Keys solve this by acting as a temporary handshake. When Newt starts for the first time, it exchanges the provisioning key for a permanent, unique ID and Secret. It then overwrites its own configuration file, wiping the provisioning key from the disk. This ensures that even if a device is later compromised, the original key is gone and the device possesses its own isolated credentials.
To set this up:
1. Navigate to the Pangolin Dashboard > Management > Provisioning.
2. Generate a new key.
3. (Optional) Set security constraints, such as an expiration date (e.g., one week) or an activation limit (e.g., 50 uses).
Create a `/var/config.json` file that looks like this on your device and include the key you just generated:
```json
{
"Name": "{{env.HOSTNAME}}",
"provisioningKey": "spk-g6smpa86cn6oa2h.o3efm7a7rl5cn7exqpdsuxacnup7b7v36biq4o25",
"endpoint": "https://app.pangolin.net"
}
```
After the first run, Newt will automatically overwrite this file with unique credentials:
```json
{
"id": "2ix2t8xk22ubpfy",
"secret": "nnisrfsdfc7prqsp9ewo1dvtvci50j5uiqotez00dgap0ii2",
"endpoint": "https://app.pangolin.net"
}
```
When creating a provisioning key, you will notice an Approve New Sites checkbox. When enabled, any new site created using that key is automatically added to your production site table. If disabled, new sites are placed in a "pending" state which is essentially a waiting room that requires an administrator to manually review and approve or reject the connection before it moves into production. This adds an extra layer of security for high-trust environments.
### **Create the Blueprints**
Getting a device online is only the first step. Blueprints eliminate the need to manually configure resources (like SSH or Web access) in the dashboard.
Blueprints are a declarative YAML file that defines exactly what resources should exist and how they should be configured on that device. You define Pangolin resources (public or private) for this device and include roles or users that should have access. You can use environment variables like `{{env.SERIAL_NUMBER}}` so that each device dynamically names its own resources or domains for easier management later.
Reference the blueprint documentation to create a file for you, but this is a simple example [https://docs.pangolin.net/manage/blueprints](https://docs.pangolin.net/manage/blueprints). Create the blueprint in /var/blueprint.yml:
```yaml
private-resources:
ssh-resource:
name: SSH Server
mode: host
destination: localhost
tcp-ports: "22"
roles:
- Engineering
- DevOps
public-resources:
secure-resource:
name: Web Resource
protocol: http
full-domain: {{env.SERIAL_NUMBER}}.example.com
auth:
sso-enabled: true
sso-roles:
- Admin
targets:
- site: my-site
hostname: app
port: 8080
method: http
```
When provisioned, this blueprint will create a resource like this:
A couple notes about using blueprints this way:
Usually when using blueprints to define resources you must define the sites on each so Pangolin can route to the right device, but when a blueprint is applied via Newt, the local site is automatically assigned to the resources, removing the need to define site IDs manually.
Pangolin gives you two ways to manage these configurations long-term:
* **Provisioning Mode**: Use `--provisioning-blueprint-file`. The device sets itself up once, and then you can make manual tweaks in the dashboard that won't be overwritten.****
* **Continuous Sync**: Use `--blueprint-file`. This makes the device the "source of truth." If you need to change the SSH ports across 500 devices, you just push an updated YAML file to them. newt watches that file, detects the change, and updates the Pangolin cloud immediately.
### **Deploy via systemd**
Finally, we need a way to run newt, the site connector. Systemd is a good option because it is easy to push out using tools like Ansible or Puppet. You should deploy the exact same service file and config to every device in your fleet (that's configured the same) then start the systemd service. When newt runs for the first time it will trigger the provisioning and connection process.
Either push the Newt binary directly to `/usr/local/bin` or download it with:
`curl -fsSL https://static.pangolin.net/get-newt.sh | bash`
Define the `/etc/system/systemd/newt.service`:
```plaintext
[Unit]
Description=Pangolin Newt Connector
After=network-online.target
[Service]
Type=simple
Environment=SERIAL_NUMBER=123456789
Environment=HOSTNAME=my-device-1
ExecStart=/usr/local/bin/newt --config-file /var/newt.json --provisioning-blueprint-file /var/blueprint.yml
Restart=always
RestartSec=2
[Install]
WantedBy=multi-user.target
```
The environment variables `HOSTNAME` and `SERIAL_NUMBER` should be available to the binary via environment variables in the systemd service so that newt can inject them. If you are not using interpolation this is not required.
## **Wrapping Up**
Pangolin simplifies the complex and typically brittle process of provisioning remote access to edge devices using provisioning keys and blueprints. By creating a temporary provisioning key that the Newt site connector exchanges for a unique permanent ID and secret upon first run and defining resources and access controls using declarative YAML blueprints you eliminate the need to script against the service API. Deploying the Newt connector using a systemd service file is easy and allows a single configuration to be deployed across thousands of units using existing pipelines like Ansible or Puppet.
---
### Pangolin 1.18: HTTPS Private Resources, Multi-Site, & Alerts
URL: https://pangolin.net/news/1-18-release
Published: 2026-04-28
Summary: Pangolin 1.18 adds HTTPS private resources, multi-site routing, uptime tracking, alert rules, and wildcard resources.
Category: Product
Pangolin 1.18 is a big one. This release adds HTTPS support for private resources, multi-site high-availability routing, uptime tracking, a flexible alerting system, wildcard resources, and more. Let's walk through everything.
## Release highlights
### HTTPS on Private Resources
Private HTTP is a new kind of private resource designed for web workloads. It works like a public resource in that it gets a real domain name on your Pangolin-managed domain and traffic flows through a reverse proxy with valid TLS, but it's only reachable when the user has an active Pangolin client connection. Nothing is exposed on the public internet.
When a connected user opens the URL in their browser, Pangolin resolves the name through the tunnel, the site-side reverse proxy terminates TLS using a certificate provisioned by the control plane, and the request is forwarded to your backend. The scheme and destination port are both configurable. If you've been approximating this with aliases and non-standard ports, private HTTP is the cleaner answer!
Read more about [HTTPs on private resources](https://docs.pangolin.net/manage/resources/private/private-http) in the docs.
### Multi-Site Routing (HA) on Private Resources
Private resources now support multiple sites. Attach more than one site connector to a resource and Pangolin routes client traffic through whichever path is best at the time, weighing factors like latency and availability. If a site goes offline, clients automatically fail over to the next available site with no manual reconfiguration needed.
A common pattern is redundant connectors into the same network. Install a Pangolin site on two servers in the same LAN, attach both to your private resource, and you have a resilient path in. One connector goes down and users stay connected through the other.
The one requirement is that every site you attach must have routable access to the resource's destination. Pangolin assumes any site in the list is a valid path to the same backend, so confirm reachability before adding a site. Expect a short gap of a few seconds during failover while the downed site is registered and routing changes propagate to clients.
Read more about [multi-site routing on private resources](https://docs.pangolin.net/manage/resources/private/multi-site-routing) in the docs.
### Uptime Tracking
Sites and resources now track uptime. You'll see uptime history on site and resource detail pages, giving you a quick at-a-glance view of recent availability. This also serves as the jumping-off point for creating alert rules. More on that below!
### Standalone Health Checks
Pangolin now supports standalone health checks that aren't tied to any resource. Pick a site to run the probe from, give it a target, choose HTTP or TCP, configure your timing and thresholds, and Pangolin continuously checks whether that endpoint is reachable from the site's network.
This is useful for anything you want to monitor but haven't modeled as a Pangolin resource such as a network printer, an IP camera, a PLC, a legacy server. HTTP checks issue a full request and validate the response; TCP checks simply confirm a connection can be established on a given port.
Read more about [health checks](https://docs.pangolin.net/manage/alerting/health-checks) in the docs.
### Alert Rules
Alert rules let you subscribe to state changes across sites, resources, and health checks and automatically deliver notifications when something happens. Setup involves three steps: choose a source (what to watch), a trigger (which change should fire the rule), and one or more actions (what to do).
Actions include email to users, roles, or arbitrary addresses; webhooks that POST a JSON payload to any URL; and native integrations with PagerDuty, Opsgenie, ServiceNow, and incident.io. You can stack multiple actions on the same rule.
You can create rules from the Alert rules page under Alerting, or jump directly from a site or resource detail page using the Create alert rule shortcut near the uptime graph.
Read more about [alert rules](https://docs.pangolin.net/manage/alerting/alert-rules) in the docs.
### Wildcard Resources
Public resources now support wildcard subdomains. Set the subdomain field to * and Pangolin routes every hostname at that level through the same resource and tunnel. Access rules and authentication apply across all matched hostnames, and the original Host header is preserved so downstream systems can continue routing as expected.
Wildcards require TLS certificates that cover *.your-level, which means DNS-01 validation. HTTP-01 can only prove a single exact hostname. For self-hosted Pangolin, configure Traefik and Let's Encrypt for DNS-01 and set up wildcard DNS records. For Pangolin Cloud, use a domain delegation and Pangolin handles the certificates automatically.
Read more about [wildcard resources](https://docs.pangolin.net/manage/resources/public/wildcard-resources) in the docs.
### General Improvements and Bug Fixes
A handful of smaller but worthwhile additions made it into 1.18 as well:
1. **Import an identity provider across organizations**. Organization-level identity providers can now be shared across organizations. From the Identity Providers table, click Add Identity Provider and choose Import to see providers from other organizations where you're an administrator. Auto-provisioning settings are configured separately per organization since each has its own roles, but the underlying provider configuration is shared.
2. **Quickly see resources associated with a site**. On the sites table, clicking the resource count text or opening the three-dot row menu now takes you directly to the resources table with a filter already applied for that site. The site edit page also now shows a simplified list of resources associated with that site.
3. **Reject pending sites**. Admins can now reject sites from the Pending Sites tab rather than only being able to approve them.
As always, this release also includes various other UI improvements and bug fixes throughout the product.
## Looking Forward
1.18 brings features that connect to each other in meaningful ways: health checks feed into alerting, uptime feeds into alerting, multi-site routing feeds into high availability. We're excited to see how you put it all together!
Give us a star: [https://github.com/fosrl/pangolin](https://github.com/fosrl/pangolin)
Stay tuned!
---
### Pangolin Remote Nodes: Cloud Control Plane & Failover
URL: https://pangolin.net/news/pangolin-remote-nodes-guide
Published: 2026-04-23
Summary: Pangolin remote nodes let you keep the traffic edge on infrastructure you control while Pangolin Cloud handles DNS, certificates, health checks, and failover.
Category: Product
Pangolin remote nodes are for teams that want Pangolin Cloud to run the control plane while they keep the traffic edge on infrastructure they control.
You keep ingress, TLS termination, relay-capable edge handling, regional placement, and bandwidth on your own hosting footprint without also taking on Pangolin’s database, DNS, certificate lifecycle, health monitoring, and failover coordination.
This is not full self-hosting, and it does not replace sites. It is a split deployment model: Pangolin Cloud runs the coordination layer, and your remote node runs the edge that receives and serves traffic. For the broader product model behind sites and resources, see [How Pangolin Works](https://docs.pangolin.net/about/how-pangolin-works).
## Why use Pangolin remote nodes?
Pangolin Cloud is simpler to operate, but some teams do not want all traffic ingress and relay capacity to go through the cloud infrastructure.
Remote nodes solve that by moving the traffic edge onto infrastructure you choose while keeping the hard coordination work in Pangolin Cloud.
That usually matters for a few reasons:
* you want TLS termination and public ingress on infrastructure you control
* you want a point of presence closer to users or workloads
* you want more control over relay placement for private-resource fallback traffic
* you expect sustained traffic and want to spec the bandwidth requirements of the edge yourself
* you want Pangolin-managed high availability, load balancing, and failover without fully self-hosting Pangolin
## Remote node architecture
### What is a Pangolin remote node?
A remote node is a self-hosted Pangolin edge managed by Pangolin Cloud.
In practice, the node runs the following components:
* pangolin-node, which keeps the node connected to Pangolin Cloud and applies edge configuration
* Gerbil, which handles WireGuard tunnel and relay behavior
* Traefik, which handles HTTP(S) routing and TLS termination
This is the part of the system where traffic lands. Browser traffic for public resources can terminate here. Tunnel traffic can terminate here. Relay traffic can pass through here when a direct peer-to-peer path is not available between clients and sites.
That is why a remote node is lighter than full self-hosting. You are running the traffic edge, not the whole platform.
### What runs on a remote node, and what Pangolin Cloud still manages
Remote nodes make the most sense once you separate the control plane from the data plane.
Pangolin Cloud stays responsible for the control plane:
* the dashboard and API
* configuration state for sites, resources, domains, and policies
* certificate issuance and renewal
* DNS answers for Pangolin-managed hostnames
* node health monitoring
* failover decisions
* synchronization of routes and edge configuration
Your remote node is the data plane:
* it receives and serves traffic on your infrastructure
* it uses your network path and bandwidth
* it terminates tunnels and HTTPS sessions
* it can relay traffic when clients cannot establish a direct path
That split is the whole point. You get control over where traffic runs without taking on the operational burden of the supporting control-plane stack.
### Do remote nodes replace sites?
Remote nodes do not replace [sites](https://docs.pangolin.net/manage/sites/understanding-sites), or the site connector (often called Newt). The connector is still the site that links a private network back into Pangolin. Sites still define where resources live. Access is still granted at the resource layer.
Remote nodes change where the Pangolin traffic edge runs.
That means the system still works through the same core model:
* sites connect private networks into Pangolin
* resources define what users are allowed to reach
* remote nodes receive and serve traffic at the edge
* Pangolin Cloud coordinates the system around them
If someone is trying to understand remote nodes as “the new thing that replaces Newt,” they are using the wrong frame.
### How remote nodes work with public and private resources
Remote nodes matter for both public and private traffic, but not in the same way.
For [Public Resources](https://docs.pangolin.net/manage/resources/understanding-resources#public-resources), the remote node acts as the front door. It can terminate HTTPS, route requests, and serve traffic from infrastructure you control instead of from Pangolin Cloud’s shared edge.
For [Private Resources](https://docs.pangolin.net/manage/resources/understanding-resources#private-resources), the remote node is not the site connector and not the resource itself. Private resources still depend on the site layer behind the connector. What the remote node changes is where relay-capable edge handling can happen when direct peer-to-peer connectivity is not available.
In practice:
* for public resources, remote nodes directly affect where user-facing web traffic lands
* for private resources, remote nodes affect fallback and relay behavior, not the basic site model
Use this mental model: public traffic can terminate on the remote node, while private traffic still relies on sites and clients, with the remote node helping when relaying is needed.
### Why remote nodes need Pangolin-managed DNS
Remote nodes only deliver clean failover if Pangolin can move traffic between edges without forcing you to change the public hostname manually.
That is why Pangolin needs authority over resource DNS for remote-node deployments. If you pin a hostname to one remote node with a static A record, you lose most of the operational benefit of Pangolin-managed failover. The hostname now points at one IP, and recovery depends on manual DNS changes and resolver cache timing.
For remote nodes, Pangolin needs to be able to:
* move a hostname between remote nodes
* fail traffic over from a remote node to cloud infrastructure
* keep the same public hostname while the serving edge changes
* manage certificate validation records
The practical rule is simple: if you want Pangolin-managed HA, do not point resource hostnames directly at a remote node IP with a static A record.
Use a Pangolin-controlled DNS path instead:
* delegate a domain or subdomain with NS records when Pangolin should manage that resource namespace
* use a CNAME when you want to keep your main DNS provider and let Pangolin control the final destination for a hostname
### Why remote nodes are easier than full self-hosting
The strongest reason to use remote nodes instead of full self-hosting is that Pangolin Cloud keeps the coordination work off your plate.
In a fully self-hosted high-availability deployment, you are not just running edge services. You are also responsible for the systems around them: persistent state, DNS, certificate coordination, health checks, node synchronization, and the logic that lets one edge take over cleanly from another.
With remote nodes, Pangolin Cloud handles that layer for you.
That means:
* no hand-managed certificate copying between edges
* no manual reverse-proxy sync across nodes
* easier node replacement when an edge needs to be rebuilt
* cleaner failover because the standby edge already has the right hostname and routing state
* ability to run more than one Pangolin instance with a shared dashboard and backend
That is the real difference between running some traffic handling yourself and running the whole platform.
### How remote-node failover works
Remote nodes are most useful when you think about them as part of a coordinated edge system, not as a single server with cloud branding.
If you run multiple remote nodes, Pangolin can move traffic between them when one node becomes unhealthy. The destination node already has the configuration and certificate state it needs to serve the same hostname, so failover does not depend on rebuilding the edge first.
Pangolin can also fail traffic over from your remote node to cloud infrastructure. That gives you a useful operating model: keep traffic on your own edge during normal operation, but avoid a hard outage when your self-hosted edge is unavailable.
That fallback is one of the reasons DNS control matters so much. Pangolin can only move traffic cleanly if it can move the hostname.
## Remote nodes vs full self-hosting
These options sound close, but they solve different problems.
With a remote node, you run the edge and Pangolin Cloud runs the coordination layer. With full self-hosting, you run both.
| Deployment model | Who runs the control plane | Who runs the traffic edge | Best fit |
| --- | --- | --- | --- |
| **Pangolin Cloud** | Pangolin Cloud | Pangolin Cloud | Teams that want the lowest operational burden |
| **Pangolin Cloud + remote nodes** | Pangolin Cloud | You | Teams that want a self-hosted edge without self-hosting the full platform |
| **Full self-hosting** | You | You | Teams that want full ownership of the platform and its supporting infrastructure |
Remote nodes are the better fit when you want:
* a self-hosted edge with hosted coordination
* regional or provider-specific edge placement
* Pangolin-managed DNS, certificates, and failover
* less operational complexity than a full HA self-hosted deployment
Full self-hosting is the better fit when you want:
* complete ownership of the control plane as well as the edge
* self-managed DNS and certificate workflows
* self-managed database and coordination layers
* full responsibility for HA design and maintenance
The mistake is treating remote nodes as a halfway marketing term for self-hosting. They are a specific split: self-hosted traffic edge, hosted control plane.
## Which deployment model should you choose?
Use this as the quick decision version:
| If you want... | Choose... |
| --- | --- |
| the simplest setup with hosted ingress and hosted coordination | **Pangolin Cloud** |
| traffic handling on your own infrastructure, but managed DNS, certificates, and failover | **Pangolin Cloud + remote nodes** |
| full control over the control plane, edge, and supporting services | **Full self-hosting** |
## When to choose a Pangolin remote node
Choose a remote node when Pangolin Cloud is the right operating model overall, but you want more control over where traffic is handled.
That is usually the right call when:
* your team wants hosted coordination but self-hosted ingress
* you need regional edge placement for users, workloads, or compliance
* you want TLS termination on infrastructure you control
* you want your own hosting footprint to carry relay-capable traffic
* you want failover and HA without building the full control-plane stack yourself
If Pangolin Cloud already meets your traffic-handling requirements, you may not need remote nodes. If you want to own the entire platform end to end, remote nodes are also not the final step. Full self-hosting is.
## Conclusion
Remote nodes let you keep the Pangolin traffic edge on infrastructure you control without forcing you to self-host the control plane behind it.
That gives you a cleaner middle ground between plain Pangolin Cloud and full self-hosting. You keep control over ingress, relay-capable edge placement, and traffic capacity. Pangolin Cloud keeps the DNS, certificates, health monitoring, and failover machinery that make the system practical to run.
If that is the deployment tradeoff you want, remote nodes are the right model.
For deeper architecture detail, the most useful references are [How Pangolin Works](https://docs.pangolin.net/about/how-pangolin-works), [System Architecture](https://docs.pangolin.net/development/system-architecture), and [Understanding Sites](https://docs.pangolin.net/manage/sites/understanding-sites).
## FAQ
**What are Pangolin remote nodes?**
*Pangolin remote nodes are self-hosted traffic edges managed by Pangolin Cloud. They allow you to run tunnels, TLS termination, and traffic handling on infrastructure you control, while Pangolin Cloud manages DNS, certificates, health checks, and failover.*
**Do Pangolin remote nodes support high availability?**
*Yes. Pangolin remote nodes enable high availability by allowing Pangolin Cloud to coordinate traffic routing and automatic failover between nodes or to cloud infrastructure.*
**Do remote nodes replace Newt?**
*No. Newt still connects sites into Pangolin. Remote nodes only change where the traffic edge runs, not how sites connect or how resources are defined.*
**What runs on a Pangolin remote node?**
*A Pangolin remote node runs pangolin-node, Gerbil, and Traefik. Together, these components handle edge connectivity, WireGuard tunnel and relay behaviour, HTTP(S) routing, and TLS termination.*
**Why does Pangolin manage DNS for remote nodes?**
*Pangolin manages DNS to support seamless failover and routing. This allows a resource hostname to move between remote nodes or fall back to cloud infrastructure without changing the public URL. Using static A records removes this flexibility and breaks failover.*
**Are Pangolin remote nodes only used for public resources?**
*No. Remote nodes primarily handle public resource traffic, but they also play a role in private resource relay when a direct peer-to-peer connection cannot be established.*
**When should you use remote nodes instead of full self-hosting?**
*Use Pangolin remote nodes when you want a self-hosted edge without managing the full control plane. Full self-hosting is a better fit if you need control over the database, DNS, certificate workflows, and high availability coordination.*
**Can Pangolin fail over between remote nodes?**
*Yes. Pangolin supports automatic failover between remote nodes and can also route traffic from a remote node to cloud infrastructure when configured as a fallback.*
---
### Ignition Remote Access Without Open Ports
URL: https://pangolin.net/news/ignition-remote-access-without-open-ports
Published: 2026-04-22
Summary: Keep Ignition private while providing authenticated browser access and narrow engineering connectivity without open ports.
Category: Guides
Ignition remote access gets complicated when every user is treated the same. Operators checking dashboards, integrators opening the Designer, and vendors on short support windows do not need the same path. When teams ignore that, they usually end up with either a port forwarding or a broad VPN.
## Ignition remote access needs two access models
Before looking at the access methods, it helps to define the types of access teams are usually trying to support.
Some users only need dashboards, alarms, reports, and other browser-based tools. That is an application-access problem.
Other users need access to the Designer or administrative functions. That is a private-connectivity problem.
Because these workflows have different requirements, they should be handled differently.
## How teams usually solve Ignition remote access
Teams usually default to two methods: opening a port or using a VPN. Both can provide remote access, but both come with trade-offs.
Opening a port is straightforward from a networking perspective. The user reaches the application through an IP address and port, but that also creates a standing path from the internet to the application.
A VPN is often a better alternative than opening a port because the user must authenticate before joining the remote network, and traffic between the user device and the remote environment is encrypted.
## Why open ports and broad VPNs break down
Open ports may provide quick access, but they also create a direct inbound path from the internet to the Gateway. That increases exposure, adds operational overhead, and often leaves a sensitive application reachable in a way it was not designed for.
VPNs reduce that exposure, but they bring their own complexity. User access has to be distributed and managed, revocation has to be handled cleanly, and many VPNs grant far broader network access than most users actually need.
That matters in Ignition because the Gateway sits in front of projects, devices, data, and administrative control. In both cases, the result is usually more reach than the task calls for.
## Implementation model
### How to provide Ignition remote access without open ports
A cleaner approach is to establish an outbound connection from the environment where Ignition is hosted and put the Gateway behind an authenticated access layer. That allows browser-based access without directly exposing the private environment to the internet, while ensuring users authenticate before they reach the interface.
Users who need the Designer or administrative access can still be given private connectivity, but with tighter policy enforcement than a traditional VPN, limiting access to the specific hosts and ideally the specific ports they actually need.
### Reference architecture for Ignition remote access
A practical deployment looks like this:
1. The Ignition Gateway remains on a private network with no public inbound exposure. No publically open ports.
2. An outbound only connector establishes the private path from the building’s network, rather than relying on inbound internet access.
3. The Gateway is published with a domain name and HTTPS through an authenticated access portal that proxies traffic to the application port.
4. Users who only need browser access are given that path and nothing broader. They don’t have to install client-side software.
5. Users who need direct connections to the network are given authenticated connectivity only to the exact hosts they require. They aren’t given access to the entire network unless you give explicit permission.
6. Every instance of access is tied back to a user’s identity for better control, auditability, and maintainability. Contractor access remains narrow and time-bounded rather than becoming a permanent network entitlement. It becomes easy to manage users, network resources, and access controls in a single pane of glass.
### How Pangolin improves Ignition remote access
For browser-based access, Pangolin can publish Ignition through [Public Resources](https://docs.pangolin.net/manage/resources/understanding-resources#public-resources). Users connect through a managed hostname over HTTPS/TLS, authentication happens first, and the Gateway stays private. Browser-only users do not need client-side VPN software.
For the Designer and other workflows that require direct connections to systems, Pangolin can provide [Private Resources](https://docs.pangolin.net/manage/resources/understanding-resources#private-resources). Users authenticate with their identity and get direct connections to systems on the network only when they need it. Access is scoped directly to specific IPs and ports. That keeps access tied to the job instead of inheriting broad network reach.
That gives teams a cleaner access model:
* browser users get the Ignition interface they need without exposing the Gateway
* engineers get the direct path they need without making broad access the default
* vendors get narrower, time-bounded access without becoming standing network users
Pangolin is not an Ignition management platform. It is the access layer around the environment.
## Conclusion
Most Ignition remote-access problems are scope problems. Keep the Gateway private, publish browser access through an authenticated front door, and reserve direct, VPN-like connectivity for the smaller group that actually needs it and ensure it’s scoped to specific network resources.
## FAQ
**Can you provide Ignition remote access without opening inbound ports?**
*Yes. Keep Ignition on private networks, publish browser access through an authenticated layer with a managed hostname and HTTPS/TLS, and use private, VPN-like connectivity only for deeper workflows that require direct connectivity.*
**Is a VPN still useful for the Ignition Designer?**
*Sometimes. Some engineering workflows still need private connectivity. The mistake is making that the default for everyone.*
**What is the safer way to expose Ignition remotely?**
*Do not expose the Gateway directly. Keep it private and put an authenticated front door in front of it so identity is checked before traffic reaches Ignition.*
**Should browser-based Ignition access and Designer access use the same remote-access method?**
*Usually no. They are different workflows with different connectivity and risk requirements.*
**Where does Pangolin help in this architecture?**
*Pangolin can protect private browser-based Ignition access behind an authenticated HTTPS/TLS front door and provide narrower private access for engineering workflows.*
---
### IoT Provisioning at Scale with Golden Edge Images
URL: https://pangolin.net/news/iot-device-provisioning-at-scale-with-golden-images-for-edge-fleets
Published: 2026-04-22
Summary: Provision IoT edge fleets with golden images, first-boot assignment, Pangolin sites, and declarative blueprints.
Category: Guides
If you run a large fleet of edge devices, provisioning IoT devices at scale is not just an imaging problem. It is an operational one.
Raspberry Pis, industrial edge boxes, cellular routers, and similar field devices are often shipped to provide remote access to equipment at sites. Getting the device online is rarely the hard part. The hard part is provisioning the tunnelling software, identity, naming, and remote-access configuration on each unit without turning every deployment into a custom setup exercise.
This is where many provisioning systems begin to break down. They rely on device-specific configuration files, certificates, or secrets being copied onto each device individually. You can script that process, but you are still carrying a per-device manufacturing workflow that becomes slower, more brittle, and harder to reason about as the fleet grows.
## Provisioning workflow
### Start with a golden image for each device class
For fleet provisioning, the golden image matters more than going through a checklist.
The image should include the base OS, the site connector, and only the minimum local config needed to complete first boot. It should be consistent enough to flash onto many devices without per-unit changes.
If every device needs its own image, the provisioning problem has simply been moved upstream into manufacturing. That slows release work, increases the number of artifacts you need to track, and makes it harder to understand what actually shipped.
The goal is not to deliver a fully customised device. The goal is to deliver a device that can customize itself safely and predictably once it comes online.
### Keep bootstrap small
Most teams overcomplicate the factory stage. They generate a new secret package for every device, copy device-specific certificates into the image, or build custom configuration bundles for each site. That can work, but it creates a brittle manufacturing workflow.
Large fleets usually need something lighter. The image should contain only the bootstrap material needed for the device to connect back and enrol. In many cases, that means using the same provisioning key, or a batch-level bootstrap credential, across a manufacturing run instead of creating a unique setup package for every unit.
The point of bootstrap material is not to define the device's final state. Its purpose is only to get the device online and into the provisioning system.
### Let first boot assign the final state
Once the device comes online, it should complete the rest of provisioning itself. That means identifying itself, receiving the correct name or assignment, and pulling the configuration it actually needs for that site. The device leaves the bench generic. First boot is what moves it into its operational role.
That is what zero-touch provisioning should mean at scale. A technician should not need to log in manually and finish the setup just because the device has reached the field. For remote-access devices, first boot should handle registration, configuration retrieval, and local role assignment automatically.
### In-field rollout should follow the same discipline.
Provisioning is not finished once the device is deployed.
If flashing the original image is the only clean part of the process, the fleet is still hard to manage. You also need a reliable way to deliver software updates and configuration changes to devices that are already in the field.
That does not mean re-imaging hardware for every change. It means building a scriptable, repeatable rollout path for updates after the first deployment.
A fleet that is easy to install but difficult to update still carries operational debt.
## Pangolin as a concrete example
Pangolin is a useful example of how to make remote-access fleet provisioning operationally manageable.
The same problems show up again and again in these deployments: too much device-specific material in the image, too much manual setup after first boot, and no clean path from flashed hardware to a usable remote-access node. That is where Pangolin helps.
You can keep the golden image generic. Instead of generating a unique connector identity for every device during manufacturing, you can ship the image with a shared [provisioning key](https://docs.pangolin.net/manage/sites/site-provisioning#site-provisioning-keys) and let the connector exchange it for real site credentials on first boot. That removes a large amount of per-device secret handling from the factory workflow.
As shown above, the provisioning key can also carry usage policies, including maximum batch size, validity period, and whether new sites are approved automatically.
You can also keep the first boot responsible for the real assignment. Once the device comes online, it can register itself, create or join the correct site, and pull the configuration it actually needs. With [Blueprints](https://docs.pangolin.net/manage/blueprints), that setup can be applied automatically instead of being rebuilt by hand for every deployment.
```yaml
private-resources:
ssh-resource:
name: SSH Server
mode: host
destination: localhost
site: {{env.SERIAL_NUMBER}}-site
alias: {{env.SERIAL_NUMBER}}.example.local
tcp-ports: "22,3389"
udp-ports: "*"
disable-icmp: false
roles:
- Customer1
- DevOps
users:
- user@example.com
public-resources:
secure-resource:
name: Web Resource
protocol: http
full-domain: {{env.SERIAL_NUMBER}}.example.com
targets:
- site: {{env.SERIAL_NUMBER}}-site
hostname: localhost
method: http
port: 8080
auth:
sso-enabled: true
sso-roles:
- Member
- Admin
sso-users:
- user@example.com
```
In the Blueprint example above, the device is configured to grant access to Private Resources listening on the localhost interface. More specifically, the rules allow TCP ports 22 and 3389, and all UDP ports, as indicated by the * character.
In the second half of the Blueprint, a Public Resource is defined. It is configured to register as a subdomain of example.com, using the device serial number as the subdomain value.
That gives you a cleaner end-to-end path: flash one image, ship the device, let it connect back, let Pangolin assign its identity and site configuration, and bring it online without per-device image edits or manual dashboard setup.
That is the real benefit. The image stays simple, first boot handles the site-specific state, and the rollout becomes repeatable across large numbers of devices.
It also produces a better operating model once the box is in the field. Rather than acting as a basic VPN endpoint on an off-the-shelf router, the device becomes part of a platform with centralized users, sites, policy, and audit visibility. It can connect outbound from behind NAT or firewalls, support both browser-based and private access, and fit into a multi-site deployment model without turning every user into a broad network user.
## Conclusion
For large edge fleets, provisioning should start with a golden image, not a pile of per-device exceptions.
Keep the bootstrap small. Let the first boot handle the real setup. Use the same repeatable path for updates after deployment.
For remote-access devices, Pangolin provides a concrete approach: ship one repeatable image with provisioning keys, let Newt bring the site online on first boot, and use Blueprints to apply resource state without recreating the same deployment by hand each time.
We also can supply our own [Pangolin edge-devices](/news/pangolin-edge-devices-drop-in-remote-access) that follow this principle.
## FAQ
**What is IoT device provisioning at scale?**
*It is the process of turning many shipped devices into working fleet members without hand-configuring each one. That usually means a repeatable image, a small bootstrap step, first-boot enrollment, and a controlled update path afterward.*
**What is a golden image for edge devices?**
*A golden image is the repeatable base image you flash onto a class of devices before they leave the bench. It should contain the OS, the required software, and the minimum bootstrap material needed for first boot.*
**What is zero-touch provisioning in IoT?**
*Zero-touch provisioning means the device can come online and complete its setup path without a technician finishing the install by hand. In practice, that usually means bootstrap material in the image, first-boot enrollment, and config pulled after the device connects.*
**Why is per-device secret generation a problem?**
*It creates a slower and more fragile factory workflow. You can automate it, but you are still carrying device-by-device state through manufacturing instead of letting the device enroll and pull its real state later.*
**What should happen when the device first comes online?**
*It should connect back, identify itself, register or name itself correctly, and pull the config it needs for that site or role.*
**How does Pangolin fit into this workflow?**
*Pangolin can be part of the bootstrap path for remote-access devices. A provisioning key lets Newt come online and establish the site, and blueprints let the device apply repeatable resource configuration on first boot.*
---
### Remote PLC/SCADA Access Without Open Ports
URL: https://pangolin.net/news/remote-plc-scada-access-without-open-ports
Published: 2026-04-17
Summary: Secure remote PLC and SCADA access by keeping interfaces private, closing open ports, and scoping engineering access.
Category: Guides
Remote access requests in PLC/SCADA environments usually start the same way: someone needs a dashboard, historian, engineering workstation, or PLC from outside the site. Most teams answer with port forwarding or a VPN. Both can get someone connected. Both leave behind tradeoffs that outlast the original access request.
## PLC/SCADA remote access needs two access models
One group of users only needs the SCADA application. They want dashboards, alarms, trends, historian data, or routine system visibility. In many cases, the SCADA interface or web HMI is enough. These users usually should not need client-side software just to open a browser and sign in.
Another group needs deeper reach into the environment. Control engineers, integrators, and vendors may need PLC programming tools, engineering workstations, OPC services, or other systems on the OT network. Those workflows are not the same as routine interface access, so they should not share the same path.
## How teams usually solve PLC/SCADA remote access
Most teams do not separate those access needs at the beginning. One remote-access method gets picked and then stretched across both models.
The first move is often a firewall rule and port forward to the SCADA gateway, engineering workstation, or another target. It is familiar, direct, and usually the fastest way to make something reachable, especially when the immediate goal is simply to get a screen or service working from outside the site. In practice, that means users anywhere on the internet connect to `:` to reach the downstream system.
The second option is usually a VPN. Instead of publishing the application or device itself, the user joins the remote network with VPN software first and then reaches the SCADA system, workstation, or PLC environment from inside that connection. It is safer than direct exposure because the user has to authenticate before they can reach the network, and it feels like a more complete answer when teams know some users will need more than a web interface.
## Why port forwarding and VPNs are a poor fit
Port forwarding solves reachability, but it leaves behind public exposure and operational overhead. You need inbound firewall rules and a public IP. You create a standing path from the internet to a SCADA service, gateway, or adjacent industrial system that usually was not meant to be publicly reachable. You also leave users managing raw IP-and-port combinations when a managed hostname and HTTPS would be cleaner for the web-facing part of the environment.
VPNs remove some of that public exposure, but they introduce a different set of problems. Client rollout, certificates or keys, revocation, and contractor offboarding all become part of the day-to-day burden. They also tend to grant broad network reach by default, which means a user who only needs one application, one workstation, or a short support session often gets more access than the task requires.
## Implementation model
### How to provide PLC/SCADA remote access without open ports
A better design starts with an outbound connection from inside the industrial environment and separates the browser workflow from the engineering workflow. Publish the SCADA interface behind an authenticated access layer so users sign in before requests ever reach the backend. That gives users browser-based access without directly exposing the industrial environment to the internet.
For PLC programming, engineering tools, vendor support, and other non-browser work, provide private connectivity only to the hosts and ports involved. That preserves the deeper path when it is genuinely needed without making it the default for everyone else. The goal is not to remove deeper access entirely. It is to stop granting full-network reach when a user only needs one workstation, one PLC, or a small set of approved systems.
### Reference architecture for PLC/SCADA remote access
A practical deployment looks like this:
* SCADA gateways, historians, PLCs, and related services stay on private address space with no public inbound exposure.
* A connector or tunnel originates outbound from the site instead of waiting for inbound internet traffic.
* The SCADA interface is published through an authenticated portal with a domain name and HTTPS.
* Users who only need dashboards or HMIs get application-level access and do not need client-side VPN software.
* Engineers, integrators, and vendors get authenticated private connectivity only to the hosts and ports involved in their work.
* Every access path ties back to user identity, which makes review, audit, and temporary third-party access easier to manage.
This is closer to how industrial teams actually operate. The plant manager, operator, controls engineer, and vendor do not need the same path, so the architecture should stop treating them as if they do.
### Where Pangolin fits
Pangolin can support both sides of that model. In Pangolin, you define a site for the remote industrial network and install a connector on a Windows or Linux system inside that environment.
That connector establishes the outbound path for both browser access to private applications and narrower private access when direct network reach is required.
Pangolin can enforce an authenticated access layer in front of private web applications using [Public Resources](https://docs.pangolin.net/manage/resources/understanding-resources#public-resources). Users connect through a managed domain over HTTPS, authenticate first, and then reach the backend service. That means routine users can reach the SCADA interface they need without exposing the origin or installing client-side VPN software.
When the job requires deeper OT access, Pangolin can provide [Private Resources](https://docs.pangolin.net/manage/resources/understanding-resources#private-resources) for specific hosts, subnets, and ports. Users authenticate with their identity and use client software only when that deeper path is required. Admins can keep access narrow instead of dropping users onto the full network.
The result is a narrower access model: browser access for routine SCADA work, resource-scoped private access for controls and vendor workflows, and fewer reasons to keep inbound ports or broad VPN access around.
## Conclusion
Most PLC/SCADA remote access issues are really access-design issues. The challenge is not just getting people connected. It is deciding what each person should be allowed to reach while keeping the rest of the environment private.
Split SCADA access from engineering access. Keep the industrial environment off the public internet. Put the SCADA interface behind an authenticated front door. Reserve direct connectivity for the smaller set of users and tools that actually need it.
That is a cleaner way to handle remote PLC/SCADA access without relying on open ports.
## FAQ
**Can you provide PLC/SCADA remote access without opening inbound ports?**
*Yes. Keep SCADA systems, PLCs, and related services on private networks. Publish the SCADA interface through an authenticated access layer, and use narrower private connectivity only for the workflows that need it.*
**Is a VPN still useful for PLC access?**
*Sometimes. Some engineering workflows still need private connectivity. The point is to stop making that the default for every remote user.*
**What is the safer way to expose a SCADA interface remotely?**
*Do not expose it directly. Keep it private and put an authenticated front door in front of it so identity is checked before traffic reaches the backend.*
**Should the SCADA application and PLC access use the same remote-access method?**
*Usually no. They are different workflows with different risk and connectivity requirements.*
**Where does Pangolin help in this architecture?**
*Pangolin can protect the private SCADA application behind an authenticated access layer and provide narrower private access for PLCs, engineering tools, and other internal industrial systems.*
---
### Remote Access for Tridium Niagara Without Open Ports
URL: https://pangolin.net/news/remote-access-for-tridium-niagara-without-open-ports
Published: 2026-04-16
Summary: Provide Tridium Niagara remote access with authenticated browser access and narrow engineering paths without open ports.
Category: Guides
At first glance, remote access to Tridium Niagara can seem simple. It is a web interface with an address and a port, so the first question is how can we provide remote access. This usually means giving someone access to alarms, graphics, schedules, or Niagara Workbench. Most teams do that with either port forwarding or a VPN. Both work, but both come with tradeoffs. This article looks at those approaches and then at a more secure model that avoids open ports.
## Tridium Niagara remote access needs two paths
Before looking at access methods, it helps to separate the two access needs most teams are trying to support.
Routine access is for users who need to check alarms, graphics, schedules, or general system status. In most cases, access to the Niagara interface is enough. Usually, you don’t want these users to install client-side software, so instead they should be able to access from any web browser as long as they can pass the authentication portal.
Some users, like engineers, need direct connectivity to systems on the network. For example, they might need to connect desktop (thick client) software to devices on the LAN or run commands while they are remote. These users can install client side software to establish scoped tunnels to the remote networks.
## How Tridium Niagara remote access is usually approached
Most teams do not build separate access paths for those two needs at the start. They pick one method and try to make it cover everything.
When a user needs access to an application, the first thought is often to open a port on the firewall and forward it to the application. It is familiar, direct, and usually the fastest way to get someone connected, especially when the immediate goal is simply to make the interface reachable. This means users anywhere in the world go to `:` to access the downstream service.
The second method is to use a VPN. Instead of publishing the application itself, the user connects to the remote network with VPN software first and then reaches Niagara from inside that private connection. It is more secure than port forwarding because the user has to authenticate before they can access the remote network. It also feels like a more complete answer when teams know some users will need deeper access, not just the web interface. VPNs usually grant broad network access to the entire remote network.
## Why port forwarding and VPNs fall short
Port forwarding may solve access quickly, but it often introduces ongoing operational burden and unnecessary risk such as information exposure. You need to set up your firewall to open an inbound only port to a device on your network. You also need a public IP address. This creates a direct open path to the application on the open internet, and many applications are not designed to be exposed safely. Additionally, you have to remember the \:\ combo, when it’d be more convenient, instead, to have a friendly domain name of your choice with an encrypted HTTPS connection.
VPNs avoid some of that exposure, but they add their own complexity. You have to distribute keys or certificates to your users so they can connect from their own computers which gets complicated as your user-base grows. Keys are long-lived, and if lost or stolen can grant an unwanted user access. They’re hard to revoke when a user leaves the organization, and VPNs most often provide broad network wide access to every device meaning users can access more than just what you want them to.
## Implementation model
### How to provide Tridium Niagara remote access without open ports
A cleaner approach is to establish an outbound connection from the environment where Niagara is hosted and put the web UI behind an authenticated access layer. That gives browser based access to the interface without directly exposing the environment to the internet, and users must log in first.
Engineers and integrators who need Workbench or other non-browser tools can still be given private connectivity, much like a VPN, but with policy enforcement that limits access only to specific hosts (IPs) on the network. Ideally, scope access down to specific ports.
### Reference architecture for Niagara remote access
A practical deployment looks like this:
1. The Niagara server, station, or controller remains on a private network with no public inbound exposure. No publically open ports.
2. An outbound only connector or tunnel establishes the private path from the building’s network, rather than relying on inbound internet access.
3. The web UI is published with a domain name and HTTPS through an authenticated access portal that proxies traffic to the application port.
4. Users who only need browser access are given that path and nothing broader. They don’t have to install client-side software.
5. Engineers and integrators who need direct connections to the network are given authenticated connectivity only to the exact hosts they require. They aren’t given access to the entire network unless you give explicit permission.
6. Every instance of access is tied back to a user’s identity for better control, auditability, and maintainability. Contractor access remains narrow and time-bounded rather than becoming a permanent network entitlement. It becomes easy to manage users, network resources, and access controls in a single pane of glass.
This model lines up more closely with how BAS teams actually work as it's easier to grant access to the user role and job requirements.
### Where Pangolin fits
Pangolin supports both sides of the Niagara remote access model. In Pangolin, you define a site. A site is the remote building network you need access to. Then you install a software connector on any Windows or Linux machine in the network.
The connector creates an outbound tunnel that both tunnels out the Niagara web UI for browser-based access and provides scoped VPN-like access to specific IPs and ports when direct connections are needed to the remote network.
For the Niagara web UI, Pangolin can sit in front of the private web applications as an authenticated access layer using [Public Resources](https://docs.pangolin.net/manage/resources/understanding-resources#public-resources). Users must authenticate and connect through a domain name (URL) of your choice and an HTTPS connection Any user with a web browser can access the authenticated web portal meaning they don’t need to install any client side VPN software. Authentication happens before the request reaches the backend, meaning the service stays private.
For Workbench and other engineering workflows, Pangolin can provide private, resource-scoped connectivity through [Private Resources](https://docs.pangolin.net/manage/resources/understanding-resources#private-resources), without relying on public exposure or broad VPN access. Use Private Resources when you need access to a specific IP/host or subnet on a remote network. Users must download client side software and authenticate with their identity. The administrator gives the user access to specific IPs and ports, called resources, on the network of the connector, so access remains scoped down to the port level.
Pangolin does not force every Niagara use case through one blunt remote-access method. It gives BAS teams a cleaner and more controlled way to apply the right access path to each workflow. It has the best of both worlds, browser based access with an authentication portal for simple access, and client based access for when direct connections are needed. Both of these replace your legacy VPN and help you close down inbound ports.
## Conclusion
Most Niagara remote access problems are really access design problems. The issue is not just how to connect users, but how to give each user the right level of access without exposing more than necessary.
Separating web access from direct connectivity access leads to a cleaner and more secure design. Keep Niagara private, put the interface behind an authenticated front door, and reserve deeper connectivity for engineers, integrators, and tools that genuinely need it while keeping it scoped.
That is the more maintainable way to handle Tridium Niagara remote access without relying on open ports.
## FAQ
**Can you provide Tridium Niagara remote access without opening inbound ports?**
*Yes. Keep Niagara on private networks, publish the interface through an authenticated access layer, and use private connectivity only for the workflows that need deeper reach.*
**Is a VPN still useful for Niagara Workbench?**
*Sometimes. Some engineering workflows still need private connectivity. The point is to stop making that the default for everyone.*
**What is the safer way to expose the Niagara web UI remotely?**
*Do not expose it directly. Keep it private and place an authenticated front door in front of it so identity is checked before traffic reaches Niagara.*
**Should the Niagara web interface and Workbench use the same remote-access method?**
*Usually no. They are different workflows with different risk and connectivity requirements.*
**Where does Pangolin help in this architecture?**
*Pangolin can protect the private web interface behind an authenticated front door and provide narrower private access for engineering workflows.*
---
### Pangolin 1.17 - Full RBAC, Site Provisioning Keys, Log Streaming
URL: https://pangolin.net/news/1-17-release
Published: 2026-04-03
Summary: Pangolin 1.17 improves roles, identity provider mapping, site provisioning, connection logs, and log streaming.
Category: Product
Pangolin 1.17 brings a wave of quality-of-life improvements that strengthen existing functionality around roles, identity providers, site provisioning, logging, and more. Let's dig in!
## Release highlights
### Multiple Roles per User
Pangolin has always let you define as many custom roles as you'd like, but believe it or not, for over a year Pangolin only supported one role per user - a strict one-to-one relationship. This made it surprisingly difficult to map your team's real-world structure to access controls in Pangolin. What if a user spans the dev team, the DevOps team, and also needs access to the support team's resources?
Now, each user can be a member of one or many roles - there's no limit. This brings full RBAC to Pangolin. Create a role for developers, DevOps, and support, then place your users accordingly. At the resource level, simply define which roles have access, and a user will be able to reach any resource that falls within the union of all their assigned roles.
### Improved Identity Provider Role Mapping
With the addition of multiple roles, identity provider role mapping had to be updated as well. Role mapping here refers to the configuration admins set up when enabling auto-provisioning, so that users synced from the identity provider at login are automatically placed into the appropriate Pangolin roles based on data returned from the provider.
There are now three options when configuring role mappings in auto-provisioning settings: fixed roles, the mapping builder, and raw expression.
Fixed roles is the simplest option. It places all users who log in through the identity provider into the same set of roles. Use this when you don't need dynamic mapping and it's fine to apply a blanket role assignment across everyone. You can always manually adjust roles on individual users after they've been auto-provisioned. This is the easiest, lowest-friction way to get started.
The mapping builder is a new addition that makes it easy to dynamically map roles from your identity provider to Pangolin roles. Say a user logs in from Azure and belongs to several groups there. Azure identifies those groups with its own internal ID strings. The mapping builder is how you translate those to Pangolin roles without writing any expressions. First, pick the claim in the OIDC token where roles are passed - often groups. Then define a 1:1 mapping for each role: on the left, the role ID from the identity provider; on the right, the equivalent role name in Pangolin.
The raw expression option is the most flexible - and the most complex. This is how most users previously defined mappings in Pangolin. You provide a raw JMESPath expression that must return a string or array of strings representing the roles the user should be placed into. This enables nearly infinite possibilities. If you can write a logical expression for it, it will work. You could do something like: if the user's first name starts with "B," their email ends in @domain.com, and their last name is exactly six characters long, add them to the admin group. Not sure why you'd ever need that, but you get the idea.
Read more about [identity providers](https://docs.pangolin.net/manage/identity-providers/add-an-idp) and [auto provisioning](https://docs.pangolin.net/manage/identity-providers/auto-provisioning) in the docs.
### Google and Azure Identity Providers
We've added Google and Azure as built-in templates for the global identity provider type. For those unfamiliar, Pangolin supports two types of identity providers: global and organization-level. Organization-level providers are scoped to a single organization and are useful when a tenant has their own identity provider that shouldn't appear on the main login page. Global providers are server-level and show up on the main login page for all users.
Google and Azure templates have been available for organization-level providers for a while - we've now brought them to the global level as well, making setup easier for those who need it there.
### Site Provisioning Keys
As you may already know, a Pangolin site authenticates using two components: an ID and a secret - both randomly generated strings you receive when creating a site for the first time. This works fine at small scale, but gets unwieldy fast.
This is especially common in IoT scenarios, where sites are deployed to fleets of edge devices and each device needs its own credentials. Previously, you'd have to script against the API to generate an ID-secret pair per site, then find a way to push those credentials to each device individually. With provisioning keys, you can generate a single long-lived token, embed it into your device image before deployment, or push it to every device with one script.
When a site (Newt) starts up with a provisioning key, it reaches out to Pangolin, exchanges the key for an ID-secret pair, replaces the provisioning key with the new credentials, and immediately comes online. Combine this with [Pangolin Blueprints](https://docs.pangolin.net/manage/blueprints) for declarative configuration, and you have a straightforward way to provision large fleets of Pangolin sites for remote connectivity.
```yaml
private-resources:
ssh-resource:
name: SSH Server
mode: host
destination: localhost
site: {{env.SERIAL_NUMBER}}-site
alias: {{env.SERIAL_NUMBER}}.example.local
tcp-ports: "22,3389"
udp-ports: "*"
disable-icmp: false
roles:
- Customer1
- DevOps
users:
- user@example.com
public-resources:
secure-resource:
name: Web Resource
protocol: http
full-domain: {{env.SERIAL_NUMBER}}.example.com
targets:
- site: {{env.SERIAL_NUMBER}}-site
hostname: localhost
method: http
port: 8080
auth:
sso-enabled: true
sso-roles:
- Member
- Admin
sso-users:
- user@example.com
```
Provisioning keys also support a maximum usage count and an expiration time. Say you need to provision 250 devices over the course of a week - set the max usage to 250 and the expiration to one week. Once either threshold is met, the key becomes inactive and the Pangolin server will reject it. It's worth noting that provisioning keys are not API keys - they cannot be used for any other actions in Pangolin and exist solely for this one purpose.
Optionally, sites provisioned via a provisioning key can be placed into a pending state. These will appear under the Pending Sites tab on the provisioning page, giving admins a single place to review newly provisioned sites and manually approve them before they move into production.
Read more about [site provisioning keys](https://docs.pangolin.net/manage/sites/site-provisioning) in the docs.
### Connection Logs
Pangolin now logs raw TCP and UDP sessions between the Pangolin client (CLI, Mac, Windows, iOS, Android, etc.) and private resources. This applies to zero-trust private resources accessed over the Pangolin network - not public, browser-based resources, which have had access logs for some time.
Use connection logs as an audit trail to understand which users are accessing which private resources, when, and for how long.
Read more about [connection logs](https://docs.pangolin.net/manage/analytics/connection) in the docs.
### Log Streaming
Pangolin now supports streaming log events to third-party data collectors like Datadog, Splunk, or Microsoft Sentinel - commonly referred to as SIEM integration. You define a destination, a push method (HTTP, S3, etc.), and which Pangolin log types to forward: access logs, action logs, connection logs, or request logs. Pangolin will automatically push events to your external service as they're generated.
 
Read more about [log streaming](https://docs.pangolin.net/manage/analytics/streaming) in the docs.
## Looking Forward
We're expecting to pick up the pace of releases compared to the stretches between 1.15, 1.16, and 1.17. There's a lot in development and a lot on the horizon - we can't wait to get it all out into the open.
Give us a star: [https://github.com/fosrl/pangolin](https://github.com/fosrl/pangolin)
Stay tuned!
---
### What is an Identity-Aware Proxy (IAP)?
URL: https://pangolin.net/news/what-is-an-identity-aware-proxy
Published: 2026-04-02
Summary: Learn what an identity-aware proxy is, how it compares to VPNs and ZTNA, and how Pangolin protects private web apps.
Category: Engineering
An identity-aware proxy is an access layer that sits in front of an application or service and decides whether a request should be allowed before it reaches the backend.
Instead of trusting a user because they are on the corporate network or connected through a VPN, an identity-aware proxy checks identity, evaluates policy, and grants access only to the specific resource the user is allowed to reach. In more mature implementations, it can also consider context such as group membership, IP range, device trust, location, or session conditions.
That makes identity-aware proxies an important part of [modern Zero Trust access models](https://csrc.nist.gov/pubs/sp/800/207/final). Rather than relying on network location as proof of trust, they move the access decision closer to the application itself.
If you only want the short version, the model is simple:
* A user requests an internal application.
* The proxy checks for a valid session or redirects the user to an identity provider.
* Identity and policy are evaluated before traffic is forwarded.
* If the request is approved, traffic reaches the backend.
* If the request is denied, the application stays protected.
One terminology note is worth clearing up early. Identity-Aware Proxy is both a generic architectural concept and the product name Google uses for its own [Identity-Aware Proxy](https://docs.cloud.google.com/iap/docs/concepts-overview). In this article, the term refers to the broader category.
## Identity-aware proxy fundamentals
### What an identity-aware proxy is and how it works
The simplest way to understand an identity-aware proxy is to compare it with a standard reverse proxy.
A reverse proxy sits in front of an application and handles traffic on its behalf. It can terminate TLS, route requests, and present a clean public hostname. Those are useful functions, but they do not make it identity-aware on their own.
An identity-aware proxy adds access control to that front door. It does not just decide where traffic should go. It decides whether the request should be allowed before it reaches the application.
In practice, every request reaches the proxy first. The proxy checks whether the user has a valid session and, if needed, redirects them to an identity provider such as Okta, Microsoft Entra ID, Google Workspace, or Authentik. Once the user is authenticated, the proxy evaluates the request against policy.
That policy can include group membership, role, source IP, device posture, session age, geography, or reauthentication requirements.
If the request satisfies policy, the proxy forwards it to the backend. If not, the request is denied or the user is challenged for stronger authentication. Once traffic is approved, the backend receives only requests that have already passed those checks.
Many identity-aware proxies also pass trusted identity context downstream through headers such as Remote-User, Remote-Email, Remote-Name, or Remote-Role, which can help applications use identity information without building the full authentication stack themselves.
This model works best when the backend is not directly exposed and only trusts requests that come through the intended access layer.
### Why identity-aware proxies matter
Most organizations no longer operate inside a single, well-defined network perimeter.
Applications now span cloud platforms, on-prem environments, branch offices, and hybrid infrastructure. Employees work remotely, and contractors or partners often need access to only a small number of internal tools. In that environment, broad network access is harder to justify and harder to control.
That is where older access models begin to show their limits. A traditional VPN usually grants network-level access first and relies on downstream controls to restrict what happens next. A standard reverse proxy can publish or route traffic, but it does not automatically make access decisions based on identity and context.
An identity-aware proxy moves the access decision to the start of the request path. Instead of asking whether a user is on the right network, it asks whether this specific identity should be allowed to reach this specific application under these conditions.
This reduces unnecessary trust and makes access easier to scope. If a contractor needs one dashboard, they should not also inherit broad access to an internal subnet. If an employee needs browser-based access to an admin tool, that access should be enforced at the application front door.
### Identity-aware proxy vs reverse proxy vs VPN vs ZTNA
These terms are related, but they are not the same thing.
| Term | Main role | Access model | What to remember |
| --- | --- | --- | --- |
| **Reverse proxy** | Routes traffic to backend services | Application traffic flow | Useful, but not identity-aware by default |
| **Identity-aware proxy** | Enforces identity and policy in front of an application | Application-level, usually protocol-aware access | Grants access to a specific application or service |
| **VPN** | Connects a user or device to a private network | Network-level access | Provides broader connectivity to a network |
| **ZTNA** | Applies identity, policy, and least privilege to private access | Resource-level access | A broader access model, not a single product |
In simple terms, a reverse proxy handles traffic, an identity-aware proxy handles traffic and access decisions, a VPN provides network connectivity, and ZTNA is the broader model that can include proxies, clients, and policy engines.
An identity-aware proxy is not the same as ZTNA. It is often one part of a ZTNA architecture, especially for browser-based access to internal applications, but ZTNA usually extends beyond a single enforcement point.
Another important distinction is how they operate. An identity-aware proxy is usually protocol-aware, most often for HTTP and HTTPS, while a VPN works at a lower level by routing traffic into a private network. That is why a VPN often grants broader access, while an identity-aware proxy is better suited to controlling access to a specific application or service.
### Benefits of an identity-aware proxy
When implemented well, identity-aware proxies offer several clear benefits:
1. More precise access control. Users get access to a specific application instead of broad network access.
2. Less implicit trust. Access is based on identity and context, such as location, device state, session age, or time-limited access.
3. Better third-party access. Contractors, partners, and vendors can be given access to one application without exposing a wider network.
4. Centralised policy. Security teams can manage access rules for identities, groups, and context in one place.
5. Better visibility and auditability. A central enforcement layer makes it easier to log sign-ins, access decisions, and application access.
6. A simpler experience for web apps. For many internal applications, browser-based access is easier than requiring a full VPN connection.
### Common use cases
Identity-aware proxies are most useful when users need access to a specific application rather than a broader network.
Common use cases include:
* internal web applications
* admin dashboards and control panels
* developer portals and staging tools
* partner and contractor access
* hybrid-hosted applications
* private applications that should remain off the public internet
This model is especially effective for protecting browser-based access to private services without exposing more of the environment than necessary.
### Limitations and tradeoffs
Identity-aware proxies are useful, but they are not a complete security architecture.
They do not replace application authorization, and they do not remove the need for logging, monitoring, or strong identity hygiene. They are often strongest for HTTP and browser-based access, although some platforms extend beyond that. They also depend on clear policy design and a reliable identity layer.
They are much less effective if the origin can still be reached directly and bypass the proxy. If the application remains directly exposed, the proxy becomes optional rather than authoritative. A well-designed deployment makes the proxy the real front door, not just one possible path.
### What to look for in an identity-aware proxy solution
If you are comparing platforms, ask a few practical questions:
* Does it integrate cleanly with your identity provider?
* Can it enforce deny-by-default access to specific resources?
* Can it protect private origins without exposing them directly?
* Can the backend verify that requests came through the intended access path?
* Does it support the mix of browser-based and broader private access your environment needs?
* Does it provide enough visibility for support, audit, and incident response?
The strongest solution is not the one with the longest feature list. It is the one that fits your access model and can be operated consistently.
## Where Pangolin fits
Pangolin fits this conversation well because it can implement the identity-aware proxy pattern for private web applications while also supporting broader private access models.
For browser-based access, requests hit the Pangolin server first, not the backend service directly. Pangolin evaluates identity, policy, and request context at that front door, and only approved traffic is forwarded down the tunnel to the protected resource. This creates clear separation between the access decision point and the service being protected.
That separation matters because it keeps the backend off the public internet, makes the access layer authoritative, and reduces the risk of the application being treated as directly reachable infrastructure. Instead of exposing a service and then trying to secure it in place, Pangolin keeps it behind the access layer and only carries approved traffic to it.
Pangolin is built around sites, resources, and access control. Sites connect networks back to Pangolin, while resources define the applications, hosts, or ranges users are allowed to reach. In practice, access is granted at the resource layer, while connectivity to the backend is delivered through the site hosting that resource.
That structure makes Pangolin more than a simple publishing layer. It provides an identity-aware front door for private applications while keeping the protected service behind a tunnelled access path rather than directly exposed.
## Pangolin for browser-based access to private apps
For public HTTPS resources, Pangolin can sit in front of an internal web application and provide a browser-based access path without exposing the backend directly.
In practical terms, Pangolin can:
* present a browser-based route to the application
* require authentication before traffic reaches the backend
* apply policy based on users, roles, countries, IPs, and CIDRs
* keep the backend on a private network behind a site connector
For teams looking for a cleaner way to publish and protect private applications, that maps closely to what they usually mean by an identity-aware proxy.
## Pangolin beyond the proxy pattern
Pangolin is not limited to browser-based front-door access.
Its private resources support identity-based access to internal services through the Pangolin client. Access is still granted at the resource layer, but the control model differs from a standard identity-aware reverse proxy. Rather than simply placing a proxy in front of HTTP traffic, Pangolin can provide identity-based private connectivity to the systems and services a user has been allowed to reach.
This matters because many organizations do not have a single access problem. They need a consistent way to control access to internal web tools, private services, administrative paths, and hybrid infrastructure.
Pangolin is useful here because:
* sites run behind firewalls and deny traffic by default
* resources must be explicitly defined and assigned
* external identity can be connected through OAuth2 and OIDC
* public and private access patterns can be managed in one platform
That makes Pangolin more than a simple identity-aware proxy. It is better understood as a private access platform that includes identity-aware proxy behaviour for web applications and extends into broader Zero Trust private access.
## Related reading
* [How ZTNA Works](/news/how-ztna-works)
* [Tunneled Reverse Proxy Architecture](/news/tunneled-reverse-proxy)
* [Secure Remote Access: Enterprise ZTNA Implementation Guide](/news/secure-remote-access)
## Final thoughts
An identity-aware proxy is an application front door that makes access decisions based on identity and policy rather than inherited network trust.
It is a strong fit for internal web applications, partner access, contractor access, and other scenarios where broad VPN reach is unnecessary or undesirable. It also fits naturally into Zero Trust and ZTNA architectures because it moves access control closer to the resource.
For Pangolin, this is a useful entry point because it connects directly to a common buyer question: how do you protect private applications without defaulting to broad VPN access or direct exposure?
Pangolin is compelling in that conversation because it can serve as the identity-aware front door for browser-based access while also supporting broader private-resource access when the problem extends beyond a single web app.
## FAQ
**Is an identity-aware proxy the same as a reverse proxy?**
*No. A reverse proxy handles traffic routing and mediation. An identity-aware proxy adds authentication and policy enforcement before traffic reaches the application.*
**Is an identity-aware proxy the same as ZTNA?**
*No. An identity-aware proxy is often one component inside a ZTNA architecture. ZTNA is the broader secure access model.*
**Does an identity-aware proxy replace a VPN?**
*Sometimes, especially for browser-based access to internal applications. Not always. Many organizations use both patterns during migration or for different use cases.*
**Can an identity-aware proxy protect non-web applications?**
*Some platforms extend beyond web apps, but the classic identity-aware proxy pattern is usually strongest for HTTP and browser-based access. Broader private access often requires a client or a different access path.*
**Does Pangolin count as an identity-aware proxy?**
*For authenticated public HTTPS resources, yes. More broadly, Pangolin is a private access platform that also supports client-based private resources.*
## Further reading
* [NIST SP 800-207: Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final)
* [Google Cloud Identity-Aware Proxy overview](https://docs.cloud.google.com/iap/docs/concepts-overview)
* [Google Cloud Identity-Aware Proxy documentation](https://docs.cloud.google.com/iap/docs)
* [How Pangolin Works](https://docs.pangolin.net/about/how-pangolin-works)
* [Pangolin System Architecture](https://docs.pangolin.net/development/system-architecture)
* [Understanding Pangolin Resources](https://docs.pangolin.net/manage/resources/understanding-resources)
* [Understanding Pangolin Sites](https://docs.pangolin.net/manage/sites/understanding-sites)
* [Install Pangolin Sites](https://docs.pangolin.net/manage/sites/install-site)
---
### Modernizing Enterprise SSH Access
URL: https://pangolin.net/news/modernizing-enterprise-ssh-access
Published: 2026-03-24
Summary: Modernize enterprise SSH with identity-driven access, short-lived credentials, and private connectivity instead of static keys.
Category: Product
SSH remains one of the most important protocols in enterprise infrastructure, but the way many organizations manage SSH access has not kept pace with the way infrastructure has changed.
Teams now operate across cloud platforms, on-prem environments, remote workforces, and hybrid networks. Security expectations have shifted with them. Access is expected to be tied to identity, tightly scoped, and easy to review. Yet in many enterprises, SSH still depends on patterns that were designed for a different era: static keys that live too long, bastion hosts that accumulate operational baggage, manual account changes on individual systems, and VPN access that reaches far beyond the original task.
The result is familiar. SSH still works, but the workflow around it becomes messy. Security teams are left asking who still has access. Platform teams are left maintaining exceptions. Offboarding becomes harder than it should be. Audits turn into archaeology. What starts as a straightforward administrative protocol slowly turns into a governance problem.
That is why SSH modernization matters. The issue is no longer just how to reach a server. It is how to make access to private infrastructure secure, manageable, and consistent with the way enterprises now think about risk.
Pangolin fits into that conversation because it brings SSH into a broader private access model instead of treating it as a completely separate workflow.
## Challenges of Managing Enterprise SSH Access Over Time
SSH is rarely difficult on day one. It becomes difficult over time, usually for the same reason many infrastructure systems become difficult: the environment grows faster than the operating model around it.
One team adds a bastion because it is the quickest way to centralize access. Another distributes keys because it is easier than formalizing identity-driven access. Another keeps using a VPN because it already exists. None of these decisions look unreasonable in isolation. The trouble comes later, when those choices overlap and harden into a patchwork of access paths, local exceptions, and unclear ownership.
At that point, the problem is not the protocol. The problem is that SSH access has become fragmented. Some people authenticate one way, others another. Some environments are tightly controlled, others depend on old habits. Revoking access is slower than granting it. Logging exists, but not always in one place or in a form that makes governance easy.
This is the pattern many enterprises are trying to escape. The goal is not just to improve the shell experience. The goal is to stop SSH from being one of the last unmanaged corners of the infrastructure estate.
## What enterprises are really trying to solve
When a company starts evaluating SSH modernization, it is usually responding to a broader set of pressures.
The security team wants less credential sprawl and a cleaner answer to access reviews. The platform team wants to reduce the number of manual steps involved in onboarding and offboarding. Infrastructure leaders want to modernize bastion access without blowing up familiar architecture patterns. Engineering leaders want developers and operators to reach the systems they need without dragging broad network access and brittle workarounds behind them.
Put simply, enterprises are not searching for a better SSH client. They are trying to figure out how private infrastructure access should work in an environment where identity, policy, and auditability matter far more than they used to.
That is why SSH should not be framed as an isolated problem. It sits inside a larger question about how access to private systems is granted, governed, and withdrawn.
## SSH modernization patterns
### Static Keys, Bastion Hosts, and VPNs: Strains in Traditional SSH Access Models
Traditional SSH environments are often built from sensible components: static keys, local accounts, bastion hosts, and VPN connectivity. None of those elements are inherently wrong. The problem is the way they tend to age.
Static keys are a good example. They are easy to issue, but much harder to track over time. Once they have been copied across users, laptops, and environments, confidence starts to erode. You can no longer be sure which credentials still matter, which ones are stale, or whether revocation is as complete as you think it is.
Bastion hosts solve a different problem by centralizing ingress. That can be useful, especially in segmented environments, but bastions often become overloaded with operational responsibility. They need to be secured, maintained, monitored, and explained. In some organizations, the bastion becomes the answer to every access question without ever becoming a clean governance layer.
VPNs introduce another kind of drag. They are often used because they are already there, not because they are the best fit for the specific task. A user may only need SSH access to one administrative path, but the VPN gives them a much wider slice of the network. That gap between what is needed and what is granted is exactly where enterprises start to feel uncomfortable.
Taken together, these patterns create more than inconvenience. They create uncertainty. The access path exists, but the control model around it is harder to reason about with confidence.
### What modern SSH access looks like in practice
Modernizing SSH does not mean throwing away everything familiar. It means changing the logic behind how access is controlled.
In a stronger model, SSH access is tied more closely to workforce identity, so permissions follow the same lifecycle as the people using them. Credentials are temporary or centrally governed rather than scattered and long-lived. Access decisions are easier to review, revoke, and explain. Teams can still preserve controlled access paths where they need them, but without defaulting to broad network trust as the foundation.
The practical difference is important. Instead of treating SSH as a narrow technical protocol that sits outside the rest of access governance, enterprises start treating it as another private resource that needs clear ownership, policy, and auditability.
That shift is what makes SSH modernization meaningful. It is not just a cleaner login path. It is a cleaner operating model.
## How Pangolin changes the shape of the problem
Pangolin is most useful when it is understood as a private access platform that includes SSH, rather than as a stand-alone SSH tool.
That distinction matters because most enterprises are already dealing with more than one access problem at a time. They are securing internal applications, administrative interfaces, private services, and infrastructure endpoints all at once. If SSH is handled in isolation, it often becomes one more disconnected workflow that has to be governed separately.
Pangolin takes a different approach by bringing SSH into the same broader access model used for private resources. That gives teams a more coherent way to think about access across the environment. It also reduces the temptation to solve each access problem with a separate product and a separate set of operational habits.
For enterprise teams, that is often the bigger win. The value is not just that SSH works through Pangolin. The value is that SSH stops sitting off to the side as a special-case exception.
## Reducing key sprawl without adding more friction
One of the oldest SSH problems is also one of the hardest to clean up: the spread of long-lived keys across users, machines, and environments.
This is where Pangolin offers a more modern approach. By supporting temporary, signed access, it gives enterprises a way to move away from the idea that every user needs a persistent key relationship with every relevant system. That makes credential hygiene easier to manage and reduces the amount of trust that quietly accumulates over time.
Just as important, it does this without pushing teams toward yet another disconnected process. Engineers do not want one access model for internal applications, another for private networking, and a third for servers. A better SSH model is one that improves control while making the overall experience simpler, not more fragmented.
## Modernizing bastion access without abandoning familiar architecture
Bastion hosts remain a normal part of enterprise infrastructure, and for good reason. Many teams still want a controlled path into production or segmented environments. The issue is not the existence of the bastion. The issue is everything that tends to collect around it.
Over time, bastion-based access can become a bundle of manual steps, host hardening work, local policy exceptions, and uneven identity controls. It still functions, but it no longer feels modern or especially clean.
Pangolin helps here by supporting SSH in ways that can fit both direct and bastion-style models. That matters because most enterprise migrations are gradual. Teams need room to improve identity alignment and access governance without pretending they can redesign the entire environment in one move.
In practice, that makes modernization more realistic. It lets enterprises improve the control model around SSH while respecting the fact that infrastructure tends to evolve in stages.
## Bringing SSH closer to enterprise identity
One of the clearest signs that an SSH environment is maturing is that access starts following identity instead of drifting away from it.
Pangolin supports external identity providers through OAuth2 and OIDC, which makes it easier to connect SSH and other private resource access to the same identity layer used elsewhere in the business. That matters because governance gets much easier once onboarding, offboarding, and access review processes are not fighting against separate local workflows.
This is where SSH stops being mostly a credential distribution problem and starts becoming a policy problem. That is a better place for enterprises to operate from. Identity systems already carry the lifecycle information the business trusts. When infrastructure access lines up with that model, control becomes easier to maintain and easier to explain.
## Why this matters beyond SSH itself
Most enterprises are not trying to modernize SSH for its own sake. They are trying to reduce sprawl in the way private resources are accessed overall.
That is why Pangolin has a stronger story as a private access platform than as a single-purpose SSH product. It lets organizations think about SSH in the same conversation as internal applications, administrative tools, and other private services. That does not just simplify tooling. It improves the clarity of the access model itself.
And that clarity matters. The more systems an organization has, the more expensive fragmented access becomes. Every extra workflow creates more places for ownership to blur, for exceptions to pile up, and for security reviews to become harder than they need to be.
## What to look for in an SSH modernization effort
The most useful way to evaluate any SSH modernization approach is to ask whether it improves the system around SSH, not just the act of connecting.
Does it reduce long-lived credentials? Does it align access with identity and lifecycle controls? Does it help limit access to what is actually needed? Does it make audits, reviews, and offboarding easier? Does it fit into the wider way the organization wants to manage private access?
Those questions matter more than a feature checklist. Enterprises do not struggle with SSH because the protocol is weak. They struggle because access has grown into an awkward mix of habits, exceptions, and inherited infrastructure. A good modernization effort brings that complexity back under control.
## Final thoughts
Enterprise SSH access does not have to remain tied to static keys, manual provisioning, and broad network reach.
The stronger path is to bring SSH into an identity-driven, policy-aware access model that is easier to manage and easier to trust over time. That is where Pangolin is compelling. It does not just provide another way to reach a server. It helps enterprises make SSH part of a cleaner, more consistent approach to private infrastructure access. For a practical getting-started guide, see [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin).
---
### How Does ZTNA Work? Unlocking the Secrets of Enhanced Security
URL: https://pangolin.net/news/how-ztna-works
Published: 2026-03-20
Summary: Learn how ZTNA works, why it differs from VPN-based remote access, and how identity, device posture, and policy combine to protect private applications.
Category: Engineering
Zero Trust Network Access, or ZTNA, is a modern way to control access to private applications and services. Instead of placing users on a network and trusting them once they are inside, ZTNA evaluates each request based on identity, device posture, context, and policy before granting access.
In practical terms, ZTNA works by placing an identity- and policy-aware control layer between users and private resources. When a user tries to reach an internal app, the system authenticates the user, checks device and session signals, evaluates policy, and allows access only to the specific resource they are authorized to use.
That is the core shift. Traditional remote access is network-centric. ZTNA is resource-centric.
This matters because most organizations no longer operate inside a clean perimeter. Users work remotely. Contractors need narrow access. Applications span cloud environments, internal infrastructure, and hybrid networks. In that world, “trusted once connected” creates too much exposure.
If you only need the short version, this is how ZTNA works:
* a user requests access to a private app or service
* the platform verifies identity through an IdP, often with MFA
* device posture and other contextual signals are checked
* a policy engine decides whether access should be allowed
* the user gets access only to the approved resource
* the session can be monitored, revalidated, or revoked if risk changes
## What is ZTNA?
ZTNA provides secure access to private applications and services without exposing broad network access to the user. It is commonly used to replace or reduce reliance on traditional VPNs, especially for web apps, internal tools, admin interfaces, and hybrid environments.
ZTNA is closely related to Zero Trust, but the two are not the same thing.
Zero Trust is the broader security model. NIST describes Zero Trust as an approach that moves security away from assumptions based on network location and toward continuous evaluation of users, assets, and resources. ZTNA is one practical way to apply that idea to access control.
So if Zero Trust is the strategy, ZTNA is one access pattern within that strategy.
That distinction matters. Many vendors market ZTNA as if it is the whole Zero Trust story. It is not. A complete Zero Trust architecture also includes identity security, endpoints, workloads, data protection, telemetry, and policy enforcement across the environment. ZTNA is one important part of that picture because access to private resources is one of the most visible and urgent problems organizations need to solve.
## Why organizations moved toward ZTNA
ZTNA gained traction because the assumptions behind legacy remote access no longer hold up well.
Traditional VPNs were designed for a world where users connected back into a central corporate network. Once connected, they often received broad network reach and could interact with multiple internal systems beyond the original purpose of the session. That may have been acceptable in more centralized environments, but it creates real problems in modern infrastructure:
* users often need access to one application, not a whole subnet
* contractors and third parties should not receive broad internal reach
* internal applications are spread across cloud, on-prem, and hybrid systems
* identity risk can change during a session
* endpoint trust is variable
* lateral movement becomes a larger concern when network access is wide
ZTNA addresses those issues by narrowing access to the resource level and making policy decisions based on more than whether a user successfully connected to the network.
## How ZTNA works step by step
The simplest way to understand ZTNA is to follow a single access request from start to finish.
### 1. A user tries to access a private application or service
The process starts when a user attempts to reach an internal application, service, admin console, or other protected resource.
That request might come from:
* a browser session to an internal web app
* a remote employee trying to reach a private tool
* a contractor accessing a limited internal system
* an administrator connecting to a sensitive service
In a legacy model, this often begins with a VPN connection to the broader network. In a ZTNA model, the request is directed to a broker, gateway, or policy enforcement point that sits in front of the resource.
### 2. The system verifies identity
Before access is granted, the ZTNA system checks who the user is. This typically happens through integration with an identity provider such as Microsoft Entra ID, Okta, Google Workspace, or another SSO platform.
This stage often includes:
* single sign-on
* multi-factor authentication
* group or role lookup
* session validation
Identity is the first major input into the access decision. If the user cannot be strongly authenticated, access should stop there.
### 3. The system evaluates context and device posture
ZTNA does not stop at identity. Strong implementations also evaluate the context around the request.
That can include:
* device health or posture
* operating system status
* certificate presence
* geographic location
* time of access
* network characteristics
* previous user behavior
* risk signals from security tools
This matters because an authenticated user is not automatically a safe request. A valid identity coming from an unmanaged device, an unusual location, or a high-risk session may require stronger controls or may be denied altogether.
This reflects a core Zero Trust principle: a valid login alone is not enough to justify access.
### 4. A policy engine decides whether access should be allowed
Once identity and context are available, the ZTNA platform evaluates policy.
This is the decision layer. A policy engine answers questions such as:
* Is this user allowed to access this specific application?
* Is their device trusted enough for this resource?
* Does this request meet location, time, or risk requirements?
* Should additional authentication be required?
* Should access be read-only, temporary, or fully blocked?
NIST’s Zero Trust Architecture model describes this kind of policy-based decision-making as central to Zero Trust. The practical point is simple: access is not granted because someone is “inside the network.” It is granted because a defined policy says this request is acceptable for this resource under these conditions.
### 5. Access is granted only to the specific resource
If the request is approved, the user is connected only to the application or service they are authorized to use.
This is one of the biggest differences between ZTNA and traditional VPNs.
A VPN often creates a network path first and then relies on segmentation, ACLs, or internal controls to limit what happens next. ZTNA is designed to avoid that broad first step. The user receives access to the intended resource, not a wider portion of the network.
That narrower access model reduces unnecessary exposure and can limit lateral movement opportunities if an account or session is compromised.
### 6. The session is monitored and can be re-evaluated
Strong ZTNA systems do not assume that a session is trustworthy forever just because it passed the first check.
Risk can change during a session. Device posture can drift. Identity risk can rise. Behavior can become suspicious. Policies can change. As a result, Zero Trust guidance generally favors continuous or repeated validation rather than one-time trust at login.
As conditions change, the system may:
* re-check session validity
* trigger re-authentication
* revoke access if risk rises
* log activity for audit and detection
This is another major difference from legacy access models that rely heavily on a trusted tunnel after the initial connection is established.
## ZTNA workflow at a glance
| Step | What happens | Why it matters |
| --- | --- | --- |
| **User request** | A user attempts to reach a private app or service | Access starts at the resource, not the network |
| **Identity check** | The platform verifies identity through SSO, MFA, and directory data | Confirms who is making the request |
| **Context evaluation** | Device posture, location, time, and other signals are reviewed | Helps detect risky or non-compliant sessions |
| **Policy decision** | Rules determine whether access should be allowed, denied, or challenged | Enforces least-privilege access |
| **Resource connection** | The user is connected only to the approved app or service | Limits attack surface and lateral movement |
| **Continuous validation** | The session can be monitored and re-evaluated | Prevents one-time trust from lasting indefinitely |
## What components make ZTNA work?
Different vendors use different terms, but most ZTNA architectures rely on a familiar set of building blocks.
| Component | Role in the architecture |
| --- | --- |
| **Identity provider** | Authenticates the user and supplies signals such as roles, group membership, and MFA status |
| **Policy engine** | Decides whether a request should be allowed, denied, or challenged based on defined rules |
| **Policy enforcement point or access broker** | Sits between the user and the resource and enforces the policy decision |
| **Device posture and context signals** | Supplies information about endpoint health, certificates, location, risk, and session context |
| **Resource connectors or protected application paths** | Provide a controlled path from the protected resource to the access layer |
| **Logging and monitoring** | Capture access decisions and activity for troubleshooting, audits, and incident response |
## ZTNA vs VPN: what actually changes?
The most useful way to explain the difference is this: a VPN connects a user to a network, while ZTNA connects an authorized user to a specific resource.
That does not mean all VPNs are inherently insecure or that every ZTNA product solves every access problem. It means the underlying trust model is different.
| Area | Traditional VPN | ZTNA |
| --- | --- | --- |
| **Access model** | Connects the user to a network | Connects the user to a specific app or service |
| **Trust decision** | Often concentrated at initial login | Evaluated before access and often during the session |
| **Scope of access** | Can be broader than the user actually needs | Intended to be limited to approved resources |
| **Lateral movement risk** | Higher if the user lands on a wider network segment | Lower because access is narrower by design |
| **Policy inputs** | Often identity plus network controls | Identity, device posture, context, and policy |
| **Migration reality** | Often already deployed for legacy access | Frequently introduced gradually alongside VPNs |
This narrower model helps reduce attack surface and makes access easier to reason about.
In practice, most organizations do not replace VPNs overnight. Many run VPNs and ZTNA side by side for a period, and some legacy protocols or operational requirements still make VPNs useful in specific cases. The real shift is that broad network access stops being the default answer for every remote access problem.
## Where ZTNA fits inside a Zero Trust architecture
One of the most common misunderstandings in this category is treating ZTNA as if it equals Zero Trust.
It does not.
ZTNA primarily addresses access to applications and services. Zero Trust architecture is wider. According to NIST and NCSC guidance, a full Zero Trust program also includes:
* strong identity governance
* device trust and health validation
* policy-based decision-making
* monitoring and telemetry
* workload and resource protection
* segmentation and data protection
* continuous verification and adaptive response
ZTNA is best understood as the access layer that applies Zero Trust principles to user-to-resource connectivity. Its effectiveness depends on the quality of the surrounding identity, endpoint, and policy ecosystem.
## Benefits of ZTNA
When implemented well, ZTNA delivers several practical benefits:
* reduced implicit trust because users are not trusted simply for being “on the network”
* more granular access because permissions can be tied to specific applications and services
* lower lateral movement risk because users are not broadly placed on internal network segments
* better support for remote, third-party, and contractor access because access can be narrow and auditable
* stronger policy consistency because decisions can be applied through a centralized control layer
## Tradeoffs and limitations
ZTNA has clear benefits, but it also has practical limits:
* ZTNA is not a complete security architecture and does not replace identity security, endpoint management, threat detection, or data protection
* policy quality matters, so messy roles, unmanaged exceptions, and weak device trust lead to weak outcomes
* legacy apps and unusual protocols may require more design work than modern web applications
* device posture signals are only as strong as the endpoint tooling behind them
* migration usually requires inventory work, policy design, identity cleanup, and staged rollout
## What to look for in a ZTNA solution
If an organization is evaluating ZTNA, the most important questions are not just about features. They are about how well the platform supports a workable access model in the real environment.
Look for:
* strong identity provider integration
* clear and granular policy controls
* support for both public and private application access patterns
* visibility into access events and decision logs
* support for modern MFA and adaptive access flows
* a deployment model that does not require excessive complexity
* a realistic path for mixed environments during migration
The right solution should make access both safer and easier to manage. If it adds too much operational friction or only works for a narrow set of applications, adoption will stall.
## Common questions about how ZTNA works
### Is ZTNA the same as Zero Trust?
No. ZTNA is one access-control approach within a broader Zero Trust architecture.
### Does ZTNA replace a VPN?
Sometimes, but not always immediately. Many organizations use ZTNA to replace VPN access for specific applications first, then reduce VPN reliance over time.
### Is ZTNA only for remote workers?
No. It is useful anywhere an organization wants policy-based, identity-aware access to private resources, including internal admins, contractors, vendors, and hybrid teams.
### Does ZTNA only protect web applications?
No. Web applications are often the easiest starting point, but support for other protocols depends on the platform architecture.
### What is the biggest difference between ZTNA and legacy remote access?
Legacy remote access often grants network connectivity first. ZTNA evaluates the request first and grants access only to the approved resource.
### Is ZTNA enough on its own?
No. ZTNA improves access control, but it works best when paired with strong identity security, endpoint visibility, logging, and broader Zero Trust policy enforcement.
## Final takeaway
ZTNA works by putting identity, device trust, and policy checks in front of private resources so that users get access only to what they are explicitly allowed to use. That makes it fundamentally different from legacy remote access models that begin by extending network connectivity and trusting users too broadly once they are inside.
For organizations modernizing secure access, that shift is the real value. ZTNA does not solve every Zero Trust problem on its own, but it gives security and infrastructure teams a stronger way to control who can access what, under which conditions, and for how long.
## Sources
* [NIST SP 800-207, Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final)
* [NCSC, Demystifying Zero Trust](https://www.ncsc.gov.uk/collection/zero-trust/demystifying-zero-trust)
* [NCSC, Zero trust architecture design principles](https://www.ncsc.gov.uk/collection/zero-trust/architecture-design-principles)
* [BeyondCorp reference site](https://www.beyondcorp.com/)
## Related reading
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [What is an Identity-Aware Proxy?](/news/what-is-an-identity-aware-proxy)
* [Secure Remote Access: Enterprise ZTNA Implementation Guide](/news/secure-remote-access)
* [How Pangolin Works](/news/how-pangolin-works)
---
### Pangolin for MSPs: Secure Remote Access Per Customer
URL: https://pangolin.net/news/pangolin-for-msps
Published: 2026-03-16
Summary: Pangolin helps MSPs replace VPN sprawl with a multi-tenant, identity-based remote access platform built to scale across client environments.
Category: Product
Most MSPs did not set out to build a different remote-access stack for every client. It just happened one request at a time.
One customer already had a VPN in place, so the MSP kept it. Another needed an internal web app exposed to a few users, so a reverse proxy got added. Another had a vendor who needed temporary access, so somebody opened a rule or stood up a jump box. A year later, the MSP is supporting a pile of access patterns that all solve roughly the same problem in slightly different ways.
That is the real issue. MSPs are usually not missing access tools. They are carrying too many of them, and the inconsistency starts showing up everywhere: onboarding takes longer, support gets harder, technicians keep context-switching between clients, and users often end up with more access than the job called for.
## The remote access problem is not the same for every user
Most client environments need two different things.
Some users only need a private web app. That might be an admin portal, an internal dashboard, a line-of-business application, or some other browser-based system that should stay private.
Other users need deeper access. MSP technicians, engineers, and vendors may need a specific host, service, or subnet behind the environment.
Those should not be treated as the same request. If a browser user gets a VPN because that is the default tool, they inherit client rollout and more network reach than they needed. If a technician workflow gets forced through whatever web-facing access pattern is already available, the MSP usually ends up with awkward exceptions that nobody likes maintaining.
## Key details
### Why MSP remote access stacks get messy
Messy access stacks are usually the result of small local decisions.
Teams add one more VPN because a client already uses it. They add one more reverse proxy because somebody needs a portal reachable. They keep one more firewall hole because removing it would take coordination. Each decision is understandable on its own. Together, they create a service model that is harder to scale.
At that point, the MSP is not really standardizing access. It is managing drift.
That drift has a cost:
* support teams have to remember too many client-specific exceptions
* onboarding a new customer takes more design work than it should
* access reviews are harder because every environment is a little different
* offboarding contractors and vendors gets riskier when access is scattered across tools
### What a cleaner secure remote access model looks like
A better approach is to separate the browser path from the deeper private path and keep both inside one consistent system.
Browser users should get a managed hostname, HTTPS, and an authenticated front door in front of the private application. They should not need client software just to open a page.
Technicians and vendors who need deeper reach should get a narrower private path tied to the systems involved in the work. That keeps private connectivity available when it is needed without making broad network access the default answer for everybody else.
That model is easier for an MSP to run because it lines up with real jobs. Staff opening an internal app, a support engineer reaching an admin service, and a contractor connecting for a short maintenance window do not need the same access path.
### Where Pangolin helps
Pangolin gives MSPs a way to run that split access model across many client environments from one platform.
Each client can be kept in its own organization with its own users, resources, and policies. That gives the MSP tenant separation without forcing it to support a different remote-access product for each customer. For the broader architecture, see [How Pangolin Works](https://docs.pangolin.net/about/how-pangolin-works).
For browser-based access to private applications, Pangolin uses [Public Resources](https://docs.pangolin.net/manage/resources/understanding-resources#public-resources). The user connects through a managed hostname over HTTPS, authenticates first, and then reaches the backend service. The app stays private, and the user does not need a VPN just to open it in a browser.
For deeper workflows, Pangolin uses [Private Resources](https://docs.pangolin.net/manage/resources/understanding-resources#private-resources). The MSP can grant access to the specific private target involved instead of dropping the user onto a broad section of the client network.
That gives MSPs a practical split:
* browser users get the application they need without broad network access
* technicians get the deeper path only when the job calls for it
* vendors can be granted narrower access that is easier to review and revoke
* clients stay separated without turning the MSP stack into a patchwork
### Why that matters commercially
The best MSP platforms do not just improve security. They reduce operational waste.
If secure access can be delivered from one repeatable model, the MSP spends less time maintaining exceptions and more time running a service it can scale. That shows up in faster onboarding, cleaner support workflows, and a more credible story when clients ask how access is controlled.
Pangolin also gives MSPs something they can package more cleanly. Instead of selling a loose combination of VPNs, proxies, and special cases, the MSP can offer a standard access layer for private apps, technician workflows, and client separation. With [Blueprints](https://docs.pangolin.net/manage/blueprints), that model can also become more repeatable across deployments.
## Conclusion
Most MSPs do not need more remote-access products. They need fewer exceptions.
Pangolin gives them a cleaner way to handle private web access, deeper technician access, and multi-client separation from one operating model. That makes the security story tighter, but it also makes the service easier to deliver.
For MSPs, that is the point. Secure access should be something the team can standardize, not something it has to reinvent for every client.
## FAQ
**What remote access solution works best for MSPs?**
*The best fit is usually a model that separates private web access from deeper technician access. That keeps browser users out of unnecessary VPN workflows while still giving engineers and vendors the narrower private path they need.*
**How do MSPs stop every client from becoming a one-off remote access setup?**
*They standardize the access model instead of standardizing on a single blunt tool. If the same platform can handle private web apps, technician access, and client separation, the MSP can repeat that pattern across clients without rebuilding the stack every time.*
**Can an MSP give client staff secure browser access without installing a VPN?**
*Yes. If the job is opening a private web application, the cleaner design is an authenticated browser path with a managed hostname and HTTPS. The user signs in first and reaches the app without joining the full client network.*
**What is the right way to handle technician and vendor access for MSP clients?**
*Give them the specific private access path the work requires and avoid leaving behind standing broad network access. That keeps support practical while making offboarding and access review easier.*
**Why would an MSP use Pangolin instead of piling on more VPNs and proxies?**
*Pangolin gives the MSP one platform for private web access, narrower private connectivity, and tenant separation. That reduces tool sprawl and makes secure remote access easier to package as a repeatable service.*
---
### What Is a Tunneled Reverse Proxy? Architecture & Uses
URL: https://pangolin.net/news/tunneled-reverse-proxy
Published: 2026-03-13
Summary: Learn how tunneled reverse proxies publish private apps through outbound tunnels without broad VPN access or exposed networks.
Category: Engineering
Enterprises need a way to publish private applications without exposing private infrastructure to the internet.
In practice, that creates a familiar tradeoff. Teams either open inbound paths to internal services and increase their attack surface, or they rely on broad VPN access that gives users more network reach than they actually need. Neither approach fits well with modern enterprise security.
A tunneled reverse proxy solves that problem with a different model. It lets organizations publish private applications through a controlled access layer while the backend stays behind firewalls, private IP space, and NAT. Instead of exposing the application network directly, the connection is established outward from the private environment and tied back to an authenticated front door.
This is why tunneled reverse proxies have become more relevant to enterprise security, infrastructure, and platform teams. The problem is not just connectivity. It is secure application delivery, least-privilege access, auditability, and operational consistency across hybrid environments.
That direction aligns closely with [NIST SP 800-207: Zero Trust Architecture](https://www.nist.gov/publications/zero-trust-architecture).
In this guide, we explain what a tunneled reverse proxy is, how it works, how it differs from a standard reverse proxy, where it fits in enterprise architecture, and how platforms like Pangolin can implement this model in practice.
## Tunneled Reverse Proxy Definition
A tunneled reverse proxy is an application delivery model where a reverse proxy presents a public or managed access point for users, while backend traffic reaches private applications through an encrypted outbound tunnel established from inside the private environment.
The proxy handles routing, TLS, identity checks, and access policy. The origin stays private and does not require direct inbound exposure.
At its core, the model combines three things:
* Reverse proxy behavior at the edge
* Encrypted tunnel-based connectivity on the backend
* Controlled access to private applications without direct network exposure
## Tunneled reverse proxy fundamentals
### What Is a Reverse Proxy?
A reverse proxy sits in front of one or more backend services and handles incoming requests on their behalf.
Users connect to the reverse proxy, not directly to the application. The proxy then forwards traffic to the correct backend service and can apply controls such as:
* TLS termination
* Hostname routing
* Authentication
* Access control
* Header management
* Request policy
In a standard reverse proxy deployment, the proxy still needs direct network reachability to the origin. That usually means the backend is on the same network, in the same cloud environment, or otherwise reachable through routing and firewall rules.
That model works well in many environments, but it becomes harder when the backend application lives in a private network that is intentionally not exposed inbound.
### What Makes a Reverse Proxy Tunneled?
A tunneled reverse proxy changes how the proxy reaches the backend.
Instead of depending on inbound reachability to the private application, a connector inside the private network establishes an outbound tunnel back to the access layer. User traffic arrives at the reverse proxy, passes authentication and policy checks, and is then forwarded through that tunnel to the internal service.
The application remains private, but it is still reachable through a managed entry point.
That architectural inversion is the key. The private side initiates the connection outward. This allows enterprises to publish internal services without opening inbound firewall ports across remote environments, branch sites, data centers, or private cloud networks.
For enterprise teams, that is usually easier to govern, easier to deploy across mixed environments, and safer to scale.
### How a Tunneled Reverse Proxy Works
At a high level, the request flow looks like this:
1. A user requests an internal application through a managed hostname.
2. The request reaches the reverse proxy or edge gateway.
3. The gateway applies TLS, identity checks, and access policy.
4. Approved traffic is forwarded through an encrypted tunnel.
5. A connector inside the private network receives the traffic and forwards it to the application.
6. The response returns through the same path to the user.
This is what makes tunneled reverse proxies effective for hybrid infrastructure. They let organizations keep applications where they already live, whether that is on-prem, in private cloud networks, in branch offices, or behind customer firewalls, while still placing a consistent access layer in front of them.
### Tunneled Reverse Proxy vs Standard Reverse Proxy
From the user’s perspective, a standard reverse proxy and a tunneled reverse proxy can look similar. Both may present the same hostname, TLS certificate, and login experience.
The real difference is on the backend side.
A standard reverse proxy assumes it can directly reach the origin through normal routing. A tunneled reverse proxy assumes the origin may not be reachable inbound at all, so it relies on an outbound connector and a maintained tunnel from the private environment.
For enterprises, that changes both the security model and the operating model.
A tunneled reverse proxy reduces direct exposure of internal infrastructure because applications do not need public IP addresses or inbound openings. In return, the access platform takes responsibility for connector lifecycle, tunnel health, resource definitions, access policy, and the secure path between the edge and the origin.
That tradeoff is often worth it because the enterprise gains a controlled access layer instead of direct network exposure.
### Tunneled Reverse Proxy vs VPN
This is one of the most important distinctions for enterprise buyers.
A VPN is usually network-first. Once connected, the user gains some level of network reachability to a subnet, segment, or broader internal environment.
A tunneled reverse proxy is usually application-first. It is designed to expose specific services, hostnames, or routes instead of expanding general network access.
That difference matters because most enterprises are trying to reduce lateral movement, avoid over-permissioning, and apply policy at the resource level.
This is exactly the direction set out in zero trust architecture, where access decisions are centered on subjects, resources, and policy rather than broad trust in a network zone.
A tunneled reverse proxy does not replace every VPN use case. It solves a different and increasingly common one: secure access to private applications without granting broad internal network reach.
## When a Tunneled Reverse Proxy Is the Right Fit
A tunneled reverse proxy is most useful when the goal is controlled access to a defined application or service, not broad access to an internal network.
It is usually a strong fit when:
* The application must stay behind NAT, a firewall, or private addressing
* Users only need access to a specific app, hostname, or route
* The organization wants identity-aware access controls at the application layer
* Infrastructure is spread across cloud, on-prem, branch, or customer-managed environments
* Teams want to reduce inbound exposure without redesigning the underlying application
It is usually a weaker fit when users need full network-level access to many internal systems at once, or when the use case depends on protocols and workflows better served by a broader private networking model.
## Why Enterprises Use Tunneled Reverse Proxies
The reasons are practical. For most teams, the value comes from reducing exposure while making private applications easier to publish and govern.
1. Reduced inbound exposure. Many internal applications were never designed to sit directly on the public internet. A tunneled reverse proxy lets enterprises keep those services behind firewalls while still making them available to authorized users through a managed access point.
2. Better fit for zero trust access. A tunneled reverse proxy places identity, policy, and access control at the application front door. That makes it a strong fit for zero trust strategies built around least privilege and resource-level access.
3. Easier publishing behind NAT or restrictive firewalls. This is one of the most common operational drivers. Enterprises often need to expose services in branch offices, private cloud networks, data centers, or customer environments where inbound changes are undesirable or impossible. Outbound tunnel models are built for exactly this scenario.
4. Simpler hybrid infrastructure access. Modern enterprises run applications across multiple environments. A tunneled reverse proxy gives teams one access layer for services that live across on-prem, cloud, edge, and remote networks.
5. Safer access to legacy applications. Older applications often cannot support modern identity and access patterns on their own. A tunneled reverse proxy lets teams place security and access controls in front of them without forcing a full redesign.
## Common Enterprise Use Cases
This model is most useful when a team needs controlled access to a specific private service rather than broad network reach.
* Secure access to internal web applications. Dashboards, internal portals, admin panels, and line-of-business applications are strong candidates because they can be published through a browser-based access layer without exposing the underlying network.
* Contractor and partner access. External users usually need access to one application, not an entire corporate network. A tunneled reverse proxy is a cleaner fit for this than broad VPN access.
* Hybrid cloud publishing. When services are split across cloud and on-prem environments, a tunneled reverse proxy provides a consistent way to publish and protect them.
* SaaS callbacks and inbound webhooks. Some external platforms need to reach private services. A tunneled reverse proxy can provide a controlled public entry point while the backend remains private.
* Fast-moving projects and temporary access. Migrations, acquisitions, remote sites, and time-sensitive rollouts often need secure access quickly. Tunnel-based models reduce the networking overhead involved in standing that up.
## Security Considerations
A tunneled reverse proxy can improve security posture significantly, but only when it is deployed as part of a deliberate access model. The key controls to evaluate are:
* Identity and policy enforcement. The biggest value comes from making access decisions at the edge based on identity, policy, and context rather than just IP reachability. This is the point where a tunneled reverse proxy becomes part of a zero trust architecture instead of just a transport mechanism.
* Connector trust. The connector becomes part of the trusted path. Enrollment, credentials, upgrade hygiene, and scoping all matter. The tunnel is only as trustworthy as the connector maintaining it.
* Deny-by-default exposure. A strong model does not expose services simply because a connector is installed. Resources should be explicitly defined, and access should be explicitly assigned.
* Auditability. Enterprise access layers need logs, visibility, and clear ownership. Application publishing is not just a networking task. It is part of security operations, access governance, and compliance.
* Reduced lateral movement. When access is granted to a defined application instead of a broader internal network, the blast radius is smaller. This is one of the main reasons application-first access models are increasingly preferred over broad network-first approaches.
## What to Look for in a Tunneled Reverse Proxy Platform
When evaluating platforms, do not just ask whether they can create a tunnel.
Ask whether they can:
* Enforce identity-aware policy
* Define resources cleanly
* Keep the backend private by default
* Support browser-based access for web applications
* Support private access patterns where needed
* Scale across multiple sites and environments
* Provide operational clarity for deployment, policy, and monitoring
Those are the capabilities that turn a tunnel into an enterprise access layer.
The best platforms combine secure publishing, access control, and operational structure in one system.
## How Pangolin Fits This Model
Pangolin is one example of a platform built around this model.
In Pangolin, resources are the applications, hosts, or network ranges made available for remote access. Public resources act as reverse proxies to backend services. Sites connect Pangolin to the networks where those resources live. Newt is the connector that establishes secure connectivity to remote networks and routes traffic to targets.
By default, nothing is exposed. Resources must be explicitly defined, and access must be explicitly assigned.
This architecture matters because it separates access, policy, and connectivity in a way that maps cleanly to enterprise operating models.
Relevant documentation:
* [Pangolin Resources](https://docs.pangolin.net/manage/resources/understanding-resources)
* [Pangolin Sites](https://docs.pangolin.net/manage/sites/understanding-sites)
In practice, that shows up in four ways:
1. Browser-based access without client-side software. For web applications, Pangolin provides public HTTPS resources that sit behind an authenticated reverse proxy. Users access those resources in a browser, and Pangolin applies identity and context-aware access policies before traffic reaches the backend.
2. Secure outbound connectivity from remote networks. Pangolin sites are designed to run behind a firewall, not on the public internet. Users do not connect to sites directly. They connect to resources, and Pangolin handles the path between the access layer and the private network through the site and connector architecture. For most deployments, Newt sites are the recommended model because they expose remote resources through a managed tunnel and do not require NAT configuration.
3. Resource-level access instead of broad network exposure. Pangolin is built around resource-based access. Users connect to resources, not to entire networks by default. That makes it easier to deliver least-privilege access for internal applications while keeping the blast radius smaller than broad network-first approaches.
4. One platform for public and private access patterns. Public resources are ideal for browser-based application publishing through an authenticated reverse proxy. Private resources support broader zero-trust VPN-style access when a client-based model is the better fit. This gives enterprises one platform that can handle both application-first access and broader private connectivity where needed.
Pangolin sites can also be deployed redundantly. Resources are deny-by-default, and the platform is structured around explicit definitions for sites, resources, and access control.
That combination makes Pangolin relevant for teams that want more than a simple tunneling utility. It gives them a governed way to publish, protect, and manage private access.
For broader context, see [Pangolin vs Reverse Proxy vs VPN](https://docs.pangolin.net/about/pangolin-vs-reverse-proxy-vs-vpn).
## Why This Matters for Enterprise Architecture
Enterprises do not need more disconnected access tools. They need a consistent model for delivering secure access across mixed infrastructure.
A tunneled reverse proxy is valuable because it solves more than one problem at once. It reduces inbound exposure, improves access control, supports hybrid environments, and creates a cleaner operating boundary around private applications.
That is why this pattern fits so well into modern zero trust architecture. It is not just about tunneling traffic. It is about controlling how private applications are published, protected, and governed.
## Final Thoughts
A tunneled reverse proxy is more than a clever way to move traffic. It is a practical pattern for publishing private applications securely without exposing the underlying network.
It combines the control of a reverse proxy with the reach of an outbound tunnel, allowing enterprises to deliver access without broadening internal network exposure. For teams moving away from broad VPN access and toward resource-level, identity-aware security, it is an increasingly important architectural building block.
The core value is not tunneling for its own sake. The value is being able to publish private applications through a controlled access layer with better security, clearer governance, and less operational friction across hybrid environments.
For organizations evaluating this pattern, the important questions are whether the platform keeps backends private by default, applies access policy at the right layer, and gives teams enough operational clarity to manage the system over time. Platforms like Pangolin are relevant when they satisfy those requirements without turning private access into another collection of disconnected tools.
## Related reading
* [What is an Identity-Aware Proxy?](/news/what-is-an-identity-aware-proxy)
* [Building a Peer-to-Peer Alternative to Cloudflare Tunnels](/news/building-a-peer-to-edge-peer-reverse-proxy)
* [How Pangolin Works](/news/how-pangolin-works)
## FAQ
**Is a tunneled reverse proxy the same as a VPN?**
*No. A VPN is usually network-first and expands reachability into an internal environment. A tunneled reverse proxy is usually application-first and exposes specific services through a controlled access layer.*
**Does a tunneled reverse proxy require inbound firewall changes?**
*Not in the typical model. The defining pattern is that the private side establishes an outbound connection to the access layer, which reduces the need for inbound exposure.*
**When should an enterprise use a tunneled reverse proxy?**
*Use it when you need to publish private applications securely, reduce inbound exposure, and apply policy at the resource level instead of granting broad internal network access.*
**How does Pangolin fit this model?**
*Pangolin uses sites to connect remote networks, Newt as the connector, and resources as the units of access. Public resources act as reverse proxies, while access remains explicitly defined and deny-by-default.*
---
### Comparison - Pangolin vs. WireGuard
URL: https://pangolin.net/news/pangolin-vs-wireguard
Published: 2026-03-12
Summary: Compare WireGuard tunnels with Pangolin’s full remote access platform for identity, policy, automation, and browser access.
Category: Product
## The Difference Between a Tunnel and a Complete Zero Trust Access Platform
The comparison between Pangolin and WireGuard often misses a key distinction. While WireGuard is a superb, high-performance Layer 3 tunnel protocol, it functions purely as a secure network interface, not a complete remote access solution. Pangolin, however, is a full remote access platform that uses WireGuard as its foundation. It builds upon WireGuard by integrating essential features for real-world secure deployment, including identity management, policy enforcement, automation, and a user experience that doesn't demand specialized networking knowledge.
If you appreciate WireGuard, you will find Pangolin an ideal solution. It allows you to manage access at scale without the time and effort required to build the missing platform layer yourself.
## Quick comparison
| Feature | Pangolin | WireGuard |
| --- | --- | --- |
| **Core function** | ✓ Remote access platform with a control plane, identity, and policy | Secure Layer 3 tunnel protocol and interface |
| **Mental model** | ✓ Users, roles, resources, sites, policies | Keys, peers, routes, allowed IPs |
| **Access control** | ✓ Zero trust, deny by default, identity based access to resources | Network level, enforced by routing and firewall rules |
| **Connectivity** | ✓ Automated NAT traversal with hole punching and relay fallback | You design topology and handle NAT realities, often using keepalives |
| **Web access** | ✓ First class browser access through an integrated proxy and access layer | Not included. You add a reverse proxy separately |
## WireGuard: A minimalist tunnel protocol that you assemble into a solution
WireGuard is intentionally simple. You create a virtual interface, exchange public keys, define which IP ranges are routed through the tunnel, and bring the interface up. It gives you a strong foundation that is small, auditable, and fast.
That simplicity is also where most teams feel the friction. WireGuard’s model is “cryptokey routing”. You associate a peer public key with what it is allowed to reach, and everything else depends on the system you build around those primitives.
### Problem 1: Key exchange is simple once, then becomes a scaling problem
For small setups, WireGuard's simplicity, often likened to exchanging SSH keys, holds true.
However, the complexity escalates significantly with larger deployments involving numerous users, multiple sites, external contractors, frequent device changes, and the requirement for auditable security from a dedicated team. In these scenarios, WireGuard lacks essential features such as an enrollment workflow, an identity directory, or a robust policy engine. Organizations are left to manually manage key issuance, device approval, and, critically, access revocation across all locations where peer configurations are defined.
Consequently, many WireGuard implementations quickly evolve into unmanaged "DIY access control" systems.
### Problem 2: Key storage becomes your security model
WireGuard long term keys live wherever your configuration lives. That might be on endpoints as configuration files, in automation tooling, in a password manager, or in a configuration repository. The protocol is secure, but your security posture is now strongly influenced by how well you manage secret sprawl and configuration drift.
Common failure modes include:
* Key and configuration sprawl across laptops, servers, and administrator machines.
* Revocation that is slow or incomplete, because it depends on updating many distributed configurations.
* Configuration mistakes that grant broad network access by accident, especially through routes and allowed IP ranges.
* A lack of consistent auditing, because the access decision is encoded in static configuration.
### Problem 3: Access control is network oriented, not identity oriented
WireGuard does not know what an “employee”, “contractor”, “database”, or “admin panel” is. It moves packets. Least privilege is possible, but you implement it using routing, IP plans, and firewalls, and you must keep those rules correct over time.
In practice, this is why WireGuard deployments often start narrowly and then drift toward broader access than intended as exceptions pile up.
### Problem 4: NAT and reachability introduce routine operational work
WireGuard is silent when idle by design. In NAT heavy environments, peers may require persistent keepalives to maintain inbound reachability. This is a normal trade off of keeping the protocol minimal, but it pushes deployment complexity up into operations.
The result is a familiar set of issues: a peer works at home but not on hotel Wi Fi, it works on one mobile network but not another, or it requires additional infrastructure like hubs and jump hosts to provide consistent connectivity.
### The result
WireGuard is powerful, but it is a building block. It gives you a fast encrypted tunnel. It leaves key distribution, lifecycle management, policy design, NAT traversal strategy, and day two operations to you.
## Pangolin: WireGuard transport, with identity, policy, and automation added
Pangolin’s value is that it turns WireGuard from a great tunnel into a complete access product. Pangolin is a zero trust access platform built on WireGuard. It shifts the model away from IP level plumbing and toward users, roles, and resources.
## How Pangolin solves WireGuard’s biggest operational problems
### Solution to Problem 1 and 2: Replace key exchange chaos with a managed control plane
Instead of treating every peer configuration as a hand crafted artefact, Pangolin introduces a control plane that coordinates connectivity and access. The architecture includes a control plane with a web interface, API, authentication, a database, and WebSocket coordination, plus components that manage WireGuard tunnels and connectivity.
Pangolin offers a client credential model that streamlines operations by eliminating the need to distribute static peer configurations across an organization. Clients first set up a control channel and then use ephemeral keys to establish their WireGuard tunnels.
The practical benefit is straightforward: teams stop spending time managing peer files and start managing access policy.
### Solution to Problem 3: Move from network access to resource access
Pangolin’s resource model is explicit: access must be granted to users, roles, or machines for a WireGuard tunnel to be established to the site hosting the resource. The default posture is denied by default.
Instead of giving someone a tunnel into a network and hoping firewall rules stay perfect, Pangolin encourages a safer model: define the resources that matter, then grant access to those resources based on identity.
This aligns with how organisations actually think about risk. People need access to a database, an internal dashboard, or a subnet used by a staging environment. They rarely need unrestricted network presence.
### Solution to Problem 4: Make NAT traversal and connectivity selection a product feature
Pangolin directly addresses the real world mess of NAT and firewalls.
Pangolin implements a two-stage connectivity strategy. It initially tries to achieve direct peer-to-peer connection using NAT hole punching. If a direct path fails, it reverts to relaying traffic via Gerbil. Critically, this relay forwards WireGuard packets while maintaining the integrity of the end-to-end WireGuard encryption.
This enhancement shifts the user experience from a dependence on network conditions, where "the VPN sometimes works," to an automatic resolution where "the client finds a working path." The benefit is a reduced need for users to implement manual network adjustments and fragile workarounds.
## Pangolin also adds two capabilities WireGuard does not try to provide
### First class browser access for web applications
WireGuard does not include web access. Pangolin includes a reverse proxy and middleware layer that provides browser based access for public resources, integrated with the same identity and access control system.
This is a major difference for teams that want a single system for both web applications and private TCP or UDP services.
### Platform workflows for teams, not just tunnels
Pangolin offers a more advanced operational framework than Wireguard. This framework is built around concepts such as sites and resources, and features deployment and configuration workflows optimized for continuous management, rather than focusing solely on a one-time initial setup.
## The trade off, and why Pangolin is usually the practical choice
The fundamental difference between Pangolin and WireGuard is the scope of their features.
WireGuard is celebrated for its elegance and minimalism. It is the ideal choice for environments with simple network topologies where an organization prefers to manage and build its own custom access system around a core tunneling protocol.
Pangolin, by contrast, provides a more comprehensive platform. While this means introducing more components and complexity, it integrates many features that most teams ultimately need to develop internally: Identity-based access policies, default-deny resource access control, automatic NAT traversal with relay as a backup, and built-in web access.
For the majority of organizations, this comprehensive trade-off is beneficial. Pangolin utilizes WireGuard's high-level security and performance characteristics at the transport layer, but extends them with a platform layer that creates a truly scalable, usable access solution.
## Related comparisons
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [Pangolin vs. Tailscale](/news/pangolin-v-tailscale)
* [Pangolin vs. NetBird](/news/pangolin-v-netbird)
* [How Pangolin Punches Through NATs and Firewalls](/news/nat-holepunching)
---
### Comparison - Pangolin vs. Teleport
URL: https://pangolin.net/news/pangolin-vs-teleport
Published: 2026-03-11
Summary: Compare Pangolin and Teleport across workforce access, engineering sessions, protocol coverage, and zero trust architecture.
Category: Product
## Network-First Zero Trust Access vs. Protocol-First Access Broker
At first glance, Pangolin and Teleport appear to solve a similar problem: controlling access to private resources and improving on legacy methods within the broader Zero Trust conversation.
But they are built for different jobs.
Teleport is a protocol-first access broker. It is designed to manage and audit access to specific infrastructure resource types such as SSH, Kubernetes, databases, desktops, and internal applications. It's an excellent fit for organizations requiring deep control over engineering and administrative sessions.
Pangolin is a network-first Zero Trust Access Platform built on top of WireGuard. It begins with secure private connectivity and then applies identity-based policy to control access across the entire business for both regular users and the engineering team. This makes Pangolin better suited for organizations that want to move beyond traditional VPNs and deliver secure access consistently across the entire workforce.
This is the core difference:
* Teleport is built primarily around infrastructure access.
* Pangolin is built to become the private access layer for the enterprise.
## Two Products, Two Different Access Strategies
When evaluating remote access, the most important question is not which product has the longest feature list, but which access model fits the organization.
Teleport takes a session-centric approach. It brokers and governs access to supported resource types, with a strong emphasis on auditability and administrative control.
Pangolin takes a connectivity-first approach. It creates secure private access across networks, then enforces Zero Trust policy, ensuring users only reach the applications, services, and systems they are authorized to use.
This fundamental difference shapes everything from user experience to deployment strategy and long-term scalability.
## Where Teleport Fits
Teleport is a credible choice when the access challenge is centered on engineering infrastructure.
If your primary concern is controlling privileged access to SSH servers, Kubernetes clusters, databases, and similar technical resources, Teleport aligns well with that requirement. It is especially relevant when compliance, session governance, and detailed administrative auditing are major drivers. For this use case, Teleport is focused and capable.
The issue is that most enterprises are not trying to solve access only for engineering teams. They are trying to solve access problems for everyone.
## The Enterprise Access Gap
In most organizations, secure private access is no longer limited to developers and infrastructure teams.
Modern enterprises need a single approach that can support employees, contractors, and partners across a wide range of internal applications, services, and systems. The challenge is not just privileged engineering access. It is delivering secure, reliable access across the business without creating separate tools, policies, and workflows for different teams.
This is where protocol-first products begin to show their limits. Teleport is strongest when access maps neatly to infrastructure workflows. Enterprises, however, rarely operate in neat categories. They need one secure access layer that can support engineering and non-engineering teams alike, across many types of private resources.
That is the problem Pangolin is built to solve.
## Pangolin: Zero Trust Private Access for the Entire Enterprise
Pangolin is designed for organizations that want to replace broad-trust VPNs with a modern Zero Trust model without creating separate access silos for different teams.
Rather than starting with a narrow list of protocols, Pangolin starts with the enterprise reality: people across the business need secure access to private resources from anywhere, on any network, without exposing more access than necessary.
Pangolin provides this by combining secure network connectivity with identity-based access control, giving organizations a single platform for private access across browser-based applications, internal services, and private network resources.
The result is not just a tool for engineers. It is a platform for enterprise access.
### 1\. A Better Alternative to Legacy VPNs
Traditional VPNs are difficult to scale cleanly because they extend broad network trust where organizations actually need precise access control.
Pangolin takes a different approach. It provides secure private connectivity, but access is governed by identity and policy rather than implicit network trust. Users get access only to the resources they are allowed to use, not blanket access to the network.
For enterprises, this is a meaningful shift. It reduces the attack surface, improves segmentation, and delivers a more modern access experience without the operational baggage of legacy VPN architecture.
### 2\. One Platform for the Whole Workforce
Most access products are either too broad in trust or too narrow in audience. Pangolin is positioned in the middle, where enterprises increasingly need to operate. It supports the engineering team, but it is not limited to the engineering team.
That means one platform can support:
* Developers accessing infrastructure and internal tooling.
* Sales teams reaching internal systems securely from remote locations.
* Support teams using private dashboards and admin interfaces.
* Operations teams connecting to internal services and file resources.
* Third parties like contractors receiving tightly scoped access to only what they need.
This is a major commercial distinction. Pangolin is not just an infrastructure access product; it is a workforce access platform.
### 3\. A Network-First Architecture That Scales with Real Environments
Enterprise environments are messy. They contain internal applications, bespoke services, legacy platforms, non-standard ports, file systems, admin consoles, and business-critical tools that do not fit neatly into a few protocol categories.
Pangolin is built for that reality. Instead of requiring connectivity and access to be configured machine by machine, Pangolin is designed around site-level connectivity. You deploy connectivity once at the site or network level, then make resources within that private environment available through policy. That reduces deployment overhead, simplifies expansion, and makes it easier to bring large or mixed environments under one access model.
A network-first Zero Trust Access Platform is better aligned to how enterprises actually operate. With Pangolin, the question is not whether a resource belongs to the right technical bucket, but whether the user should have access. That creates a more consistent policy model across the business and avoids the fragmentation that often appears when different teams rely on different access tools for different classes of resource.
### 4\. A Simpler User Experience with Stronger Control
Enterprise security tools fail when they create too much friction for end-users or too much complexity for administrators. Pangolin is designed to reduce both.
Users get a simpler experience: they authenticate once and access the resources they have been granted. Administrators get a clearer operating model centered on users, resources, sites, and policy. Security teams get stronger control without having to rely on outdated network-level trust assumptions.
This balance matters in enterprise adoption. The best access platform is not only secure it is the one the business can realistically deploy, scale, and manage.
## Where Teleport Remains Strong
Teleport still has a clear advantage in one area: deep infrastructure session governance.
If the main requirement is detailed auditing of administrative access to supported protocols, Teleport is a strong option. Organizations with highly specialized compliance requirements or a narrow focus on engineering access control may prefer that model.
That is an important distinction, and it should be acknowledged clearly. But for many enterprises, that is not the primary buying decision.
The larger challenge is replacing fragmented remote access with one secure, scalable, Zero Trust platform that works across the business. That is where Pangolin has the stronger story.
## Why This Matters for Enterprise Buyers
Enterprise leaders are not just selecting a product; they are choosing an operating model for private access.
Do you want a platform primarily optimized for controlling technical sessions for infrastructure teams?
Or do you want a platform that can become the secure access foundation for the broader enterprise?
That is the real choice.
## Final Recommendation
Choose Pangolin if your organization wants to move beyond VPNs and standardize on a modern Zero Trust Access Platform for the enterprise. It is the stronger fit when you need one platform that can securely serve engineering, IT, operations, support, sales, and other teams without forcing access into separate silos.
Choose Teleport if your main requirement is protocol-specific governance for engineering infrastructure and deep session auditing for administrative workflows.
In simple terms:
* Teleport is built to control infrastructure sessions.
* Pangolin is built to secure enterprise access.
## Related comparisons
* [Pangolin vs. WireGuard](/news/pangolin-vs-wireguard)
* [Modernizing Enterprise SSH Access](/news/modernizing-enterprise-ssh-access)
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
---
### How Pangolin Works
URL: https://pangolin.net/news/how-pangolin-works
Published: 2026-03-08
Summary: Learn how Pangolin connects sites, resources, identity, and policy to provide zero trust remote access without opening ports.
Category: Product
Pangolin is a zero-trust remote access platform that provides secure, identity-centric access to applications and infrastructure without opening firewall ports or deploying traditional VPNs. Let's walk through how the system works: the control plane, how you connect networks and define resources, and how policy is enforced for users and devices. The result is a single platform for both web application access and private (VPN-style) access, with centralized policy and full auditability.
Pangolin delivers **zero-trust network access (ZTNA)** for workforce and machine identity: users and systems only reach the applications and hosts you explicitly allow, based on identity, role, and context. Public resources provide secure web access (clientless access) to internal applications via identity-aware reverse proxy. Private resources provide least-privilege access to specific hosts and network segments through an optional client. A unified policy model and integration with your identity provider (IdP) lets you manage access once and enforce it everywhere.
Let’s walk through the architecture and key concepts from the ground up:
## Architecture overview
Pangolin separates **control plane** and **data plane**. The Pangolin server is the control plane: it handles authentication, stores access policies, and coordinates authorization. It does not sit in the path of user or machine traffic. The data plane is made up of **sites** (connectors in your networks) and **clients** (on user devices or machines). Sites run a WireGuard peer; clients authenticate and then connect directly “peer-to-peer” to the appropriate sites to reach authorized resources. This gives you centralized policy and governance without a single choke point for traffic.
Access is **deny-by-default**. Deploying a site does not expose any resources. Defining a resource does not grant access until you assign users or roles. Zero-trust is enforced by explicit policy: you define what exists, who can access it, and under what conditions. Logs and audit trails support compliance and incident response.
Lets walk through how to setup the system:
## Core workflow
### Step 1: Connect Infrastructure with Sites
Sites extend Pangolin’s secure access to your networks: edge locations, office LANs, cloud VPCs, data centers, etc. A **site** is a logical representation of a network segment connected via the **Newt** connector: a lightweight software component you install (binary or container) on a host that already has network access. Newt creates secure, outbound-only tunnels to the Pangolin control plane. No public IP addresses or inbound firewall rules are required; infrastructure remains behind the perimeter.
Sites run inside your perimeter. They maintain outbound connectivity to the server and, by default, do not allow any traffic until you define resources and assign access in policy. Adding a site does not expose the network; it registers the segment so you can later define resources and enforce who may access them. They also run a WireGuard peer sitting and waiting for clients to establish peer-to-peer connections.
Each site is provisioned with credentials (endpoint, ID, secret) and supported deployment options: Unix, Windows, Docker, Kubernetes, and many others. Credentials can be rotated without re-deploying the connector.
Organizations typically deploy multiple sites for redundancy (one or two per network). Each site is a policy enforcement point for the resources attached to it. Users and machines never think about connecting “to a site” directly; they think about connecting to authorized **resources** that the site can see on the network. Sites provide the underlying connectivity; resources and policy define what can be accessed.
### Step 2: Define Resources and Policy
**Resources** are the applications, hosts, or network segments you expose for secure access. They are bound to sites and have no access until you define policy: which roles and users (or machine identities) may reach them. This application, and resource, level model supports least-privilege access and reduces the attack surface compared to network-wide VPN access.
Pangolin supports two resource types: **public** (browser-based, reverse proxy) and **private** (client-based, ZTNA-style access to specific hosts or CIDRs). Both share the same identity and policy framework.
### Public Resources: Secure Application Access
Public resources provide secure web access to internal and third-party applications. They function as identity-aware reverse proxies: users access a URL in the browser, authenticate (via SSO, MFA, or password), and are routed to the backend based on policy. No client is required on the user device. Pangolin handles TLS termination, routing, and policy enforcement at the control plane level before forwarding down a tunnel to a site.
You configure backend targets (addresses and ports), path-based routing, optional path rewriting, and health checks. Traffic is sent only to healthy targets. Applications remain behind the firewall; only the site’s outbound tunnel is used.
Health status is visible per resource and per target, so operations teams can monitor availability and troubleshoot before user impact.
Policy for public resources can require authentication, enforce MFA, and apply rules based on user, role, group, geography, IP, or path. This supports secure access to internal tools, admin consoles, and SaaS-style applications with a consistent policy model.
### Private Resources: Least-Privilege Infrastructure Access
Private resources provide access to specific hosts or network ranges, like databases, SSH servers, internal APIs, or subnets, for users or machines that have the Pangolin client. Access is scoped to the resources you grant. There is no broad network access. This is zero-trust network access (ZTNA): only explicitly authorized resources are reachable.
For each private resource you define the destination (hostname, IP, or CIDR), optional internal DNS alias, and port policy (TCP, UDP, ICMP). Port-level restrictions limit exposure compared to full-network VPN access.
Access is granted per resource by roles and users (and optionally machine clients). Administrative roles retain access; all other access is explicitly assigned in policy.
In summary: **public resources** provide clientless, browser-based access with identity-aware policy; **private resources** provide client-based, least-privilege access to specific infrastructure. Both use the same identity store and policy engine.
### Step 3: Identity, Roles, and Device Trust
Access is granted only after authentication and authorization. The Pangolin server enforces policy and typically integrates with your existing identity provider (IdP) so that workforce identity, SSO, and MFA are consistent across applications and infrastructure.
### Federated Identity and Login
Users authenticate via the Pangolin login page or the client. Organizations can use a single **identity provider,** like Microsoft Entra ID, Google Workspace, Okta, or another OIDC/SAML-compatible IdP, for SSO and MFA. It consumes identity from the IdP and applies the roles and resource entitlements you configure. Pangolin can also manage its own set of internal users if you are not working with an IdP.
### Users and Role-Based Access Control
**Users** and **roles** are managed in the admin console. Users are linked to an identity (e.g. email) and an IdP. You assign one or more roles per user. Roles define entitlements: which resources (public and private) can be accessed, plus SSH and other capability settings. This role-based access control (RBAC) keeps policy manageable at scale and supports compliance and audit requirements.
Roles can include SSH-specific policy: whether SSH is allowed, sudo level (none, full, or restricted commands), Unix groups, and home directory provisioning for use with Pangolin's ssh daemon which can run on the site or as a remote auth daemon on the same network the site can access. This gives a single place to define infrastructure access behavior for each role. See [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin) for how SSH access works in practice.
### Endpoints and Device Trust
For **private** resource access, users (or automated systems) use the Pangolin **client** on supported endpoints (Mac, Windows, Linux, iOS, Android). The client authenticates, receives the set of authorized resources, and establishes encrypted tunnels **directly** to the appropriate sites. No per-application configuration is required; the client fully handles routing and tunnel management.
## Related reading
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [How ZTNA Works](/news/how-ztna-works)
* [What Are Pangolin Remote Nodes?](/news/pangolin-remote-nodes-guide)
* [Pangolin vs. Tailscale](/news/pangolin-v-tailscale)
**Device approval** can be required so that new devices cannot access resources until an administrator approves them. This extends zero-trust to the endpoint: valid credentials alone are not sufficient without device trust.
Pending requests appear in a dedicated approvals queue so administrators can review device details and grant or deny access in one place.
Devices can be **blocked** (e.g. lost, stolen, or compromised) so that access is revoked immediately. The device record is retained for audit and compliance.
## Key Concepts Summary
So to recap we have the:
* **Pangolin Server (control plane)**: Central policy, authentication, and coordination. Available as Pangolin Cloud (managed) or self-hosted. Does not sit in the data path; enforces who may access what.
* **Sites**: Network segments connected via the Newt connector. No public IPs or open inbound ports. Sites enable resource definitions and policy enforcement at the edge.
* **Resources** : Applications and infrastructure exposed for access. Public = identity-aware reverse proxy (browser). Private = ZTNA-style access to specific hosts/CIDRs (client). Both are deny-by-default and policy-driven.
* **Clients**: Endpoint software for users and machines. Single sign-on; access to all resources permitted by role. Handles routing and tunnels without application changes.
## How Pangolin Differs from Traditional VPN and Proxy
* **Vs. reverse proxy**: Pangolin’s public resources provide identity- and context-aware reverse proxy capabilities without requiring public IPs or open ports; sites use outbound tunnels only so you can route to networks anywhere.
* **Vs. VPN**: Private resources provide access to specific applications and segments, not entire networks. Least-privilege and role-based access reduce over-permission and support zero-trust and compliance objectives.
* **Vs. mesh VPN:** Sites are intelligent proxies that can route anywhere on the network and are not required to be run on every host. Sites don't communicate with each other and traffic is unidirectional between clients and sites. This makes access controls easy by distilling access down to which users and roles (clients) can access downstream resources on sites. A site does not need to
* **Unified platform**: One policy model for web and infrastructure access. Single integration with your IdP; consistent RBAC and auditability across use cases. No separate reverse proxy and VPN products to operate and reconcile.
## Enterprise Use Cases and Benefits
* **Secure hybrid workforce access:** Provide identity-centric access to internal applications and infrastructure from any location, with SSO/MFA and device trust, without exposing the corporate network or maintaining VPN concentrators.
* **Application and infrastructure access without perimeter exposure**: Replace bastion hosts and jump boxes with role-based access to [SSH](/news/how-to-ssh-with-pangolin), databases, and internal services. No inbound SSH or database ports; policy is enforced at the application and resource level.
* **Unified access policy and auditability:** Define users, roles, and resource entitlements in one place. Full visibility into who and which devices accessed what, supporting compliance, incident response, and access reviews.
* **Reduced attack surface**: No public IPs or open inbound ports for access. Sites and clients use outbound connectivity and NAT traversal. Firewall posture can remain restrictive while enabling secure access.
* **Identity-centric access**: Integrate with enterprise IdPs for SSO and MFA. Govern access by user and role rather than IP; align with existing identity and access management (IAM) processes.
For organizations that need both secure web application access and least-privilege infrastructure access under a single policy model - with full auditability and no open ports - Pangolin is designed for that requirement.
## Get Started
You can use [Pangolin Cloud](https://app.pangolin.net) for a managed control plane, or self-host the server for full control over data and infrastructure. The same architecture and concepts apply: connect sites, define resources, assign users and roles, and enforce secure access across your environment.
---
### Comparison - Pangolin vs. Zscaler
URL: https://pangolin.net/news/pangolin-v-zscaler
Published: 2026-03-03
Summary: How a self-hostable open-source access platform and an enterprise cloud security suite differ in architecture, traffic routing, deployment, and fit.
Category: Product
Pangolin and Zscaler Private Access (ZPA) both provide zero-trust, identity-based access to private resources. They share the same core idea: users get access to specific applications, not a whole network. Under the hood, however, they differ significantly in architecture, traffic routing, deployment model, scope, and who they are built for. 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](/news/how-to-ssh-with-pangolin) use the Pangolin client. Both paths share the same identity and permissions.
## What is Zscaler Private Access?
Zscaler Private Access (ZPA) is a cloud-native, enterprise-grade zero-trust access control solution. It is designed for large organizations that need to provide access to private resources - whether on-premises or hosted in the cloud - to all users regardless of location. It is one part of the broader Zscaler platform; a separate subscription, Zscaler Internet Access (ZIA), handles internet and SaaS traffic.
You deploy App Connectors on your private resources. Each App Connector establishes an outbound proxy connection to the nearest Zscaler data center. Users install the Zscaler client, which also connects outbound to the nearest Zscaler data center. Zscaler's Private Service Edges - running across a global network of more than 150 data centers - link the two connections together. All user traffic passes through Zscaler's cloud infrastructure; there are no direct connections between users and resources.
Zscaler's control plane is cloud-hosted and multi-tenant. There is no self-hosted option. Pricing is opaque and requires consultation with Zscaler or a reseller. The platform is aimed at large enterprises with dedicated security teams that need comprehensive policy enforcement, compliance monitoring, and DLP at scale.
## How the two compare
The table below summarizes the main differences. The sections after it walk through each area in order.
| Feature | Pangolin | Zscaler |
| --- | --- | --- |
| **Architecture** | ✓ Hub-and-spoke; control plane + sites; clients connect directly to sites via WireGuard | Proxy-based; all traffic routed through Zscaler's global cloud data centers |
| **Access model** | ✓ Resources (web apps, hosts, ports); FQDN or IP; role-based access control | Resources (apps/hosts); policies based on identity, device, and group |
| **Self-hosting** | ✓ Self-hostable or cloud; full control over data and infrastructure | Cloud-only; all traffic passes through Zscaler's infrastructure |
| **Open source** | ✓ Server and clients fully open source (AGPLv3 or Commercial License) | Closed source; proprietary |
| **SSO / IdP** | ✓ Built-in SSO with OIDC; connects to any OIDC-compatible IdP | Integrates with enterprise identity providers |
| **Web app exposure** | ✓ Clientless browser access; identity-aware reverse proxy; custom domains; automatic SSL | Zscaler Browser portal can be used to access clientless |
| **Pricing** | ✓ Transparent; self-hostable for free; clear cloud plan pricing | Opaque; requires consultation with Zscaler or a reseller |
| **Target** | ✓ Teams of any size; self-hosters to enterprises | Large enterprises with dedicated security teams |
| **Scope** | ✓ Unified platform: VPN + reverse proxy + identity in one product | ZPA for private access; ZIA is a separate subscription for internet/SaaS traffic |
| **Device security** | ✓ Device posture checks; device approvals; device fingerprinting | Device posture checks; identity and device-based access policies |
| **Transport** | ✓ WireGuard; NAT traversal via P2P or relay; no open ports | TLS-based proxy tunnels through Zscaler cloud; no open ports |
## Detailed comparison
### Architecture
In both systems you deploy a connector on a network, define resources behind it, grant users access to those resources, and require no open inbound ports. The similarities end there.
Pangolin uses direct connections. When a client accesses a resource, the Pangolin server facilitates discovery and NAT traversal, then the client and site establish a WireGuard tunnel directly - peer-to-peer when possible, through a relay only when NAT prevents a direct link. Data travels on the shortest path.
Zscaler uses a proxied architecture. The App Connector on your resource connects outbound to the nearest Zscaler data center. The Zscaler client on the user's device connects outbound to the nearest Zscaler data center. Zscaler's Private Service Edge in that data center links the two connections together. Every byte of traffic passes through Zscaler's cloud infrastructure. Latency depends on how close users and resources are to their respective nearest data center. There are no direct connections between user devices and resources.
### Traffic routing and performance
Because Pangolin establishes direct WireGuard connections between the client and the site, traffic takes the most efficient path between user and resource. Relay is only used as a fallback when NAT traversal cannot establish a direct link. This keeps latency low and avoids routing traffic through third-party infrastructure.
Zscaler routes all traffic through its network of 150+ Private Service Edges globally. This centralized routing means performance is dependent on cloud routing efficiency and the distance to the nearest Zscaler data center. Users and resources that are far from Zscaler edges may experience higher latency.
### 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 automatically. 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.
Zscaler Private Access does have a browser access feature - ZPA Browser Access - that provides clientless access to private web apps through a Zscaler-hosted user portal. It is aimed at BYOD and third-party users on unmanaged devices. However, there are meaningful differences in how the two approaches work. Zscaler's browser access is portal-based: users log in to a Zscaler-managed user portal that lists their authorized apps. Pangolin gives each resource its own URL with a custom domain you control - `tools.yourcompany.com`, `grafana.yourcompany.com` - and a single shared portal. Private app FQDNs are obscured from users in Zscaler's model by design, which limits direct linking and bookmarking. Pangolin's resources are first-class URLs.
### Deployment and data sovereignty
Pangolin can run fully on your own infrastructure. You can self-host the server, control plane, and all relay nodes. Alternatively, you can use Pangolin Cloud and optionally add your own relay nodes so traffic stays on your infrastructure while using the cloud control plane. Traffic between clients and sites travels directly between them; it does not pass through Pangolin's servers once the tunnel is established unless it needs to be routed through a relay node when it is still end-to-end encrypted.
With Zscaler Private Access, all traffic is routed through Zscaler's global cloud data centers. There is no self-hosted option for the control plane or for the traffic path. All user and resource traffic passes through Zscaler infrastructure by design - that is how Zscaler applies security inspection. If your organization's policy or regulations require that traffic stay on your own infrastructure, or if you simply prefer not to send all traffic through a third-party cloud, Pangolin's architecture supports that; Zscaler's does not.
### Scope and product model
Pangolin is a unified platform. Private resource access (VPN-style, via the client) and public web app exposure (reverse proxy, browser-based) are part of the same product, managed with the same identity and permissions, deployed as one system.
Zscaler is a broader security suite split into separate products. Zscaler Private Access handles access to private resources (on-premises or cloud-hosted). Zscaler Internet Access is a separate subscription that manages internet and SaaS traffic - threat protection, secure web gateway, CASB, and DLP for outbound internet traffic. If you need both, you subscribe to both. Zscaler's suite is comprehensive, but it means more products, more complexity, and more cost.
### Setup and operational complexity
Pangolin is designed to be lightweight to deploy. You have the server (self-hosted or cloud), deploy a site connector on a network, define resources, and set up users. The setup is approachable for small teams and individual operators and just enterprise IT departments alike.
Zscaler requires substantial configuration before deployment: administrators must define access control policies, security rules, compliance settings, and integrate with identity providers. The platform is designed for large enterprises with dedicated security teams. Smaller teams or those without full-time security personnel will likely find the operational overhead significant.
### Pricing and transparency
Pangolin is open source and self-hostable at no cost in addition to the Enterprise Edition which has published pricing. Pangolin Cloud has clear, published pricing. You know what you are paying before you commit.
Zscaler's pricing is opaque. There is no published price list; you must contact Zscaler or a reseller for a quote. Enterprise agreements are custom, and the total cost depends on features, seat counts, and which products (ZPA, ZIA, and others) you need. For teams that want predictable, transparent costs, Pangolin's model is straightforward; Zscaler's is not.
### 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.
Zscaler is proprietary. The platform is entirely closed source. You cannot self-host any component or inspect the code. If transparency, auditability, or the freedom to run and modify the system matter to you, Pangolin's licensing and architecture support that.
### Device security
Both platforms support device posture checks: they collect information about security-relevant settings on the device - disk encryption, firewall status, antivirus, OS version - and allow you to enforce access policies based on posture.
Pangolin adds a device approvals feature. When enabled, all new devices are denied by default. Admins see a queue of pending devices and must explicitly approve each one before it can connect. That gives you explicit control over the device inventory, not just the user account.
### Tenancy
Pangolin supports multiple organizations under one account, with the ability to share or assign users and resources across them. That makes it well suited for MSPs or teams managing multiple environments from one place.
Zscaler is single-tenant by signup. Each organization gets its own tenant; managing multiple separate organizations is not a native capability in the same way.
### Best fit
**Choose Pangolin if** you want a zero-trust, resource-centric access platform that is lightweight to deploy, transparent in pricing, and open source. Pangolin is self-hostable if you need full control over your infrastructure and traffic, and it includes both client-based private access and clientless browser access for web apps in one unified system. It fits teams of any size - from a self-hosted home lab to a multi-site enterprise.
**Choose Zscaler if** you are a large enterprise with a dedicated security team that requires a comprehensive cloud security suite with advanced threat protection, DLP, and a secure web gateway at global scale. Zscaler fits organizations with strict compliance and monitoring requirements that can manage complex configuration and enterprise pricing, and that are comfortable routing all traffic through Zscaler's cloud infrastructure.
## Related comparisons
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [Pangolin vs. Cloudflare One](/news/pangolin-v-cloudflare)
* [Pangolin vs. Twingate](/news/pangolin-v-twingate)
* [How ZTNA Works](/news/how-ztna-works)
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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](/contact).
---
### Pangolin 1.16 - Certificate Based SSH
URL: https://pangolin.net/news/1-16-0-release
Published: 2026-02-27
Summary: Pangolin 1.16 adds certificate-based SSH, short-lived credentials, and just-in-time user provisioning for private infrastructure.
Category: Product
If you've ever managed SSH access for a team, you know the drill: generate keys, copy them to servers, remember which key goes where, revoke access when someone leaves, and pray nobody puts their private key in a public GitHub repo. It's tedious, error-prone, and doesn't scale.
We built Pangolin to make private access simple and secure - whether you're accessing a web app through your browser or connecting directly to private resources. Today, we're taking that mission to the terminal.
Pangolin 1.16.0 introduces native SSH support with certificate-based authentication and PAM integration. No more managing SSH keys. No more `ssh-copy-id`. Just use your Pangolin identity to connect to any server, and let Pangolin handle the rest.
## Release highlights
### SSH the way it should be
Here's what SSH access looks like with the Pangolin CLI and any resource alias:
```shell
$ pangolin ssh vm-01.prod.example.com
Welcome to Ubuntu 24.04.2 LTS (GNU/Linux 6.14.0-1010-aws aarch64)
System information as of Sat Feb 28 01:41:10 UTC 2026
System load: 0.0 Temperature: -273.1 C
Usage of /: 23.9% of 29.95GB Processes: 155
Memory usage: 48% Users logged in: 0
Swap usage: 0% IPv4 address for ens5: 10.30.0.212
Last login: Mon Feb 23 19:36:15 2026 from 10.30.2.199
p-owen@vm-01.prod.example.com:~$
```
Behind the scenes, Pangolin:
1. Generates a temporary key pair on your machine
2. Sends the public key to Pangolin's server along with your identity
3. Verifies you have access to that resource
4. Signs your public key with your organization's certificate authority
5. Establishes the SSH connection using the short-lived certificate
The certificate is valid for just 5 minutes - long enough to establish a connection, short enough to limit blast radius if something goes wrong. Once you're connected, your session can stay open as long as you need it.
You need to be connected to the Pangolin network to make the SSH connection.
### Identity-based access control
SSH access in Pangolin follows the same zero-trust principles as everything else in the platform. You create a private resource for each server you want to SSH into, grant access to specific users or roles, and ensure TCP port 22 is allowed in the resource's port restrictions.
No access granted on the resource? No SSH session. It's that simple.
This means your SSH access policies live in the same place as your web app and private network policies. One dashboard, one source of truth, one audit log.
### Just-in-time user provisioning
Here's where it gets interesting. When you SSH into a server through Pangolin, we don't just authenticate you - we provision your user account on the fly.
Pangolin derives your username from your identity (the part before the `@`), creates a home directory, and sets up the account with the right permissions before your SSH session even starts. If the username is already taken in your organization, we add a numeric suffix to keep it unique.
This happens automatically through PAM (Privileged Access Management), the same authentication framework your Linux server already uses. No manual account creation and you dont need to pre-provisioning users across dozens of servers. User settings can be configured on a per-role basis:
### Built into Newt, your site connector
The magic happens in Newt, Pangolin's site connector that already handles your private network connectivity. When you run Newt with the `--auth-daemon` flag, it becomes an SSH authentication daemon for the host it runs on:
```shell
$ sudo newt --id --secret --endpoint --auth-daemon
```
Then configure your SSH server to trust Pangolin's certificate authority and use Newt to resolve principals. Add these lines to `/etc/ssh/sshd_config`:
```ocaml
TrustedUserCAKeys /etc/ssh/ca.pem
AuthorizedPrincipalsCommand /usr/local/bin/newt auth-daemon principals --username %u
AuthorizedPrincipalsCommandUser root
```
Restart SSH, and you're done. Your server now accepts certificate-based authentication from any Pangolin user with access to that resource. The OpenSSH server will check with Newt to see if the user is authorized, and if so, allow the connection.
### For more complex setups: external auth daemons
If you need to SSH into multiple servers that don't run Newt themselves, Pangolin supports an external auth daemon architecture. One host runs Newt as a bastion, and each target server runs Pangolin's auth daemon. Newt proxies SSH connections through to the target servers, and the auth daemon handles user provisioning and certificate validation.
This is perfect for environments where you have a jump host or bastion pattern. We won't dive into the details here, but if that's your setup, check out our [SSH documentation](https://docs.pangolin.net/manage/ssh) for the full configuration guide. For a current overview of browser and private CLI SSH, see [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin).
### Short-lived certificates, long-term security
Traditional SSH key management is a mess because keys are long-lived. Someone generates a key, copies it to a server, and it sits there forever - or until someone remembers to remove it. With Pangolin's certificate-based approach, keys are ephemeral by design.
Each certificate is valid for just 5 minutes from the moment it's issued. That's enough time to establish your connection, but not enough time for an attacker to do much with a compromised certificate. And because certificates are signed by your organization's CA, you can revoke access instantly by removing a user from the resource - no need to hunt down keys scattered across servers.
## Give it a try!
Pangolin 1.16.0 is live today. If you're tired of managing SSH keys and want terminal access that's as secure and simple as the rest of your Pangolin setup, this release is for you.
You can get started with a free account on [Pangolin Cloud](https://app.pangolin.net/), or self-host with the Open Source Community or Enterprise Editions.
**Also in this release:**
* Add list of accessible private resources to non-admin/member landing page
* Add server side pagination, filter, sort, and search to major tables
* Add support pathname in logo URL for branding
* Add delete account from profile
* Add improved user prompt dialogs to installer script
* Other minor bug fixes and visual enhancements
---
### How Pangolin Punches Through NATs and Firewalls
URL: https://pangolin.net/news/nat-holepunching
Published: 2026-02-26
Summary: A deep dive into how Pangolin establishes direct peer-to-peer connections through NAT devices and firewalls without opening ports.
Category: Engineering
## How Pangolin Navigates NATs and Firewalls
Pangolin is designed to forge encrypted links between your hardware and distant networks without the headache of manual port forwarding or wrestling with complicated router settings. This deep dive explores the mechanics of establishing direct peer-to-peer communication across Network Address Translators (NATs) and stateful security barriers. We will break down the challenge from the ground up, illustrating how Pangolin connects a mobile device to a remote site regardless of the digital hurdles in between. Whether your traffic originates from a public Wi-Fi hotspot, a restrictive corporate office, or a standard home router, our system coordinates multiple techniques to find the most efficient data path.
## NAT traversal fundamentals
### The Core Essentials: UDP and Socket Management
Before we can bypass NAT constraints, two architectural prerequisites must be met. First, the communication must rely on `UDP` rather than `TCP`. While traversing `TCP` is technically possible, it is notoriously cumbersome and often requires invasive kernel-level adjustments. Because Pangolin is built on `WireGuard` — which is natively `UDP`-based — it is perfectly primed for this kind of traversal.
Second, the application must maintain absolute authority over the network `socket`. Successful NAT traversal involves managing auxiliary packets alongside the primary protocol traffic. You cannot achieve this by simply using a high-level, "black box" library. The traversal logic and the main data stream have to operate on the exact same `socket`, as NAT devices assign unique mappings to every individual `socket`. Once these foundations are set, we can tackle the primary obstacles: firewalls and NATs.
### Navigating Stateful Firewalls
Stateful firewalls represent the first, more manageable hurdle. Since nearly every NAT device includes a stateful firewall, mastering this is a prerequisite for broader connectivity. You likely interact with these daily via Windows Defender, Linux `iptables`, or cloud-based security groups. While they are highly flexible, most follow a simple "default-deny" logic: outbound traffic is fine, but unsolicited inbound traffic is blocked.
However, "inbound" and "outbound" are just conceptual labels; on the wire, there are only individual packets. How does the firewall decide what to let in?
The secret is the "state". The firewall keeps a log of outgoing packets and uses that history to vet incoming ones. For `UDP`, the rule is simple: the firewall allows an incoming packet only if it matches a destination that the internal device recently messaged. If your laptop pings a remote server, the firewall makes a mental note to let that specific server ping you back. Because the trusted internal device started the conversation, the firewall assumes the response is safe.
### The Deadlock of Facing Firewalls
This logic works great for simple client-server models, but it creates a "who goes first?" dilemma when two firewalled clients try to talk directly. Both sides are waiting for the other to initiate, but neither can receive the initial "hello" because their respective firewalls block it. While opening ports manually is an option, it is a nightmare to manage at scale and impossible on networks you don't control, like at an airport. We need a more elegant workaround.
### Piercing the Veil Without Manual Setup
The key is that an outbound packet must clear the path before an inbound one can enter. Crucially, the firewall doesn't care if the original outgoing packet actually reached its destination; it only cares that the attempt was made. To exploit this, both peers must first know each other's `ip:port`. Pangolin uses a central coordination server to swap this metadata securely.
Once the peers have each other’s addresses, they start firing `UDP` packets at one another. Many of these initial packets will vanish into the void, which is a normal part of the process. Consider a laptop and a server:
* The laptop sends a packet to the server. It clears the laptop's firewall but is killed by the server's corporate firewall.
* Crucially, the laptop's firewall is now "open" for a response from the server.
* Simultaneously, the server sends a packet to the laptop.
* Because the laptop’s firewall already saw an outbound attempt to the server, it identifies this incoming packet as a valid "response" and lets it through.
* Now the server’s firewall also opens up, recognizing the laptop as a legitimate contact.
By sending a follow-up packet, the laptop completes the bridge. We have now forced a two-way street through two defensive walls that were designed to stay closed.
### Vital Considerations for Success
This process requires precision. What are the traps?
* **Timing is everything:** Both sides need to try connecting at roughly the same time so the firewall windows overlap. Rather than guessing, Pangolin uses a coordination "side channel" to sync the start time using the `websocket` connection to the Pangolin server.
* **The Gerbil Role:** The coordination and relay (`Gerbil`) handles this discovery and provides a safety net if direct paths fail.
* **Staying Alive:** Firewalls have short memories (often just 30 seconds for `UDP`). We have to send "heartbeat" packets regularly to keep the connection active.
* **Layering:** The best part is that this works regardless of how many firewall layers are stacked in between, as long as they all allow outbound traffic.
## The NAT Complication
NAT devices add a layer of translation to the firewall logic. Because your home network uses private IP space (like `192.168.1.0/24`) that cannot be routed on the open internet, your router must act as a translator.
When your laptop (`192.168.1.50:1234`) sends data to a server at `77.88.99.100:5678`, your router intercepts it. It picks a random available port on its own public interface—for example, `11.22.33.44:4242`. It then creates a mapping: internal `192.168.1.50:1234` is now represented globally as `11.22.33.44:4242`.
The remote server only ever sees the public address (`11.22.33.44:4242`) and sends its replies there. The router then transparently swaps the addresses back so your laptop receives the data without ever knowing its "identity" was changed.
However, some "difficult" corporate NATs change this mapping for every new destination. If you send data to one peer at `55.66.77.88:1234` and another at `77.88.99.100:2345`, a restrictive NAT might assign you two completely different public ports on `11.22.33.44`, breaking the simple discovery model.
## Finding Your Public Identity
The problem is that neither peer knows where to aim their packets because their public `ip:port` doesn't technically exist until they start talking. To solve this, Pangolin asks our `Gerbil` relay servers: "How do I look to you?". The server tells the client its observed public `ip:port`, and the client then shares that info with its peers using the central Pangolin server. This is why using the same `socket` for the protocol and the discovery is mandatory; a new `socket` would result in a totally different NAT mapping.
## When Simple Discovery Stalls
While this works for most home users, it often fails on "high-security" corporate NATs. Some "easy" NATs use the same public mapping for every destination. However, "difficult" NATs create a unique mapping for every single destination you contact. If the port you use to talk to the `Gerbil` server is different from the port you use to talk to your peer, the connection will fail.
## Relay and fallback behavior
### The Safety Net: Gerbil Relay Servers
When all the NAT-piercing tricks in the book fail, Pangolin doesn't give up. We utilize a relay system where both sides connect to a middleman that passes packets between them. While this adds a slight bit of latency, if the relay is well-positioned, the impact is minimal. It is infinitely better than having no connection at all.
Some environments are so restrictive they block everything but `DNS` traffic. In these cases, no amount of cleverness can force a direct path. `Gerbil` acts as a multi-tool: it handles the initial handshake, helps with endpoint discovery, and steps in as a high-performance relay whenever a direct peer-to-peer path is blocked.
### How the Relay Works
The relay server hosts a simple `UDP` socket for the clients on default port `21820`. Any client can send `WireGuard` packets to this port and the `Gerbil` server identifies them as `WG` packets using their headers. If its a relay `WireGuard` connection it checks with all of the sites connected using their direct backhaul `WireGuard` tunnels. If the destination site is already connected and ready to accept traffic from the client, it sends it right down that same tunnel we use for proxy connections. When a client connects to the relay, it establishes a secure `WireGuard` tunnel end to end. The relay then forwards packets between the two clients as needed. This allows us to maintain end-to-end encryption and authentication, even when the traffic is passing through an intermediary.
While some services use the `WebRTC` standard `STUN` and `TURN` protocols for NAT traversal and relaying, we built our own custom solution to have more control over the process and to optimize for our specific use case. The relay server is designed to be lightweight and efficient, minimizing latency while maximizing reliability.
### From the Site's Perspective
When a site connects to the `Gerbil` relay, it establishes a secure `WireGuard` tunnel end to end — directly to the relay server. This tunnel is used for the public pangolin application resources that use proxy connections from the Pangolin server. Its the secure transport to get from the proxy to the site. The nice thing is we can also use this same tunnel to forward packets for clients that are connecting through the relay. This means that even if a client is connecting through the relay, the traffic is still encrypted end-to-end between the client and the site, with the relay simply acting as a pass-through.
### How Pangolin Discovers the Best Path
To connect, we first compile a list of "candidate" endpoints - every possible way to reach a site.
We swap these lists via the `websocket` backend side channel and then blast probe packets at every single candidate on the list. These "pings" serve two roles: they punch through the NAT/firewall and they measure the quality of the path.
We don't just guess which path is best; we observe which ones actually work and select the one with the lowest round-trip latency. This prioritizes direct `WAN` over relays. Because we start communicating through the relay immediately, the connection feels instant, even while we are quietly upgrading you to a faster direct path in the background.
### Same Network Detection
Sometimes the client and the site are already on the same local network. Pangolin detects this during candidate discovery by probing local `ip:port` addresses alongside public ones.
When both peers are on the same LAN, they form a direct peer-to-peer connection over the local network. Packets stay inside the network and are never routed out to the internet. In this case the connection does not use the `Gerbil` relay at all; traffic goes straight from client to site on the LAN.
This is the fastest path available. Local round-trip times are typically a fraction of a WAN or relay path, and the connection avoids unnecessary egress through your router or ISP.
## Maintenance and Security
Connections are living things. Pangolin continuously sends probes to keep NAT mappings from expiring and to ensure the path is still healthy. If a direct path suddenly dies, we immediately drop back to the `Gerbil` relay and start searching for a new direct route.
Security is baked into the protocol itself. Because we use `WireGuard`'s public key crypto, it doesn't matter which IP path we use; the data is always encrypted and authenticated end-to-end. Even our discovery packets are encrypted to prevent any potential tampering.
## Summary of the Process
1. **Identify** all local and public `ip:port` candidates.
2. **Coordinate** with peers via the `Gerbil` side channel to swap keys and addresses.
3. **Initiate** immediate connectivity through the `Gerbil` relay (skipped when peers are already on the same LAN).
4. **Probe** all direct paths to pierce firewalls and NATs, including same-network local candidates.
5. **Upgrade** to the fastest discovered direct path transparently, preferring local LAN when available.
6. **Monitor** and fail back to relays if the network environment changes.
The result is a connection that is as robust as it is fast, working in nearly every network configuration on the planet.
**Would you like me to help you set up a self-hosted `Gerbil` server or walk through the `WireGuard` configuration for your specific site?**
## Learn more
Want to see Pangolin's NAT traversal in action? [Get started](https://app.pangolin.net/) with a free account or [self-host](https://docs.pangolin.net/self-host/quick-install) the open-source server.
For questions about how Pangolin handles your specific network environment, [reach out](/contact) to our team.
---
### Comparison - Pangolin vs. Cloudflare One
URL: https://pangolin.net/news/pangolin-v-cloudflare
Published: 2026-02-23
Summary: How an open-source, self-hostable remote access platform compares to Cloudflare One (ZTNA, WARP, Access, and Tunnel).
Category: Product
Pangolin and Cloudflare One both provide identity-based access to internal applications without a traditional VPN. Cloudflare One is a cloud-only suite: Access for application access, WARP as the client, and Cloudflare Tunnel (cloudflared) for outbound ingress from your network. Pangolin is an open-source, self-hostable platform built on WireGuard with P2P connectivity that combines a tunneled reverse proxy for web apps with client-based access for [SSH](/news/how-to-ssh-with-pangolin), databases, and other TCP resources. This article outlines what each does and where they differ.
## 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.
Access policies and filtering are defined in the control plane and propagated to the edge—sites and clients—so rules are enforced everywhere: on relay paths, on peer-to-peer connections, and for clientless web access. 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 Cloudflare One?
Cloudflare One is Cloudflare’s zero trust platform. It includes **Cloudflare Access** (identity-based access to applications), **WARP** (the client on user devices), and **Cloudflare Tunnel** (cloudflared), which runs in your network and creates an outbound tunnel to Cloudflare’s edge so you can expose apps without opening ports.
For web applications, users open a URL, authenticate (e.g. via an identity provider or one-time PIN), and reach the app in the browser. No VPN client is required. Access validates each request. Traffic flows: user → Cloudflare edge → Tunnel (cloudflared) → your origin. The tunnel is outbound-only from your side, so no public IP or port forwarding is needed; it works from behind CGNAT or a home router.
For non-HTTP resources (SSH, RDP, databases, internal APIs), users run the WARP client (or the Access client for some flows). Traffic goes device → WARP → Cloudflare edge → Tunnel → your resource. So Cloudflare supports both web (clientless) and TCP application access, with one control plane and one identity model.
Cloudflare One is cloud-only: the control plane, edge, and routing all run on Cloudflare’s global network. You cannot self-host the Access or Gateway control plane. Cloudflared (the tunnel daemon) is open source; the rest of the stack is proprietary. Cloudflare One often bundles in **Gateway** (DNS and HTTP filtering, DLP) when traffic is routed through WARP, so it doubles as a secure web gateway (SWG) and ZTNA.
## How the two compare
The table below summarizes the main differences. The sections after it walk through each area in order.
| Feature | Pangolin | Cloudflare One |
| --- | --- | --- |
| **Architecture** | ✓ Control plane + sites; browser or client to resources | Access + WARP + Tunnel; traffic via Cloudflare edge |
| **Access model** | ✓ Resources; role-based; deny-by-default | Access policies; identity-based |
| **Self-hosting** | ✓ Full self-hosting or cloud; your infra optional | Cloud-only; no self-hosted control plane |
| **Open source** | ✓ Server and clients open source (AGPLv3 / Commercial) | cloudflared only; Access and WARP proprietary |
| **Web app exposure** | ✓ Clientless; tunneled reverse proxy; custom domains | Clientless; Tunnel; custom domains |
| **Non-HTTP access** | ✓ Pangolin client; hole punch or relay to site | WARP; traffic via Cloudflare edge to Tunnel |
| **SaaS web gateway** | ✓ Can proxy SaaS apps through sites | Gateway for general DNS/HTTP; Access for apps |
| **Device posture** | ✓ Enforced per resource before access | Enforced per resource before access |
## Detailed comparison
### Architecture
Both systems use an outbound tunnel from your network so you never open ports. In Cloudflare’s case, you run cloudflared (the Tunnel daemon) on a machine that can reach your apps. It connects out to Cloudflare; browser and WARP traffic hit Cloudflare’s edge and are sent through the tunnel to that machine and on to the origin. The control plane is Cloudflare’s; you configure Access policies and Tunnel routes in the dashboard or API.
Pangolin uses a site (connector) in each network. For web, the site opens an outbound tunnel to Pangolin; browser traffic flows via Pangolin (control plane or your relay) through that tunnel to the site and then to the app. For SSH, databases, and other TCP, the Pangolin client connects to the site—directly via NAT hole punching when possible, or via a relay when not. See [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin) for browser and private CLI setup. The control plane can be self-hosted or Pangolin Cloud; you can also self-host relay nodes so no traffic touches third-party infrastructure.
So: both support tunneled, clientless web access and client-based access to non-HTTP resources. The main architectural differences are where the control plane and data path run (yours vs. Cloudflare’s) and how the client reaches the resource (P2P or relay in Pangolin vs. always via Cloudflare in WARP).
### Web apps and clientless access
Pangolin and Cloudflare both expose internal web apps without a VPN client. Users open a URL, authenticate (e.g. SSO), and use the app in the browser. Every request can be validated against identity and policy. Both use an outbound tunnel from your network (Pangolin site vs. cloudflared), so no open ports or public IP are required; both work from behind CGNAT.
Pangolin lets you run the control plane and relays yourself, so all traffic can stay on your infrastructure. Cloudflare routes traffic through its global edge; you can use Regional Data Residency options where available to keep data in a chosen region, but you cannot self-host the Access or Tunnel control plane. Pangolin also supports custom domains and automatic SSL for web resources, plus per-resource options (pin codes, passcodes, email whitelists). Cloudflare offers custom hostnames and strong DNS/CDN integration.
### Client path: peer-to-peer vs. always via edge
For non-HTTP access (SSH, RDP, databases), the data path differs.
With **Pangolin**, the client tries to form a direct connection to the site using NAT hole punching. If that succeeds, traffic is peer-to-peer: client ↔ site ↔ resource, with no relay. If hole punching fails, traffic relays through a Pangolin server or your self-hosted relay. Either way, access policies and filtering are defined in the control plane and propagated to the edge—the client and the site both enforce the same rules, so policy is applied even when the data path is direct. The relay is a fallback for connectivity; you can eliminate third-party from the path entirely by self-hosting.
With **Cloudflare One**, the WARP client sends traffic to Cloudflare’s edge; from there it goes through the Tunnel (cloudflared) to your resource. There is no direct client-to-origin path; every connection passes through Cloudflare. That gives a consistent path and lets Gateway apply DNS/HTTP policy, but it adds latency and means all traffic crosses Cloudflare’s network.
If you want the option of direct client-to-connector connectivity and full self-hosting of the data path, Pangolin supports that. If you want one vendor for ZTNA and secure web gateway with traffic always on their edge, Cloudflare One fits.
### NAT traversal and tunneled ingress
Both Pangolin and Cloudflare use a tunnel-at-the-end-of-the-reverse-proxy model. Your network only needs outbound internet; the connector (Pangolin site or cloudflared) opens a tunnel, and browser traffic reaches your apps through it. No port forwarding, no public IP, and it works behind CGNAT.
Pangolin’s client path adds NAT hole punching so that client-to-site traffic can go direct when possible; Cloudflare’s client path is always device → WARP → Cloudflare edge → Tunnel → origin. So for web, the NAT story is similar (outbound tunnel); for the client, Pangolin can avoid a relay when the network allows it.
### Self-hosting and data sovereignty
Pangolin can run entirely on your infrastructure: self-host the server, sites, and relay nodes. You can also use Pangolin Cloud but self-host only relays so traffic never leaves your side. The control plane and all data can stay under your control.
Cloudflare One is offered only as a managed service. You cannot self-host Access, WARP’s coordination, or the Tunnel control plane. Data flows through Cloudflare’s global network (with optional regional constraints where the product supports it). If you need the control plane and data path fully on your own infrastructure or in your own cloud, Pangolin supports that; Cloudflare One does not.
### Data sovereignty
With Cloudflare One, SSL termination and decryption happen on Cloudflare’s servers. They could, in principle, man-in-the-middle that traffic (we’re not saying they do). With Pangolin you can self-host the relays, so TLS terminates on infrastructure you control and traffic never passes through a third party. That improves privacy and is also useful when you need to stream high-bandwidth content through the proxy without sending it over someone else’s network.
### Gateway and secure web gateway (SWG)
Cloudflare One often includes Gateway: when users have WARP enabled, their DNS and HTTP traffic can be sent to Cloudflare for filtering, DLP, and policy. So Cloudflare One is both ZTNA (access to your private apps) and an SWG (control over general internet-bound traffic). Pangolin does not filter general web traffic. It can, however, act as a web gateway for SaaS apps: you can proxy any web traffic through Pangolin sites so that access to Salesforce, Jira, or other SaaS applications is subject to your identity and resource policies—traffic to those apps flows through Pangolin and is gated by the same rules as your internal resources. If you only need private app access (internal + optional SaaS via proxy), Pangolin covers that without full SWG. If you want ZTNA and broad SWG (DNS/HTTP filtering of all internet traffic) from one vendor and are fine with cloud-only, Cloudflare One covers both.
### Device posture enforcement
Both Pangolin and Cloudflare One support device posture enforcement. You can require that devices meet certain conditions (e.g. disk encryption enabled, firewall on, OS version, antivirus present) before access is granted. Policies are applied to resources: access to a given app or host can be gated on posture checks, so only compliant devices can reach it. In both platforms, posture is evaluated and enforced before access is allowed; users on non-compliant devices are denied or prompted to remediate.
### 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. Cloudflare’s Tunnel daemon (cloudflared) is open source; Access, WARP, and the Zero Trust control plane are proprietary. For full transparency and the ability to self-host and modify the entire access stack, Pangolin provides that; with Cloudflare you depend on their closed-source control plane and clients.
### Best fit
**Choose Pangolin if** you want open-source, self-hostable remote access with the option of peer-to-peer client connections and no third-party in the data path. Pangolin fits when you need both web and non-HTTP resources under one identity model and want full control over where the control plane and traffic run.
**Choose Cloudflare One if** you want a single cloud vendor for ZTNA and optional secure web gateway (Gateway), are fine with all traffic passing through Cloudflare’s edge, and do not need to self-host the control plane. Cloudflare One fits when you value global edge scale and integration with Cloudflare’s DNS, CDN, and DDoS products.
## Related comparisons
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [Pangolin vs. Tailscale](/news/pangolin-v-tailscale)
* [Pangolin vs. Pomerium](/news/pangolin-v-pomerium)
* [Tunneled Reverse Proxy Architecture](/news/tunneled-reverse-proxy)
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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](/contact).
---
### Comparison - Pangolin vs. Pomerium
URL: https://pangolin.net/news/pangolin-v-pomerium
Published: 2026-02-23
Summary: How an identity-based remote access platform and an identity-aware reverse proxy differ in scope, layer, and deployment.
Category: Product
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** | ✓ Control 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 |
## Detailed comparison
### 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](/news/how-to-ssh-with-pangolin), 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.
## Related comparisons
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [Pangolin vs. Cloudflare One](/news/pangolin-v-cloudflare)
* [What is an Identity-Aware Proxy?](/news/what-is-an-identity-aware-proxy)
* [Pangolin vs. Twingate](/news/pangolin-v-twingate)
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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](/contact).
---
### Comparison - Twingate vs. NetBird
URL: https://pangolin.net/news/twingate-v-netbird
Published: 2026-02-23
Summary: How Twingate and NetBird are solving different problems in modern remote access.
Category: Product
Twingate and NetBird both provide zero-trust remote access, but they take fundamentally different approaches. Twingate focuses on resource-centric access through connectors with a cloud-only control plane. NetBird builds peer-to-peer overlay networks where devices connect directly to each other. This article outlines what each does and where they diverge.
## 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.
You define logical networks in the dashboard and assign connectors to them. You then define resources behind those connectors. Users install the Twingate client, sign in, and get access to only the resources you have allowed. Access is deny-by-default and resource-centric: you grant access to specific applications or hosts, not entire networks.
Twingate is closed source and uses a cloud-hosted, multi-tenant control plane. The Controller is always hosted by Twingate; you cannot self-host it. Connectors and Relays run in your infrastructure or Twingate's, but the control plane - where configuration and ACLs live - is cloud-only.
## 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 | Twingate | NetBird |
| --- | --- | --- |
| **Architecture** | ✓ Controller + Relays + Connectors + Clients; Controller never touches data | Peer-to-peer VPN; devices connect directly to each other |
| **Access model** | ✓ Resources (FQDN/IP); ACLs for Clients and Connectors | Peer-to-peer device connectivity; groups and policies |
| **Self-hosting** | ✓ Controller is cloud-only, multi-tenant | Both SaaS and self-hosted options; full control if self-hosting |
| **Open source** | ✓ Closed source; no self-hosted control plane | Fully open source: client agents and coordination server |
| **SSO / IdP** | ✓ Delegates authentication to IdP | Built-in SSO with OIDC free plan; advanced identity providers from Team plan |
| **Web app exposure** | ✓ Private resources only; client required for access | Peer-to-peer and basic web app exposure connectivity |
| **Tenancy** | ✓ Single tenant per signup; one tenant for your team | Single tenant per deployment |
| **Device security** | ✓ Device posture (encryption, firewall, antivirus, etc.) | Device posture checks supported |
| **Transport** | ✓ Custom protocol; TLS tunnels; NAT traversal via Relay or P2P; no open ports | WireGuard NAT traversal; no open ports |
## Detailed comparison
### Architecture
Twingate uses a hub-and-spoke architecture with a cloud-hosted Controller. You deploy Connectors in your private networks; they maintain outbound-only connections to the Controller. Users run the Twingate client and connect to Connectors (directly when NAT allows, or via Twingate's Relays when it does not). The Controller handles authentication, authorization, discovery, and coordination. Data flows from client to Connector to resource; the Controller never touches your data, only metadata for coordination.
You organize Connectors into logical networks in the dashboard. This lets you group related infrastructure and manage access at a higher level. Clients connect to the resources you allow; they do not form a mesh or talk to each other.
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.
Both architectures avoid opening ports. Twingate Connectors and NetBird peers use outbound-only connections for control and coordination. Data connections use NAT traversal when possible and fall back to relaying when not.
### How clients and access work
In Twingate you think in terms of resources: specific hosts or applications identified by FQDN or IP. Admins grant users (or groups) access to specific resources. A user installs the Twingate client, signs in via their identity provider, and sees only the resources they are allowed to use. Access is deny-by-default. No resource is reachable until you grant it. Twingate supports both interactive user devices and machine clients for servers, CI/CD, and other automated systems.
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. Once devices are on the network and policy allows, they can communicate with each other using their overlay IPs.
### Access control and security
Twingate uses the UI to define who can access which specific resources. Admins manage everything from the dashboard. You use groups and resource-based ACLs to segment access. SSO and identity providers plug in for authentication; Twingate delegates all authentication to your IdP. Policies are resource-centric: "this group can reach this host on these ports." Both declarative setup (via Terraform or API) and UI-based management are supported.
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.
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.
### Web apps and clientless access
Twingate is built around private Resources only. Access to private Resources requires the Twingate client on the user's device. There is no built-in, clientless browser path for web applications. If you need to provide access to internal web apps, users must install and use the Twingate client.
NetBird has peer-to-peer device connectivity and web application exposure. NetBird primarily is about connecting devices to each other, but do have the ability to route traffic through a reverse proxy running on the NetBird server with basic access controls.
### Deployment and data sovereignty
Twingate operates as a cloud-hosted service. The Controller (control plane) is managed by Twingate; you do not self-host it. Connectors run in your infrastructure (on-premises, cloud VPCs, etc.), and you can optionally deploy your own relay nodes to keep data traffic on your infrastructure. However, the control plane - where configuration, ACLs, and user data live - remains cloud-only. If you require the entire control plane and all metadata to run on your own infrastructure, Twingate does not offer that option.
NetBird offers both a fully managed cloud service and a self-hosted option. With self-hosting, you run the entire NetBird stack - control plane, coordination server, and optionally your own relay nodes - on your own infrastructure. This gives you full control over data and sovereignty. The cloud service reduces operational overhead while NetBird manages the infrastructure. NetBird does not currently support hybrid deployments where you use the cloud control plane but host your own relay nodes.
### Scaling and connector model
Twingate uses a connector-per-network model. You deploy one Connector (or a few for redundancy) in each private network or segment. You then define Resources - specific hosts, applications, or services - behind that Connector. Users can have access to Resources across multiple networks simultaneously. The Connector handles routing to those Resources. This model scales by adding Connectors and Resources. You do not maintain a large overlay IP space, and you do not manage peer-to-peer connections between all devices. If you have two cloud VPCs - one with production databases and one with staging servers - you deploy two Connectors and define Resources in each. Users connect to the Connectors, not to individual servers. The operational complexity is linear: more networks mean more Connectors, but not exponentially more connections or ACL entries.
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. The "N-squared" problem of mesh networks applies: as you add devices, the number of potential peer connections and ACL rules grows quadratically. DNS in NetBird is node-oriented: names point at devices on the network, rather than resources on a remote network.
With NetBird, if you need to access resources in a network, you have two main options: install the NetBird client on every device you want to reach, or set up exit nodes that route traffic into a network. The latter requires switching between exit nodes if you need access to multiple networks. For large deployments with many resources, this can become complex compared to a connector-per-network model.
### Tenancy
Twingate is single-tenant. When you sign up, you get one tenant for your organization. Managing multiple separate organizations (e.g., as an MSP serving many customers) requires separate Twingate accounts or using their special MSP service and is less natural than a multi-org model.
NetBird Cloud offers an MSP Portal designed for Managed Service Providers. MSPs can manage multiple customer tenants from a single NetBird account., Self-hosted NetBird deployments follow a single-tenant model where each deployment serves one organization.
### Device security
Both platforms support device posture checks: gathering information about security settings on user devices. You can use posture data in access policies to allow or deny access based on device security state.
Twingate enforces posture checks on a per-Resource basis. You can require that a device meets certain security criteria before it can access a Resource. Twingate also supports device fingerprinting: collecting device-specific identifiers like serial numbers and hardware information to recognize and track devices over time.
NetBird offers device posture as well through partners like Crowdstrike and some built in controls. You can require that devices meet posture requirements to join the NetBird network. Posture checks are enforced at the network level or via policies.
### Open source
Twingate is fully closed source. You cannot inspect, modify, or self-host the Controller or any part of the platform. The entire stack - clients, Connectors, Controller, and relays - is proprietary.
NetBird is fully open source. The client agent and coordination server are available for you to run, inspect, and modify. You can self-host the entire stack if you choose.
### Best fit
**Choose Twingate if** you want zero-trust, resource-centric access where you grant users access to specific applications, databases, or servers - not entire networks. Twingate fits organizations that think in terms of "who can access which internal app or service" and want a system that enforces deny-by-default access without requiring users to understand networking. It is a good fit if you are comfortable with a cloud-only control plane and do not need clientless web access or self-hosting the control plane.
**Choose NetBird if** you want a peer-to-peer VPN focused on device-to-device and server-to-server connectivity with full open source transparency and optional self-hosting. NetBird fits small to medium overlay networks where device-to-device connectivity is the main goal and you value the ability to run the entire stack on your own infrastructure.
### Consider Pangolin as an alternative
If you are evaluating Twingate for zero-trust, resource-centric access but want more flexibility or control, **Pangolin** is worth considering. Like Twingate, Pangolin uses a connector-based model (Pangolin calls them sites). You deploy lightweight connectors in your networks, define resources (web apps, databases, SSH hosts, APIs), and grant users access to specific resources. Access is deny-by-default. Clients connect directly to sites, not to each other.
If you are considering NetBird for peer-to-peer connectivity but want a more resource-centric model with clientless web access and self-hosting options, Pangolin is also a strong alternative. Pangolin's architecture combines the best of both worlds: it supports resource-centric access like Twingate while also offering clientless web access and full self-hosting options like NetBird.
Where Pangolin differs:
* **Open source and self-hostable**: Pangolin's server and clients are fully open source (AGPLv3 or Commercial License). You can self-host the entire platform if you need full control over the control plane and data. Alternatively, use Pangolin Cloud and optionally deploy your own relay nodes to keep traffic on your infrastructure.
* **Clientless web access**: Pangolin can expose web applications without a client. Users open a URL, sign in (e.g., with SSO), and reach the app in the browser. Pangolin can act as an identity-aware reverse proxy with automatic SSL certificates, custom domains, and layered authentication (pin codes, passcodes, user auth, email whitelists) in addition to VPN capabilities. This fits contractors, BYOD, or quick access to internal tools without installing software.
* **Built on WireGuard**: Pangolin uses the same proven, open-source WireGuard protocol that NetBird is built on, not a proprietary transport like Twingate.
* **Multi-tenancy**: Pangolin supports multiple organizations under one account. You can share users and resources across organizations, making it well suited for MSPs or teams managing multiple customers.
Pangolin combines the resource-centric, zero-trust model of Twingate with clientless web access, full self-hosting options, and the transparency and flexibility of open source like NetBird. If those capabilities matter to you, Pangolin is a strong alternative.
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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 compares to Twingate or Tailscale for your specific setup, [reach out](/contact).
---
### Comparison - Twingate vs. Tailscale
URL: https://pangolin.net/news/twingate-v-tailscale
Published: 2026-02-23
Summary: How Twingate and Tailscale are solving different problems in modern remote access.
Category: Product
Twingate and Tailscale both provide secure remote access without traditional VPNs. They take different approaches: Twingate is built around zero-trust resource access, while Tailscale creates a mesh network where devices can talk to each other. This article outlines what each platform does and where they diverge, so you can see which fits your needs.
## What is Twingate?
Twingate is a zero-trust remote access platform that gives users access to specific resources - hosts or applications identified by FQDN or IP - rather than entire networks. You deploy connectors in your private networks; they maintain outbound-only connections to Twingate's cloud control plane, so no inbound ports are required. Users connect to resources by FQDN or IP; the system handles routing and encryption over proprietary TLS-based tunnels, using direct peer-to-peer connections when possible and relaying through Twingate's infrastructure when not.
The model is resource-centric: you define specific applications, databases, or servers as Resources in the dashboard. You then grant users or groups access to specific Resources. Users install the Twingate client, sign in, and see only what they are authorized to access. Access is deny-by-default. Twingate is closed source and operates as a cloud-hosted, multi-tenant service. You do not self-host the control plane (called the Controller).
## 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 as if they were on the same LAN.
Devices join the tailnet by running the Tailscale client. Each device gets an IP address on the overlay network. Once connected, devices can reach each other directly using those IPs. Tailscale uses NAT hole punching and WireGuard key exchange so devices can form direct links through firewalls without opening ports; when direct connections fail, traffic relays through Tailscale's DERP (Designated Encrypted Relay for Packets) infrastructure.
Tailscale is built for device-to-device and server-to-server connectivity. The mental model is "devices on a shared private network" rather than "users accessing specific resources." You control who can reach what using ACLs (access control lists) written in JSON. Tailscale runs as a cloud-only service with their hosted control plane. A community project called Headscale reimplements the Tailscale control plane for self-hosting, but it is not an official Tailscale product and requires you to maintain it yourself.
## How the two compare
The table below summarizes the main differences. The sections after it walk through each area in order.
| Feature | Twingate | Tailscale |
| --- | --- | --- |
| **Architecture** | ✓ Controller + Connectors + Clients; resource-centric access | Mesh-based VPN with overlay network; devices peer directly |
| **Access model** | ✓ Resources (FQDN/IP); ACLs for Clients and Connectors; deny-by-default | Devices (nodes) on tailnet; JSON ACLs define network access |
| **Self-hosting** | ✓ Controller is cloud-only, multi-tenant | Cloud only; Headscale is community-supported alternative |
| **Open source** | ✓ Closed source; no self-hosted control plane | Client daemon partially open source; server closed source |
| **SSO / IdP** | ✓ Delegates authentication to IdP | Built-in SSO with OIDC |
| **Web app exposure** | ✓ Private resources only; client required for access | Tailscale Funnel for public ingress; limited auth, shared domain |
| **Transport** | ✓ Custom protocol; TLS tunnels; NAT traversal via Relay or P2P; no open ports | WireGuard; NAT traversal via DERP relay or P2P; no open ports |
| **Device security** | ✓ Device posture (encryption, firewall, antivirus, etc.) | Device posture checks available |
| **Tenancy** | ✓ Single tenant per signup; one tenant for your team | Single tailnet per account |
| **Scaling model** | ✓ Add Connectors per network; define Resources behind each | Add devices to mesh; manage overlay IPs and ACLs |
## Detailed comparison
### Architecture
Twingate and Tailscale use fundamentally different architectures to solve remote access.
Twingate uses a connector-based, hub-and-spoke model. Connectors run in your private networks and maintain outbound-only connections to the cloud. When a user wants to access a Resource, their client connects directly to a Connector (peer-to-peer when possible, or via Twingate's relay when NAT traversal fails). Clients do not talk to each other; they only reach the Resources you have granted them access to. This keeps the model simple: you scale by adding Connectors to new networks and defining Resources behind them.
Tailscale uses a full mesh architecture. Every device in the tailnet can form direct WireGuard links to every other device. Data flows peer-to-peer when possible; when direct connections fail, traffic routes through Tailscale's DERP relay servers. The network model is "all devices on one virtual network" (subject to ACLs). This works well for small to medium sets of devices that need to talk to each other. At larger scale, managing the mesh topology, overlay IP space, and ACL complexity grows with the number of devices.
### How clients and access work
Twingate organizes access around resources: specific applications, hosts, or services identified by FQDN or IP. Admins define Resources in the dashboard and grant users or groups access to them. Users install the Twingate client, sign in, and see only the Resources they are authorized to use. Access is deny-by-default: nothing is reachable until you explicitly grant it. Sessions are per Resource, and the client handles routing transparently. Twingate also supports service accounts for machine-to-machine access - servers, CI/CD pipelines, and other non-interactive systems that need to reach private Resources.
Tailscale organizes access around devices (nodes) on a tailnet. You install the client on each device that should join the network. Each device gets an overlay IP address (typically in the `100.x.x.x` CGNAT range). ACLs define which nodes (or tags) can reach which other nodes, subnets, or ports. The unit of access is the device or subnet, not a named application. It is powerful for network-level control, but less direct for "grant this user access to this specific app" without thinking in terms of IPs, ports, and device tags.
### Access control and security
Twingate provides a dashboard to define who can access which Resources. You grant access to users and groups. Twingate delegates authentication to your identity provider (Okta, Azure AD, Google Workspace, and others). The system manages who can access what and pushes this to Clients and Connectors; you do not edit ACLs by hand. Twingate also supports device posture checks: you can require that devices have disk encryption enabled, a firewall running, antivirus up to date, and similar security settings before granting access. Policies are resource-centric: "this group can access this database" or "these users can reach this internal API."
Tailscale uses JSON ACLs written in a policy file. You define rules that allow or deny traffic between nodes, by tag, user, or to specific ports and subnets. It is network-centric: you think in terms of IP ranges, ports, and device tags. Tailscale also supports SSO via OIDC and device posture checks (called device authorization). The main lever for access control is the ACL file, which you edit in the Tailscale admin console or manage via gitops. It gives you fine-grained networking control, but it is less intuitive for application-level access policies like "grant this person access to Grafana."
### Web apps and clientless access
Twingate is built for private Resource access. All access requires the Twingate client installed on the user's device. There is no built-in, clientless browser path for web applications. If you need users to access internal web apps, they must install the client first. Twingate does not function as an identity-aware reverse proxy with custom domains and public URLs for web resources.
Tailscale offers Tailscale Funnel for exposing services from your tailnet to the public internet. Funnel lets you route public HTTPS traffic through the tailnet to a local service without opening ports. However, Funnel has limitations for web app access: authentication options are limited (primarily tailnet member access or fully public), and all Funnel resources share the same base domain (e.g., `*.ts.net`) - you control only the subdomain, not the full domain. Funnel is not designed as a full identity-based reverse proxy for internal web apps with strong authentication, custom domains, and per-resource access control. It is more akin to a quick way to expose a service publicly, similar to ngrok or Cloudflare Tunnel, but with less emphasis on identity and access management.
Neither platform offers the same level of clientless, identity-aware web access that a platform like Pangolin provides (see below).
### Deployment and data sovereignty
Twingate operates as a cloud-hosted service. The Controller (control plane) is managed by Twingate; you do not self-host it. Connectors run in your infrastructure (on-premises, cloud VPCs, etc.), and you can optionally deploy your own relay nodes to keep data traffic on your infrastructure. However, the control plane - where configuration, ACLs, and user data live - remains cloud-only. If you require the entire control plane and all metadata to run on your own infrastructure, Twingate does not offer that option.
Tailscale also operates as a cloud-only service. You depend on Tailscale's hosted coordination server and DERP relay infrastructure. Tailscale's client daemon (tailscaled) is partially open source, but the coordination server is proprietary. Headscale is a community-built, open-source implementation of the Tailscale coordination server. Some teams use Headscale to self-host the control plane, but you are responsible for deploying, maintaining, and operating it. It is not an official Tailscale product, and it may lag behind Tailscale's feature set. You can also self-host DERP relay nodes to keep traffic off Tailscale's infrastructure, but the coordination server remains cloud-only unless you use Headscale.
### Scaling and connector/device model
Twingate uses a connector-per-network model. You deploy one Connector (or a few for redundancy) in each private network or segment. You then define Resources - specific hosts, applications, or services - behind that Connector. Users can have access to Resources across multiple networks simultaneously. The Connector handles routing to those Resources. This model scales by adding Connectors and Resources. You do not maintain a large overlay IP space, and you do not manage peer-to-peer connections between all devices. If you have two cloud VPCs - one with production databases and one with staging servers - you deploy two Connectors and define Resources in each. Users connect to the Connectors, not to individual servers. The operational complexity is linear: more networks mean more Connectors, but not exponentially more connections or ACL entries.
Tailscale uses a device-per-node model. Each device you want to access must either run the Tailscale client. In the same two-VPC scenario, you would 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 for resources that cannot run the Tailscale client - like managed databases, appliances, or services where you do not control the OS. Each device gets an overlay IP address (typically in the `100.x.x.x` range), and you manage that address space as the tailnet grows. You also manage ACLs that define which nodes can reach which other nodes or subnets. At large scale, the mesh and ACL complexity can grow significantly: adding more devices means more peer relationships, more overlay IPs to track, and longer ACL files.
### Device security
Both platforms support device posture checks: gathering information about security settings on user devices. This includes whether disk encryption is enabled, the firewall is on, antivirus is present and up to date, OS version, and similar. You can use posture data in access policies to allow or deny access based on device security state.
Twingate enforces posture checks on a per-Resource basis. You can require that a device meets certain security criteria before it can access a Resource. Twingate also supports device fingerprinting: collecting device-specific identifiers like serial numbers and hardware information to recognize and track devices over time.
Tailscale offers device posture through its device authorization feature. You can require that devices meet posture requirements to join the tailnet or access certain nodes. Posture checks are enforced at the tailnet level or via ACL rules.
### Tenancy
Twingate is single-tenant. When you sign up, you get one tenant for your organization. Managing multiple separate organizations (e.g., as an MSP serving many customers) requires separate Twingate accounts or using their special MSP service and is less natural than a multi-org model.
Tailscale is also single-tenant by default: one tailnet per account. Tailscale does offer a feature for larger organizations to create multiple tailnets under one umbrella, but the primary model is one tailnet for one team or organization.
### Open source
Twingate is fully closed source. You cannot inspect, modify, or self-host the Controller or any part of the platform. The entire stack - clients, Connectors, Controller, and relays - is proprietary.
Tailscale has a partially open-source model. The Tailscale client daemon (`tailscaled`) and some libraries are open source. Full client applications (mobile apps, GUI apps) and the coordination server are proprietary. You cannot self-host the official Tailscale coordination server. **Headscale** is an independent, open-source reimplementation of the coordination server that you can self-host, but it is maintained by the community and may not have feature parity with Tailscale's official service.
### Best fit
**Choose Twingate if** you want zero-trust, resource-centric access where you grant users access to specific applications, databases, or servers - not entire networks. Twingate fits organizations that think in terms of "who can access which internal app or service" and want a system that enforces deny-by-default access without requiring users to understand networking. It is a good fit if you are comfortable with a cloud-only control plane and do not need clientless web access or self-hosting the control plane.
**Choose Tailscale if** you want a simple mesh VPN where devices and servers can talk to each other as if on a private LAN. Tailscale fits small to medium deployments where device-to-device or server-to-server connectivity is the main goal, and you are comfortable expressing access policy in JSON ACLs. It works well when you control the devices and can install the Tailscale client on them. Tailscale is also a good fit if you value the WireGuard protocol and want a service that is partially open source, with the option to use Headscale for self-hosting the control plane if needed.
### Consider Pangolin as an alternative to Twingate
If you are evaluating Twingate for zero-trust, resource-centric access but want more flexibility or control, **Pangolin** is worth considering.
Like Twingate, Pangolin uses a connector-based model (Pangolin calls them sites). You deploy lightweight connectors in your networks, define resources (web apps, databases, SSH hosts, APIs), and grant users access to specific resources. Access is deny-by-default. Clients connect directly to sites, not to each other.
Where Pangolin differs:
**Open source and self-hostable**: Pangolin's server and clients are fully open source (AGPLv3 or Commercial License). You can self-host the entire platform if you need full control over the control plane and data. Alternatively, use Pangolin Cloud and optionally deploy your own relay nodes to keep traffic on your infrastructure.
**Clientless web access**: Pangolin can expose web applications without a client. Users open a URL, sign in (e.g., with SSO), and reach the app in the browser. Pangolin can act as an identity-aware reverse proxy with automatic SSL certificates, custom domains, and layered authentication (pin codes, passcodes, user auth, email whitelists) in addition to VPN capabilities. This fits contractors, BYOD, or quick access to internal tools without installing software.
**Built on WireGuard**: Pangolin uses the same proven, open-source WireGuard protocol that Tailscale is built on, not a proprietary transport.
**Multi-tenancy**: Pangolin supports multiple organizations under one account. You can share users and resources across organizations, making it well suited for MSPs or teams managing multiple customers.
Pangolin combines the resource-centric, zero-trust model of Twingate with clientless web access, full self-hosting options, and the transparency and flexibility of open source. If those capabilities matter to you, Pangolin is a strong alternative.
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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 compares to Twingate or Tailscale for your specific setup, [reach out](/contact).
---
### Pangolin SSO with Google, Microsoft & OAuth2/OIDC
URL: https://pangolin.net/news/idp-support
Published: 2026-02-17
Summary: You can now log in to Pangolin with your existing identity provider - including Google, Microsoft, and any OAuth2/OIDC compatible IdP.
Category: Guides
## External Identity Provider SSO with Pangolin
Managing access to applications across different networks and clouds is often messy. Traditional reverse proxies get scattered in different places, each with its own login logic and credentials. Maintaining them means duplicating authentication and policies everywhere.
Pangolin simplifies this. It provides a centralized, managed proxy layer:
* Secure tunnels to any environment such as a datacenter, office, IoT device, or multi‑cloud.
* Apps exposed in the browser without VPN clients.
* Identity and access control managed from one dashboard.
Because Pangolin becomes the front door for your apps, Single Sign‑On (SSO) is essential. Users should log in once with the accounts they already use, and admins should be able to manage access from a single source of truth.
That’s why Pangolin Cloud now supports Google Workspace and Microsoft Entra ID (Azure AD) as native identity providers, alongside any OAuth2/OIDC system.
## Key details
### Why this matters
Supporting identity providers directly in Pangolin Cloud unlocks three key benefits:
* **Single Sign-On (SSO):** Your team logs in once with their existing account and seamlessly gains access to Pangolin resources, without managing a new set of usernames and passwords.
* **Centralized identity management:** Because authentication runs through your IdP, you can manage access in one place. Disable a user in Google Workspace or Microsoft Entra, and their access to Pangolin is cut off immediately.
* **Consistent security policies:** Enforce MFA, conditional access rules, and compliance requirements across Pangolin just as you do for the rest of your stack.
With **auto-provisioning**, new users can be created automatically in Pangolin at first login and assigned roles based on your IdP’s group or attribute data. No more sending invites or chasing people down to set passwords because your IdP remains the single source of truth.
### How this helps in practice
Pangolin acts as an identity-aware proxy: a central point through which you can expose internal applications securely over the internet, while managing who can access what. With IdP support in the cloud, this becomes even more powerful.
Imagine you’re exposing an internal admin dashboard, developer tooling, or a legacy web app through Pangolin. Instead of maintaining a separate login system or manually handling user credentials, you can require authentication through your existing provider. A contractor logging in with their company Google Workspace account only sees the apps they’ve been granted, while everyone else is automatically blocked. When that contract ends, disabling their Google account instantly revokes their access to Pangolin too.
For organizations running hybrid environments, this provides a consistent way to secure applications no matter where they live — on-prem, in the cloud, or on a developer’s laptop. And because Pangolin handles access at the proxy layer, you get unified visibility and control across your network without having to retrofit every app with custom authentication.
### Custom domains for authentication
Alongside identity provider support, we’ve also added a new feature that lets organizations set a **custom domain for their authentication page**. This is the page users see whenever they log in to access a Pangolin-protected resource or the Pangolin management dashboard. With a custom domain, users encounter a URL that matches your organization’s brand which increases trust and reduces confusion.
Instead of being redirected to a generic login, your team might see something like `auth.yourcompany.com` each time they authenticate. This reinforces that access is sanctioned by your organization and makes the login process more familiar. It’s especially valuable when giving access to external collaborators or contractors: the domain signals that they’re logging in through *your systems*, not a third party.
You can configure this custom domain directly in the **Organization Settings** page in the dashboard.
### Native Google and Microsoft integrations
While Pangolin supports any OIDC-compliant provider, we’ve gone further with dedicated integrations for **Google** and **Microsoft Entra ID**. These make setup even simpler, with configuration flows purpose-built for the ecosystems most teams are already using.
* **Google Workspace integration:** Ideal if your organization already relies on Gmail, Calendar, or Google Docs. Users authenticate directly with their existing Google accounts for seamless access to Pangolin Cloud.
* **Microsoft Entra ID integration:** Perfect for enterprises standardized on Microsoft 365 or Azure services. Leverage your existing Active Directory groups to grant and revoke access automatically.
We’ve also put together short demo videos to walk through both setups:
### Google login with Pangolin Cloud
### Microsoft Entra ID login with Pangolin Cloud
## Dive deeper
If you’re ready to try it out, we’ve documented the full setup process:
* [Set up Google login](https://docs.pangolin.net/manage/identity-providers/google)
* [Set up Microsoft Entra ID / Azure AD](https://docs.pangolin.net/manage/identity-providers/azure)
* [Add a generic OAuth2/OIDC IdP](https://docs.pangolin.net/manage/identity-providers/add-an-idp)
We’re excited to keep expanding how identity integrates with Pangolin. Give it a try and let us know how it works for your team.
---
### Comparison - Pangolin vs. Twingate
URL: https://pangolin.net/news/pangolin-v-twingate
Published: 2026-02-03
Summary: How two identity-based remote access platforms differ in architecture, web access, and deployment options.
Category: Product
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](/news/how-to-ssh-with-pangolin) 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 |
## Detailed comparison
### 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.
## Related comparisons
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [Pangolin vs. Tailscale](/news/pangolin-v-tailscale)
* [Pangolin vs. NetBird](/news/pangolin-v-netbird)
* [Twingate vs. Tailscale](/news/twingate-v-tailscale)
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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](/contact).
---
### Comparison - Pangolin vs. NetBird
URL: https://pangolin.net/news/pangolin-v-netbird
Published: 2026-01-30
Summary: A comparison of two WireGuard-powered remote access solutions and their differences in architecture, permissions, and use cases.
Category: Product
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](/news/how-to-ssh-with-pangolin) 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; 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 | Peer-to-peer and basic web app exposure 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 |
## Detailed comparison
### 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. While it can facilitate basic web app access through the overlay network from the server, it does not offer the same level of clientless web access or identity-aware reverse proxy capabilities as Pangolin. NetBird is more suited for scenarios where device-to-device connectivity is the main goal, rather than providing granular access to specific web applications.
### 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.
## Related comparisons
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [Pangolin vs. Tailscale](/news/pangolin-v-tailscale)
* [Pangolin vs. WireGuard](/news/pangolin-vs-wireguard)
* [Twingate vs. NetBird](/news/twingate-v-netbird)
### FAQ
### Is Pangolin a NetBird alternative?
Yes, especially for organizations that want identity-based access to specific applications, servers, databases, and internal services. NetBird is a better fit when the core requirement is peer-to-peer connectivity between devices.
### Do Pangolin and NetBird both use WireGuard?
Yes. Both use WireGuard for encrypted transport. The main difference is the access model around it: Pangolin organizes access around sites and resources, while NetBird organizes access around peers and networks.
### Which is better for clientless web access?
Pangolin is designed to expose private web applications through an identity-aware access layer without requiring every user to install a client. NetBird is primarily an overlay VPN, so web access usually happens through the connected network path.
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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](/contact).
---
### Comparison - Pangolin vs. Tailscale
URL: https://pangolin.net/news/pangolin-v-tailscale
Published: 2026-01-27
Summary: How two WireGuard-based tools for remote access differ in design, access control, and fit.
Category: Product
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](/news/how-to-ssh-with-pangolin) 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 |
## Detailed comparison
### 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.
## Related comparisons
* [How to SSH with Pangolin](/news/how-to-ssh-with-pangolin)
* [Pangolin vs. NetBird](/news/pangolin-v-netbird)
* [Pangolin vs. WireGuard](/news/pangolin-vs-wireguard)
* [Pangolin vs. Twingate](/news/pangolin-v-twingate)
### FAQ
### Is Pangolin a Tailscale alternative?
Yes, for teams that want remote access organized around users, resources, and private applications instead of a device mesh. Tailscale is often stronger when the primary goal is simple device-to-device connectivity.
### Can Pangolin replace a VPN for internal apps?
Yes. Pangolin can provide browser-based access for internal web apps and client-based private access for SSH, databases, APIs, and other services, with policies scoped to specific resources.
### Which is better for self-hosting?
Pangolin supports a self-hosted server and clients as part of the core product. Tailscale’s official control plane is cloud-hosted; Headscale exists for self-hosting, but it is a community implementation rather than the official Tailscale backend.
## Try Pangolin
[Get started with Pangolin](https://app.pangolin.net/). 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](/contact).
---
### Pangolin 1.15: Mobile Apps, Device Approvals & Posture
URL: https://pangolin.net/news/1-15-0-release
Published: 2026-01-23
Summary: Pangolin 1.15 adds iOS and Android apps, device approvals, posture tracking, fingerprinting, and stability improvements.
Category: Product
One year ago, in January 2025, we unleashed the very first beta of Pangolin. To be honest, it was a bit lean and had a few "character-building" bugs - but it quickly struck a chord as the go-to open-source alternative to Cloudflare Tunnels for browser-based access.
Fast forward to today, and Pangolin has grown up. We’ve spent the last year stabilizing the core, expanding the feature set, and watching our community thrive. At the end of 2025, we introduced a major new category: Zero-Trust Private Access. This was our answer to months of requests for VPN-like functionality, turning Pangolin into a true one-stop shop for identity-based remote access - whether you’re using a browser or a direct client connection.
Today, we are thrilled to release Pangolin 1.15.0. This update officially takes Private Access out of beta and introduces some heavy hitters: iOS and Android apps, device fingerprinting, posture tracking, and more.
## Release highlights
### iOS/iPadOS and Android
Developing for mobile is a journey through the seven circles of... well, let’s just call it "challenging." Beyond the technical hurdles, there’s the arduous dance with Apple and Google to get through the App Store gates.
After weeks of refreshing our developer dashboards, the wait is over. You can now take your zero-trust network on the road:
* **iPhone and iPad**: Download on the [Apple App Store](https://apps.apple.com/kz/app/pangolin-client/id6757407406).
* **Android**: Download on the [Google Play Store](https://play.google.com/store/apps/details?id=net.pangolin.Pangolin).
### Device Fingerprint and Posture Collection
Long-time users likely remember Olm, our Go-based client (named after the small, cave-dwelling salamander). Olm is the workhorse under the hood, handling everything from holepunching and NAT traversal to websocket enforcement.
We architected Olm to be as headless and portable as possible, which allowed us to use it as the "brain" for all of our clients across Mac, Windows, Linux, and iOS and Android. In addition to the Olm core, now each client can collect specific device data to help you secure your perimeter.
**What is fingerprinting?** It’s like a digital ID card for your hardware. We collect identifying info like serial numbers, OS versions, and hostnames. This helps admins distinguish between "Bob's Work Laptop" and "Bob's 4th Replacement Laptop," and it ensures that if you block a device, it stays blocked, even if the user tries to wipe their credentials.
What are posture checks? Fingerprinting tells us who the device is; posture checks tell us if the device is healthy. We look for security vitals like:
* Disk encryption status
* Firewall status
* Antivirus activity
* And more…
You can dive into the details in our [docs](https://docs.pangolin.net/manage/clients/fingerprinting).
### Device Approvals
Pangolin Private Access is built on zero-trust principles: admins explicitly define which users and roles can access specific hosts and network ranges. However, until now, those principles primarily applied to resources. By default, a user could connect any number of devices as long as they could log in with an approved account. With version 1.15, we are extending zero-trust to the hardware layer by introducing Device Approvals.
When enabled on a user’s role, Pangolin shifts to a "deny by default" stance for new hardware. Even with valid credentials, a new device is entirely blocked until an admin decisively approves the connection. This works hand-in-hand with our new device posture and fingerprinting features, allowing admins to verify that a device is trusted and secure before letting it through the door.
You can manage this on a per-role basis within the Pangolin dashboard. We’ve added an Approvals Feed to the sidebar where you can see a running log of pending requests. Admins can use this feed to quickly review device details and either approve or deny access, ensuring that only authorized hardware can touch your network.
 
### Device Blocking and Archiving
Have a device that’s gone rogue or been lost? You can now officially Block it via the Action Menu (three dots). This moves the device to a restricted list and kills its access immediately.
You’ll also notice you can’t "delete" a device; you can only Archive it.
**Why no delete button?** For security, Pangolin keeps a permanent record of every device that has touched your resources. If you could delete a device entirely, an admin's "Block" rule would vanish with it. Archiving keeps your UI clean of old or duplicate devices while keeping your security audit trail intact.
### General Stability Improvements
As demonstrated by dropping the beta tag from the private access features in Pangolin, we worked hard on stability and performance for all of Pangolin’s clients and private connectivity features.
## Give it a try!
We are incredibly proud of 1.15.0. Between the mobile apps and the new zero-trust controls, Pangolin is more flexible and secure than ever.
You can jump in today with a free account on [Pangolin Cloud](https://app.pangolin.net/). or stick to your roots and self-host the Open Source Community or Enterprise Editions.
Thanks for being part of the journey!
---
### Declarative Configuration with YAML and Docker Labels
URL: https://pangolin.net/news/blueprints
Published: 2025-09-23
Summary: Pangolin Blueprints let you manage resources as code with YAML or Docker labels, making configurations automated, consistent, and scalable.
Category: Guides
## Managing Resources at Scale with Pangolin Blueprints
When teams expose services across multiple environments, the biggest challenges are usually consistency and scale. You might run a mix of cloud services, on‑prem systems, or even IoT devices in the field. Each environment has different access methods and security considerations, but you still need a single way to expose them securely, apply authentication, and control traffic.
Pangolin Blueprints provide a way to define this centrally. Instead of applying reverse proxy rules manually in different places, you describe each resource once using a declarative configuration. Pangolin then applies that configuration, ensuring that proxies, authentication, and target mappings stay consistent no matter where the service runs.
## Key details
### Examples: YAML and Docker Labels
A Blueprint for a single HTTP service can be described in YAML. Below, a Grafana instance in a VPC is exposed at a domain with SSO enabled:
```yaml
proxy-resources:
grafana:
name: Grafana
protocol: http
full-domain: grafana.example.com
auth:
sso-enabled: true
targets:
- hostname: localhost
port: 3000
method: http
```
For containerized workloads, you can define the same setup directly in a `docker-compose.yml` file using labels. The Newt agent detects these at startup and automatically provisions them in Pangolin:
```yaml
services:
grafana:
image: grafana/grafana
container_name: grafana
labels:
- pangolin.proxy-resources.grafana.name=Grafana
- pangolin.proxy-resources.grafana.full-domain=grafana.example.com
- pangolin.proxy-resources.grafana.protocol=http
- pangolin.proxy-resources.grafana.auth.sso-enabled=true
- pangolin.proxy-resources.grafana.targets[0].method=http
- pangolin.proxy-resources.grafana.targets[0].port=3000
```
This approach means you don’t need to configure the proxy separately. Your Compose stack definition and your network access controls live in one place.
### Watch It in Action
This short walkthrough shows a Grafana service being exposed with a Pangolin Blueprint, both through YAML and Docker labels.
### How Teams Use Blueprints
Once services can be declared as code, a wide set of use cases follow naturally:
* **Temporary environments**: Spin up a staging or preview stack with Docker Compose and have Pangolin automatically register domains, enforce authentication, and route traffic without extra configuration.
* **Multiple offices or sites**: Connect tunnels from different physical networks into Pangolin, then apply the same proxy rules and security policies consistently across locations.
* **IoT and edge environments**: Define resources for devices that exist outside your main datacenter and manage access centrally, with the same login rules as cloud applications.
* **Hybrid and multi‑cloud setups**: Expose services running across providers while keeping control of how traffic flows and what authentication is required, all from one dashboard.
Blueprints also make it easier to handle traffic distribution and availability. You can attach multiple targets to a single resource, allowing Pangolin to automatically balance requests across services or fail over if one goes offline.
Here’s an example of a resource with two HTTP backends:
```yaml
proxy-resources:
webapp:
name: WebApp
protocol: http
full-domain: app.example.com
targets:
- hostname: localhost
port: 8080
method: http
site: "aws-vpc-01"
- hostname: localhost
port: 8080
method: http
site: "aws-vpc-02"
```
For developers and operators, this keeps traffic rules explicit. Adding or removing targets is done through the config file rather than by re‑entering settings into a UI.
### Centralized Control
Another advantage of Blueprints is centralization. Access policies, authentication rules, and connection definitions are applied at the proxy layer and enforced the same way across all resources. For example:
* Require SSO for certain applications while leaving others public.
* Apply path‑based rules to allow or block specific endpoints.
* Restrict access to resources by IP or region.
Because these settings are declarative, they can be versioned, audited, and reviewed in the same way as application code. This reduces configuration drift and makes it easier for teams to collaborate on network and access policies.
## Final Thoughts
Pangolin Blueprints provide a way to treat reverse proxy configurations as code and deploy applications that exist on any network anywhere. Whether you define YAML files checked into Git, or embed labels in Compose stacks, service definitions and access controls are created automatically when infrastructure comes online.
That makes it straightforward to manage reverse proxies, authentication policies, load balancing, and site‑to‑site connections from a single place without duplicating manual steps across environments.
Learn more by reading our [documentation](https://docs.pangolin.net/manage/blueprints).
---
### Pangolin Cloud is Now Available in Europe
URL: https://pangolin.net/news/pangolin-cloud-eu
Published: 2025-09-04
Summary: We've deployed dedicated points of presence in the EU for our European cloud users.
Category: Engineering
Last month, we launched Pangolin Cloud in beta with points of presence (PoPs) across North America. Since then, performance has been pretty solid, and we’ve been steadily improving the experience to make sure your sites just work.
Today, we’re excited to share that Pangolin Cloud is spreading across the pond: **we’ve added a brand-new region in the EU.**
## What this means for you
When you connect to Pangolin Cloud, Newt automatically picks the best PoP for you based on real-time metrics (with latency being the big one). Once connected, all your users are routed through the closest PoP before reaching your private network.
With our new EU region, users in Europe will now see faster, more reliable connections. Simply set up your sites as usual, and Newt will automatically pick the best PoP.
## Key details
### Looking ahead
We’re planning to roll out more PoPs worldwide in regions where our users need them most. Pangolin Cloud is still early, and your feedback is a huge part of shaping where we go next.
If you’re trying it out, we'd love to hear from you -- drop us a note at [**contact@pangolin.net**](mailto:contact@pangolin.net) with your thoughts, questions, or how you’re using Pangolin Cloud.
### Don’t forget: self-hosted nodes
Within Pangolin Cloud, you can also use our [**remote nodes**](https://docs.pangolin.net/manage/remote-node/understanding-nodes) option. This lets you deploy your own PoP in any region you choose. Your tunnels will always connect directly to your server, giving you the benefits of self-hosting (data sovereignty, control, and proximity to your VPS) while still taking advantage of cloud features like geo-blocking, high availability, and health checks, for example.
## Try it today
Whether you’re in North America, Europe, or running your own node, Pangolin Cloud is here to make ingress to your as simple, secure, and reliable as possible. [Try it out](https://app.pangolin.net/auth/signup) and let us know what you think!
---
### Health Checks and Load Balancing on Targets for Resources
URL: https://pangolin.net/news/health-check
Published: 2025-08-29
Summary: Configure Pangolin health checks and target-level load balancing to improve resource availability.
Category: Guides
**Health checks and automatic failover** are in Pangolin Cloud, remote node Pangolin instances, and self-hosted editions! This powerful combination of intelligent load balancing and automated health monitoring makes it incredibly simple to build resilient, high-availability applications that can handle failures gracefully.
## Release highlights
### What's New?
### Target-Level Site Assignment
We've restructured how sites work in Pangolin. Instead of attaching sites directly to resources, **sites are now attached to individual targets**. This architectural change unlocks new capabilities:
* **Cross-site redundancy**: Deploy targets across different sites for geographic failover
* **Cross-site load balancing**: Load balance users between different sites hosting many instances of the application
### Automatic Load Balancing
When you add multiple targets to a resource, Pangolin automatically begins **round-robin load balancing** between them if they are attached to the same node. Traffic is distributed evenly across all healthy targets.
### Intelligent Health Monitoring
The health check system continuously monitors your targets from inside Newt and automatically removes unhealthy instances from the load balancing rotation.
## See It In Action
Here's how simple it is to set up high-availability load balancing:
---
### How to Geo-block with Pangolin
URL: https://pangolin.net/news/how-to-geoblock
Published: 2025-08-29
Summary: Learn how to use Pangolin rules to geo-block resources and limit access by country or region.
Category: Guides
We're excited to announce that Pangolin now supports native geo blocking functionality within our cloud platform, remote node instances, and self-hosted editions. This allows you to have granular control over who can access your resources based on their geographic location (country, city, state).
## Release highlights
### What's New?
Geo blocking can be set up in the rules tab for any of your connected resources, and you'll find a new "Country" option alongside the existing IP and IP range filters. From there, you can create sophisticated access control policies.
You can combine country-based restrictions with other rule types like IP addresses, CIDR ranges, and path matching to create layered security policies that fit your exact needs.
### Common Use Cases
**Security Hardening**: Reduce your attack surface by blocking access from regions with high levels of malicious activity or areas where you don't expect legitimate users.
**Resource Optimization**: Prevent unnecessary load on your services from regions where you don't operate, helping you optimize performance and costs.
### Flexible Configuration Options
Pangolin's geo blocking supports multiple configuration patterns:
* **Allowlist**: Create "Allow" rules for approved countries and deny all others
* **Blocklist**: Block specific high-risk countries while allowing access from everywhere else
* **Hybrid Policies**: Combine geographic restrictions with authentication requirements using "Pass to Auth" actions
The rules process in priority order, giving you fine-grained control over complex access scenarios. For example, you might allow direct access from your headquarters country while requiring authentication from trusted partner countries and blocking access entirely from high-risk regions.
### Real-World Example
Here's a typical configuration for a company operating in the US, UK, and Germany:
1. **Priority 1**: Allow - Country: United States
2. **Priority 2**: Allow - Country: United Kingdom
3. **Priority 3**: Allow - Country: Germany
4. **Priority 4**: Deny - Country: ALL
This setup provides immediate access for users in your approved regions while blocking everyone else.
### Important Considerations
While geo blocking provides valuable security benefits, it's important to remember that IP geolocation isn't always 100% accurate. Users with VPNs, proxies, or mobile networks may appear to be from different countries than expected. We recommend testing your rules thoroughly and considering how legitimate users might be affected.
---
### Self-hosted Remote Nodes - What Are They, and Why Do They Exist?
URL: https://pangolin.net/news/manage-self-hosted
Published: 2025-08-29
Summary: Learn about our new remote node self-hosted offering, which combines the best of self-hosted and cloud solutions.
Category: Guides
**Remote Nodes for Pangolin** are a deployment option that combines the control and privacy of self-hosting with the reliability and convenience of cloud management. This hybrid approach gives you high availability and cloud features without the operational complexity.
## How Remote Nodes Work
Remote Nodes split responsibilities between you and us:
**You control the data plane**: Your Pangolin node runs on your infrastructure, handling all tunnels, SSL termination, and traffic processing. Your data never leaves your servers.
**We handle the control plane**: Pangolin Cloud manages DNS coordination, certificate management, database operations, backups, monitoring, and the dashboard interface.
When you deploy a Remote Node, it connects back to Pangolin Cloud for coordination while keeping all traffic processing local to your infrastructure. This architecture enables powerful features like automatic failover between multiple nodes and seamless integration with our cloud points of presence.
## Key details
### Quick Installation Overview
Getting started with a Remote Node deployment is remarkably simple. The installation process looks nearly identical to a standard Pangolin install, with just a few additional configuration steps.
### Key Benefits
### High Availability by Default
Deploy multiple Remote Nodes across different regions or providers. If one goes down, traffic automatically fails over to healthy nodes. You can even configure failover to our cloud infrastructure during maintenance windows.
### Reduced Operational Burden
No more database migrations, backup management, or complex monitoring setup. We handle the operational complexity in the cloud while you focus on your core business.
The cloud dashboard evolves rapidly with new features and improvements. Your Remote Nodes stay current automatically without manual intervention.
### Global Load Balancing
Users automatically connect to the closest healthy node, with intelligent routing and failover between your self-hosted Remote Nodes and cloud points of presence.
### Complete Data Control
Despite cloud coordination, all your traffic and sensitive data flows through your own servers. You maintain complete control over data transit and compliance requirements.
Because data flows through your servers, you don’t pay data costs on the cloud to route your traffic!
### How It Differs from Regular Self-Hosted
### Perfect for Production Workloads
Remote Nodes are ideal for organizations that need:
* **Enterprise reliability** without enterprise complexity
* **Data sovereignty** with operational simplicity
* **High availability** across multiple regions
* **Compliance requirements** that mandate self-hosted infrastructure
* **Reduced operational overhead** while maintaining control
*Ready to experience the best of both worlds?* [*Get started with Remote Nodes in Pangolin today*](https://app.pangolin.net/auth/signup) *and see how enterprise-grade reliability doesn't have to mean giving up control.*
---
## Downloads
### Downloads
URL: https://pangolin.net/downloads
# Downloads
Download Pangolin clients for desktop and mobile platforms.
### macOS
Requires macOS Sonoma 14.0 or later.
Primary action: Download Pangolin for macOS
### Windows
Requires Windows 10 or later.
Primary action: Download Pangolin for Windows
### Linux
Available for most Linux distributions.
Primary action: View Installation Instructions
### iOS
Requires iOS 17.0 or later.
Primary action: Download on the App Store
### Android
Requires Android 7.0 or later.
Primary action: Get it on Google Play
---
### macOS
URL: https://pangolin.net/downloads/mac
Requires macOS Sonoma 14.0 or later.
Primary action: Download Pangolin for macOS
---
### Windows
URL: https://pangolin.net/downloads/windows
Requires Windows 10 or later.
Primary action: Download Pangolin for Windows
---
### Linux
URL: https://pangolin.net/downloads/linux
Available for most Linux distributions.
Primary action: View Installation Instructions
---
### iOS
URL: https://pangolin.net/downloads/ios
Requires iOS 17.0 or later.
Primary action: Download on the App Store
Store: https://apps.apple.com/us/app/pangolin-client/id6757407406
---
### Android
URL: https://pangolin.net/downloads/android
Requires Android 7.0 or later.
Primary action: Get it on Google Play
Store: https://play.google.com/store/apps/details?id=net.pangolin.Pangolin
---
## Legal
### Privacy policy
URL: https://pangolin.net/privacy
## **FOSSORIAL PRIVACY POLICY**
Last modified: June 9, 2026
Fossorial Inc. ("**Fossorial**," "**we**," "**us**," or "**our**") has prepared this Privacy Policy to explain (1) what personal information we collect, (2) how we use and share that information, and (3) your choices concerning our privacy and information practices.
### **Applicability of this Privacy Policy**
We provide self-hosted and cloud-based identity and secure access tools that let you safely share internal websites and applications over the internet... This Privacy Policy applies exclusively to personal information that we collect in connection with our public marketing websites (including [https://pangolin.net](https://pangolin.net)), our billing transactions via Stripe, and basic account registration metrics.
If you are an enterprise customer or business entity utilizing Fossorial to route infrastructure connections, this public Privacy Policy does not apply to the personal information, technical metadata, or network payloads that we process on your behalf as your service provider. Our processing of your secure production data is instead strictly governed by the Fossorial Data Protection Addendum (DPA) incorporated into our Terms of Service.
## **1. Personal Information We Collect**
### **1.1. Information You Provide to Us**
* **Account information:** When you create an account to use the Services, we collect information such as your email address, password, and other similar account registration information.
* **Business contact information:** If you are a representative of one of our actual or prospective customers, suppliers or business partners, we may collect personal information about you (such as your name, work email, place of work, role, and other contact details) when entering into an agreement with your company or otherwise the during the course of our relationship with your company.
* **Payment information** needed to complete your transactions with us, including name, payment card information, and billing information. This information is processed by our payment service provider(s), which may handle your payment information in accordance with its or their own privacy policy(ies). We do not have access to your full payment card information.
* **Feedback or correspondence,** such as information you provide when you contact us with questions, surveys, feedback, reviews, or otherwise correspond with us online.
* **Usage information,** such as information about how you use the Services and interact with us.
* **Marketing information,** such as your preferences for receiving communications about our activities, services, and publications, and details about how you engage with our communications.
* **Other information** that we may collect which is not specifically listed here, but which we will use in accordance with this Privacy Policy or as otherwise disclosed at the time of collection.
### **1.2. Information We Obtain from Third Parties**
We may obtain your personal information from other third parties, such as marketing partners, publicly-available sources and data providers, for the purposes of marketing products and services that may interest you, delivering personalized communications, and other similar activities. In addition, we may maintain pages on social media platforms, such as LinkedIn, Twitter, Instagram, and other third-party platforms. When you visit or interact with our pages on those platforms, the platform provider's privacy policy will apply to your interactions and their collection, use and processing of your personal information. You or the platforms may provide us with information through the platform, and we will treat such information in accordance with this Privacy Policy.
### **1.3. Automatic Data Collection**
We and our service providers may automatically log information about you, your computer or mobile device, and your interaction over time with our Services, our communications and other online services. This applies to visitors of our websites and may include:
* **Device data,** such as your computer's or mobile device's operating system type and version, manufacturer and model, browser type, screen resolution, RAM and disk size, CPU usage, device type (e.g., phone, tablet), IP address, unique identifiers (including identifiers used for advertising purposes), language settings, mobile device carrier, radio/network information (e.g., WiFi, LTE, 4G), and general location information such as city, state or geographic area.
* **Online activity data,** such as pages or screens you viewed, how long you spent on a page or screen, browsing history, navigation paths between pages or screens, information about your activity on a page or screen, access times, and duration of access, and whether you have opened our marketing emails or clicked links within them. We may use third party tools to assist with capturing online activity data.
* **Email Open/Click Information.** We may use pixels in our email campaigns that allow us to collect your email and IP address as well as the date and time you open an email or click on any links in the email that we may send to you.
We may use the following tools for automatic data collection:
* **Cookies,** which are text files that websites store on a visitor's device to uniquely identify the visitor's browser or to store information or settings in the browser for the purpose of helping you navigate between pages efficiently, remembering your preferences, enabling functionality, helping us understand user activity and patterns, and facilitating online advertising.
* **Local storage technologies,** like HTML5, that provide cookie-equivalent functionality but can store larger amounts of data, including on your device outside of your browser in connection with specific applications.
* **Web beacons,** also known as pixel tags or clear GIFs, which are used to demonstrate that a webpage or email was accessed or opened, or that certain content was viewed or clicked.
## **2. How We Use Your Personal Information**
### **2.1. To Operate Our Services**
Including to:
* Provide, operate, maintain, secure and improve our Services.
* Provide information about our Services.
* Communicate with you about our Services, including by sending you announcements, updates, security alerts, and support and administrative messages.
* Respond to your requests, questions and feedback.
### **2.2. To Improve, Monitor, Personalize, and Protect Our Services**
Which includes:
* Enriching your user experience and customise your relationship with us;
* Protecting the security of our Services;
* Preventing and detecting security threats, fraud or other criminal or malicious activities; and
* Administering content, promotion, sweepstakes, surveys, voting polls and other Website features.
### **2.3. Marketing and Advertising**
We may from time-to-time send you direct marketing communications as permitted by law, including, but not limited to, notifying you of special promotions, offers and events via email. Unless we're required to obtain your consent to send you marketing communications, we will rely on our legitimate business interests to market to you. You may opt out of our marketing communications as described in the "**Opt out of marketing communications**" section below.
### **2.4. For Research and Development**
We may use data for research and development purposes, including to analyze and improve our Services and our business. If personal information is included, we may create aggregated, de-identified, or other anonymous data from personal information we collect. We make personal information into anonymous data by removing information that makes the data personally identifiable to you. We may use this anonymous data and share it with third parties for our lawful business purposes, including to analyze and improve our Services and promote our business.
### **2.5. Compliance and Protection**
To comply with our legal obligations, we may use personal information to:
* Comply with applicable laws, lawful requests, and legal process, such as to respond to subpoenas or requests from government authorities.
* Protect our, your or others' rights, privacy, safety or property (including by making and defending legal claims).
* Audit our internal processes for compliance with legal and contractual requirements and internal policies.
* Enforce the terms and conditions that govern our Services.
* Prevent, identify, investigate and deter fraudulent, harmful, unauthorized, unethical or illegal activity, including cyberattacks and identity theft.
## **3. How We Share Your Personal Information**
* **Service providers.** We may share your personal information with third party companies and individuals that provide services on our behalf or help us operate our Services (such as lawyers, bankers, auditors, insurers, and providers that assist with hosting, analytics, email delivery, marketing, and database management).
* **Authorities and others.** We may disclose your personal information to law enforcement, government authorities, and private parties, as we believe in good faith to be necessary or appropriate for the compliance and protection purposes described above.
* **Business transfers.** We may sell, transfer or otherwise share some or all of our business or assets, including your personal information, in connection with a business transaction (or potential business transaction) such as a corporate divestiture, merger, consolidation, acquisition, reorganization or sale of assets, or in the event of bankruptcy or dissolution. In such a case, we will make reasonable efforts to require the recipient to honor this Privacy Policy.
* **Affiliates:** We may share personal information with our current and future affiliates, meaning an entity that controls, is controlled by, or is under common control with us. Our affiliates may use the personal information we share in a manner consistent with this Privacy Policy.
## **4. Your Choices**
### **4.1. Access or Update Your Information**
If you have registered for an account with us, you may review and update certain personal information in your account profile by logging into the account.
### **4.2. Opt Out of Marketing Communications**
You may opt out of marketing-related communications – both emails and texts – by following the opt-out or unsubscribe instructions in the communications you receive from us or by contacting us as provided in the "**How to contact us**" section below. You may continue to receive Services-related and other non-marketing communications.
### **4.3. Opt Out of Online Tracking**
There are a number of ways to opt out of having your online activity and device data collected through our Services, which we have summarized below:
* **Blocking cookies in your browser.** Most browsers let you remove or reject cookies, including cookies used for interest-based advertising. To do this, follow the instructions in your browser settings. Many browsers accept cookies by default until you change your settings. For more information about cookies, including how to see what cookies have been set on your device and how to manage and delete them, visit [www.allaboutcookies.org](http://www.allaboutcookies.org/).
* **Blocking advertising ID use in your mobile settings.** Your mobile device settings may provide functionality to limit use of the advertising ID associated with your mobile device for interest-based advertising purposes.
* **Using privacy plug-ins or browsers.** You can block our Services from setting cookies by using a browser with privacy features, like [Brave](https://brave.com/), or installing browser plugins like [Privacy Badger](https://privacybadger.org/), [DuckDuckGo](https://duckduckgo.com/), [Ghostery](https://www.ghostery.com/) or [uBlock Origin](https://ublock.org/en), and configuring them to block cookies/trackers.
* **Google Analytics.** We use Google Analytics to help us better understand how people engage with our Services by collecting information and creating reports about how users use our Services. For more information on Google Analytics, click [here](https://marketingplatform.google.com/about/analytics/). For more information about Google's privacy practices, click [here](https://www.google.com/policies/privacy/partners/). You can opt out of Google Analytics by downloading and installing the browser plug-in available at: [https://tools.google.com/dlpage/gaoptout](https://tools.google.com/dlpage/gaoptout).
* **Platform opt-outs.** The following advertising partners offer opt-out features that let you opt out of use of your information for interest-based advertising:
* [Google](https://adssettings.google.com/anonymous?hl=en)
* [Facebook](https://www.facebook.com/about/ads)
* [LinkedIn](https://www.linkedin.com/mypreferences/d/categories/ads)
* [Microsoft](https://account.microsoft.com/privacy/ad-settings/signedout)
* **Advertising industry opt-out tools.** You can also use these opt-out options to limit use of your information for interest-based advertising by participating companies:
* [Digital Advertising Alliance](https://optout.aboutads.info/?c=2&lang=EN)
* [Network Advertising Initiative](https://optout.networkadvertising.org/?c=1)
Note that because these opt-out mechanisms are specific to the device or browser on which they are exercised, you will need to opt out on every browser and device that you use.
### **4.4. Do Not Track**
Some Internet browsers may be configured to send "Do Not Track" signals to the online services that you visit. We currently do not respond to "Do Not Track" or similar signals. To find out more about "Do Not Track," please visit [http://www.allaboutdnt.com](http://www.allaboutdnt.com/).
## **5. Data Retention**
We may retain your personal information for as long as it is reasonably needed to maintain and expand our relationship and provide you with our Services; in order to comply with our legal and contractual obligations; or to protect ourselves from any potential disputes. To determine the appropriate retention period for personal information, we consider the amount, nature, and sensitivity of such information, the potential risk of harm from unauthorized use or disclosure of such information, the purposes for which we process it, and the applicable legal requirements.
## **6. Other Sites, Mobile Applications and Services**
Our Services may contain links to other websites, mobile applications, and other online services operated by third parties. These links are not an endorsement of, or representation that we are affiliated with, any third party. In addition, our content may be included on web pages or in mobile applications or online services that are not associated with us. We do not control third party websites, mobile applications or online services, and we are not responsible for their actions. Other websites and services follow different rules regarding the collection, use and sharing of your personal information. We encourage you to read the privacy policies of the other websites and mobile applications and online services you use.
## **7. Security Practices**
We use reasonable organizational, technical and administrative measures designed to protect against unauthorized access, misuse, loss, disclosure, alteration and destruction of personal information we maintain. Unfortunately, data transmission over the Internet cannot be guaranteed as completely secure. Therefore, while we strive to protect your personal information, we cannot guarantee the security of personal information. If we are required to notify you about a situation involving your data, we may do so by email or telephone to the extent permitted by law.
## **8. Children**
Our Services are not intended for children, and we do not collect personal information from them. We define "children" as anyone under 18 years old. If we learn we have collected or received personal information from a child without verification of parental consent, we will delete the information. If you believe we might have any information from or about a child, please contact us via the contract information noted below.
## **9. Changes to this Privacy Policy**
We reserve the right to modify this Privacy Policy at any time. If we make material changes to this Privacy Policy, we will notify you by updating the date of this Privacy Policy and posting it on our Services. We may also provide notification of changes in another way that we believe is reasonably likely to reach you, such as via e-mail (if you have an account where we have your contact information) or another manner through our Services.
Any modifications to this Privacy Policy will be effective upon our posting the new terms and/or upon implementation of the new changes on our Services (or as otherwise indicated at the time of posting). In all cases, your continued use of the Services after the posting of any modified Privacy Policy indicates your acceptance of the terms of the modified Privacy Policy.
## **10. How to Contact Us**
If you have any questions or concerns, you can reach us by email at [privacy@pangolin.net](mailto:privacy@pangolin.net).
---
### Terms of service
URL: https://pangolin.net/tos
# **FOSSORIAL TERMS OF SERVICE**
Last modified: June 9, 2026
Fossorial, Inc. (“**Fossorial**”, “**we**”, “**us**”, or “**our**”) has made these Terms of Service (the “**Agreement**”) available to explain the terms and conditions by which you may access and use (a) Fossorial’s tools and services made available through [https://pangolin.net/](https://pangolin.net/) and (b) other related products and services that link to this Agreement (collectively, the “**Services**”).
You must read this Agreement carefully as it governs your use of the Services. By accessing or using the Services, you signify that you have read, understand, and agree to be bound by this Agreement in its entirety. If you do not agree, you are not authorized to access or use of our Services and should not use our Services.
PLEASE READ THIS AGREEMENT CAREFULLY, AS THEY CONTAIN AN AGREEMENT TO ARBITRATE AND OTHER IMPORTANT INFORMATION REGARDING YOUR LEGAL RIGHTS, REMEDIES, AND OBLIGATIONS. THE AGREEMENT TO ARBITRATE REQUIRES (WITH LIMITED EXCEPTION) THAT YOU SUBMIT CLAIMS YOU HAVE AGAINST US TO BINDING AND FINAL ARBITRATION, AND FURTHER (1) YOU WILL ONLY BE PERMITTED TO PURSUE CLAIMS AGAINST FOSSORIAL ON AN INDIVIDUAL BASIS, NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY CLASS OR REPRESENTATIVE ACTION OR PROCEEDING, (2) YOU WILL ONLY BE PERMITTED TO SEEK RELIEF (INCLUDING MONETARY, INJUNCTIVE, AND DECLARATORY RELIEF) ON AN INDIVIDUAL BASIS, AND (3) YOU MAY NOT BE ABLE TO HAVE ANY CLAIMS YOU HAVE AGAINST US RESOLVED BY A JURY OR IN A COURT OF LAW.
### **Fossorial Services**
* **Our Services.** Fossorial provides self-hosted and cloud based tools that let you securely access and share internal websites and applications over the internet without opening ports or setting up a VPN. We are constantly improving the Services. You agree and acknowledge that the Services is subject to modification and change, including but not limited to how connections are managed and what features are available to you.
* **Registration.** In order to use certain portions of the Services, you must register an account by providing us with your name, email, and other information requested in our registration form. You agree to provide us with complete and accurate registration information. You may not attempt to impersonate another person in registration. If you are registering for our Services on behalf of an organization, you warrant that you are authorized to agree to this Agreement on their behalf. You agree to be responsible for the security of your account including all usernames, passwords, API tokens, OAuth credentials, and other access credentials associated with your account. You accept that you are solely responsible for all activities that take place through your account, and that failure to limit access to your devices or browser may permit unauthorized use by third-parties. Only one user may use the Services per registered account. Each user of the Services may only have one account. You agree to notify Fossorial promptly of any actual or suspected unauthorized use of your account. Fossorial reserves the right to suspend access to any account that Fossorial reasonably determines may have been accessed or used by an unauthorized third party and will provide immediate notice of such to you.
* **No Minors Permitted.** Our Services are not intended for minors under the age of 18. If you are a minor under the age of 18, please do not register for our Services or send any personal information to us. If you have reason to believe that a minor under the age of 18 is using our Services, please let us know immediately at [support@pangolin.net](mailto:support@pangolin.net) and we will seek to revoke access and delete any associated information as quickly as possible.
* **Additional Policies.** You agree and acknowledge that your use of the Services is subject to our Privacy Policy available at [https://pangolin.net/privacy](https://pangolin.net/privacy). Furthermore, if you are a business, enterprise, or organization utilizing the Services to handle or route data on behalf of your end users, you acknowledge and agree that our processing of such data is governed strictly by the Fossorial Data Protection Addendum (“**DPA**”), located at [https://pangolin.net/dpa](https://pangolin.net/dpa). The terms of the DPA are hereby incorporated by reference into, and form an essential, legally binding part of, this Agreement.
## **1. Usage Requirements**
### **1.1. Use of Services**
You may access, and we grant you a non-exclusive right to use, the Services in accordance with this Agreement. You will comply with this Agreement and all applicable laws when using the Services. We and our affiliates own all rights, title, and interest in and to the Services, including the underlying technology and intellectual property rights therein.
### **1.2. Content**
You retain ownership of all content, materials, documentations, and any other information you provide or use in conjunction with the Services (“**User Content**”). Subject to your compliance with this Agreement and to the extent Fossorial acquires any right in any User Content, Fossorial hereby assigns to you all its right, title and interest in and to your User Content. During the term of this Agreement, Fossorial may use your User Content as reasonably necessary to provide you with access to the Services. In addition, during and after the term of this Agreement, Fossorial may use your User Content to comply with applicable laws and enforce our policies. You are responsible for all User Content, including for ensuring that it does not violate any applicable law or this Agreement.
### **1.3. Feedback**
We appreciate feedback, comments, ideas, proposals and suggestions for improvements (collectively, “**Feedback**”). If you provide any Feedback to Fossorial, you hereby grant Fossorial the right to freely use such Feedback to maintain, improve, and enhance Fossorial’s current and future products, services and technologies without restriction or compensation to you.
### **1.4. Usage Data**
You agree that Fossorial will have the right to collect and analyze data and other information relating to the access, use, and performance of the Services (“**Usage Data**”), and Fossorial will be free (during and after the term of this Agreement) to use Usage Data in de-identified or aggregated form to maintain, improve, train, finetune, and enhance Fossorial’s current and future products, services and technologies. Examples of Usage Data include technical logs, metadata, telemetry data, and any other information about how you use and interact with the Services.
### **1.5. Services Restrictions**
You may not:
* **(i)** use the Services in a way that infringes, misappropriates or violates any person’s rights;
* **(ii)** reverse assemble, reverse compile, decompile, translate or otherwise attempt to discover the source code or underlying components of models, algorithms, and systems of the Services (except to the extent such restrictions are contrary to applicable law);
* **(iii)** use the Services to develop products and services that compete with Fossorial;
* **(iv)** use the Services for phishing, malware distribution, or other deceptive practices;
* **(v)** use any automated or programmatic method to extract data from the Services, including scraping, web harvesting, or web data extraction;
* **(vi)** send us any personal information of children under 13 or the applicable age of digital consent; or
* **(vii)** use the Services in violation of any applicable laws and regulations (including any export control laws). You will comply with any rate limits and other requirements in our documentation.
### **1.6. User Conduct**
You represent, warrant, and covenant that:
* **(i)** any User Content you transfer via the Services have been legally obtained and belong to you;
* **(ii)** you will not upload or create any User Content that contains gore, sexual abuse material or any content that exploits or promotes harm to any individual;
* **(iii)** you will not engage in any conduct that is or could be considered illegal, obscene, defamatory, threatening, intimidating, harassing, hateful or racially or ethnically offensive;
* **(iv)** you will not use the Services for any purpose not expressly authorized in this Agreement, including, but not limited to, any high-risk or regulated activities (such as military, medical, nuclear, or critical infrastructure operations);
* **(v)** you will not provide any false, inaccurate or misleading information while using the Services, or engage in any activity that operates to defraud Fossorial, other users of the Services, or any other person or entity;
* **(vi)** you will not create Fossorial authentication subdomains that include deceptive, infringing, or offensive terms, or impersonate third-party businesses, organizations, or individuals ;
* **(vii)** you will not interfere with or disrupt the Services or servers or networks connected to the Services, or disobey any requirements, procedures, policies, or regulations of networks connected to the Services;
* **(viii)** you will not impersonate any person or entity, or falsely state or otherwise misrepresent your affiliation with a person or entity;
* **(ix)** you will not infringe, misappropriate or violate any intellectual property, privacy, publicity or other proprietary rights of Fossorial or any third party;
* **(x)** you will not disguise your location through IP proxying or other methods; and
* **(xi)** you will not obtain or attempt to access or otherwise obtain any content or information through any means not intentionally made available or provided for through the Services, including attempting to avoid, bypass, remove, deactivate, impair, descramble or otherwise circumvent any technological measure implemented by us or any of our service providers or any other third party to protect the Services.
### **1.7. User Responsibility**
If you deploy any self-hosted components of the Services, you acknowledge and agree that you are solely responsible for the integration, deployment, configuration, operation, and security of such components. You assume full ownership, liability, and warranty obligations related to your deployment, including, without limitation, any system failures, data breaches, operational misconfigurations, or violations of applicable law arising from your use. You further acknowledge that you are responsible for:
* **(i)** all activity of your end users and their compliance with this Agreement;
* **(ii)** complying with all applicable laws and any relevant third-party terms of service, including providing clear and conspicuous notice to end users that you may monitor their traffic or activities through the Services;
* **(iii)** forwarding your end users’ DNS queries, web traffic, or internal traffic to Fossorial via valid forwarding mechanisms described in our documentation (e.g., the tunneling client, IPSec tunnels); and
* **(iv)** configuring and maintaining your third-party identity provider for use with the Services.
For any self-hosted deployments of the Software, Customer acknowledges that Fossorial does not host, store, or possess access to Customer's underlying network traffic, payloads, or interactive developer sessions. Consequently, the DPA shall apply strictly "as applicable" to the technical account telemetry, registration logs, and license validation metadata that physically transmit to Fossorial’s managed systems.
### **1.8. Confidentiality**
In connection with the Services, you may be given access to certain Confidential Information of Fossorial. You may use Confidential Information only as needed to use the Services as permitted under this Agreement. You may not disclose Confidential Information to any third party, and you will protect Confidential Information in the same manner that you protect your own confidential information of a similar nature, using at least reasonable care. “**Confidential Information**” means nonpublic information that Fossorial or its affiliates or third parties designate as confidential or should reasonably be considered confidential under the circumstances, including software, specifications, and other nonpublic business information. Confidential Information does not include information that:
* **(i)** is or becomes generally available to the public through no fault of yours
* **(ii)** you already possess without any confidentiality obligations when you received it under this Agreement
* **(iii)** is rightfully disclosed to you by a third party without any confidentiality obligations or
* **(iv)** you independently developed without using Confidential Information.
You may disclose Confidential Information when required by law or the valid order of a court or other governmental authority if you give reasonable prior written notice to Fossorial and use reasonable efforts to limit the scope of disclosure, including assisting us with challenging the disclosure requirement, in each case where possible.
### **1.9. Third Party Services**
To the extent you use any third party software, services, or other products in connection with your use of the Services (“**Third Party Services**”), any such Third Party Services are subject to their own terms, and we are not responsible for any such Third Party Service.
### **1.10. Security Obligations**
You are solely responsible for securing your self-hosted deployment of the Services. Fossorial disclaims all liability for any security incidents, data loss, or breaches resulting from your deployment, including any misconfigurations, failure to implement recommended security controls, or non-compliance with applicable legal or regulatory requirements.
## **2. Fees and Payments**
### **2.1. Fees and Billing**
To the extent the Services are made available to you for a subscription fee, you will pay all fees charged to your account (“**Fees**”) according to the prices and terms on the applicable pricing page, or as otherwise agreed between us in writing. We have the right to correct pricing errors or mistakes even if we have already issued an invoice or received payment. To pay the subscription fee, you may be required to select a payment plan and provide information regarding your credit card or other payment instrument. You represent and warrant to Fossorial that such information is true and that you are authorized to use the payment instrument. You will promptly update your account information with Fossorial or Stripe (as defined below), as applicable, of any changes (for example, a change in your billing address or credit card expiration date) that may occur. If your payment plan includes an ongoing subscription that is automatically renewed periodically, you hereby authorize Fossorial (through Stripe) to bill your payment instrument in advance on such periodic basis in accordance with the terms of the applicable payment plan until you terminate your account, and you further agree to pay any charges so incurred. If you dispute any charges you must let Fossorial know within sixty (60) days after the date that Fossorial charges you, or within such longer period of time as may be required under applicable law. Payments are nonrefundable except as provided in this Agreement. You may cancel your subscription online by emailing us at: [support@pangolin.net](mailto:support@pangolin.net).
### **2.2. Payment Processing**
Notwithstanding any amounts owed to Fossorial hereunder, FOSSORIAL DOES NOT PROCESS PAYMENT FOR ANY SERVICES. To facilitate payment for the Services via bank account, credit card, or debit card, we use Stripe, Inc. and its affiliates (“**Stripe**”), a third-party payment processor. These payment processing services are provided by Stripe and are subject to the Stripe terms and conditions and other policies available at [https://stripe.com/legal](https://stripe.com/legal) and Stripe’s Global Privacy Policy available at: [https://stripe.com/privacy](https://stripe.com/privacy) (collectively, the “**Stripe Agreements**”). By agreeing to this Agreement, users that use the payment functions of the Services also agree to be bound by the Stripe Agreements, as the same may be modified by Stripe from time to time. You hereby authorize Stripe to store and continue billing your specified payment method even after such payment method has expired, to avoid interruptions in payment for your use of the Services. Please contact Stripe for more information. Fossorial assumes no liability or responsibility for any payments you make through the Services.
### **2.3. Taxes**
Unless otherwise stated, Fees do not include federal, state, local, and foreign taxes, duties, and other similar assessments (“**Taxes**”). You are responsible for all Taxes associated with your purchase, excluding Taxes based on our net income, and we may invoice you for such Taxes. You agree to timely pay such Taxes and provide us with documentation showing the payment, or additional evidence that we may reasonably require. Fossorial uses the name and address in your account registration as the place of supply for tax purposes, so you must keep this information accurate and up-to-date.
### **2.4. Changes in Fees**
We may change our prices by posting notice to your account and/or to our website. Price increases will be effective 14 days after they are posted, except for increases made for legal reasons or increases made to any free or beta services, which will be effective immediately. Any price changes will apply to the Fees charged to your account immediately after the effective date of the changes.
### **2.5. Free Tier**
Fossorial may make available a free-tier of the Services. You may only use the free tier for non-commercial purposes only. In addition, you may not create more than one account to benefit from credits provided in the free tier of the Services. If we believe you are not using the free tier in good faith, we may charge you standard fees or stop providing access to the Services. Fossorial reserves the right to modify or discontinue your access to the free tier of the Services at any time without prior notice. Fossorial will not be liable for any damages or losses resulting from such modification or discontinuation.
## **3. Term and Termination**
### **3.1. Termination; Suspension**
This Agreement takes effect when you first use the Services and remain in effect until terminated. You may terminate this Agreement at any time for any reason by discontinuing the use of the Services. We may terminate this Agreement for any reason by providing you at least 30 days’ advance notice. We may terminate this Agreement immediately upon notice to you if you materially breach this Agreement (including any breach of Sections 2.7 and 2.8), if there are changes in relationships with third party technology providers outside of our control, or to comply with law or government requests. We may suspend your access to the Services, with or without notice, if you do not comply with this Agreement, if your use poses a security risk to us or any third party, or if we suspect that your use is fraudulent or could subject us or any third party to liability. Notwithstanding anything to the contrary in this Agreement or the incorporated DPA, Fossorial reserves the absolute right to monitor Customer's platform use during any Free Trial or Free Tier to prevent platform abuse. If Fossorial reasonably suspects an account is being used for illicit activities—including fraud, network scanning, malware deployment, or phishing—Fossorial may access, monitor, and audit account logs to the extent permitted by law, and the restrictive processing terms of the DPA shall not apply to such anti-abuse investigations.
### **3.2. Effect on Termination**
Upon termination, you will stop using the Services and you will promptly return or, if instructed by us, destroy any Confidential Information. The sections of this Agreement which by their nature should survive termination or expiration should survive, including but not limited to Sections 2.2, 2.5, 2.6, 2.7, 2.8, 4, and 5-8.
## **4. Proprietary Rights**
### **4.1. Services Content**
You acknowledge and agree that the Services may contain content, assets, or features made available by Fossorial or other Fossorial users (“**Services Content**”) that are protected by copyright, patent, trademark, trade secret, or other proprietary rights and laws. Except as expressly set forth herein, we reserve all right, title and interest to the Services Content.
### **4.2. Trademarks**
The Fossorial name and logos are trademarks and service marks of Fossorial (collectively the “**Fossorial Trademarks**”). Other company, product, and service names and logos used and displayed via the Services may be trademarks or service marks of their respective owners who may not endorse or be affiliated with or connected to Fossorial. This Agreement and the Services do not grant you any license or right to use any of Fossorial Trademarks, without our prior written permission.
### **4.3. Publicity**
You grant Fossorial a non-exclusive, royalty-free, worldwide, irrevocable (except as set forth herein), and fully paid-up license to use your name, trademarks, service marks, and logos in connection with the marketing, advertising, and promotion of the Services. This includes, without limitation, the right to identify you as a customer in Fossorial’s online and offline marketing materials, sales collateral, social media, and other business communications. You may revoke this license at any time by providing written notice to [support@pangolin.net](mailto:support@pangolin.net); upon receipt of such notice, Fossorial will cease new use of your branding and, within a commercially reasonable timeframe, remove existing references from Fossorial’s digital properties.
### **4.4. Copyright Complaints**
Fossorial respects the intellectual property of others, and we ask our users to do the same. If you believe that your work has been copied in a way that constitutes copyright infringement, or that your intellectual property rights have been otherwise violated, you should notify Fossorial of your infringement claim in accordance with the procedure set forth below.
Fossorial will process and investigate notices of alleged infringement and will take appropriate actions under the Digital Millennium Copyright Act (“**DMCA**”) and other applicable intellectual property laws with respect to any alleged or actual infringement. A notification of claimed copyright infringement should be emailed to Fossorial’s Copyright Agent at [email address] (Subject line: “DMCA Takedown Request”).
To be effective, the notification must be in writing and contain the following information:
* **a** physical or electronic signature of a person authorized to act on behalf of the owner of the copyright or other intellectual property interest that is allegedly infringed
* **identification** of the copyrighted work or other intellectual property that you claim has been infringed, or, if multiple copyrighted works or other intellectual property are covered by a single notification, a representative list of such works or other intellectual property
* **identification** of the content that is claimed to be infringing or to be the subject of infringing activity, and where the content that you claim is infringing is located within the Services, with enough detail that we may find it within the Services
* **your** address, telephone number, and email address
* **a** statement by you that you have a good faith belief that the disputed use is not authorized by the copyright or intellectual property owner, its agent, or the law and
* **a** statement by you that the information in your notice is accurate and, under penalty of perjury, that you are the copyright or intellectual property owner or are authorized to act on the behalf of the owner of the copyright or intellectual property that is allegedly infringed.
### **4.5. Counter-Notice**
If you believe that your User Content that was removed (or to which access was disabled) is not infringing, or that you have the authorization from the copyright owner, the copyright owner’s agent, or pursuant to the law, to upload and use the content in your User Content, you may send a written counter-notice containing the following information to the Copyright Agent:
* **your** physical or electronic signature
* **identification** of the content that has been removed or to which access has been disabled and the location at which the content appeared before it was removed or disabled
* **a** statement by you, made under penalty of perjury, that you have a good faith belief that the content was removed or disabled as a result of mistake or a misidentification of the content to be removed or disabled and
* **your** name, address, telephone number, and email address, a statement that you consent to the jurisdiction of the federal court located within the Northern District of California and a statement that you will accept service of process from the person who provided notification of the alleged infringement.
If a counter-notice is received by the Copyright Agent, Fossorial will send a copy of the counter-notice to the original complaining party informing them that Fossorial may replace the removed content or cease disabling it within ten (10) business days. Unless the owner of the applicable copyrighted work or other intellectual property files an action seeking a court order against Fossorial or the user, the removed content may be replaced, or access to it restored, within ten (10) to fourteen (14) business days or more after receipt of the counter-notice, at our sole discretion.
### **4.6. Repeat Infringer Policy**
In accordance with the DMCA and other applicable law, Fossorial has adopted a policy of terminating, in appropriate circumstances and at Fossorial’s sole discretion, the accounts of users who are deemed to be repeat infringers. Fossorial may also at its sole discretion limit access to the Services and/or terminate the accounts of any users who infringe any intellectual property rights of others, whether or not there is any repeat infringement.
## **5. Indemnification Disclaimer Limitations on Liability**
### **5.1. Indemnity**
You agree to hold harmless, release, defend, and indemnify us and our officers, directors, employees, contractors, agents, affiliates, and subsidiaries from and against all claims, damages, obligations, losses, liabilities, costs, and expenses arising from: (a) your access to or use of our Services (including any User Content) or (b) your violation of any term or condition of this Agreement, the right of any third party, or any other applicable law, rule, or regulation.
### **5.2. Disclaimer**
We plan to continue to develop and improve Fossorial, but we make no guarantees or promises about how it operates or that it will function as intended, and your use is at your own risk. THE SERVICES ARE PROVIDED “AS IS.” EXCEPT TO THE EXTENT PROHIBITED BY LAW, WE AND OUR AFFILIATES AND LICENSORS MAKE NO WARRANTIES (EXPRESS, IMPLIED, STATUTORY OR OTHERWISE) WITH RESPECT TO THE SERVICES, AND DISCLAIM ALL WARRANTIES INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, SATISFACTORY QUALITY, NON-INFRINGEMENT, AND QUIET ENJOYMENT, AND ANY WARRANTIES ARISING OUT OF ANY COURSE OF DEALING OR TRADE USAGE. WE DO NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED, ACCURATE OR ERROR FREE, OR THAT ANY USER CONTENT WILL BE SECURE OR NOT LOST OR ALTERED.
### **5.3. Limitations of Liability**
UNDER NO CIRCUMSTANCES SHALL WE OR ANY OF OUR OFFICERS, DIRECTORS, EMPLOYEES, CONTRACTORS, AGENTS, AFFILIATES, OR SUBSIDIARIES BE LIABLE TO YOU FOR ANY INDIRECT, PUNITIVE, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR EXEMPLARY DAMAGES, INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF PROFITS, GOODWILL, USE, DATA, OR OTHER INTANGIBLE PROPERTY, ARISING OUT OF OR RELATING TO ANY ACCESS OR USE OF OR INABILITY TO ACCESS OR USE OF THE SERVICES, NOR WILL WE BE RESPONSIBLE FOR ANY DAMAGE, LOSS, OR INJURY RESULTING FROM HACKING, TAMPERING, OR OTHER UNAUTHORIZED ACCESS OR USE OF OUR SERVICES OR THE INFORMATION CONTAINED WITHIN IT, WHETHER SUCH DAMAGES ARE BASED IN CONTRACT, TORT, NEGLIGENCE, STRICT LIABILITY, OR OTHERWISE, ARISING OUT OF OR IN CONNECTION WITH AUTHORIZED OR UNAUTHORIZED USE OF OUR SERVICES.
SOME JURISDICTIONS DO NOT ALLOW THE LIMITATION OF LIABILITY FOR PERSONAL INJURY, OR OF INCIDENTAL OR CONSEQUENTIAL DAMAGES, SO THIS LIMITATION MAY NOT APPLY TO YOU. IN NO EVENT SHALL OUR TOTAL LIABILITY TO YOU FOR ALL DAMAGES (OTHER THAN AS MAY BE REQUIRED BY APPLICABLE LAW IN CASES INVOLVING PERSONAL INJURY) EXCEED IN THE AGGREGATE (A) THE AMOUNTS YOU HAVE PAID US TO US IN THE SIX (6) MONTHS PRECEDING THE DATE OF THE CLAIM OR (B) ONE HUNDRED U.S. DOLLARS ($100.00 USD) OR ITS EQUIVALENT IN THE LOCAL CURRENCY OF THE APPLICABLE JURISDICTION.
THE FOREGOING LIMITATIONS WILL NOT APPLY TO THE EXTENT PROHIBITED BY LAW.
## **6. Dispute Resolution By Binding Arbitration**
### **6.1. Agreement to Arbitrate**
This Dispute Resolution by Binding Arbitration section is referred to in this Agreement as the “**Arbitration Agreement**.” You agree that any and all disputes or claims that have arisen or may arise between you and Fossorial, whether arising out of or relating to this Agreement (including any alleged breach thereof), the Services, and any aspect of the relationship or transactions between us, shall be resolved exclusively through final and binding arbitration, rather than a court, in accordance with the terms of this Arbitration Agreement, except that you may assert individual claims in small claims court, if your claims qualify. Further, this Arbitration Agreement does not preclude you from bringing issues to the attention of federal, state, or local agencies, and such agencies can, if the law allows, seek relief against us on your behalf. You agree that, by entering into this Agreement, you and Fossorial are each waiving the right to a trial by jury or to participate in a class action. Your rights will be determined by a neutral arbitrator, not a judge or jury. The Federal Arbitration Act governs the interpretation and enforcement of this Arbitration Agreement.
### **6.2. Prohibition of Class and Representative Actions and Non-Individualized Relief**
YOU AND FOSSORIAL AGREE THAT EACH OF US MAY BRING CLAIMS AGAINST THE OTHER ONLY ON AN INDIVIDUAL BASIS AND NOT AS A PLAINTIFF OR CLASS MEMBER IN ANY PURPORTED CLASS OR REPRESENTATIVE ACTION OR PROCEEDING. UNLESS BOTH YOU AND FOSSORIAL AGREE OTHERWISE, THE ARBITRATOR MAY NOT CONSOLIDATE OR JOIN MORE THAN ONE PERSON’S OR PARTY’S CLAIMS AND MAY NOT OTHERWISE PRESIDE OVER ANY FORM OF A CONSOLIDATED, REPRESENTATIVE, OR CLASS PROCEEDING. ALSO, THE ARBITRATOR MAY AWARD RELIEF (INCLUDING MONETARY, INJUNCTIVE, AND DECLARATORY RELIEF) ONLY IN FAVOR OF THE INDIVIDUAL PARTY SEEKING RELIEF AND ONLY TO THE EXTENT NECESSARY TO PROVIDE RELIEF NECESSITATED BY THAT PARTY’S INDIVIDUAL CLAIM(S), EXCEPT THAT YOU MAY PURSUE A CLAIM FOR AND THE ARBITRATOR MAY AWARD PUBLIC INJUNCTIVE RELIEF UNDER APPLICABLE LAW TO THE EXTENT REQUIRED FOR THE ENFORCEABILITY OF THIS PROVISION.
### **6.3. Pre-Arbitration Dispute Resolution**
Fossorial is always interested in resolving disputes amicably and efficiently, and most user concerns can be resolved quickly and to the user’s satisfaction by emailing support at [support@pangolin.net](mailto:support@pangolin.net). If such efforts prove unsuccessful, a party who intends to seek arbitration must first send to the other, by certified mail, a written Notice of Dispute (“**Notice**”). The Notice to Fossorial should be sent to 169 Madison Ave, STE 81373, New York, NY 10016, United States (“**Notice Address**”). The Notice must (i) describe the nature and basis of the claim or dispute and (ii) set forth the specific relief sought. If Fossorial and you do not resolve the claim within sixty (60) calendar days after the Notice is received, you or Fossorial may commence an arbitration proceeding. During the arbitration, the amount of any settlement offer made by Fossorial or you shall not be disclosed to the arbitrator until after the arbitrator determines the amount, if any, to which you or Fossorial is entitled.
### **6.4. Arbitration Procedures**
To begin an arbitration proceeding, you must send a letter requesting arbitration and describing your dispute or claim or request for relief to the address set forth in Section 7.3. The arbitration will be conducted by JAMS, an established alternative dispute resolution provider. Disputes involving claims, counterclaims, or request for relief under $250,000, not inclusive of attorneys’ fees and interest, shall be subject to JAMS’s most current version of the Streamlined Arbitration Rules and procedures available at [http://www.jamsadr.com/rules-streamlined-arbitration/](http://www.jamsadr.com/rules-streamlined-arbitration/); all other disputes shall be subject to JAMS’s most current version of the Comprehensive Arbitration Rules and Procedures, available at [http://www.jamsadr.com/rules-comprehensive-arbitration/](http://www.jamsadr.com/rules-comprehensive-arbitration/). JAMS’s rules are also available at [www.jamsadr.com](http://www.jamsadr.com) or by calling JAMS at 800-352-5267. If JAMS is not available to arbitrate, the parties will select an alternative arbitral forum. If the arbitrator finds that you cannot afford to pay JAMS’s filing, administrative, hearing and/or other fees and cannot obtain a waiver from JAMS, Fossorial will pay them for you. In addition, Fossorial will reimburse all such JAMS’s filing, administrative, hearing and/or other fees for disputes, claims, or requests for relief totaling less than $10,000 unless the arbitrator determines the claims are frivolous. You may choose to have the arbitration conducted by telephone, based on written submissions, or in person in the county where you live or at another mutually agreed location. Any judgment on the award rendered by the arbitrator may be entered in any court of competent jurisdiction.
### **6.5. Authority of Arbitrator**
The arbitrator shall have exclusive authority to (a) determine the scope and enforceability of this Arbitration Agreement and (b) resolve any dispute related to the interpretation, applicability, enforceability or formation of this Arbitration Agreement including, but not limited to, any assertion that all or any part of this Arbitration Agreement is void or voidable. The arbitration will decide the rights and liabilities, if any, of you and Fossorial. The arbitration proceeding will not be consolidated with any other matters or joined with any other cases or parties. The arbitrator shall have the authority to grant motions dispositive of all or part of any claim. The arbitrator shall have the authority to award monetary damages and to grant any non-monetary remedy or relief available to an individual under applicable law, the arbitral forum’s rules, and this Agreement (including the Arbitration Agreement). The arbitrator shall issue a written award and statement of decision describing the essential findings and conclusions on which the award is based, including the calculation of any damages awarded. The arbitrator has the same authority to award relief on an individual basis that a judge in a court of law would have. The award of the arbitrator is final and binding upon you and us.
### **6.6. Batch Arbitration**
If seventy-five (75) or more claimants represented by the same or similar counsel file demands for arbitration raising substantially similar disputes within 90 days of each other, then you and Fossorial agree that JAMS will administer them in batches of up to seventy-five (75) claimants each (“**Batch**”), unless there are less than seventy-five (75) claimants in total or after batching, which will comprise a single Batch. JAMS will administer each Batch as a single consolidated arbitration with one arbitrator, one set of arbitration fees, and one hearing held by videoconference or in a location decided by the arbitrator for each Batch in accordance with the JAMS Mass Arbitration Rules. If any part of this section is found to be invalid or unenforceable as to a particular claimant or Batch, it will be severed and arbitrated in individual proceedings.
### **6.7. Confidentiality**
All aspects of the arbitration proceeding, and any ruling, decision, or award by the arbitrator, will be strictly confidential for the benefit of all parties.
### **6.8. Severability**
If a court or the arbitrator decides that any term or provision of this Arbitration Agreement (other than Section 8.2 above) is invalid or unenforceable, the parties agree to replace such term or provision with a term or provision that is valid and enforceable and that comes closest to expressing the intention of the invalid or unenforceable term or provision, and this Arbitration Agreement shall be enforceable as so modified. If a court or the arbitrator decides that any of the provisions of Section 8.2 are invalid or unenforceable, then the entirety of this Arbitration Agreement shall be null and void, unless such provisions are deemed to be invalid or unenforceable solely with respect to claims for public injunctive relief. The remainder of this Agreement will continue to apply.
### **6.9. Future Changes to Arbitration Agreement**
Notwithstanding any provision in this Agreement to the contrary, Fossorial agrees that if it makes any future change to this Arbitration Agreement (other than a change to the Notice Address) while you are a user of the Services, you may reject any such change by sending Fossorial written notice within thirty (30) calendar days of the change to the Notice Address provided above. By rejecting any future change, you are agreeing that you will arbitrate any dispute between us in accordance with the language of this Arbitration Agreement as of the date you first accepted this Agreement (or accepted any subsequent changes to this Agreement).
## **7. Miscellaneous**
### **7.1. Entire Agreement**
These terms constitute the entire agreement between you and us with respect to the subject matter hereof. This Agreement supersedes any and all prior or contemporaneous written and oral agreements, communications and other understandings (if any) relating to the subject matter of the terms.
### **7.2. Assignment**
You may not assign or transfer this Agreement, by operation of law or otherwise, without our prior written consent. Any attempt by you to assign or transfer this Agreement without our prior written consent shall be null and void. We may freely assign or transfer this Agreement. Subject to the foregoing, this Agreement will bind and inure to the benefit of the parties, their successors and permitted assigns.
### **7.3. Notice**
We may provide any notice to you under this Agreement using commercially reasonable means, including using public communication channels. Notices we provide by using public communication channels will be effective upon posting.
### **7.4. Modifications**
We may amend this Agreement from time to time by posting a revised version on the website, or if an update materially adversely affects your rights or obligations under this Agreement we will provide notice to you either by emailing the email associated with your account or providing an in-product notification. Those changes will become effective no sooner than 14 days after we notify you. All other changes will be effective immediately. Your continued use of the Services after any change means you agree to such change.
### **7.5. Equitable Remedies**
You acknowledge that if you violate or breach this Agreement, it may cause irreparable harm to Fossorial, and Fossorial shall have the right to seek injunctive relief against you in addition to any other legal remedies.
### **7.6. Severability**
If any provision of this Agreement shall be determined to be invalid or unenforceable under any rule, law, or regulation of any local, state, or federal government agency, such provision will be changed and interpreted to accomplish the objectives of the provision to the greatest extent possible under any applicable law and the validity or enforceability of any other provision of this Agreement shall not be affected.
### **7.7. Special Notice for International Use Export Controls**
Fossorial is headquartered in the United States. Whether inside or outside of the United States, you are solely responsible for ensuring compliance with the laws of your specific jurisdiction. Portions of the Services, the Mobile Apps and the transmission of applicable data, if any, is subject to United States export controls. No portion of the Services may be downloaded or otherwise exported or re-exported in violation of U.S. export laws. Downloading, accessing or using the Services is at your sole risk.
### **7.8. Governing Law**
This Agreement will be governed by the laws of the State of California without regard to its conflict of law provisions. With respect to any disputes or claims not subject to arbitration, as set forth below, you and Fossorial agree to submit to the personal and exclusive jurisdiction of the state and federal courts located within San Francisco, CA. The failure of Fossorial to exercise or enforce any right or provision of this Agreement will not constitute a waiver of such right or provision. If any provision of this Agreement is found by a court of competent jurisdiction to be invalid, the parties nevertheless agree that the court should endeavor to give effect to the parties’ intentions as reflected in the provision, and the other provisions of this Agreement remain in full force and effect.
---
### Data processing addendum
URL: https://pangolin.net/dpa
## **FOSSORIAL DATA PROCESSING ADDENDUM (CUSTOMER AGREEMENT)**
Last modified: June 9, 2026
This Data Protection Addendum (“DPA”) is incorporated into and forms part of the master agreement, terms of service, sales order, or other principal written or electronic agreement (the “Agreement”) by and between Fossorial, Inc. (“Fossorial,” “we,” “us,” or “our”) and the legal entity using the self-hosted or cloud-based identity, tunneling, and secure access software and services (the “Services”) as identified in the Agreement (“Customer”).
Fossorial and Customer are each referred to as a “Party” and collectively as the “Parties.” Customer enters into this DPA on behalf of itself and, to the extent applicable, its authorized Affiliates.
### **Applicability of this DPA**
This DPA applies to and takes strict precedence over the underlying Agreement to the extent of any operational or legal conflict concerning the Processing of Personal Data. Capitalized terms not explicitly defined herein shall carry the meanings assigned to them in the Agreement or applicable Data Protection Laws.
## **1. Definitions**
* **“Affiliate”** means any entity that directly or indirectly controls, is controlled by, or is under common control with a party to this DPA, where “control” refers to the direct or indirect ownership or management of more than fifty percent (50%) of the voting or equity interests of the subject entity.
* **“Contractual Documents”** means the master agreement between Fossorial and Customer together with any associated sales orders, statements of work, or service specifications.
* **“Data Protection Laws”** means all applicable regional, national, and state laws, regulations, and statutory requirements in any global jurisdiction relating to privacy, data protection, data security, data residency, or data breach notification, including, without limitation:
* The European Union General Data Protection Regulation (Regulation (EU) 2016/679) (**“GDPR”**);
* The United Kingdom Data Protection Act 2018 and the GDPR as incorporated into UK law (**“UK GDPR”**);
* The Swiss Federal Act on Data Protection (**“FADP”**);
* The California Consumer Privacy Act (Cal. Civ. Code § 1798.100 et seq.), as amended by the California Privacy Rights Act of 2020 (**“CCPA/CPRA”**); and
* Any omnibus privacy enactments passed by other U.S. states (together with the CCPA, **“U.S. Privacy Laws”**).
* **“Data Subject”** means an identified or identifiable natural person to whom Personal Data relates, and includes the term “consumer” as specified under U.S. Privacy Laws.
* **“EU SCCs”** means the Standard Contractual Clauses issued pursuant to Commission Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council.
* **“Personal Data”** means any personal data, personal information, or personally identifiable information (as defined by applicable Data Protection Laws) that Customer or its authorized end users submit, transmit, store, or route through the platform infrastructure, software, or SaaS Services.
* **“Process” or “Processing”** means any operation or set of operations performed on Personal Data or sets of Personal Data, whether or not by automated means, such as collection, recording, organization, structuring, storage, hosting, retrieval, execution, transmission, routing, dissemination, alignment, restriction, erasure, or destruction.
* **“Security Breach”** means any confirmed accidental, unauthorized, or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Personal Data processed on Fossorial’s managed infrastructure.
**Note:** For the avoidance of doubt, Security Breaches do not include unsuccessful infrastructure attempts or activities that do not compromise the security or integrity of Personal Data, including unsuccessful log-in attempts, ping sweeps, port scans, broadcast storms, denial-of-service attacks, or other routine network edge security events.
* **“Subprocessor”** means any third-party corporate entity or infrastructure provider engaged by Fossorial to assist in Processing Personal Data under the strict terms of this DPA.
* **“UK Addendum”** means the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the United Kingdom Information Commissioner’s Office (ICO).
* **Core Privacy Roles:** The terms **“Business,”** **“Controller,”** **“Processor,”** and **“Service Provider”** shall carry the definitions established within applicable Data Protection Laws. For interpretation purposes, “Controller” is deemed to include a “Business” and “Processor” is deemed to include a “Service Provider.”
## **2. Roles, Scope, and Purposes of Processing**
### **2.1. Dual-Role Applicability**
The Parties acknowledge and agree that with respect to the Processing of Customer’s Personal Data via the identity platform, secure access tunnels, or cloud routing components of the Services:
* To the extent that Customer acts as the direct Controller of the data, Fossorial is its Processor.
* To the extent that Customer acts as a Processor of Personal Data on behalf of a third party, Fossorial operates as its Subprocessor.
### **2.2. Trial and Free Tier Abuse Exception**
As set forth in the underlying Agreement, Fossorial explicitly retains the right to monitor Customer's use of the Software or SaaS Services during any Free Trial or Free Tier to verify operational compliance with platform resource usage and anti-malware laws. If Fossorial reasonably suspects that Customer's account or secure tunnels are being utilized for unlawful activities—including but not limited to financial fraud, phishing, ransomware command-and-control infrastructure, or the dissemination of malicious binaries—Fossorial may access, monitor, audit, and review Customer's account metadata and activities. This DPA does not apply to Personal Data processed for these platform abuse monitoring purposes.
### **2.3. Documented Instructions**
Fossorial will Process Personal Data solely:
1. To execute its technical obligations to Customer under the underlying Agreement;
2. On Customer’s explicit documented instructions;
3. In compliance with Data Protection Laws; and
4. For the technical purposes set forth in Exhibit A of this DPA.
### **2.4. Explicit Service Provider Restrictions**
Fossorial certifiably warrants that it will:
* **i.** Not retain, use, or disclose Personal Data outside of the direct business relationship between Customer and Fossorial, or for any commercial purpose other than the specific infrastructure purposes specified in this DPA and the Agreement.
* **ii.** Not “sell” or “share” any Personal Data, as such terms are defined across applicable U.S. Privacy Laws, to any third party for behavioral advertising or monetization.
* **iii.** Not attempt to re-identify any pseudonymized, anonymized, or aggregated telemetry or technical logs derived from the operations of the Services without Customer’s express prior written permission.
* **iv.** Comply with all applicable restrictions under Data Protection Laws on combining Personal Data received from Customer with data collected from other customer interactions or separate commercial services.
* **v.** Comply with all applicable provisions of the CCPA/CPRA, providing the baseline level of privacy protection required by the CCPA/CPRA to all covered data.
### **2.5. Customer Warranties**
Customer is solely responsible for fulfilling its statutory obligations as a Controller under Data Protection Laws. Customer represents and warrants that it has executed all legally mandatory requirements (including providing clear privacy notices and obtaining active user consents) to ensure that its transmission of Personal Data through Fossorial's secure tunneling mechanisms is entirely compliant with law. Customer will not instruct Fossorial to process data in a manner that violates privacy regulations. Fossorial will immediately inform Customer if, in its professional opinion, an instruction from Customer infringes Data Protection Laws.
## **3. Personnel Confidentiality and Technical Security**
### **3.1. Authorized Personnel**
Fossorial will ensure that all employees, contractors, and engineering personnel authorized to have access to or handle the Personal Data have committed themselves to strict contractual confidentiality or are bound by an appropriate statutory obligation of confidentiality.
### **3.2. Technical and Organizational Measures**
Fossorial will implement, maintain, and test appropriate administrative, technical, physical, and organizational security controls designed to protect Personal Data against a Security Breach, as detailed in Exhibit B of this DPA.
### **3.3. Regulatory Inquiries and Data Subject Requests**
Fossorial will promptly notify Customer if it receives:
* **(i)** Any Data Subject requests exercising rights under Data Protection Laws (such as deletion or access rights); or
* **(ii)** Any formal regulatory or government inquiries regarding the data processed on Customer's behalf.
Unless compelled by law, Fossorial will not respond directly to such requests but will instead await written instructions from Customer on how to assist.
## **4. Security Breach Notification and Mitigation**
### **4.1. Notice Timeline**
Fossorial will notify Customer of any confirmed Security Breach without undue delay, and where feasible, within **72 hours** of confirming the event. Notice will be sent to the administrative or legal contact specified in the Customer's Account.
### **4.2. Mitigation and Assistance**
Fossorial will immediately take steps to mitigate the effects of any Security Breach and minimize security risks to Data Subjects. Fossorial will assist Customer in satisfying its statutory breach notification obligations by providing the following data points as they become known:
* **i.** The nature of the Security Breach, including how it occurred and the approximate categories/number of Data Subjects and records impacted;
* **ii.** The anticipated operational or security consequences of the breach; and
* **iii.** The exact remedial measures taken or planned to be taken by Fossorial.
## **5. Subprocessors**
### **5.1. General Authorization**
Customer grants Fossorial general written authorization to engage infrastructure Subprocessors (such as primary cloud hosting services, logging endpoints, or database infrastructure) to maintain the platform.
### **5.2. Notice of Updates**
An up-to-date list of authorized Subprocessors is maintained at [https://trust.pangolin.net/subprocessors](https://trust.pangolin.net/subprocessors). Customer acknowledges and agrees that it is Customer's sole responsibility to check this URL periodically for updates. Fossorial will post any new Subprocessor additions to this page at least **10 days** before authorizing the Subprocessor to process any Personal Data.
Fossorial may provide a mechanism on that page (such as an email list signup or RSS feed) where Customer can subscribe to receive automated alerts regarding changes, but the lack of a direct email from Fossorial shall not invalidate the notice.
### **5.3. Objection Mechanics**
Customer may reasonably object to a new Subprocessor within **10 days** of the addition being posted to the URL specified in Section 5.2, provided such objection is made on documented, reasonable data protection grounds. Upon receipt of a valid written objection, the Parties will cooperate in good faith to discuss alternative configurations. If the Parties cannot reach a mutually agreeable solution within **30 days**, Customer’s sole and exclusive remedy is to terminate the specific portion of the Services involving the objected-to Subprocessor upon written notice to Fossorial.
### **5.4. Downstream Agreements**
Fossorial will execute a legally binding agreement with each Subprocessor containing data protection obligations at least as restrictive as those imposed on Fossorial within this DPA.
## **6. International Data Transfers**
### **6.1. Cross-Border Compliance**
Fossorial will not engage in cross-border Processing or transmit Personal Data out of the EEA, United Kingdom, or Switzerland to a country without an adequacy decision unless it complies strictly with valid transfer mechanisms.
### **6.2. Incorporation of EU SCCs**
For data transfers subject to the GDPR, the Parties hereby agree that by executing the underlying Agreement, they are deemed to have executed and signed the EU Standard Contractual Clauses (SCCs), which are fully incorporated by reference into this DPA. The clauses are completed as follows:
* **i.** Module 2 (Controller-to-Processor) applies where Customer is a Controller and Fossorial is a Processor.
* **ii.** Module 3 (Processor-to-Processor) applies where Customer is a Processor and Fossorial is a Subprocessor.
* **iii.** Clause 7 (Docking Clause) is excluded.
* **iv.** Clause 9 (Use of sub-processors): The Parties select Option 2 (General written authorization) as governed by Section 5 of this DPA.
* **v.** Clause 11 (Redress): The optional language regarding independent dispute resolution is excluded.
* **vi.** Clause 17 (Governing Law): The Parties select the law of Ireland.
* **vii.** Clause 18 (Choice of Forum): The Parties select the courts of Ireland.
### **6.3. UK Data Transfers**
For transfers of Personal Data subject to the UK GDPR, the Parties are deemed to have executed the UK Addendum issued by the ICO. The information required within Tables 1 through 4 of the UK Addendum is mapped directly to the details specified in Section 6.2 and Exhibit A of this DPA. Either Party may terminate the UK Addendum in accordance with Section 19 of its standard terms.
### **6.4. Swiss Data Transfers**
For transfers subject to the Swiss FADP, the EU SCCs shall apply with the following adjustments:
* **i.** References to the GDPR are understood to apply to the FADP.
* **ii.** The term “Member State” shall not be interpreted to prevent Swiss Data Subjects from seeking redress or filing claims in their place of habitual residence (Switzerland).
* **iii.** The relevant supervisory authority is the Swiss Federal Data Protection and Information Commissioner.
## **7. Audit Rights**
### **7.1. Independent Audits**
Fossorial utilizes independent, third-party external auditors to perform annual security audits of its systems. These evaluations result in the generation of a confidential audit report (such as a SOC 2 Type II, ISO 27001 certificate, or equivalent standard).
### **7.2. Review Rights**
Upon reasonable written request, and no more than once per **12-month** calendar period, Fossorial will make available to Customer a copy of its most recent third-party security verification report under strict non-disclosure controls.
To the extent that this report does not provide sufficient detail to satisfy Customer's regulatory audit requirements under Data Protection Laws, Customer may submit a list of specific compliance queries, and Fossorial will provide written answers or technical documentation to demonstrate adherence to this DPA. Customer agrees that these procedures fully satisfy its statutory audit rights.
## **8. Return or Destruction of Personal Data**
### **8.1. Post-Termination Deletion**
Within **60 days** of Customer’s written request or the formal termination of the underlying Agreement, Fossorial will securely delete or return all Personal Data processed within its systems.
### **8.2. Archival Retention**
Customer acknowledges and accepts that Fossorial may retain structural fragments of Personal Data as necessary within system backups and archival media. Fossorial will securely isolate such media and delete the associated data in accordance with its routine archival rotation cycles. Fossorial will maintain the full legal protections of this DPA for any data retained until destruction is finalized.
## **9. Indemnification and Limitation of Liability**
### **9.1. Liability Cap Alignment**
To the maximum extent permitted under applicable Data Protection Laws, any liability, indemnification claims, or structural losses arising out of a breach of this DPA or a Security Breach shall be subject to the standard Limitations of Liability and commercial liability caps established within the underlying main Agreement.
## **10. Survival**
### **10.1. Indefinite Protection**
The commercial and technical provisions of this DPA shall survive the expiration or formal termination of the underlying Agreement for as long as Fossorial or its downstream Subprocessors retain or maintain any operational access to Customer's Personal Data.
## **EXHIBIT A: DETAILS OF PROCESSING AND TRANSFER**
### **A. List of Parties**
* **Data Exporter:** Customer (as identified in the main Agreement, Sales Order, or corporate registration).
* *Role:* Controller (or Business).
* **Data Importer:** Fossorial, Inc., 169 Madison Ave, STE 81373, New York, NY 10016, United States.
* *Role:* Processor (or Service Provider).
### **B. Description of Processing and Transfer**
* **Categories of Data Subjects:** Customer’s internal employees, software developers, security teams, network administrators, system architects, and authorized corporate end users who utilize the identity routing or tunneling platforms.
* **Categories of Personal Data:** Operational network metadata, user login records, secure connection email addresses, source and destination IP addresses, platform authentication tokens, cryptographic public keys, SSH/Kubernetes technical connection logs, configuration file schemas, and telemetry logs routing through secure access tunnels.
* **Sensitive Data:** None.
* **Frequency of Transfer:** Continuous and on-demand for the full duration of the underlying Agreement.
* **Nature and Purpose of Processing:** The Data Importer will process the data to provide secure access routing, manage zero-trust network tunnels, authenticate end users to internal infrastructure components, prevent network performance anomalies, and fulfill its engineering delivery obligations under the main Agreement.
* **Retention Period:** Personal Data is maintained for the operational duration of the Customer’s account, or as modified by explicit retention configurations, and is deleted within **60 days** following platform termination.
### **C. Competent Supervisory Authority**
The competent supervisory authority is the **Irish Data Protection Commission** (for GDPR-related transfers).
## **EXHIBIT B: TECHNICAL AND ORGANIZATIONAL MEASURES (TOMs)**
Fossorial implements the following industry-standard technical, organizational, and physical security measures to guarantee the safety and isolation of processed data:
* **1. Transport Layer Encryption:** All customer session data and tunnel routing traffic are forcefully encrypted in transit using industry-standard TLS 1.3 or SSHv2 protocols over public networks.
* **2. Access Control Architecture:** Production system clusters, data routing logs, and configuration interfaces are locked down using zero-trust access profiles. Administrative access is granted purely on the principle of least privilege and requires hardware-backed multi-factor authentication (MFA).
* **3. Continuous Infrastructure Monitoring:** Security logging agents actively track system behavior, authentication anomalies, port configurations, and edge state changes across our infrastructure platforms.
* **4. Vendor Risk Management:** All primary infrastructure hosting sub-vendors utilize SOC 2 Type II and ISO 27001 certified physical data centers with automated data isolation routines.
* **5. Operational Resiliency:** Daily backup systems maintain fully isolated recovery targets to prevent complete data loss or catastrophic state failures.
---
### Service level agreement
URL: https://pangolin.net/sla
# **FOSSORIAL SERVICE LEVEL AGREEMENT**
Last modified: June 9, 2026
This Service Level Agreement (“**SLA**”) is integrated into and forms a core component of the Subscription Agreement (the “**Agreement**”) between Fossorial, Inc. (“**Fossorial**”) and the Customer. This SLA applies to Enterprise-tier Services as identified in an Order Form and remains active throughout the duration of the Subscription Term.
## **1. Part I: Platform Availability**
### **1.1. Uptime Commitment**
Fossorial guarantees that the Services will maintain an Actual Availability of at least 99.99% during each calendar month of the Subscription Term (the “**Uptime Commitment**”). This commitment applies exclusively to Fossorial’s Cloud Enterprise-tier services and does not extend to other product offerings or tiers.
### **1.2. Service Credit Eligibility**
Should Fossorial fail to meet the Uptime Commitment in a given month, the Customer may be eligible for a Service Credit. To qualify, the Customer must report the shortfall and formally request the credit as outlined in Section 3.
Credits are calculated by multiplying the monthly service fee (X) by the Credit Percentage (Y) based on the table below:
| Actual Monthly Availability | Credit Percentage (of monthly fee) |
| :--- | :--- |
| < 99.99% but ≥ 99.5% | 10% |
| < 99.5% but ≥ 99.0% | 20% |
| < 99.0% | 30% |
### **1.3. Claims Process and Limitations**
To initiate a credit request, the Customer must email [support@pangolin.net](mailto:support@pangolin.net) within thirty (30) days following the end of the month in which the downtime occurred. Requests must include the Account ID and the specific dates/times of the reported unavailability.
* **Issuance:** Approved credits will be applied to the Customer’s account within 30 days.
* **Nature of Credits:** Credits are non-refundable, hold no cash value, and apply only to future invoices.
* **Exclusive Remedy:** Unless otherwise stated in Section 4, Service Credits are the Customer’s sole remedy and Fossorial’s entire liability regarding uptime failures.
### **1.4. Availability Definitions**
* **Scheduled Availability:** Total minutes the Services are intended to be accessible to Authorized Users.
* **Unscheduled Downtime:** Minutes the Services are unavailable, excluding:
* Acts/omissions by the Customer or their users.
* Force majeure events or external internet outages.
* Planned maintenance (notified at least 24 hours in advance via email).
* Emergency security patching or virus-related mitigation.
* **Actual Availability:** Calculated as: Scheduled Availability - Unscheduled Downtime
## **2. Part II: Support Services**
### **2.1. Severity Classifications**
* **Level 1 (Urgent):** A total system failure or critical defect rendering the platform unusable for all production users.
* **Level 2 (High):** Major functional disruption or significant performance lag affecting a large portion of the user base.
* **Level 3 (Normal):** A component is not operating as documented, or a general technical inquiry.
* **Level 4 (Low):** General information requests or suggestions for new features.
### **2.2. Response Time Targets**
Fossorial provides tiered support based on the Customer's chosen plan. "Business Hours" are defined as 9:00 AM to 5:00 PM (Local Timezone), Monday through Friday, excluding public holidays.
| Severity Level | Bronze Support | Silver Support | Gold Support |
| :--- | :--- | :--- | :--- |
| **1. Urgent** | 4 Business Hours | 2 Hours (24/7/365) | 1 Hour (24/7/365) |
| **2. High** | 8 Business Hours | 4 Business Hours | 2 Hours (24/7/365) |
| **3. Normal** | 2 Business Days | 2 Business Days | 8 Business Hours |
| **4. Low** | 3 Business Days | 2 Business Days | 1 Business Day |
| **Allowed Contacts** | 2 Users | 3 Users | 4 Users |
---
**Note:** The response times, uptime percentages, service credits, and other commitments described in this SLA are illustrative and subject to the final terms of your executed contract. Specific commitments may vary based on deployment scope, service tier, and other factors agreed upon in your Order Form.
---
### Fossorial commercial license
URL: https://pangolin.net/fcl
# **FOSSORIAL COMMERCIAL LICENSE**
Last modified: June 9, 2026
This Fossorial Commercial License (the “**License**”) governs access to and use of Fossorial software and related licensed materials (collectively, the “**Licensed Materials**”, or “**Software**”) provided by Fossorial, Inc. (“**Fossorial**”), a Delaware corporation.
By accessing, installing, downloading, or using any portion of the Licensed Materials, you (“**Licensee**”) agree to be bound by the terms of this License as of the date you first do so (the “**Effective Date**”). Continued use constitutes acceptance. If you are entering into this License on behalf of an organization, you represent that you have authority to bind such entity, in which case “**Licensee**” refers to that entity.
This License supersedes any prior application of the GNU Affero General Public License version 3 (“**AGPLv3**”) or other open-source terms to the Licensed Materials, except where expressly re-incorporated herein (for example, in contributed open-source projects pursuant to Exhibit A).
Use of the Licensed Materials without a License Key is permitted under the free or unlicensed tier, which provides limited functionality. Access to or activation of any Paid Features requires a valid License Key under either a Personal or Enterprise License (as defined herein). By using the Licensed Materials, Licensee also agrees to Fossorial’s Terms of Service and Privacy Policy, available at [https://pangolin.net/terms-of-service.html](https://pangolin.net/terms-of-service.html) and [https://pangolin.net/privacy-policy.html](https://pangolin.net/privacy-policy.html).
## **1. LICENSE GRANTS AND RESTRICTIONS**
### **1.1. Grant of License**
Subject to the terms outlined in this License, Fossorial grants Licensee and its Affiliates (as defined in Section 8) a limited, non-exclusive, non-transferable, and non-sublicensable license.
Despite the rights granted, the Licensee acknowledges that Fossorial and/or its licensors retain all ownership and intellectual property rights in and to the Software, including any modifications or patches created by the Licensee. Any use, reproduction, alteration, display, or distribution of the Software must strictly comply with this License.
Additionally, Licensee acknowledges and agrees that this License explicitly supersedes and replaces any prior application of the GNU Affero General Public License Version 3 (the “**AGPLv3**”) or any earlier versions of the GNU Affero General Public License to the Licensed Software. Where the Licensed Software is currently distributed under the AGPLv3, this License shall take precedence in its entirety, and any terms or obligations derived from the AGPLv3 shall no longer apply unless expressly incorporated herein.
Collectively, the Software and Fossorial Materials are referred to as the “**Licensed Materials.**”
### **1.2. License Restrictions**
Licensee shall not, and shall not permit any third party to:
* **(1)** Distribute, sublicense, or make available the source code of any Licensed Software components to any third party;
* **(2)** Use Fossorial’s proprietary source code to develop, market, or distribute any competing product or derivative work that offers similar or substitute functionality to the Licensed Software;
* **(3)** Claim ownership, copyright, or patent rights over any modifications or derivatives made to Fossorial’s Licensed Software code;
* **(4)** Resell, sublicense, or repackage the Licensed Software as a competing product, standalone Software as a Service (SaaS) product, standalone offering, or derivative solution without prior written approval from Fossorial;
* **(5)** Provide, lease, lend, or otherwise make the Licensed Software available for the benefit of any third party except as expressly permitted under this License, including but not limited to timesharing, service bureau use, or outsourcing;
* **(6)** Remove, alter, or obscure any notices (including copyright, trademark, or branding) of Fossorial on or within copies of the Licensed Software;
* **(7)** Resell or redistribute the Licensed Software as-is, or provide third-party access to Fossorial container images or other deployment artifacts;
* **(8)** Allow any third party to deploy, host, or operate any component of the Licensed Software.
### **1.3. Right to Modify for Internal Use**
The Licensee is hereby granted the right to modify the Software, including its source code and accompanying materials, solely for the Licensee's Internal Use, provided that all copyright notices, disclaimers, and other proprietary notices are maintained in all copies of the modified Software.
For the purposes of this License, "Internal Use" means use of the Software, whether in its original or modified form, exclusively:
* **(1)** Within the Licensee's organization or business entity;
* **(2)** By the Licensee's employees, contractors, or agents while performing work for the Licensee;
* **(3)** On equipment owned, leased, or otherwise controlled by the Licensee;
* **(4)** For the Licensee's business or operational purposes; and
* **(5)** Not for commercial redistribution, sublicensing, or provision of the Software or any modified version thereof as a service to any third party.
* **(6)** Internal Use specifically excludes any distribution, transfer, or disclosure of the modified Software to any third party outside the Licensee's organization, except as may be expressly permitted elsewhere in this License.
Notwithstanding anything to the contrary, Licensee agrees that Fossorial and/or its licensors (as applicable) retain all right, title and interest in and to all Software incorporated in such modifications and/or patches, and all such Software may only be used, copied, modified, displayed, distributed, or otherwise exploited in full compliance with this License.
Notwithstanding the foregoing, Licensee shall not modify, alter, disable, or otherwise circumvent any license validation, telemetry, or access control mechanism included in the Software, nor use any modification for the purpose of avoiding fee payment, usage restrictions, or license enforcement. Any such action shall constitute a material breach of this License and immediately terminate all rights granted herein.
## **3. LICENSE STATE, FEES, AND SUBSCRIPTION TERM**
### **3.1. License State**
The Software may operate in either a licensed or unlicensed state. The Software shall be considered in a licensed state upon the successful input and validation of a valid License Key, as defined herein. Operating the Software in a licensed state may enable additional functionalities ("**Paid Features**") as defined in Section 8. The use of any Paid Features while the Software is in an unlicensed state constitutes a material breach of this Agreement.
### **3.2. License Tiers and Fees**
Access to a License Key requires the payment of applicable fees, except where explicitly provided for. The Licensor offers two tiers of licenses: **Personal** and **Enterprise**.
### **3.3. Personal License**
A Personal License is available free of charge. You are eligible for a Personal License if you meet at least one of the following criteria:
* **(1) Non-Commercial Use:** You are an individual using the Software for your own personal, non-commercial purposes (such as for education, personal projects, or other non-remunerative activities), irrespective of your personal annual income from other sources.
* **(2) Small-Scale Commercial Use:** You are an individual or a legal entity using the Software for commercial purposes, provided that you or your entity's gross annual revenue does not exceed one hundred thousand United States Dollars ($100,000 USD).
For clarity, any use of the Software by or for a commercial entity with a gross annual revenue exceeding $100,000 USD requires an Enterprise License.
### **3.4. Enterprise License**
Any use of the Software not expressly permitted under the Personal License tier requires an Enterprise License.
* **(1)** An Enterprise License must be procured directly from **Fossorial** subject to the execution of a separate commercial agreement and payment of the applicable fees.
* **(2)** For evaluation purposes, a temporary, self-service Enterprise License Key with a term of seven (7) days may be made available, subject to the terms of this Agreement.
### **3.5. License Key Validity and Term**
A "**License Key**" is considered valid only if it has been issued by the Licensor and is successfully authenticated by the Licensor's designated license verification server. Each License Key is subject to a specific term and will have an expiration date. Your right to use the Software in a licensed state, and to access any Paid Features, will terminate upon the expiration of the License Key.
Each Host (as defined in Section 8) may operate the Software in either a licensed or unlicensed state. Operation without a valid License Key is permitted only for use of features available under the unlicensed tier. Access to Paid Features requires that the Host be covered by a valid License Key under an active Personal or Enterprise License. Use of any Paid Features on an unlicensed Host constitutes unlicensed use and a material breach of this License.
## **4. INTELLECTUAL PROPERTY**
### **4.1. Ownership and Retention of Rights**
Fossorial retains all rights, title, and interest, including all intellectual property rights, in and to the Licensed Software, along with any modifications, enhancements, or derivative works, whether created by Fossorial, Licensee, or any third party. No rights are granted to Licensee except as expressly set forth in this License. This License does not constitute a sale and does not convey to Licensee any ownership interest in the Licensed Software or any associated intellectual property.
Any custom modifications, enhancements, or new features developed specifically for Licensee and funded by Licensee shall be subject to a separate written agreement. Licensee shall receive a non-exclusive, non-transferable license to use such custom work solely as part of its authorized Fossorial deployment.
### **4.2. Open Source Contributions**
Should Licensee choose to contribute code, improvements, or modifications to any Fossorial open-source project:
* **(1)** Licensee must execute the Contributor License Agreement (CLA) as set forth in Exhibit A.
* **(2)** All such contributions shall be the exclusive property of Fossorial and may be used at Fossorial’s sole discretion in both open-source and proprietary offerings.
* **(3)** Fossorial may license contributed code under any open-source or commercial license it selects.
* **(4)** Contributions are voluntary, and Licensee waives any rights to compensation, royalties, or licensing fees.
## **5. TECHNICAL INTEGRATION AND HOSTING**
### **5.1. Licensee's Responsibilities**
Licensee acknowledges and agrees that it is solely responsible for the integration, deployment, security, and operation of its self-hosted Fossorial components. Specifically, Licensee shall:
* **(1)** Assume full ownership, liability, and warranty obligations over its deployment, including any issues arising from system failures, security vulnerabilities, data breaches, or operational misconfigurations;
### **5.2. Security Obligations**
* **(1)** Licensee assumes full responsibility for securing and maintaining any self-hosted Fossorial components. Fossorial shall not be liable for any security incidents, breaches, or data loss resulting from Licensee’s improper deployment, misconfiguration, or lack of compliance with regulatory requirements.
* **(2)** Licensee shall indemnify and hold Fossorial harmless from any claims, fines, penalties, or damages arising from Licensee's failure to secure its hosted Fossorial deployment. ( see Section 6 and the Terms of Service for additional indemnification provisions).
## **6. INCORPORATION OF TERMS OF SERVICE**
Licensee acknowledges and agrees that its access to and use of the Licensed Materials, as well as any related Fossorial services, are also subject to Fossorial’s Terms of Service, available at [https://pangolin.net/terms-of-service.html](https://pangolin.net/terms-of-service.html) (the “**Terms of Service**”).
By entering into this License, Licensee expressly agrees to be bound by and comply with all terms, conditions, and obligations set forth in the Terms of Service, as amended from time to time. In the event of a conflict between this License and the Terms of Service, the terms of this License shall control solely with respect to the Licensed Materials.
## **7. PRIVACY AND DATA PROTECTION**
Licensee acknowledges and agrees that any collection, storage, use, or processing of personal data by Fossorial in connection with the Licensed Materials shall be governed by Fossorial’s Privacy Policy, available at [https://pangolin.net/privacy-policy.html](https://pangolin.net/privacy-policy.html) (the “**Privacy Policy**”).
By using the Licensed Materials, Licensee consents to Fossorial’s handling of information as described in the Privacy Policy. Licensee further agrees to comply with all applicable data protection and privacy laws when deploying or using the Licensed Materials.
## **8. DEFINITIONS**
* **“Affiliate”** means any entity(ies) controlling, controlled by, and/or under common control with a party hereto, where “control” means the ownership of more than 50% of the voting securities in such entity.
* **"Host"** means each individual machine (real or virtual, including servers, containers, workstations, smartphones, POS, industrial controls, gateways, sensors, IoT endpoints, or any other physical or simulated computing interface or machine) of Licensee and/or its Affiliates (including, without limitation, employees, agents or consultants thereof) with access to Licensed Material.
* **“Paid Features”** means any functionality, capability, or component of the Software that is disabled or non-functional when a Host is operating in an unlicensed state. Paid Features are enabled only when the Host is operating under a valid Personal or Enterprise License Key. Within the Software’s user interface, Paid Features are indicated or labeled with a designated badge or marker to distinguish them from features available under the free or unlicensed tier.
This License shall be governed by and construed in accordance with the laws of the State of Delaware, without regard to its conflict of laws principles.
## **EXHIBIT A - CLA**
By creating this pull request, I grant the project maintainers an unlimited, perpetual license to use, modify, and redistribute these contributions under any terms they choose, including both the AGPLv3 and the Fossorial Commercial license terms. I represent that I have the right to grant this license for all contributed content.
---