cloudflared: Cloudflare Tunnel client and daemon

What cloudflared is

cloudflared is the command-line client for Cloudflare Tunnel. Its README describes it as a tunneling daemon that proxies traffic from the Cloudflare network to your origins. The daemon runs next to your service, for example on the same host as a web server, and Cloudflare attracts client requests and sends them to you through it, without you having to open holes in your firewall. In the README's words, your origin can remain as closed as possible.

The same binary does a second job on the client side. cloudflared access lets a user reach Tunnel-protected origins for TCP traffic at Layer 4, which matters for non-HTTP protocols such as SSH and RDP. The README notes that the WARP client can be used instead to reach private origins behind Tunnels without running cloudflared access commands on the client.

The repository is maintained by Cloudflare, written in Go and licensed under Apache-2.0. It is useful to be precise about the boundary: the client is open source, but it connects to Cloudflare's global network, which is a hosted service. You need a Cloudflare account for anything beyond Quick Tunnels, and production use of public hostnames requires a domain on Cloudflare. The project is aimed at developers and operators who want to publish internal web apps, APIs or development servers without public IPs or inbound firewall rules, and at teams using Cloudflare's Zero Trust products to replace VPN access to private networks.

How it works

Outbound-only connections

According to Cloudflare's documentation, cloudflared establishes outbound connections between your resources and Cloudflare's network. Because most firewalls allow outbound traffic by default, the daemon can connect out from the server it runs on, and once that connection exists traffic flows in both directions over the tunnel. You can then configure the firewall to allow only those outbound connections and block all inbound traffic, so the origin is reachable from nothing other than Cloudflare. The docs call this a positive security model: only the services listed in the tunnel configuration are exposed.

A tunnel is a persistent object identified by a UUID, the logical link between your origin and Cloudflare. Within one tunnel you can run as many cloudflared processes, called connectors or replicas, as you need, and each sends traffic to the nearest Cloudflare data center. Each running instance opens four outbound connections to four different servers spread across at least two data centers, so a single connection, server or data center can go offline without taking your service down.

Remotely and locally managed tunnels

Tunnels come in two management styles. A remotely-managed tunnel is created in the Cloudflare dashboard (or through the API): you name the tunnel, pick your operating system, copy the generated installation command and run it on the origin server, then add published application routes or private network routes in the dashboard. A locally-managed tunnel is created and configured entirely from the CLI: you authenticate cloudflared, which writes an account certificate, create a named tunnel, which writes a credentials file and a subdomain of cfargotunnel.com, and describe routing in a local YAML configuration file.

Ingress rules

For published applications, the configuration file maps hostnames to local services through ingress rules. Rules can match a hostname, a wildcard subdomain such as *.example.com, or a path regular expression, and point at HTTP, HTTPS, SSH and other services. A configuration with ingress rules must end with a catch-all rule. Matching does not rewrite requests: cloudflared forwards the full original path to your service, so path stripping has to happen at the edge with URL Rewrite Rules or in a local reverse proxy. In the absence of a configuration file, the docs say cloudflared proxies outbound traffic through port 8080.

Routing traffic to a tunnel

The README lists three ways to send traffic into a tunnel: public DNS records in Cloudflare (a CNAME pointing at <UUID>.cfargotunnel.com), a public hostname behind a Cloudflare Load Balancer, or private traffic from WARP clients routed to IP addresses and CIDR ranges behind the tunnel.

Key features

