Cloudflare Tunnels vs. NetBird Reverse Proxy

You have a dashboard running on a machine with no public IP. You want colleagues or customers to reach it over HTTPS, authenticated, without opening a single firewall port. Which tool should you reach for?

The pattern you are looking for is the outbound tunnel: a process running on your server that dials out to an edge endpoint, requiring no inbound ports and no public IP on the origin machine. If you’ve already explored DDNS, SSH tunnels, or the port-forward-and-hope approach, you know the shape of the problem. Those efforts establish the right mental model for what follows. Anyone running services on a homelab, a private cloud, or behind a corporate NAT already knows: external access requires operational overhead that compounds as infrastructure grows. Cloudflare Tunnels solved this elegantly for millions of developers: install , configure the daemon to point at your service, and Cloudflare handles the rest. The trade-offs are real, though. Cloudflare terminates TLS at their edge, which means Cloudflare has technical access to your decrypted traffic, and some teams do not want a CDN giant in front of their own Bitwarden or Firefly III instance.

NetBird's Reverse Proxy (launched in v0.65.0) offers a privacy-first alternative built on WireGuard .

NetBird Reverse Proxy is available on both NetBird Cloud and self-hosted deployments. The configuration details in this article (environment variables, Docker containers, Traefik labels) apply to self-hosted setups; Cloud users configure the proxy through the NetBird dashboard.

This piece compares both tools honestly, through the lens of the specific problem both tools solve: safely exposing internal services to the internet without opening ports.

What is NetBird’s reverse proxy?

NetBird’s Reverse Proxy lets you expose any internal service, running on a peer or behind a network resource, to the public internet without opening ports or touching your firewall. The key differentiator versus standalone reverse proxies like Nginx or Caddy: the mesh is already there. You surface services through an encrypted network you already operate.

The mechanism works through your existing WireGuard mesh: incoming HTTPS requests hit the NetBird proxy cluster (running on your infrastructure), which terminates TLS and forwards traffic through an encrypted WireGuard tunnel to the target service. The target service only needs to be reachable within your NetBird network. The proxy cluster connects to your management server via gRPC, provisions TLS certificates automatically (ACME/Let’s Encrypt or static), and supports path-based routing to consolidate multiple services under a single domain. Path-based routing is configured in the NetBird management UI when defining a service: you specify the public URL path prefix and the target internal service, and Traefik applies the routing rule automatically.

The authentication layer (SSO via your identity provider, shared passwords, or PINs) means the proxy is also an access control point, not just a traffic forwarder.

The current constraints: self-hosted deployments require Traefik as the reverse proxy (Traefik is required because NetBird’s proxy container integrates via Traefik’s Docker label routing model; Nginx and Caddy are not currently supported by NetBird Reverse Proxy), and the feature does not support pre-shared keys or Rosenpass. For self-hosted setups, the deployment footprint is a separate container alongside your existing NetBird stack. NetBird Cloud users get the proxy capability without managing additional infrastructure.

What are Cloudflare tunnels?

Cloudflare Tunnel () creates a secure outbound connection from your server to Cloudflare’s global edge network, making any internal service reachable via HTTPS without a public IP or open inbound port. The daemon dials out to Cloudflare’s edge; Cloudflare terminates TLS there and proxies traffic to your origin. This architecture is the defining choice: Cloudflare sits in the middle.

You get DDoS protection, a global CDN with points of presence in hundreds of cities globally, Gateway HTTP/network policies, and zero infrastructure to manage on your end. For teams that need a service exposed in five minutes with automatic TLS, is hard to beat.

Where this architecture creates constraints: TLS terminates at Cloudflare’s edge, not at your origin, which means Cloudflare has the technical ability to read decrypted traffic between their edge and your server. UDP traffic is not supported for public hostnames through tunnels. Cloudflare’s Terms of Service also restrict using tunnels for large non-web traffic, including video streaming, which affects self-hosters running media servers such as Plex or Jellyfin. Your DNS, certificates, and policy management are all locked into Cloudflare’s ecosystem.

One clarification worth making: Cloudflare Tunnel (the daemon and ingress rules) is distinct from Cloudflare’s Proxy Endpoints (PAC-file-based, Gateway-filtered, clientless proxying). Both are part of Cloudflare One, but serve different use cases. This comparison focuses on Cloudflare Tunnel as the direct analog to NetBird’s Reverse Proxy.

NetBird and Cloudflare capability overview

The following table compares NetBird Reverse Proxy and Cloudflare Tunnel by capability. The differences here trace back to architectural choices, not just feature counts.

