⏱️ Lectura: 11 min

Cloudflare just added JSON output to cloudflared, the client that turns a server running on your laptop into a public, encrypted URL with a single command. The update is aimed directly at coding agents: an automated process can now read the tunnel’s hostname, edge, and health status from stdout, without parsing logs with regular expressions.

📑 En este artículo
  1. TL;DR
  2. What Happened
  3. What Quick Tunnels Are and Why They Exist
  4. How It Works Under the Hood
  5. Technical Details and Performance
  6. JSON Output for Coding Agents
  7. Getting Started
  8. Use Cases for Agents
  9. Impact and Analysis
  10. What’s Next
  11. Frequently Asked Questions
    1. What is cloudflared?
    2. Do I need a Cloudflare account to use Quick Tunnels?
    3. How long does a Quick Tunnel last?
    4. Is it safe to expose my localhost with a Quick Tunnel?
    5. How is it different from a Named Tunnel?
    6. Is it suitable for production?
  12. References

The feature lives inside Quick Tunnels, the simplest variant of Cloudflare Tunnel: no account required, no DNS changes, and no inbound port opened on your machine. With the rise of agents that write, test, and review code in loops, having an instant public URL for every run stopped being a niche detail: it became part of the daily workflow for anyone automating with AI.

TL;DR

  • Cloudflare added JSON output to cloudflared‘s Quick Tunnels, designed for coding agents to read status without parsing text.
  • A single command, cloudflared tunnel --url http://localhost:8000, exposes any local port as a public, encrypted URL.
  • Cloudflare’s network spans more than 335 cities, and the official documentation states the URL appears in about 3 seconds.
  • The tunnel opens zero inbound ports: the connection goes out from your machine to the nearest edge, never the other way around.
  • It requires no account, configuration file, or DNS record: it’s used for free straight from the terminal.
  • It’s ephemeral by design: the tunnel dies along with the cloudflared process, with nothing to revoke afterward.
  • Cloudflare positions it as infrastructure for the agent era: webhooks, screenshots, and eval harnesses.

What Happened

The official Quick Tunnels page was updated to highlight a new feature: structured JSON output over stdout with the assigned hostname, the edge that handled the connection, and the tunnel’s health status. Previously, any script that needed that data had to capture cloudflared’s text output and extract the URL with a regular expression, something fragile whenever the log format changes between versions.

The change is small in terms of lines of code, but it solves a real problem for anyone automating workflows with agents: a pipeline no longer depends on guessing the log format, it just reads a fixed field. Cloudflare explicitly frames it as a piece built for coding agents: tools like Claude Code, Codex, or any runner that builds, tests, and reviews software in short loops, without a human watching the terminal at every step.

The page also notes that the workflow remains the same as always: a single command, no login, no configuration file. The only thing that changes is that the command can now speak in a format a machine understands unambiguously.

What Quick Tunnels Are and Why They Exist

Cloudflare Tunnel (the name that replaced Argo Tunnel) connects a service running on your network, without a public IP or open port, to Cloudflare’s network through an outbound connection from the cloudflared daemon. The full variant requires an account, your own domain, and a configuration file with the tunnel’s routes.

Quick Tunnels are the minimal version of that same technology: one command, zero configuration, a random URL under the trycloudflare.com domain. They were built for quick tests (showing a client a change, testing a webhook, sharing a demo), and in that space they compete with services like ngrok, which popularized the one-command, public-URL pattern years before Cloudflare Tunnel existed.

Before tools like this existed, exposing a local port meant configuring port forwarding on the router, opening a hole in the firewall, or setting up a manual SSH tunnel with ssh -R. All of that involved touching the home or corporate network, something many IT teams block outright. A Quick Tunnel avoids that whole problem: the connection always goes out from your machine, never in.

How It Works Under the Hood

