A permanent fix for ephemeral connections

Argo Tunnel was designed to let Cloudflare proxy traffic to your origin without exposing a publicly routable IP address. A lightweight daemon runs in your infrastructure and makes outbound-only connections to Cloudflare's edge, so attackers never get a direct path around Cloudflare's security filters. All requests to your resources pass through Cloudflare's network first.

But the original architecture conflated two very different kinds of objects: persistent ones like DNS records, and ephemeral ones like the live connections from cloudflared to Cloudflare. That conflation created real problems. When a connection dropped, cloudflared had to recreate the entire deployment, including re-registering DNS records from scratch. A simple restart could become an outage if any upstream service was degraded at the wrong moment. Control plane issues could even turn into edge issues for Tunnel users, because Tunnel creation and management were tied to the control plane.

That's changing today. The new Argo Tunnel architecture decouples DNS management from connection management, introduces the concept of named Tunnels with permanent UUIDs, and treats Tunnel connections like true origin servers — without ever exposing them to the public Internet.

The problem with conflating permanent and ephemeral state

Cloudflare runs on two components: the anycast edge network spread across 200 cities, and the control plane that manages configuration. The edge is built to stay healthy even if the control plane degrades — it keeps serving traffic from the last known configuration. The original Argo Tunnel didn't respect that boundary.

Every connection attempt, whether it was the first or the hundredth, repeated the same high-level sequence:

  1. cloudflared connected to an Argo Tunnel service in the control plane, which registered the Tunnel and its connections.
  2. cloudflared created a public DNS record pointing to a randomly generated CNAME (for load balanced Tunnels) or an IPv6 address (for traditional Tunnels).
  3. The control plane pushed those DNS entries to the edge so traffic could be routed to cloudflared.
  4. If the Tunnel disconnected for any reason, the Argo Tunnel service unregistered the Tunnel and deleted the DNS record.

That last step was the killer. Most Tunnels run services meant to be available indefinitely — the DNS record should be permanent. But any restart meant going through the whole flow again, and cloudflared would fail to reconnect if any upstream service had issues. You also couldn't change a Tunnel's DNS record gracefully; you had to stop cloudflared and rerun it. Visibility was limited, and load balancing introduced complications around origin counting.

Phase 1: stability first

Before rolling out the new architecture, the team quietly fixed the stability layer. Argo Tunnel migrated to Cloudflare's Unimog edge load balancer, which increased the average connection lifetime from minutes to days. Fewer restarts meant fewer opportunities to hit upstream failures. Additionally, reconnecting Tunnels could now opportunistically reuse records already present at the edge instead of following the full creation flow every time.

Those changes made the platform dramatically more stable, but two core issues remained: reconnections were still treated like brand-new connections, and managing connections still required too much friction.

Phase 2: named Tunnels that outlive connections

The new architecture separates DNS record creation from connection creation. With cloudflared tunnel create, you assign a permanent, stable name to a Tunnel — not necessarily a hostname. It could represent the application, the server, or the cloud environment where it runs. Cloudflare associates that name with a UUID that never changes for the life of the Tunnel.

Once a named Tunnel exists, you can point any DNS record in your account to a stable subdomain backed by that UUID. Because the name and UUID are persistent, your DNS record never needs to be cleaned up or recreated when the Tunnel restarts. In the event of a disconnect, cloudflared simply reconnects to the same UUID address.

Named Tunnels behave like origins in the control plane, but with a critical constraint: they can only be reached through a DNS record in your own account. You can delete a DNS record, create a new one pointing to the UUID address, and traffic will start flowing — all without restarting cloudflared.

Working with named Tunnels

You'll need cloudflared version 2020.9.3 or later. The new architecture is fully backwards compatible with the legacy model.

Login and create

Run cloudflared tunnel login and authenticate to your Cloudflare account. This generates a cert.pem file containing a token that authorizes your cloudflared instance to create named Tunnels and manage DNS records.

Next, run cloudflared tunnel create <name>. This creates a Tunnel with your chosen name and a UUID. The name is account-scoped: only DNS records in your account can proxy traffic to the connection. It will not be removed unless you explicitly delete it, no matter how many times the connection stops and restarts.

Credentials, not certificates

Creating a named Tunnel generates a credentials file that is distinct from the cert.pem issued at login. To run the Tunnel, you only need the credentials file. If you've already created your Tunnels and DNS records, you can delete cert.pem from your environment entirely — that avoids leaving API tokens and certificates on your servers. The credentials file contains a secret scoped to the Tunnel's UUID, which cloudflared uses to establish a TLS connection from your infrastructure to Cloudflare's edge.

If you want to hand off the Tunnel to another team member, you can share the credentials file alone. cert.pem is still required to create additional Tunnels, list existing ones, manage DNS records, or delete Tunnels.

Configure and run

Configure your cloudflared instance with the URL it should proxy traffic to. Then run cloudflared tunnel run <name> or cloudflared tunnel run <UUID>. If you're running without cert.pem, you must use the UUID form of the command.

Routing traffic

There are two ways to send traffic to your named Tunnel. In the Cloudflare dashboard, you can create a DNS record pointing to UUID.cfargotunnel.com as a long-lived CNAME-style target. The same address works in the Cloudflare Load Balancer panel — a named Tunnel appears as just another origin in a pool.

Alternatively, do it from the command line: cloudflared tunnel route dns <name> <hostname> (or use the UUID variant). This works only for the zone you authenticated with. Unlike the old architecture, a disconnect will not delete this DNS record.

Verifying and cleaning up

A few management commands round out the new model:

  • cloudflared tunnel list — view all Tunnels and their connection status
  • cloudflared tunnel delete <name> or cloudflared tunnel delete <UUID> — remove a Tunnel (requires cert.pem)

The new architecture is available today. The separation of DNS state from connection state makes Argo Tunnel more stable, easier to manage, and finally treats the tunnels that run your infrastructure like the permanent objects they were always meant to be.