Capability parity hides real differences in privacy, control, and operational cost. The next four sections unpack each.

Tunneling architecture and TLS termination

Who can read your traffic depends entirely on where TLS terminates. That single decision shapes everything else about how these two tools compare.

NetBird

The proxy cluster must run on infrastructure with a public IP, typically a VPS or cloud instance. External HTTPS requests resolve to that IP via DNS, terminate TLS at the proxy cluster, and forward traffic through the WireGuard tunnel to the internal service. The internal service never needs a public IP or open ports; it only needs to be reachable within the NetBird network.

This architecture means you control the entire TLS chain. Certificate provisioning happens at the proxy via ACME/Let's Encrypt. The challenge type is configurable via : (default, requires port 443) or (requires port 80). Wildcard certificates (required for ) are not supported through the built-in ACME integration, since DNS-01 is unavailable; provision wildcard certs externally and supply them via and . WireGuard’s authenticated encryption protects the tunnel segment. For workloads involving sensitive data such as financial records, health data, or credential stores, the architecture itself prevents third-party decryption.

The proxy cluster supports multiple instances configured with the same . Deploy multiple proxy instances and add multiple DNS A records, one per proxy host, to achieve failover; if one instance becomes unreachable, DNS clients round-robin to another. No additional load balancer is required for basic high availability.

Cloudflare

The daemon creates an outbound connection from your server to Cloudflare’s nearest edge node using QUIC/HTTP2 tunneling (IETF standards, RFC 9000/RFC 9113). Cloudflare terminates TLS at that edge node and re-establishes a connection to your origin. This architecture simplifies operations substantially, but Cloudflare has the technical ability to read decrypted traffic at their edge.

Cloudflare re-encrypts traffic to your origin using a separate TLS connection, configurable as Full or Full Strict mode. Full mode accepts any certificate at the origin, including self-signed; Full Strict mode requires a valid CA-issued certificate. The distinction matters: many self-hosted deployments default to Full mode, which means the Cloudflare-to-origin segment trusts certificates that no public CA has validated, quietly reducing encryption strength on the last hop. This setup also provides DDoS protection, global CDN caching, and Gateway policies without deploying any edge infrastructure yourself.

If no third-party decryption point is acceptable, self-hosted TLS termination provides that guarantee. If infrastructure simplicity and Cloudflare's security track record are sufficient, managed-edge termination is a well-established model.

Authentication and access control

NetBird

Authentication is configured per-service (called a “Service” in the Reverse Proxy UI). Each service can enable SSO (OIDC via your already-configured IdP, the same one used for the broader NetBird mesh), a shared password, or a PIN. Multiple methods can be active simultaneously, so users choose their preferred method at access time. Restricting SSO access to specific IdP groups provides role-based access control without additional tooling.

The auth control plane runs entirely on your infrastructure. Unauthenticated (public) services are supported, but the dashboard flags them so you can see which services are unprotected at a glance. For those sharing internal dashboards with external contractors, the password/PIN options provide quick access without requiring IdP enrollment.

Cloudflare

Cloudflare Access provides the authentication layer for Tunnel-protected services. It supports OIDC from major identity providers. Access policies are rich: you can restrict by user, group, country, device posture, and network origin. Policy evaluation supports complex logic with allow, block, and bypass rules that chain together for granular control.

The control plane is fully managed by Cloudflare. Cloudflare propagates policy changes across its global edge within seconds. The trade-off is control: your authentication logic, session tokens, and access logs reside on Cloudflare’s infrastructure rather than your own. Note that Cloudflare’s Proxy Endpoints (PAC-file-based approach) add a separate identity-based vs. source IP-based authentication model; the two should not be conflated.