cloudflared opens an outbound connection to the Cloudflare location closest to your machine. Traffic arriving at the public URL travels through Cloudflare’s network (with TLS, DDoS filtering, and anycast routing) and comes back to your local process through that same outbound channel. There’s never a socket listening on a port exposed to the internet, which is why the documentation highlights 0 open ports as one of the core numbers behind the offering.

When you close the cloudflared process (with Ctrl+C or by killing the PID), the outbound connection drops and the public URL stops resolving immediately. There’s no extra cleanup step and no resource left reserved on your Cloudflare account, because a Quick Tunnel never creates any persistent resource in the first place.

flowchart LR
A["Your machine: localhost:8000"] --> B["cloudflared: outbound connection"]
B --> C["Cloudflare Edge: TLS + DDoS + Anycast"]
C --> D["Public URL: *.trycloudflare.com"]
D --> E["Team, webhooks, and agents"]
Diagram of a Cloudflare tunnel connecting a local server to the internet
The connection always goes out from your machine: no port ever comes in. Foto de Daniel Jerez en Unsplash

Technical Details and Performance

The official page sums up the offering in four numbers: 335+ cities in the edge network, ~3 seconds from running the command to having a working URL, 0 ports open on your machine, and zero cost to use Quick Tunnels. These four figures are taken directly from try.cloudflare.com.

None of these numbers depend on you configuring anything extra: TLS, edge DDoS mitigation, and anycast routing come enabled by default on every tunnel, with no extra flags. It’s the same infrastructure that protects Cloudflare’s regular traffic, applied here to a URL you might only use for a few minutes.

To decide between a Quick Tunnel, a Named Tunnel (with an account), or an alternative like ngrok, it’s worth looking at the table below rather than memorizing flags:

OptionWhen to use itAdvantageLimitation
Quick TunnelDemos, one-off tests, agent loopsZero configuration, free, no accountRandom URL that changes on every run
Named Tunnel (Cloudflare Tunnel with an account)Services that need a fixed hostnameOwn domain and Cloudflare Access rulesRequires an account, DNS, and a configuration file
ngrok-style tunnelTeams already integrated into that ecosystemDashboard and live traffic inspectionLimited free tier, URL just as ephemeral

💡 Tip: if you’re running the tunnel inside a script or an agent, always use the JSON output instead of reading console text: cloudflared’s log format can change between versions and break your parsing.

JSON Output for Coding Agents

This is the change behind the update: cloudflared can emit the hostname, the assigned edge, and the tunnel’s health status as a JSON object on stdout. An illustrative example of the format described in the documentation looks like this:

$ cloudflared tunnel --url http://localhost:8000 --output json
{
  "hostname": "quiet-marble-otter-canyon.trycloudflare.com",
  "edge": "sea01",
  "health": "healthy"
}

With that object, an agent can read hostname directly and use it to build the full URL, with no regex or heuristics over log text. It’s the difference between trusting that a line of text’s format hasn’t changed between versions, and reading a fixed-name field that a JSON parser understands unambiguously.

To confirm your installation already supports this output, run cloudflared --version and check that it’s a recent build; then run the tunnel with the JSON output flag and verify the object includes all three fields (hostname, edge, and health) before wiring it into a CI pipeline or a production agent.

Getting Started

Installing cloudflared doesn’t require logging in. Pick your platform:

# macOS (Homebrew)
brew install cloudflared

# Windows (PowerShell, winget)
winget install --id Cloudflare.cloudflared

# Linux (official binary from GitHub Releases)
curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared
chmod +x cloudflared
sudo mv cloudflared /usr/local/bin/

With the binary installed, start your app as usual and open the tunnel pointing at that port:

# 1. Start your local server (any stack)
npm run dev

# 2. In another terminal, open the tunnel and save the output as JSON
cloudflared tunnel --url http://localhost:3000 --output json > tunnel.json

# 3. An agent (or script) reads the URL without touching the log
cat tunnel.json | jq -r '.hostname'

The second block is the real pattern for an agent: start the server, open the tunnel redirecting output to a file, and have the next pipeline step read the hostname field with a tool like jq instead of parsing free-form text.

