Cloudflare Tunnel vs Tailscale: Public vs Private Access

Choose by who needs to connect

Cloudflare Tunnel connects your server to Cloudflare’s network, while Tailscale creates a private network between enrolled devices. The practical difference is who can reach your application and what they must install. A visitor opening your public website should need only a browser; an engineer administering your VPS can reasonably install a networking client.

For a single VPS running Ubuntu 24.04 LTS, we would usually choose Tailscale for administration and consider Cloudflare Tunnel separately for public web traffic. You can run both because they serve different audiences. Installing either product does not decide which applications should be public.

Write down the audience before comparing features. A deployment dashboard used by your engineers has different access requirements from a webhook receiver called by an external service. Putting both behind the same login policy can either expose the dashboard or break webhook delivery.

Use Tunnel when visitors need a public hostname

The server-side connector, cloudflared, initiates outbound connections to Cloudflare. Requests reach Cloudflare and travel through those connections to your configured service, so the origin does not need an inbound public web listener. Tunnel also supports private network access through Cloudflare’s wider access stack; public publishing is one deployment choice. See the Cloudflare Tunnel architecture.

For a small public application, we would keep the application listening on loopback and point the connector at that local listener. If you already have a reverse proxy routing several applications, the connector can target that instead. Keep the arrangement understandable enough that another engineer can trace a request without opening several dashboards.

A tunnel does not remove an existing public listener or rewrite your firewall policy. If the same application remains reachable through the VPS address, visitors may still have a route around your intended entry point. Check the actual listening addresses and externally reachable ports after changing the routing.

Keep application routing separate from availability planning. A connector on your only VPS cannot keep the application online when that VPS fails. Our explanation of where reverse proxies, load balancers and CDNs belong helps you decide which additional component would solve an actual problem.

Add Access before publishing an internal web tool

Cloudflare Tunnel is not an authentication policy. For an internal web tool, create a Cloudflare Access application covering the intended hostname and allow only the required identities before publishing the route. Configure Access token validation at the connector or application as described in Cloudflare’s protected application procedure.

This is a good fit when someone needs a browser dashboard but should not join your server network. Keep permissions specific to that application, especially for contractors. Retain application authorization where different users can perform different actions; passing an identity check should not automatically make everyone an administrator.

Treat machine callers separately from browser users. A webhook sender cannot normally complete an interactive login, and an automation job should not depend on somebody’s browser session. Use machine authentication supported by the caller, or a deliberately public endpoint that validates signed requests.

After configuring the policy, open the hostname in a clean browser session and attempt access with an identity outside the allowed group. Also attempt to reach the application through its previous public origin address. Perform these checks before sending the URL to anyone.

Use Tailscale for private administration

Enroll your laptop and VPS in the same Tailscale network, called a tailnet, when you want private administrative connectivity. Start with ordinary SSH over that network and keep your existing SSH authentication. Tailscale SSH is a separate feature with its own authorization configuration; you do not need to adopt it just to connect privately.

Inspect the tailnet policy before enrolling additional people. New tailnets start with a broad allow policy, so membership alone does not provide the separation you probably want. Replace broad permissions with specific access to required destinations and ports, using grants for new configurations; the official policy examples explain the initial defaults.

For example, allow your operations group to reach SSH on the production server while keeping database access limited to the people who need it. Review existing broad rules when adding narrower ones, because an existing permission can still allow the connection. Keep database credentials and operating-system accounts independently restricted.

A loopback-only application will not become directly reachable through the server’s Tailscale address. For a private web dashboard, use Serve as the intermediary to that local listener; for direct service access, deliberately choose its listening address and firewall rules. Our Tailscale review provides additional context for choosing it as your team’s private access layer.

Verify a fresh SSH connection over Tailscale before tightening public SSH access. Keep your existing session open and confirm that the hosting provider’s console works independently. A network policy change should never leave your only recovery instructions trapped on the inaccessible server.

Choose Serve or Funnel deliberately

Serve is for tailnet access; Funnel publishes to the internet. Funnel visitors do not need Tailscale installed, and permissions controlling who may enable Funnel are not visitor authentication. Funnel uses names within your tailnet’s domain and has bandwidth limits you cannot configure, so check those constraints before selecting it. The Funnel documentation describes both the exposure model and its limits.

We would consider Funnel for a short-lived demonstration of an application already running on a Tailscale device. We would choose a public web entry point designed around our own domain for an enduring customer-facing application. That decision follows the hostname and operational requirements, rather than assuming that every public tunnel is interchangeable.

Keep a private dashboard on Serve unless you have explicitly decided it can receive public requests. Changing the publishing mechanism does not add a login screen to the application. Before enabling Funnel, inspect the whole application for administrative routes and sensitive content, including routes that are absent from the navigation.

For a Cloudflare Tunnel alternative, first identify what you want to replace. Tailscale is a strong candidate for private connectivity, and Funnel is a candidate for limited public publishing. Neither choice automatically reproduces your existing Cloudflare authentication policies or web traffic controls.

Keep a conventional reverse proxy when it fits

On a VPS with a public address, you may not need a public tunnel. Caddy or Nginx can accept HTTPS connections and forward requests to a local application. We would keep an existing, understandable reverse proxy unless a tunnel solves a concrete origin-access or operational requirement.

This leaves you responsible for the public listener and its protection. A private Tailscale administration path can coexist with that arrangement, so adopting Tailscale does not force a website migration. Use the Caddy versus Nginx comparison when the real decision is which reverse proxy to operate.

If your reason for replacing Tunnel is reducing dependence on an external access provider, moving to another managed connectivity service may not satisfy it. Specify whether you need control over public ingress or over the private network’s coordination service. Those requirements lead to different designs and different maintenance work.

Keep recovery and agent permissions independent

Treat account recovery as part of server access. Losing an identity-provider account or applying a mistaken access policy can stop an engineer from reaching a healthy application. Store recovery information outside the protected application and document who can restore access when the usual administrator is unavailable.

Monitor the application from the audience’s side of the connection. A healthy connector process does not prove that the public hostname works, and an online tailnet device does not prove that the intended user can reach SSH. Pair service health checks with a request through the actual access path.

We recommend Claude Code for inspecting sanitized configuration and drafting narrowly scoped changes. Keep approval for public exposure and access-policy changes with a human, and grant the agent only the permissions needed for the current task. The guide to letting an agent work with Cloudflare under limits explains how to set that boundary.

Do not paste connector credentials or enrollment secrets into an investigation transcript. Have the agent describe the intended configuration diff and rollback before applying an authorized change. A request to make a dashboard reachable should include its allowed audience, so the agent does not have to infer whether public access is acceptable.

Move a low-risk service and prove the boundary

Choose a non-sensitive dashboard as your first migration on Ubuntu 24.04 LTS. Record its current listening address, intended audience and recovery path before changing anything. Preserve a copy of the relevant configuration so rollback restores known settings.

Create the narrow access policy and connect the service through your chosen route. Use Tunnel with Access for authenticated browser access, or Tailscale Serve when all intended viewers have enrolled devices. Leave existing administrative access available while checking the new path.

Attempt access as an unauthorized user and from outside the tailnet where applicable. Then remove obsolete public exposure for that dashboard and repeat the external-origin check. Preserve any public listener that is intentionally serving a different application.

Record the working route and the exact reversal procedure in your operations notes. Schedule the next service only after another team member can use the new path and locate the recovery instructions. If you operate alone, perform that recovery walkthrough from your laptop before changing SSH exposure.