Three-step tunnel setup from the dashboard

Cloudflare Tunnel — the service that connects infrastructure to Cloudflare's edge without opening inbound ports — is getting a major usability overhaul. The company announced that what previously took up to 14 terminal commands can now be done in three steps from the Zero Trust dashboard.

The change targets a fundamental tension in Cloudflare's product design. The CLI gives precise control but demands users memorize commands and syntax. The dashboard, by contrast, lets users learn by doing, with guided flows and human-readable error messages. As Cloudflare's tunnel product has grown from fewer than ten commands to a much larger library, that CLI learning curve has become a real barrier for new users.

The workflow itself is straightforward: name the tunnel, copy the installation script generated for the origin's operating system and architecture, and specify either public hostnames or private network routes. If you enter an invalid IP or CIDR block, the dashboard catches it immediately with an actionable error instead of failing silently at runtime.

Eliminating local configuration overhead

Two longstanding pain points are being removed from the tunnel management process: local configuration files and certificate token management.

Previously, most tunnel use cases required manually creating and populating a cloudflared configuration file, often by copying examples from developer documentation. With functionality added over time, those files became unwieldy — understanding which parameters belonged where was error-prone and difficult to troubleshoot. With the new dashboard approach, Cloudflare manages the configuration server-side based on the inputs you provide.

The token model simplified as well. Previously, users had to manage two credentials: cert.pem, which granted the ability to create, delete, and list tunnels via CLI, and Tunnel_UUID.json, which granted the ability to run a specific tunnel. Since tunnels are now created directly from an authenticated Cloudflare session in the dashboard, the origin no longer needs to be authenticated beforehand — that happens during the initial login. Cloudflare also handles token rotation on the user's behalf when refreshes become necessary.

Two deployment paths, one tunnel

Cloudflare Tunnel serves as the on-ramp to the company's Zero Trust platform, and the new dashboard flow supports both clientless and client-based approaches.

Clientless Zero Trust

Pairing Tunnel with Access enables clientless Zero Trust. Users create public hostnames in the dashboard flow, which now replace the ingress rules that previously lived in configuration files. Each public hostname maps to a service behind the origin, and Access policies then enforce identity-based rules on every request.

Client-based Zero Trust

For organizations preferring the WARP client with Gateway, the dashboard flow instead calls for adding a private network — replacing the cloudflared tunnel route ip add <IP/CIDR> CLI step. Two Gateway rules are sufficient to begin testing:

  • A rule allowing <IP/CIDR> as long as the destination IP matches and the user email matches the policy
  • A default deny rule blocking the same destination IP range

A single tunnel can serve both public hostnames and private networks simultaneously, so most deployments only need one. Cloudflare recommends starting with a single tunnel and using replicas for redundancy rather than creating additional tunnels — only adding more when services or networks genuinely require logical separation.

Migration and future work

With hundreds of thousands of tunnels already created, migration to the new orchestration method is a priority. Cloudflare is building tooling to convert locally managed configurations to Cloudflare-managed ones, expected within a few weeks.

Until that migration wizard ships, two notes for existing users: the dashboard doesn't yet support the global configuration options documented elsewhere, so adjusting cloudflared logging levels still means appending the --loglevel flag to the tunnel service start command. And supporting those global options incrementally is a stated next step after migration tooling is released.