What is Cloudflare Tunnel?

How Cloudflare Tunnel and cloudflared publish services without opening ports, what a tunnel, connector, route, DNS record and Quick Tunnel are, what it costs, and the limits worth knowing before you rely on it.

Cloudflare Tunnel connects a service on your computer or network to Cloudflare, so people can reach it at a hostname on your domain without you opening an inbound port, having a public IP address or touching your router. It's free, and it's what Teitunnel manages for you. This page explains the moving parts, so the plans Teitunnel shows you and the problems the Doctor reports make sense.

How a request travels

Visitor ──HTTPS──▶ Cloudflare's edge ◀══ outbound connections ══ cloudflared ──▶ localhost:3000
                   (app.yourhost.com)                            (your computer)

cloudflared, Cloudflare's open-source connector, runs on your computer and opens a few long-lived outbound connections to nearby Cloudflare data centers, on port 7844 over QUIC (UDP), falling back to HTTP/2 (TCP) when UDP is blocked.
A visitor opens https://app.yourhost.com. The hostname's DNS record points at Cloudflare, which answers HTTPS with its own certificate, applies whatever rules the domain has (logins, firewall rules, caching) and looks up which tunnel serves the name.
Cloudflare sends the request down one of that tunnel's connections. cloudflared matches it against the tunnel's routes and passes it to your service at localhost:3000. The answer goes back the same way.

Because every connection starts from your side:

there's nothing to forward on your router, and it works behind carrier-grade NAT, hotel Wi-Fi and most corporate firewalls (anything that allows outbound traffic on port 7844);
your IP address is never published in DNS, so visitors only ever see Cloudflare;
your firewall can block all inbound traffic.

The pieces, and their names

Term	What it is	In Teitunnel
Tunnel	A named, persistent object in your Cloudflare account, with an ID (a UUID) and a secret run token.	One per computer, created with your first route; more if you ask for them.
Connector	A running cloudflared process for a tunnel. Several connectors, on one or more machines, can run the same tunnel.	This computer's connector, started by the app, `teitunnel up` or an Always-on service. Listed per tunnel in Tunnels.
Route (Cloudflare calls it a published application or ingress rule)	Which hostname, and optionally which path, goes to which service.	A route.
DNS record	A proxied `CNAME` from your hostname to `<tunnel-id>.cfargotunnel.com`. It's what sends visitors to the tunnel.	Made and removed with the route, and marked as Teitunnel's.
Quick Tunnel	A throwaway tunnel with a random `trycloudflare.com` address, no account needed.	Quick Share.
Private network	An IP range reachable through the tunnel by devices signed in to Cloudflare WARP.	Private networks.
Access application	A login Cloudflare asks for before a request reaches the tunnel.	Require a login.

A route needs both halves: the tunnel has to know the hostname (the ingress rule), and DNS has to send the hostname to the tunnel (the CNAME). Most tunnel problems are one half missing or pointing at the wrong place, which is why Teitunnel always changes both together and checks the result.

Remotely-managed and locally-managed tunnels

Cloudflare supports two ways to configure a tunnel:

Remotely-managed (Cloudflare's current default): routes are stored in Cloudflare and changed through the dashboard or the API. cloudflared only needs the tunnel's run token and fetches its routes from Cloudflare. Teitunnel creates and manages these.
Locally-managed: routes live in a config.yml next to cloudflared, which authenticates with a credentials file (<tunnel-id>.json). Changing a route means editing the file and restarting cloudflared.

Teitunnel can import the routes of a locally-managed setup onto its own tunnel, and export its routes as a config.yml if you ever want to run them the other way.

What it costs

Cloudflare Tunnel is free on every Cloudflare plan, with no charge for bandwidth through the tunnel.
Routes on your own hostnames need a domain on Cloudflare (its nameservers pointed at Cloudflare). A free plan is enough. Quick Shares need no account and no domain.
Logins use Cloudflare Zero Trust, which is free for up to 50 users.
Load balancing across machines uses Cloudflare Load Balancing, a paid add-on. See load balancing.
Workers (behind Snapshots, the offline page and the webhook inbox) include 100,000 requests a day on the free plan.
Teitunnel itself is free and open source.

Limits worth knowing

These are Cloudflare's, not Teitunnel's. Where Teitunnel's route check can recognise one, it says which limit was hit.

Response time: Cloudflare waits 125 seconds for your service to start answering. After that visitors get error 524. Long-running work should answer early and continue in the background, or stream.
Upload size: request bodies over 100 MB are refused on the Free and Pro plans (error 413). Teitunnel's check reports it as Cloudflare refused a request body over 100 MB, the limit on the Free and Pro plans.
Certificates: Cloudflare's free certificate covers one level of subdomain (app.yourhost.com), not deeper names like a.b.yourhost.com. Use single-level names, or add an Advanced Certificate.
Quick Tunnels are for testing: no uptime guarantee, at most 200 requests in flight at once, and no server-sent events. Share on your own domain when you need more.
Protocols: HTTP, WebSockets and gRPC work through a tunnel for any browser or client. For other TCP services (SSH, RDP, databases), the visitor runs cloudflared too, or uses WARP; see SSH and TCP and private networks.
Content: Cloudflare's service terms apply to what you serve. Serving mostly video or large files may need Cloudflare's media products; check the current terms for your plan.

Why use Teitunnel for it

Everything above can be done with the Cloudflare dashboard and the cloudflared command. Teitunnel does the same work in one place and adds guarantees:

it installs cloudflared from Cloudflare's releases and verifies it before use;
it creates the tunnel, its routes and their DNS records together, and shows every change before making it;
it undoes a change completely if one step fails;
it never deletes a DNS record it didn't create without asking;
it keeps connectors running, restarts them after a crash and moves them to new cloudflared versions without downtime;
the Doctor explains problems and fixes them in place.

See Teitunnel, cloudflared and the Cloudflare dashboard for when to use which.

Routes and tunnels: how Teitunnel models them.
How changes are made: plan, apply, verify.
Run modes: where the connector runs.
Cloudflare's documentation: Cloudflare Tunnel.