Co-maintainer here: we also did this cool thing where we reused the same go codebase across our clients. We have a go package called olm (on our Github and following our animal theme) that implements all of the VPN capabilities. It creates the tunnel, monitors the peers, syncs with the Pangolin server. This itself is a binary that can run on its own as like our own little VPN kernel module - then in the different applications we use olm to trigger the tunnel. This is easy on Windows as the whole app is go based, but on Android, Mac, and iOS we use C bindings to compile it as a shared library into the application. Then the native application imports parts of the module to initiate the tunnel and handle the tunneling. On iOS and Macos this is handled in a "Network Extension" which is a secure environment Apple runs tunneling applications in, so we use a unix socket to communicate with the olm tunneling kernel to show status to the user and handle commands.
> The Enterprise Edition is also open-source under the commercial license which enables free personal/small business use.
Open Source can be pair or commercial. But the license of these software Enterprise Edition, called "Fossorial Commercial License", is not Open Source.
You tell who and how can use the software after the share/sell and call it Open Source.
The main site also advertises "Self Host: Enterprise Edition" as being "100% Open Source" which is simply not true and false advertising.
Pangolin is dual licensed under the AGPLv3 and the Fossorial Commercial License. The community edition includes no commercial license code and is fully AGPL compliant. The enterprise edition is also free to use for personal use.
Yes but enterprise edition seems to be falsly advertised on the main site as open source. And the community and enterprise editions are mixed in the source code making compilations of community edition complicated.
I never personally tried it but it looks great. My only concern is I have a feeling that in few years it will “discontinue” the open source or community version and now it’s paid only, after it gained all the publicity from free open source users, and there are many cases of this scenario that happened before.
Thank you, great product, can only recommend it! I've been self-hosting it since last year to access my jellyfin home-server from the web. Set up was easy and I never had any issues.
if you don’t mind me asking, any noticeable differences in throughput compared to reverse proxying directly to jellyfin? For example - how well can you stream a 4k video (let’s assume 15mbps bitrate)?
Last time i looked into it i saw zero information in the docs about network performance and what to expect. Which was surprising.
Traditional reverse proxies require a public IP and open firewall ports. Pangolin uses a tunneled reverse proxy to expose resources behind restrictive firewalls without those requirements.
A single Pangolin server can tunnel to multiple remote networks, centralizing apps from different locations into one place. It also includes VPN clients and handles NAT traversal as an alternative to traditional VPNs for direct connections.
This is perfect, I've been looking for something like this for my home network. Tailscale requires too much trust and is only partly open-source. Diy wireguard works, but Comcast has starting messing with packets, and our IP changes a lot. A self-hosted vpn to bridge consumer isp and public networks I can put on a vps, is a lot easier to trust.
I was thinking of using this to tunnel all of my public sites, do hide my home ip. But in the end whats the issue of showing my home ip? The attack surface stays the same. I just reverse proxy everything through Caddy.
Also weren’t some feature gated behind the cloud version? An appeal for this to replace cloudflare tunnels and tailscale funnel is the _fully_ opensource aspect
Hiding an IP and security are not necessarily the main use cases.
The tunneled reverse proxy aspect comes in handy when trying to expose internal apps on a network behind a hard NAT where ports can't be opened and a public IP address isn't available (like CGNAT).
Pangolin is also a VPN like Tailscale/Twingate/etc, so you can access non http resources via a direct connection via WireGuard and NAT traversal.
We do not support LDAP directly right now. We do support any OIDC / OAUTH enabled endpoint though like Entra, Google, Okta. You can use something like Authentik to pull in LDAP users into a OIDC enabled endpoint.
We have a helm chart for newt (the site connector which goes into K8S) https://artifacthub.io/packages/helm/fosrl/newt! Its pretty basic right now but we have plans to connect RBAC and the API to pull in resources and create secure access for users. Creating resources manually you can use it for remote access to the cluster or for ingress right now though!
Hey, so this pretty much looks like a Tailscale rip-off. Not a competitor, but a straight-up ripoff in the worst possible way.
Tailscale has LONG used Pangolins as a mascot (https://tailscale.com/blog/network-pangolins). They even run a "Pangolin Enthusiast" website (https://tailandscales.com/) that is essentially a demo site for their tutorials. This is an animal with a tail and scales! The branding is very good.
You clearly chose this name to deliberately create brand confusion with Tailscale, and to derail some of their marketing and community branding in your favor. That's scummy behavior by developers who don't have anything to offer but a copy of someone else's work.
If am going to choose between Tailscale, and a project opportunistically attempting to impersonate Tailscale, why would I ever choose the scummy impersonator?
The resource-centric approach is the right call. I've been running self-hosted infrastructure for my own projects for a while now, and the biggest lesson is that flat networks just don't scale when you start adding services — every new thing you expose becomes another thing to audit.
The NAT hole-punching with WireGuard for P2P connections is interesting. Do you handle cases where both sides are behind symmetric NATs? That's historically been the hardest case for hole-punching, and most solutions end up falling back to relay servers anyway (which defeats the purpose of avoiding centralized traffic).
Also curious about the connector deployment model — is it one connector per resource, or can a single connector bridge multiple resources in the same network segment?
I've maintained this list the last several years: https://github.com/anderspitman/awesome-tunneling
Pangolin has quickly risen almost to the top since being released. It's very well loved by /r/selfhosted.
Hey, great to see you here! Thanks for maintaining this great list of tools. :)
Co-maintainer here: we also did this cool thing where we reused the same go codebase across our clients. We have a go package called olm (on our Github and following our animal theme) that implements all of the VPN capabilities. It creates the tunnel, monitors the peers, syncs with the Pangolin server. This itself is a binary that can run on its own as like our own little VPN kernel module - then in the different applications we use olm to trigger the tunnel. This is easy on Windows as the whole app is go based, but on Android, Mac, and iOS we use C bindings to compile it as a shared library into the application. Then the native application imports parts of the module to initiate the tunnel and handle the tunneling. On iOS and Macos this is handled in a "Network Extension" which is a secure environment Apple runs tunneling applications in, so we use a unix socket to communicate with the olm tunneling kernel to show status to the user and handle commands.
Pangolin, Olm, Newt, Gerbil.. I haven't seen that level of animal dedication since the Apple big cats era. Cool tools, though, keep it up!
What the hell?! That is AWESOME!!!
> The Enterprise Edition is also open-source under the commercial license which enables free personal/small business use.
Open Source can be pair or commercial. But the license of these software Enterprise Edition, called "Fossorial Commercial License", is not Open Source. You tell who and how can use the software after the share/sell and call it Open Source.
The main site also advertises "Self Host: Enterprise Edition" as being "100% Open Source" which is simply not true and false advertising.
Pangolin is dual licensed under the AGPLv3 and the Fossorial Commercial License. The community edition includes no commercial license code and is fully AGPL compliant. The enterprise edition is also free to use for personal use.
Yes but enterprise edition seems to be falsly advertised on the main site as open source. And the community and enterprise editions are mixed in the source code making compilations of community edition complicated.
It's how commercial software tries to get big and a lot of undeserved, free goodwill these days.
I never personally tried it but it looks great. My only concern is I have a feeling that in few years it will “discontinue” the open source or community version and now it’s paid only, after it gained all the publicity from free open source users, and there are many cases of this scenario that happened before.
Thank you, great product, can only recommend it! I've been self-hosting it since last year to access my jellyfin home-server from the web. Set up was easy and I never had any issues.
if you don’t mind me asking, any noticeable differences in throughput compared to reverse proxying directly to jellyfin? For example - how well can you stream a 4k video (let’s assume 15mbps bitrate)?
Last time i looked into it i saw zero information in the docs about network performance and what to expect. Which was surprising.
What are the advantages of this setup rather than reverse proxying right where your jellyfin is?
Traditional reverse proxies require a public IP and open firewall ports. Pangolin uses a tunneled reverse proxy to expose resources behind restrictive firewalls without those requirements.
A single Pangolin server can tunnel to multiple remote networks, centralizing apps from different locations into one place. It also includes VPN clients and handles NAT traversal as an alternative to traditional VPNs for direct connections.
This is perfect, I've been looking for something like this for my home network. Tailscale requires too much trust and is only partly open-source. Diy wireguard works, but Comcast has starting messing with packets, and our IP changes a lot. A self-hosted vpn to bridge consumer isp and public networks I can put on a vps, is a lot easier to trust.
I was thinking of using this to tunnel all of my public sites, do hide my home ip. But in the end whats the issue of showing my home ip? The attack surface stays the same. I just reverse proxy everything through Caddy.
Also weren’t some feature gated behind the cloud version? An appeal for this to replace cloudflare tunnels and tailscale funnel is the _fully_ opensource aspect
Hiding an IP and security are not necessarily the main use cases.
The tunneled reverse proxy aspect comes in handy when trying to expose internal apps on a network behind a hard NAT where ports can't be opened and a public IP address isn't available (like CGNAT).
Pangolin is also a VPN like Tailscale/Twingate/etc, so you can access non http resources via a direct connection via WireGuard and NAT traversal.
Congrats on progress.
These are differentiating from most VPN and zero trust:
+ fully self-hostable open source
+ avoid ACL complexity (default closed architecture)
+ sovereign identity-based
OpenZiti is similar in those – how do you compare and contrast the two since very few others share those differentiators (I am an OZ maintainer)?
So, can I connect an on-prem instance to LDAP for authentication/authorization? I didn't find the word LDAP anywhere when searching the docs.
We do not support LDAP directly right now. We do support any OIDC / OAUTH enabled endpoint though like Entra, Google, Okta. You can use something like Authentik to pull in LDAP users into a OIDC enabled endpoint.
Is this there any kubernetes integration? I like the resource based approach; it would be neat to host or consume resources in kubernetes with this.
We have a helm chart for newt (the site connector which goes into K8S) https://artifacthub.io/packages/helm/fosrl/newt! Its pretty basic right now but we have plans to connect RBAC and the API to pull in resources and create secure access for users. Creating resources manually you can use it for remote access to the cluster or for ingress right now though!
Really cool product, impressive how much you've built and the usage you've attained in a short period of time
Thanks! :)
Hey, so this pretty much looks like a Tailscale rip-off. Not a competitor, but a straight-up ripoff in the worst possible way.
Tailscale has LONG used Pangolins as a mascot (https://tailscale.com/blog/network-pangolins). They even run a "Pangolin Enthusiast" website (https://tailandscales.com/) that is essentially a demo site for their tutorials. This is an animal with a tail and scales! The branding is very good.
You clearly chose this name to deliberately create brand confusion with Tailscale, and to derail some of their marketing and community branding in your favor. That's scummy behavior by developers who don't have anything to offer but a copy of someone else's work.
If am going to choose between Tailscale, and a project opportunistically attempting to impersonate Tailscale, why would I ever choose the scummy impersonator?
I replaced CF tunnels, which kept disconnecting every few minutes with it, and happy.
That's awesome! Pangolin is a great alternative to Cloudflare tunnels. It can also replace Warp for direct, private connections via the VPN clients.
The resource-centric approach is the right call. I've been running self-hosted infrastructure for my own projects for a while now, and the biggest lesson is that flat networks just don't scale when you start adding services — every new thing you expose becomes another thing to audit.
The NAT hole-punching with WireGuard for P2P connections is interesting. Do you handle cases where both sides are behind symmetric NATs? That's historically been the hardest case for hole-punching, and most solutions end up falling back to relay servers anyway (which defeats the purpose of avoiding centralized traffic).
Also curious about the connector deployment model — is it one connector per resource, or can a single connector bridge multiple resources in the same network segment?