Tailscale vs Cloudflare Tunnel for self-hosted services

Get to your apps without opening the door to everyone. Choose Tailscale when a known set of clients needs private access to a self-hosted application. Choose Cloudflare Tunnel with Cloudflare Access when people should reach a protected web application through an ordinary browser. Cloudflare also supports private network routes; pick the access model that fits your audience.

Facts from official product documentation; service.example is a placeholder.

Start with the audience, not the tunnel

Requirement	Starting point	What must be explicit
Private access for enrolled clients	Tailscale	Enrollment, least-privilege policy and application authentication
Browser access to a published web app	Cloudflare Tunnel plus Access	Access application and policies before publishing the route
Private access through Cloudflare’s network	Private network routes	Client/network enrollment, routing and Gateway policies
Public sharing through Tailscale	Funnel	Public visitors are not private tailnet members; application authentication is still needed
Operating the private control plane yourself	Headscale	Hosting responsibilities and the project’s compatibility limits

Choose the audience first, then set permissions. Encryption protects the connection; access policies decide who gets in.

How the traffic reaches the application

Tailscale: private peers, with relays when needed

Tailscale coordinates a private network of enrolled devices, called a tailnet. Its clients use WireGuard encryption and try to connect directly; when a direct connection is unavailable, DERP relays can carry the encrypted traffic. Tailscale’s security documentation describes these direct and relayed paths.

Your application’s reachable interface and its access policy must both permit the intended connection. Merely joining a tailnet does not configure the application itself. Visitors normally need an enrolled client or an approved routed path; joining does not automatically create a public browser endpoint.

Serve and Funnel are different exposure choices. Serve keeps the served resource within the tailnet. Funnel makes a resource reachable from the broader Internet. Permission to enable Funnel controls who can publish through it, not which public visitors can sign in to the application.

Cloudflare: a connector and a deliberate route type

With Cloudflare Tunnel, the cloudflared connector initiates outbound connections to Cloudflare. This avoids requiring a directly reachable public origin, but the route still needs an access decision. Reducing direct inbound exposure does not remove the application’s attack surface.

For a published application, a public hostname maps to a service behind the connector. A hypothetical browser request for service.example reaches Cloudflare’s edge and is forwarded through that connector. Ordinary web visitors can use a browser; do not extend that convenience claim to every supported protocol. Published non-HTTP services can require client-side software.

For private network routes, users connect their device or network to Cloudflare and enroll in the Zero Trust organization. Cloudflare One Client is the common device method. This can carry private HTTP and non-HTTP resources, with Gateway network policies controlling access. It is a different architecture from putting an Access login in front of a public hostname.

Authentication is a separate decision

For Tailscale, review the actual grants or ACL policy after enrollment. The documented most-permissive default permits connections between tailnet devices. Do not assume that a private network automatically isolates each application from every other member. Restrict the identities and resources that should communicate, and retain appropriate application authentication.

For Cloudflare’s published web-app path, Tunnel alone does not provide a visitor login. The Access setup guide warns that a published application without an Access application is available to anyone on the Internet. Cloudflare recommends creating Access before the tunnel route.

Define who is allowed in, rather than merely confirming that a login screen appears. Follow the same documentation’s requirement to validate the Access application token through cloudflared or the origin. That prevents a request bypassing the intended Access path from being accepted solely because it reached the application.

Then test the actual client. A browser-friendly identity flow may not suit an automated or native client. An Access identity decision is also distinct from an application’s own account permissions: getting through the front door should not automatically make someone an administrator.

What each provider can see

Private Tailscale traffic: encrypted payloads, visible metadata

Tailscale says its WireGuard payloads remain end-to-end encrypted even through DERP, and the relay cannot decrypt them. The hosted service still collects account, device and connection metadata to coordinate the network. Its security page explicitly distinguishes metadata from application data.

That is a useful trust boundary, not anonymity or an absence of control-plane trust. Consider who can enroll devices, change policies and recover the administrator account. Encryption does not protect an application from an authorized endpoint that is compromised or given excessive permissions.

Funnel has a different audience but also a relevant encryption distinction: its documentation says the relay cannot decrypt the visitor’s traffic and TLS terminates on the publishing device. That does not make public visitors authenticated tailnet members.

Public Cloudflare HTTP proxy: the edge can process HTTP content

Cloudflare’s TLS concepts distinguish the edge certificate presented to visitors from a separate HTTPS origin leg. Combined with the documented HTTP reverse-proxy route, the architectural implication is that Cloudflare terminates visitor TLS and can process HTTP request and response content at the edge.

Re-encrypting traffic toward the origin protects that leg; it does not make the HTTP content opaque to the reverse proxy. Content visibility depends on the product and protocol; edge processing and logging every request body are different things.

Private Cloudflare routing: protocol and inspection settings matter

Do not copy the public-proxy conclusion onto all private traffic. The Gateway TLS-decryption documentation says encrypted HTTPS content, including the full URL, headers and body, is not visible to Gateway without TLS decryption. Plain HTTP does not have that protection.

When configured with the required client certificate trust, Gateway can decrypt HTTPS for inspection and then re-encrypt it. Review the actual routing, application protocol and inspection configuration before making a privacy claim. “Encrypted tunnel” and “provider cannot process the application’s content” are different statements.

Current prices and free-tier limits

Provider list prices below were checked on October 18, 2026. They describe different products and entitlements, not equivalent bundles.