• No inbound ports: the origin needs only outbound connectivity, on port 7844 for tunnel traffic.
• Two transport protocols: quic over UDP and http2 over TCP, both on port 7844.
• Built-in redundancy: four connections per instance across at least two data centers, plus replicas for host-level failover.
• Public and private use: publish web applications on public hostnames, or route private IPs, CIDR ranges and private hostnames for Zero Trust network access.
• Layer 4 access: cloudflared access carries TCP protocols such as SSH and RDP to protected origins.
• Quick Tunnels: a temporary trycloudflare.com URL for a local service without a Cloudflare account or domain.
• Protected Quick Tunnels: since October 2026, an --allowed-mail flag requires visitors to pass an email one-time PIN before they reach the service.
• Flexible ingress rules: hostname, wildcard and path-regex matching to multiple local services from one tunnel, with optional URL normalization for rules that validate Cloudflare Access JWTs.
• Runs as a service: it can install itself as a system service on Linux and Windows and as a launch agent on macOS.
• Metrics: tunnel metrics such as total TCP and UDP sessions can be scraped to size deployments.
• Wide packaging: standalone binaries, Debian and RPM packages, Homebrew, Windows executables and MSIs, and a Docker image.

Getting started

On macOS, install with Homebrew; Linux users can add Cloudflare's apt or yum repository, Arch has a package, and binaries for all platforms are on the GitHub releases page:

brew install cloudflared

The fastest way to see it work is a Quick Tunnel. Start any local HTTP server on port 8080, then run:

cloudflared tunnel --url http://localhost:8080

cloudflared prints a random trycloudflare.com URL. Anyone with that URL can reach the service until the process stops. To restrict it to specific people, add an allowed email address, a comma-separated list or a quoted domain wildcard such as '*@example.com':

cloudflared tunnel --url http://localhost:8080 --allowed-mail [email protected]

For a durable, named tunnel managed from the CLI, the documented flow has the domain added to Cloudflare first, then authenticates, creates the tunnel and confirms it exists:

cloudflared tunnel login
cloudflared tunnel create <NAME>
cloudflared tunnel list

Next, create config.yml in the .cloudflared directory. Cloudflare's configuration reference shows a file that publishes two services and returns 404 for everything else:

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /root/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
ingress:
  - hostname: gitlab.widgetcorp.tech
    service: http://localhost:80
  - hostname: gitlab-ssh.widgetcorp.tech
    service: ssh://localhost:22
  - service: http_status:404

Then create the DNS record for a hostname, run the tunnel and check its status:

cloudflared tunnel route dns <UUID or NAME> <hostname>
cloudflared tunnel run <UUID or NAME>
cloudflared tunnel info <UUID or NAME>

The route command creates a CNAME pointing at <UUID>.cfargotunnel.com. For private networks, cloudflared tunnel route ip add routes a private IP or CIDR through the tunnel instead. Developers building from source need GNU Make, capnp and the Go version pinned in go.mod; the Makefile downloads that exact toolchain automatically:

make cloudflared

Running it in production

Cloudflare's sizing guidance for private network traffic recommends running a replica on two dedicated hosts per network location, each with at least 4GB of RAM and 4 CPU cores, and allocating 50,000 ports to the cloudflared process on each host. The documentation says this baseline usually handles traffic from about 8,000 Cloudflare One Client users. Port usage is the main limit: TCP requests release ports almost immediately, DNS queries hold a port for five seconds, and other UDP traffic holds a port for the life of the connection, which is why the docs suggest putting private DNS on its own tunnel and dedicated host.

Replicas all serve the same tunnel and do not support traffic steering; Cloudflare forwards each request to the geographically closest replica and retries others on failure. When you need steering based on latency, geography or health, the documented approach is multiple tunnels behind a Cloudflare Load Balancer, which also enables zero-downtime upgrades. Updating cloudflared restarts it and interrupts traffic it is currently serving, so either use multiple instances or a load balancer for upgrades.

The documentation describes how to tune capacity once real traffic exists. After at least a week with a representative population of users, set up a metrics service, query cloudflared_tcp_total_sessions and cloudflared_udp_total_sessions, divide by elapsed time to get average TCP and non-DNS UDP requests per second, add the average private DNS request rate from your resolver, and feed those figures into Cloudflare's sizing calculator. If the tunnel is undersized, the remedy is to add identical hosts running replicas. The same sizing page also has a section on host ulimits, alongside the port-allocation guidance above, which is worth reviewing before a rollout.