Control plane ownership (your infrastructure vs. Cloudflare's SaaS) is the key distinction if you have data residency requirements.

Setup, deployment, and operational complexity

You’ve decided which trust model fits. Now the question is: what does getting there actually look like?

NetBird

The setup has three prerequisites: a running self-hosted NetBird deployment (management, signal, and relay servers, all three of which can run on a single VPS via Docker Compose), Traefik as the reverse proxy, and the container.

For new deployments, NetBird’s bootstrap script (available at the NetBird self-hosted quickstart page ) automatically includes the proxy container when you select the built-in Traefik option during the interactive setup prompts. For existing deployments, follow the migration guide to add the proxy container, configure the Traefik Docker labels that route requests to the NetBird proxy container (the migration guide provides the exact label configuration), and generate an access token (from the NetBird dashboard under Settings > Access Tokens; this token authenticates the proxy container to your management server via gRPC).

DNS setup requires three records: an A record pointing to your VPS public IP, a CNAME pointing to , and a wildcard CNAME pointing to . Each service you expose gets a subdomain like . For high availability, deploy multiple proxy instances and point multiple DNS A records at each host. No additional load balancer is needed. The proxy cluster provisions TLS certificates automatically via ACME (Let’s Encrypt), or you can supply static certificates with hot-reload support (Traefik detects certificate file changes and reloads them without restarting the container). All of this is meaningful operational lift compared to .

Once the proxy cluster is running, any peer on the mesh can instantly publish a local port using , a single-command workflow that competes directly with Cloudflare Quick Tunnels. The next section compares both ephemeral exposure models in detail.

Migrating away is relatively contained: your DNS records, TLS certificates, and domain remain under your control, so swapping the proxy container requires only reconfiguring Traefik routing rules, with no DNS migration or certificate re-issuance.

Cloudflare

Cloudflare Tunnel’s setup is as simple as it sounds. Install (a single binary or Docker image), authenticate with your Cloudflare account, and run two commands:

You can alternatively define ingress rules in or through the Cloudflare Zero Trust dashboard. TLS is automatic. The global edge handles high availability transparently across hundreds of locations worldwide. No VPS, no DNS wildcard records, no container orchestration.

The trade-off is ownership: since you run no infrastructure, you control none of it. Outages are Cloudflare’s to fix on their timeline. The free tier (Cloudflare Zero Trust free tier supports up to 50 users) covers most individual and small-team use cases; paid plans (Cloudflare One) add advanced Gateway policies, device posture checks, and expanded logging. At scale, per-seat pricing for Zero Trust features can become meaningful.

When you eventually migrate, plan to reconfigure DNS, re-issue certificates, and rebuild access policies. Managed-edge services carry inherent lock-in to their control plane.

Privacy, data sovereignty, and ecosystem lock-in

Data sovereignty and ecosystem lock-in drive most self-hosters toward alternatives. Each tool makes a different architectural choice about where that control sits.

NetBird

TLS terminates on infrastructure you control. NetBird uses a dual-license model: BSD-3-Clause for client components and AGPLv3 for server-side components (management, signal, and relay servers, since v0.53.0). The company is headquartered in Berlin, building with a GDPR-first design philosophy. Your service URLs live on your domain (custom or cluster-based). No traffic passes through a third-party CDN. The ecosystem dependency is limited to NetBird itself; if you self-host, you can keep running your deployment even if NetBird changes direction.

NetBird Reverse Proxy is available on both NetBird Cloud and self-hosted deployments, so you can choose the operational model that fits your requirements: fully managed via Cloud, or full infrastructure ownership via self-hosting.

Cloudflare

Cloudflare maintains a strong security reputation and a clear privacy policy. The client is open source, providing transparency into the tunnel endpoint. That said, TLS terminates at Cloudflare’s edge, giving them technical access to decrypted traffic. The control plane is a proprietary SaaS: your tunnel configurations, DNS records, and certificates are all managed through Cloudflare’s dashboard.

The lock-in has a functional dimension as well: Cloudflare’s Terms of Service restrict tunnel use for large non-web traffic, including video streaming, which limits the architecture for self-hosters running media servers such as Plex or Jellyfin.

The architecture you choose reflects the trust model your workload requires: third-party edge management or full infrastructure ownership.

Ephemeral CLI exposure: netbird expose vs. Cloudflare Quick Tunnels

Sometimes you don't need a permanent tunnel. You just need to share a local service for thirty minutes so a colleague can review a staging build, a webhook provider can reach your dev endpoint, or a client can preview a demo. Both NetBird and Cloudflare offer single-command solutions for this use case, but the two approaches differ in authentication, domain control, and operational model.

NetBird

is built into the same agent that manages your WireGuard mesh, so there is no separate daemon or additional binary to install. When a developer runs , the agent registers an ephemeral service with the proxy cluster over the existing gRPC channel, and the proxy begins forwarding traffic through the WireGuard tunnel to . The session stays alive with a 30-second keep-alive heartbeat and expires after a 90-second TTL if the heartbeat stops, or immediately on Ctrl-C.

Because the proxy cluster already has authentication configured, every exposed port inherits those auth settings by default. A colleague clicking the generated URL will be prompted to authenticate via SSO, password, or PIN before reaching the service, with no extra configuration required. This is the key differentiator: ephemeral does not mean unauthenticated.

Domain control is another advantage. By default, exposed services get a subdomain under your proxy cluster domain (e.g., ). The flag lets you choose a human-readable prefix (e.g., ), and maps the session to a fully custom domain you control. All sessions appear in the NetBird management audit log, providing visibility into who exposed what and when.

The prerequisite is a running NetBird deployment with the proxy cluster configured, either on NetBird Cloud or self-hosted. This is not a zero-to-exposed-in-one-command experience, but it is a one-command experience once your network is in place.

Cloudflare

Cloudflare Quick Tunnels are the fastest path from zero to a public URL. Run and you get a random URL in seconds with no account, no configuration, and no DNS setup. For a developer who needs to test a webhook integration or share a prototype with someone outside the organization, the friction is essentially zero.

The trade-offs mirror that simplicity: Quick Tunnel URLs are public with no authentication, you cannot choose the subdomain, and there is no audit trail. Anyone with the URL can access the service for as long as the process is running. For sensitive services like admin panels, staging environments with real data, or internal tools, this is a non-starter.

Upgrading from a Quick Tunnel to an authenticated, named tunnel requires creating a Cloudflare account, configuring as a persistent daemon, setting up Cloudflare Access policies, and managing DNS records, which is a meaningfully larger operational jump than moving from to a permanent NetBird Reverse Proxy service, where the infrastructure and auth model are already shared.

The choice maps to the same trust-model question that runs through this entire comparison: if your ephemeral sharing needs authentication and audit logging, provides both out of the box. If you need zero-friction, public-only sharing with no account setup, Cloudflare Quick Tunnels are unmatched.

When each fits best

At one or two exposed services, Cloudflare’s zero-infrastructure model is objectively simpler. At five to ten services across environments, DNS entry, policy, and migration overhead begins to accumulate. At fifteen-plus services with data residency or compliance constraints, the control-plane ownership argument for self-hosted architecture becomes an operational necessity, not a philosophical preference.

NetBird Reverse Proxy fits best when:

• You self-host NetBird already. The proxy is a natural extension of your existing mesh; you add no new infrastructure.
• Data privacy is non-negotiable. You need TLS to terminate on infrastructure you control, not at a CDN edge you do not own.
• Your workloads include UDP. Neither NetBird's Reverse Proxy nor Cloudflare Tunnel exposes UDP to the public internet. However, NetBird's WireGuard mesh carries UDP natively between authenticated peers, so if your UDP services (game servers, VoIP) only need to reach users already on the mesh, NetBird covers that use case without an additional tool.
• You’re running services that Cloudflare’s ToS restricts. Media servers and high-bandwidth non-web apps (video streaming, large file distribution) are technically tunnelable but violate Cloudflare's ToS. NetBird imposes no such content restrictions.
• EU data residency matters. NetBird’s Berlin headquarters and GDPR-first design provide a built-in compliance posture that Cloudflare does not offer by default.
• You want full open-source control. NetBird uses a dual-license model: BSD-3-Clause for client components and AGPLv3 for server-side infrastructure (management, signal, relay). Self-hosting the full stack means no SaaS dependency for core functionality.
• You need authenticated ephemeral sharing. lets any peer share a local service with one command, with SSO/password/PIN auth and audit logging inherited from the proxy cluster, with no extra configuration.

Cloudflare Tunnel fits best when:

• Speed of setup is the priority. If you need a service exposed in five minutes with no infrastructure to manage, Cloudflare Tunnel has no real competition for that use case.
• You need global CDN performance. Cloudflare’s global edge accelerates content delivery in ways a self-hosted proxy cluster cannot replicate.
• You do not yet run a NetBird deployment. Standing up NetBird + Traefik + the proxy container to expose one service is likely overkill.
• Cloudflare Gateway policies add value. If you need HTTP inspection, threat intelligence, or DLP at the edge, Cloudflare’s integrated stack is mature and battle-tested.
• NetBird’s beta status is a blocker. The Reverse Proxy feature is currently in beta.
• You need zero-account ephemeral sharing. Cloudflare Quick Tunnels () give you a public URL in seconds with no account, no DNS, and no configuration, making it ideal for quick webhook tests or public demos.

If NetBird’s model fits your use case, the self-hosted setup guide at docs.netbird.io/manage/reverse-proxy walks through the proxy container deployment from scratch. If you are evaluating Cloudflare Tunnel, the quickstart is at developers.cloudflare.com/cloudflare-one/connections/connect-networks/ .

Both tools eliminate the port-forwarding problem. If data sovereignty and infrastructure control are requirements, NetBird's self-hosted architecture provides both. If zero-infrastructure simplicity is the priority, Cloudflare Tunnel remains the fastest path to a working HTTPS endpoint.