Cloudflare Quick Tunnels are back in the news this week, and the Hacker News thread about them hit 600-plus points in a day. The twist is that the feature itself is not new. Cloudflare launched quick tunnels in September 2021, and the company’s own announcement from that era describes the same core trick. What is actually new is a landing page at try.cloudflare.com that repackages the whole thing for AI coding agents, with structured JSON output front and center.
What it does
Run one command and you get a public URL for a local server:
cloudflared tunnel --url http://localhost:8000
No account, no DNS records, no inbound firewall holes. The quick tunnel registers a random *.trycloudflare.com subdomain at Cloudflare’s edge, and cloudflared holds an outbound-only connection to it. When the process exits, the tunnel dies. Tunnels that disconnect for more than about five minutes get cleaned up by a scheduled job on Cloudflare’s side.
The agent angle is the real story
The landing page leans hard on machine consumption: add --output json and every log line becomes a JSON object with the assigned hostname, edge connection status, and health. An agent that spins up a dev server can parse stdout, learn the public URL, and hand it to whatever needs to call back in, whether that is a webhook provider, an eval harness, or a human reviewing a preview from another device.
That framing says something about where developer tooling is going. Tools built for humans print logs and let you eyeball them. Tools built for agents print structured output the agent can act on. Cloudflare is not the only vendor making this move, but a free zero-auth tunnel that emits machine-readable connection info is a neatly minimal example of the pattern.
Under the hood
The 2021 announcement explains the mechanics, which have not changed much. A small Cloudflare Worker generates the random subdomain and writes the routing into Cloudflare’s authoritative DNS, so the edge can direct traffic to whichever cloudflared process claimed that name. Because the connection is outbound-only from your machine, nothing on your network opens a port, which is what makes the tool tolerable in locked-down corporate environments where poking holes in a firewall needs a ticket and a week.
That same design is why the URL is ephemeral. The tunnel exists exactly as long as the cloudflared process holds the connection, and the cleanup job reaps anything abandoned. There is no state to persist and no account to attach usage to, which is simultaneously the feature and the reason it cannot be a production offering.
Know the limits
Quick tunnels are explicitly a test bed, not a product tier. The docs are blunt about it:
- 200 in-flight concurrent requests, then HTTP 429.
- No Server-Sent Events support, which rules out streaming LLM responses over SSE through the tunnel.
- No SLA, and Cloudflare says they are for testing and development only.
- A single connection to the edge, unlike named tunnels which maintain multiple for high availability.
- The URL changes on every run, so anything that needs a stable hostname needs a named tunnel.
- Quick tunnels refuse to start if a
config.yamlexists in~/.cloudflared.
Against ngrok‘s free tier, the comparison is straightforward: ngrok caps free usage at 1 GB of bandwidth and 20,000 requests per month and requires an account, while Cloudflare quick tunnels are unmetered but concurrency-capped. For an agent-driven workflow that mostly moves small HTTP payloads, Cloudflare’s limits rarely bite. For anything that must stay up, the named tunnel with a persistent hostname remains the right tool.
The community reaction
The HN thread was mostly skeptical, and fairly so. “Nothing is new, this launched in 2021” was the dominant take, and it is accurate. The JSON output predates the relaunch too; --output json has been in cloudflared since the 2025.6.1 release. Marketing a five-year-old feature as if it just shipped is the kind of thing a technical audience notices and resents.
Still, the thread produced useful discussion beyond the grumbling. People flagged that public quick tunnel URLs get scanned by bots almost immediately, which is worth taking seriously: a trycloudflare.com URL is effectively public internet, so do not point one at something unauthenticated that you would not host on a public IP. Others brought up alternatives like Tailscale Funnel, localhost.run, and self-hosted options such as Pangolin for teams that want the same capability under their own domain.
Try it
If you have cloudflared installed, you are one command away from testing it yourself. For CI or agent use, add --output json and parse the hostname out of stdout. For anything persistent, create a named tunnel from the Cloudflare dashboard and put Cloudflare Access in front of it so the public URL actually requires authentication. The quick tunnel is the demo path, not the deployment path, and knowing which one you need is most of the decision.