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, 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

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. 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.

Try Pangolin

Get started with Pangolin. You can self-host the server or sign up for the cloud and try it with no commitment.

Get in touch

If you want more detail on how Pangolin can fit your setup, reach out.