Use cases

• Publishing internal apps: expose a self-hosted dashboard, Git server or API on a public hostname while the origin keeps all inbound ports closed.
• Sharing a development server: a Quick Tunnel gives a teammate, client or webhook provider a temporary URL; with --allowed-mail, only named people get in.
• VPN replacement: route private subnets through a tunnel and let users reach them through the Cloudflare One Client with Zero Trust policies.
• SSH and RDP access: reach servers behind a tunnel over TCP with cloudflared access, without exposing port 22 or 3389.
• Homelab and edge hosting: the docs note it is light enough for a Raspberry Pi or a laptop as well as data center servers.
• Multi-region failover: tunnels in different data centers behind a Cloudflare Load Balancer steer traffic away from unhealthy origins.

How it compares

Within Cloudflare's own tooling, the README positions the WARP client as an alternative to cloudflared access for reaching private origins at Layer 4. Outside Cloudflare, cloudflared sits in the broader category of reverse tunnels and NAT-traversal tools. Hosted tunnel services such as ngrok offer a similar "expose localhost" experience, while self-hosted reverse proxies such as frp let you run the relay server yourself. Mesh VPNs such as Tailscale or NetBird solve private access by connecting devices directly rather than through an edge proxy. The main distinction is that cloudflared terminates on Cloudflare's network, so it plugs into Cloudflare DNS, Access policies, load balancing and other edge features; the trade-off is that it only works with Cloudflare and you cannot run the server side yourself.

Things to know before adopting

• Open client, hosted service. The Apache-2.0 code is the connector only. Tunnels, Access, DNS and load balancing are Cloudflare services governed by your Cloudflare account and plan.
• A Cloudflare zone is still required. The README says that, for legacy reasons, you must add a website to Cloudflare and change its nameservers before using Tunnel, even though some private-routing setups do not strictly need a site.
• Quick Tunnels are for testing. They have no uptime guarantee, cap in-flight requests at 200 (extra requests get a 429), do not support Server-Sent Events, change hostname on every run, and email protection requires an interactive browser.
• Published means public. After a published application route is added, anyone on the Internet can reach that hostname unless you put a Cloudflare Access application in front of it.
• Version support window. Cloudflare supports versions released within one year of the most recent release; older versions may break. Removals of flags, environment variables, config keys or commands are announced in the Tunnel changelog first.
• Update behaviour differs by platform. Windows instances do not update automatically and must be updated manually, and an update requires restarting the service. Optional outbound access on port 443 to Cloudflare update endpoints and GitHub enables update checks and downloads.
• Firewall requirements. Allow outbound port 7844 over both TCP and UDP to the documented Cloudflare destinations; SNI-enforcing firewalls and FedRAMP or US-region setups have their own lists.
• Path normalization default is changing. In 2026.10.0, URL normalization before ingress matching exists but is off by default, and Cloudflare has announced a planned default change, so test path-based rules that rely on Access JWT validation.
• Authenticated Origin Pulls do not apply. Because there is no inbound listener, that feature has no effect on tunnel hostnames; origin traffic is authenticated by the tunnel's connector credentials instead.

Project activity

As of November 2026 the cloudflare/cloudflared repository has about 16,400 stars on GitHub. It was created in October 2017, is written in Go and is licensed under Apache-2.0. Releases use date-based versions; the most recent at the time of writing is 2026.10.7, published at the end of October 2026, and the repository was last pushed to a few days before writing. Release notes are kept in the repository, and user-facing changes are announced in the Cloudflare Tunnel changelog.

The source is at github.com/cloudflare/cloudflared, and the user documentation is in the Cloudflare Tunnel section of Cloudflare Docs.

[![Featured on TechLogHub](https://techloghub.com/badge-neutral.svg)](https://techloghub.com/open-source/cloudflared?utm_source=techloghub_badge&utm_medium=referral&utm_campaign=readme)