Tunnel Connectors That Share the Load

Cloudflare Tunnel lets you connect services and private networks to Cloudflare without opening inbound ports in your firewall. The connector, cloudflared, establishes outbound connections to the Cloudflare edge, and all traffic to your origin is proxied over those existing connections. This means your origin server doesn't need a public IP address or any inbound allowances—requests can't bypass Cloudflare to reach it directly.

Until now, a Cloudflare Tunnel was tied to a single running instance of cloudflared. That made it a potential single point of failure and a bottleneck for teams that needed to scale or redeploy their connectors. As of today, you can run the same tunnel from multiple cloudflared instances at once. Each instance, identified by its own connector ID, represents the same tunnel, and the edge distributes traffic across all running connectors.

Setting up a tunnel remains a single command:

cloudflared tunnel create --name mytunnel --url http://localhost:8080 --hostname example.com

That creates a tunnel named mytunnel and maps example.com to it. When Cloudflare receives a request for that hostname, it routes the request over one of the live connections belonging to mytunnel, and cloudflared proxies it to localhost:8080. The tunnel's DNS record or Load Balancer entry still points to the same unique tunnel ID, but that ID now resolves to one or more identical cloudflared processes.

When you launch an instance of cloudflared, it logs its connector ID:

BLOG-471 Embedded Image - FMCNSh

You can also inspect which connectors are currently running a tunnel with the new cloudflared tunnel info command:

2021-03-29T18:40:17Z INF Starting tunnel tunnelID=610a53bd-ed0c-4afe-92b5-ca0238153410
2021-03-29T18:40:17Z INF Version 2021.3.5
2021-03-29T18:40:17Z INF GOOS: darwin, GOVersion: go1.16.2, GoArch: amd64
2021-03-29T18:40:17Z INF Generated Connector ID: 14e2e624-0d32-4a21-a88c-64acf9484dac

There's a limit of 100 simultaneous connectors per tunnel. If you need more than that, you can request an increase by contacting support.

What Multiple Connectors Enable

Zero-Downtime Configuration Changes

Changing cloudflared configuration previously meant restarting the process, which caused downtime while the connector stopped, reconnected, and resumed accepting traffic. With replicated connectors, you can start a second instance with the new configuration. Once it's live and receiving traffic, stop the old one—it stops accepting new requests, drains in-flight connections, and exits cleanly. The result is a seamless cutover with no downtime.

Elastic Scaling

When traffic spikes, your origin servers scale up—your connectors should too. You can now start additional cloudflared instances on demand without touching DNS, Load Balancer settings, or tunnel enrollment. The tunnel automatically spreads requests among the available connectors, so cloudflared doesn't become the thing that caps your throughput.

Simpler Kubernetes Deployments

Two standard Kubernetes workflows were previously broken with cloudflared: scaling a deployment horizontally by adding pods with identical configuration, and performing rolling upgrades where a new pod starts before the old one is removed. In both cases, the new pod would fail because its tunnel was already in use.

Now those patterns work. A common setup is to keep the origin server in a Kubernetes Service and run cloudflared as a separate Deployment. Its ingress rules point at the origin Service, and each scale independently:

  • Scale cloudflared up or down with the origin, as load dictates.
  • Deploy new configurations or versions by adding a pod, verifying health, then draining the old one.

Redundancy Without Extra Tunnels

cloudflared already opens connections to two different data centers, with two connections per data center, for resilience against edge failures. But if the local process died, traffic stopped. The previous workaround was to run two tunnels with identical configuration and put a Cloudflare Load Balancer in front of them—a manual and operationally heavy setup.

With multi-connector tunnels, you can simply run multiple instances of the same cloudflared, whether they're in the same rack or on different continents. No load balancer, no per-instance tunnel enrollment, and no single process to worry about.