Use Cases for Agents

Cloudflare lists three concrete scenarios where a Quick Tunnel replaces a mock or a manual wait:

  • Webhooks: pointing Stripe, GitHub, or a custom callback at a live URL instead of simulating the payload with a fixture, which catches integration bugs a mock would never surface.
  • Screenshot services: an agent reviewing an interface needs a real URL that a headless browser can visit, not a port that only exists inside its own container.
  • Eval harnesses: running a test suite against the app actually exposed, not against a simulated stand-in that can hide behavioral differences.
Coding agent sharing a public URL generated by a quick tunnel
The same tunnel works for a human teammate and for an automated webhook. Foto de Michael Odelberth en Unsplash

Impact and Analysis

The ephemeral design is the product’s greatest strength: since the tunnel dies with the process, there’s no dangling URL that someone has to remember to revoke weeks later. For an agent running hundreds of times a day, that matters more than the convenience of a fixed domain.

The flip side is that a Quick Tunnel comes with no authentication of its own. Anyone with the URL (random, but public) can access your local server while the tunnel is open. For a five-minute demo the risk is low, but to expose a service with real data, even temporarily, it’s worth adding your own auth layer in the app or moving straight to a Named Tunnel with Cloudflare Access rules.

⚠️ Watch out: a Quick Tunnel’s URL isn’t secret by design, it’s just hard to guess. Don’t use it to expose sensitive data without your own authentication in the application.

Another practical limit: if your agent needs the same hostname across successive runs (for example, so a GitHub webhook always points to the same endpoint), Quick Tunnels won’t work, since it generates a new subdomain every time it starts. That’s where a Named Tunnel, with its fixed hostname, is the right tool.

It’s worth weighing the real cost of the alternative: keeping a staging server always on so an external webhook has something to point to costs compute running 24 hours a day, while a Quick Tunnel only exists for the stretch of time an agent actually needs it.

What’s Next

The JSON output fits a broader trend: infrastructure tools that until recently were designed only for humans in front of a terminal are now adding an explicit interface for automated agents. It’s reasonable to expect other pieces of the dev stack (local proxies, development servers, logging tools) to follow the same path of exposing a structured output mode meant to be read by code, not just human eyes.

📖 Summary on Telegram: View summary

Try it yourself: run cloudflared tunnel --url http://localhost:8000 against any server you have running and watch the public URL appear in the terminal within seconds.

Frequently Asked Questions

What is cloudflared?

It’s Cloudflare’s command-line client that creates an outbound connection between a local service and Cloudflare’s network, with no need to open inbound ports or have a public IP.

Do I need a Cloudflare account to use Quick Tunnels?

No. Quick Tunnels work without signing up, without logging in, and without configuring DNS: that’s the main difference from a Named Tunnel.

How long does a Quick Tunnel last?

It lives as long as the cloudflared process keeps running. When you close it, or kill the process, the URL stops working immediately.

Is it safe to expose my localhost with a Quick Tunnel?

Traffic travels encrypted and filtered through Cloudflare’s network, but the URL has no authentication of its own: anyone who knows it can access it while the tunnel is active. For sensitive data, add your own authentication layer.

How is it different from a Named Tunnel?

A Named Tunnel requires an account, your own domain, and configuration, but in exchange it gives you a fixed hostname and allows access rules through Cloudflare Access. A Quick Tunnel prioritizes speed over persistence.

Is it suitable for production?

It’s not designed for that. Its URL changes on every run and it has no long-term availability guarantees: for production, Cloudflare recommends a Named Tunnel.

References

📱 Like this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.

Imagen destacada: Foto de Ian Talmacs en Unsplash

Categories: Noticias Tech

Javier Alarcón

Infrastructure engineer specializing in networking, Linux systems, Kubernetes, and cloud architectures. Covers hardware, networking, observability, and engineering practices for production teams.

0 Comments

Leave a Reply

Avatar placeholder

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.