Tailscale Personal: $0 for eligible non-commercial use, up to 6 users, unlimited user devices, up to 3 ACL groups, 50 tagged resources and 1,000 ephemeral-resource minutes per month. Unlimited user devices is not an unlimited tagged-resource allowance. The pricing page lists additional tagged resources at $1 each per month. Ephemeral minutes count a resource’s lifespan; they are not a monthly limit on ordinary remote-access sessions.

Tailscale paid plans: Standard is $8 per user per month, Premium $18 per user per month, and Enterprise is custom. The current pricing is seat-based, with separate resource/add-on considerations. Do not assume a business workload qualifies for Personal simply because its user count fits.

Cloudflare Zero Trust: the current plan comparison lists Free at $0 with a 50-user limit, Pay-as-you-go at $7 per user per month, and Contract at custom annual per-user pricing. Those user counts belong to the identity-access plans; connection and traffic limits are separate. Tunnel itself is documented as available on all plans; paid security features, support, domains and other services remain separate considerations.

For a simple arithmetic check, the following examples assume a selected paid plan and the stated number of billable seats for a full month:

Assumed billable seats	Tailscale Standard	Tailscale Premium	Cloudflare Pay-as-you-go
10	$80.00	$180.00	$70.00
60	$480.00	$1080.00	$420.00

These are hypothetical billed-seat examples, not a recommendation to buy a paid tier when an eligible free tier already fits. The formula is billable seats × monthly rate; it does not subtract the free plan’s user cap from paid seats. The examples exclude proration, additional resources, domain registration, identity-provider charges, hosting, electricity and tax. Actual plan features and billing definitions still need checking before purchase.

Media and bandwidth: public routes are not private routes

Cloudflare’s current video-delivery guidance explicitly distinguishes Tunnel public-hostname routes from private network routes. Public-hostname traffic on the named Free, Pro and Business website plans is subject to its media/content restrictions. The same page says the restriction does not apply to private network routes.

The CDN terms describe appropriate specific paid services for video and large-file delivery and reserve the right to limit service for video or a disproportionate share of pictures, audio or other large files without those services. The video guidance names Stream and Enterprise Stream Delivery as options. A paid Zero Trust seat is not, by itself, permission to use an ordinary published hostname as an unrestricted media CDN.

For private workloads, Cloudflare’s private-network documentation specifically discusses large-file transfers, backups and high-traffic media workloads under that separate routing model. Other applicable terms and limits still matter. Adding Access authentication to a published hostname, or changing its cache policy, does not change that route into private networking.

Choose the route under its own product terms. The cited public-route guidance gives no universal safe bandwidth or percentage threshold.

On Tailscale, the Funnel limitation is specifically non-configurable bandwidth limits. Apply that limit to Funnel; assess ordinary private Tailscale paths separately. Measure the route you plan to use: direct, relayed and public-sharing paths can behave differently.

Headscale: self-hosting the control plane

Headscale’s feature matrix describes an open-source, self-hosted alternative to the Tailscale control server. It supports core private-network functions such as ACLs, grants, OIDC registration and an embedded DERP relay. Compatible clients still need an enrollment and policy design.

The matrix marks Funnel, Serve and network flow logs as unsupported. Use the feature matrix for your installed version. In particular, do not choose Headscale while assuming it supplies a supported Funnel replacement for browser visitors.

Self-hosting means taking responsibility for the control service’s availability, updates, backups and recovery. It does not automatically make every relay or identity dependency self-hosted. Budget those dependencies and the operating work rather than assuming a zero-cost replacement.

Installing cloudflared on your own server is a different arrangement: you operate a connector into Cloudflare’s managed network, not a self-hosted Cloudflare edge. Headscale is an option for private-network control-plane ownership, not software for reproducing Cloudflare’s hosted proxy service.

Your access checklist, and when using both makes sense

Before committing to either design:

1. Write down whether the audience is enrolled private clients, browser visitors, or both. Use disposable test data.
2. Choose the route before the authentication flow. Decide whether publishing a public address is actually necessary.
3. Review least-privilege policies and application permissions. For Access-protected apps, follow the documented token-validation path.
4. Check from an authorized client, a signed-out browser and a deliberately unauthorized test identity. Verify that the unauthorized identity is denied.
5. Review provider visibility, any TLS inspection, media terms and the actual client’s authentication compatibility.
6. If performance matters, record the date, route type, client software and test method. Distinguish direct from relayed connectivity; measure instead of treating subscription price as a speed rating.

A mixed design can use private connectivity for a restricted administrative audience and an independently protected public web-app path for browser visitors. Define the boundary deliberately: if both paths reach the same application, consider what a user on either path can bypass. Using both products does not automatically add another effective layer of authorization.

Network reachability also does not decide where an application processes its data. Our cloud versus local speech guide covers that separate privacy boundary. If system availability is the concern, boot-recovery testing is a separate task from access control; those measurements are not remote-access benchmarks.

Choose the simplest access model that meets the audience and trust requirements. Use Tailscale for a private-client workflow when it fits, Cloudflare’s published path with explicit Access policies for suitable browser workflows, or its private routing when that model fits better. Choose Headscale when owning the control plane is worth the additional operating work.

Taking that private access on holiday? Our Beryl 7 vs Beryl AX travel-router guide matches hotel Wi-Fi sharing, USB-C power and a VPN route home to the router you actually need.