Dora NodaIn June 2026, the most popular self-hosted Cloudflare Tunnel alternative did something its own name stopped describing: Pangolin, a tunneled reverse proxy with over 22,000 GitHub stars, turned every SSH server, Windows box, and VNC display behind its tunnels into a URL you open in a browser tab. No SSH client, no Remote Desktop app, no VPN — authenticate once through Pangolin and you get a terminal or a full desktop in the tab next to your app.
Here is the verdict up front, because the rest of this post is the evidence: if you run a self-hosted PaaS, borrow Pangolin's patterns for operator access, keep tenant debug shells in-platform, and take the HTTP overlap seriously but not literally. Browser SSH/RDP/VNC-over-tunnel is a genuinely better model for reaching your own fleet — and a genuinely different product from the tenant-facing ingress your platform needs.
What 1.19 shipped — and why 1.22 matters more
Pangolin 1.19, released June 11, 2026, made SSH, RDP, and VNC first-class public resources — the same "resource" abstraction Pangolin already used for HTTPS services. Each protocol gets its own public fully qualified domain name: point ssh-ops.example.com at a site connector, and anyone passing Pangolin authentication lands in a real web-based terminal. RDP sessions run a full Windows desktop in the browser with clipboard support and file transfers. VNC displays render directly in the tab.
Three details make this more than a novelty. First, authentication composes: SSH sessions support password, key-based, or Pangolin-identity auth depending on how the resource is configured, and the same SSO, role-based access rules, and geo-blocking that gate HTTP resources apply unchanged to terminal sessions.
Second, the site-resource model carries over — you do not install anything on the target machine. Newt, Pangolin's site connector agent, runs on any host that can reach the target network, exactly like it already did for HTTPS origins. Third, the release also shipped a simplified native Pangolin SSH mode that no longer requires configuring an OpenSSH server, editing sshd_config, or standing up a certificate authority — the setup tax its 1.16 certificate-based SSH had imposed — plus automatic site-connector updates, resource labels, and per-resource policies.
But the release most self-hosters should actually care about is 1.22, from August 24. In 1.19, browser-based SSH, RDP, and VNC were Enterprise Edition features; 1.22 moved them — along with SSH and HTTPS private resources — into the free, AGPL-licensed Community Edition. (Enterprise was already free for personal use and businesses under $100K in revenue, but a Community Edition feature is one you can depend on without a license key workflow.) September's 1.23 then added self-service high availability and clustering. So the timeline that matters: the capability landed in June, became freely self-hostable in August, and became production-shape in September.
The adoption curve explains why this is worth a PaaS operator's attention rather than a shrug. Pangolin passed 18,000 GitHub stars within a year of its first public beta, crossed 20,000 by April 2026, and sits past 22,000 today. That is the trajectory of a tool becoming default infrastructure for the self-hosting world — the same world a self-hosted PaaS recruits its operators from.
How the tunnel-plus-resource model works
Pangolin's architecture has four moving parts, and you only need the shape of it. A central Pangolin server acts as control plane and edge: it terminates inbound traffic and routes it through Traefik (via Pangolin's Badger plugin). Gerbil manages WireGuard interfaces on the server side. Newt, the site connector, dials outbound from wherever your infrastructure lives and holds the WireGuard tunnel open — no inbound ports, no firewall rules, NAT traversal for free. Olm is the optional client for private, VPN-style access.
Resources come in two flavors. Public resources get an FQDN and face the internet through the Pangolin edge, gated by identity policy. Private resources stay dark and require the Olm client. What 1.19 changed is what a resource can be: previously the interesting answer was "an HTTPS service," and now it is "an HTTPS service, an SSH server, a Windows desktop, or a VNC display" — all routed through the same tunnels, all governed by the same users, roles, and SSO.
That widening is the whole story. Pangolin's unit of management was never really the HTTP route; it was the resource behind a tunnel. Version 1.19 just admitted that interactive protocols are resources too. The project now describes itself as an Apache Guacamole alternative with site tunneling built in — clientless remote desktop, minus the part where you expose Guacamole's gateway to the internet yourself.
Where it overlaps a PaaS ingress
A self-hosted PaaS already owns an ingress layer: per-tenant domains, TLS, deploy-triggered route updates, and some story for debug shells. So the honest question is need-by-need: which PaaS ingress needs does a Pangolin-style model actually cover?
| Pangolin primitive | PaaS ingress need | Fit |
|---|---|---|
| Tunneled HTTP reverse proxy | Tenant app routing (domains, TLS, deploys) | Partial — routes traffic, knows nothing of deploys |
| Browser SSH | Operator node access | Strong — SSO-gated shells, no bastion |
| Browser SSH | Tenant app debug shells | Weak — SSH-to-node is not exec-into-container |
| Browser RDP / VNC | Support screen-share | Poor — no user on a Linux-container fleet |
| SSO policy per resource | Tenant authentication | Different model — staff identity, not tenant identity |
| Zero-client access | Onboarding friction | Strong — a URL beats a client install |
Tenant app HTTP routing: real overlap, wrong coupling. Pangolin routes FQDNs to origins with TLS and policy, which is genuinely a large fraction of what a PaaS edge does. What it lacks is deploy-awareness: per-tenant wildcard domains minted at provision time, revision-based routing during a rollout, route updates driven by a deploy event rather than a dashboard edit, and idle scale-down that parks the route when nothing is running.
A generic tunnel proxy treats the origin as a static address; a PaaS router treats it as the current revision of a living app. You could front tenant apps with Pangolin the way some teams front them with a hand-managed Traefik — and inherit the same ceiling.
Tenant debug shells: the semantics mismatch. This is the row the headline most wants to be true, and it is the one to be careful with. A tenant clicking "open shell" on their app expects a shell inside their container, scoped to their tenant identity, audited as a tenant action, gone when the container is gone.
Pangolin gives you an SSH session to a machine, authenticated as a staff identity, governed by a resource policy. Those are different security principals attached to different lifecycle scopes. Bridging them — mapping tenant A to node 3's container namespace safely — is the entire engineering problem of tenant shells, and a tunnel does not solve it. Container-native exec through the orchestrator's API remains the right primitive here.
Operator node access: the strongest fit. Your own team reaching fleet nodes is exactly the shape Pangolin models well: machines behind NAT with no public SSH, one Newt connector per site, SSO in front of every terminal, access rules per person instead of shared keys on a bastion. For a small ops team running owned hardware, replacing a hand-rolled bastion plus WireGuard mesh with per-host browser SSH behind existing SSO is a credible simplification — and 1.19's native SSH mode plus automatic connector updates removed the two setup taxes that used to make teams hesitate.
RDP and VNC: admire from a distance. On a Linux-container PaaS, there is no Windows desktop to reach and no VNC display worth publishing. The one edge case is Windows build agents in a mixed fleet, and that is an operator convenience, not a platform feature. The honest accounting: two of the three protocols in the headline have no tenant-facing user on a container PaaS at all.
Two cross-cutting gaps complete the picture. Pangolin has no tenant-isolation model — its policy unit is a staff member accessing a resource, not tenant A provably unable to see tenant B. And its audit story is thinner than Teleport-class tooling: if your compliance posture needs per-session recording and replay of privileged access, browser SSH through a reverse proxy is not a substitute for a session-aware access plane.
Borrow the patterns, not the product
The decision splits cleanly once the mapping is on the table.
Borrow these four patterns into your own ingress and access design:
- Protocol-as-resource. Any reachable thing, HTTP or interactive, deserves one managed object with one policy surface.
- FQDN-per-service. A stable name per thing beats an IP plus a port plus tribal knowledge, for terminals as much as for apps.
- SSO-before-terminal. No shell, however obtained, should exist outside the identity system — keys on a bastion are the thing being replaced.
- Zero-client access. Every client install you eliminate is onboarding friction and version skew you never pay.
Do not adopt the product as your tenant layer. The reasons are the gaps from the previous section, restated as a rule: a tool whose policy principal is a staff member cannot be the layer that isolates tenants; a router that does not know about deploys cannot be the router that serves them; and SSH-to-a-node cannot be the shell inside a tenant's container. None of these are criticisms of Pangolin — they are category boundaries. It is remote-access infrastructure that grew out of a reverse proxy, not a PaaS control plane, and it is honest about that shape.
The actionable recommendation for a self-hosted PaaS team: run Pangolin — or its pattern, if you prefer Cloudflare Tunnel plus Access for the managed equivalent — for operator access to the fleet, keep tenant debug shells on orchestrator-native exec behind your own tenant identity, and keep tenant HTTP on the deploy-aware router. Three access planes, each matched to its principal: staff-to-machine, tenant-to-container, internet-to-app.
What to watch next: 1.22's Community Edition move plus 1.23's self-service HA remove the last two objections a team would raise to the operator-access case — licensing friction and single-node fragility. And 1.22's other headline, an identity-aware AI gateway for cloud and self-hosted models, hints at where Pangolin thinks access control is going: not just people reaching machines through browsers, but agents reaching infrastructure through identity. For a platform betting that AI agents become first-class operators, that is the release note to read twice.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
