Cloudflare acaba de sumarle salida en JSON a cloudflared, el cliente que convierte un servidor que corre en tu laptop en una URL pública y cifrada con un solo comando. La novedad apunta directo a los agentes de código: ahora un proceso automatizado puede leer el hostname, el edge y el estado de salud del túnel desde stdout, sin parsear logs con expresiones regulares.
La función vive dentro de Quick Tunnels, la variante más simple de Cloudflare Tunnel: no pide cuenta, no toca DNS y no abre ningún puerto entrante en tu máquina. Con la adopción de agentes que programan, prueban y revisan código en bucle, tener una URL pública instantánea para cada corrida dejó de ser un detalle de nicho: se volvió parte del flujo diario de quien automatiza con IA.
TL;DR
- Cloudflare agregó salida JSON a los Quick Tunnels de
cloudflared, pensada para que agentes de código lean el estado sin parsear texto. - Un solo comando,
cloudflared tunnel --url http://localhost:8000, expone cualquier puerto local en una URL pública cifrada. - La red de Cloudflare cubre más de 335 ciudades y la documentación oficial indica que la URL aparece en unos 3 segundos.
- El túnel abre cero puertos entrantes: la conexión sale desde tu máquina hacia el edge más cercano, nunca al revés.
- No requiere cuenta, archivo de configuración ni registro de DNS: se usa gratis desde la terminal.
- Es efímero por diseño: el túnel muere junto con el proceso de
cloudflared, sin nada que revocar después. - Cloudflare lo posiciona como infraestructura para la era de los agentes: webhooks, capturas de pantalla y eval harnesses.
Qué pasó
La página oficial de Quick Tunnels se actualizó para destacar una función nueva: salida estructurada en JSON sobre stdout con el hostname asignado, el edge que atendió la conexión y el estado de salud del túnel. Antes, cualquier script que necesitara ese dato tenía que capturar la salida de texto de cloudflared y extraer la URL con una expresión regular, algo frágil cuando el formato de los logs cambia entre versiones.
El cambio es chico en líneas de código, pero resuelve un problema real para quien automatiza flujos con agentes: un pipeline ya no depende de adivinar el formato del log, sino que lee un campo fijo. Cloudflare lo enmarca explícitamente como una pieza para coding agents: herramientas como Claude Code, Codex o cualquier runner que construye, prueba y revisa software en bucles cortos, sin un humano mirando la terminal en cada paso.
La página también resalta que el flujo sigue siendo el de siempre: un solo comando, sin login, sin archivo de configuración. Lo único que cambia es que ese comando ahora puede hablar en un formato que una máquina entiende sin ambigüedad.
Qué son los Quick Tunnels y por qué existen
Cloudflare Tunnel (el nombre que reemplazó a Argo Tunnel) conecta un servicio que corre en tu red, sin IP pública ni puerto abierto, con la red de Cloudflare mediante una conexión saliente del demonio cloudflared. La variante completa exige una cuenta, un dominio propio y un archivo de configuración con las rutas del túnel.
Los Quick Tunnels son la versión mínima de esa misma tecnología: un comando, cero configuración, una URL aleatoria bajo el dominio trycloudflare.com. Nacieron para pruebas rápidas (mostrarle un cambio a un cliente, probar un webhook, compartir una demo) y compiten en ese terreno con servicios como ngrok, que popularizó el patrón de un comando y una URL pública años antes de que existiera Cloudflare Tunnel.
Antes de que este tipo de herramientas existiera, exponer un puerto local significaba configurar reenvío de puertos en el router, abrir un agujero en el firewall o levantar un túnel SSH manual con ssh -R. Todo eso implicaba tocar la red doméstica o corporativa, algo que muchos equipos de IT directamente bloquean. Un Quick Tunnel evita ese problema entero: la conexión siempre sale desde tu máquina, nunca entra.
Cómo funciona bajo el capó
cloudflared abre una conexión saliente hacia la ubicación de Cloudflare más cercana a tu máquina. El tráfico que llega a la URL pública viaja por la red de Cloudflare (con TLS, filtrado de DDoS y enrutamiento anycast) y vuelve a tu proceso local por ese mismo canal saliente. Nunca hay un socket escuchando en un puerto expuesto a internet: por eso la documentación remarca 0 puertos abiertos como una de las cifras centrales de la propuesta.
Cuando cerrás el proceso de cloudflared (con Ctrl+C o matando el PID), la conexión saliente se corta y la URL pública deja de resolver de inmediato. No hay un paso de limpieza adicional ni un recurso que quede reservado en la cuenta de Cloudflare, porque un Quick Tunnel nunca llega a crear ningún recurso persistente.
flowchart LR
A["Tu maquina: localhost:8000"] --> B["cloudflared: conexion saliente"]
B --> C["Edge de Cloudflare: TLS + DDoS + Anycast"]
C --> D["URL publica: *.trycloudflare.com"]
D --> E["Equipo, webhooks y agentes"]
La conexión siempre sale desde tu máquina: nunca entra un puerto.
Detalles técnicos y rendimiento
La página oficial resume la propuesta en cuatro números: 335+ ciudades en la red de borde, ~3 segundos desde que corrés el comando hasta tener una URL funcionando, 0 puertos abiertos en tu máquina y costo cero para usar Quick Tunnels. Esos cuatro datos están tomados directamente de try.cloudflare.com.
Ninguno de esos números depende de que configures nada extra: TLS, mitigación de DDoS en el borde y enrutamiento anycast vienen activados por defecto en cada túnel, sin flags adicionales. Es la misma infraestructura que protege el tráfico normal de Cloudflare, aplicada también a una URL que vas a usar apenas unos minutos.
Para decidir entre Quick Tunnel, un Named Tunnel (con cuenta) o una alternativa como ngrok, conviene mirar la tabla siguiente antes que memorizar flags:
OpciónCuándo usarlaVentajaLimitaciónQuick TunnelDemos, pruebas puntuales, loops de agentesCero configuración, gratis, sin cuentaURL aleatoria que cambia en cada corridaNamed Tunnel (Cloudflare Tunnel con cuenta)Servicios que necesitan un hostname fijoDominio propio y reglas de Cloudflare AccessRequiere cuenta, DNS y archivo de configuraciónTúnel tipo ngrokEquipos ya integrados a ese ecosistemaDashboard e inspección de tráfico en vivoCapa gratuita limitada, URL igual de efímera
💡 Tip: si vas a correr el túnel dentro de un script o un agente, usá siempre la salida JSON en lugar de leer el texto de la consola: el formato de log de cloudflared puede cambiar entre versiones y romper el parseo.
Salida JSON para agentes de código
Este es el cambio que motiva la actualización: cloudflared puede emitir el hostname, el edge asignado y el estado de salud del túnel como un objeto JSON en stdout. Un ejemplo ilustrativo del formato que describe la documentación se ve así:
$ cloudflared tunnel --url http://localhost:8000 --output json
{
"hostname": "quiet-marble-otter-canyon.trycloudflare.com",
"edge": "sea01",
"health": "healthy"
}
Con ese objeto, un agente puede leer hostname directamente y usarlo para armar la URL completa, sin regex ni heurísticas sobre el texto de log. Es la diferencia entre confiar en que el formato de una línea de texto no cambió de una versión a otra, y leer un campo con nombre fijo que un parser de JSON entiende sin ambigüedad.
Para confirmar que tu instalación ya soporta esta salida, corré cloudflared --version y verificá que sea una build reciente; después ejecutá el túnel con la flag de salida JSON y revisá que el objeto traiga los tres campos (hostname, edge y health) antes de integrarlo a un pipeline de CI o a un agente en producción.
Cómo empezar
Instalar cloudflared no pide login. Elegí tu sistema:
# macOS (Homebrew)
brew install cloudflared
# Windows (PowerShell, winget)
winget install --id Cloudflare.cloudflared
# Linux (binario oficial desde 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/
Con el binario instalado, levantá tu app como siempre y abrí el túnel apuntando a ese puerto:
# 1. Arrancas tu servidor local (cualquier stack)
npm run dev
# 2. En otra terminal, abris el tunel y guardas la salida en JSON
cloudflared tunnel --url http://localhost:3000 --output json > tunnel.json
# 3. Un agente (o un script) lee la URL sin tocar el log
cat tunnel.json | jq -r '.hostname'
El segundo bloque es el patrón real para un agente: arrancar el servidor, abrir el túnel redirigiendo la salida a un archivo, y que el paso siguiente del pipeline lea el campo hostname con una herramienta como jq en lugar de parsear texto libre.
Casos de uso para agentes
Cloudflare enumera tres escenarios concretos donde un Quick Tunnel reemplaza a un mock o a una espera manual:
- Webhooks: apuntar Stripe, GitHub o un callback propio a una URL viva en vez de simular el payload con un fixture, lo que detecta bugs de integración que un mock nunca muestra.
- Servicios de captura de pantalla: un agente que revisa una interfaz necesita una URL real que un navegador headless pueda visitar, no un puerto que solo existe dentro de su propio contenedor.
- Eval harnesses: correr una batería de pruebas contra la app expuesta de verdad, no contra un doble simulado que puede ocultar diferencias de comportamiento.
El mismo túnel sirve para un teammate humano y para un webhook automatizado.
Impacto y análisis
El diseño efímero es la mayor fortaleza del producto: como el túnel muere con el proceso, no queda ninguna URL colgada que alguien tenga que acordarse de revocar semanas después. Para un agente que corre cientos de veces por día, eso importa más que la comodidad de un dominio fijo.
La otra cara es que un Quick Tunnel no trae autenticación propia. Cualquiera que tenga la URL (aleatoria, pero pública) puede acceder a tu servidor local mientras el túnel esté abierto. Para una demo de cinco minutos el riesgo es bajo, pero para exponer un servicio con datos reales, incluso de forma temporal, conviene sumar tu propia capa de auth en la app o pasar directamente a un Named Tunnel con reglas de Cloudflare Access.
⚠️ Ojo: la URL de un Quick Tunnel no es secreta por diseño, es solo difícil de adivinar. No la uses para exponer datos sensibles sin autenticación propia en la aplicación.
Otro límite práctico: si tu agente necesita el mismo hostname en corridas sucesivas (por ejemplo, para que un webhook de GitHub apunte siempre al mismo endpoint), Quick Tunnels no sirve, porque genera un subdominio nuevo cada vez que arranca. Ahí el Named Tunnel, con su hostname fijo, es la herramienta correcta.
Vale la pena medir el costo real de la alternativa: mantener un servidor de staging siempre encendido para que un webhook externo tenga algo a qué apuntar cuesta cómputo corriendo 24 horas, mientras que un Quick Tunnel solo existe durante el rato en que un agente realmente lo necesita.
Qué sigue
La salida JSON encaja con una tendencia más amplia: herramientas de infraestructura que hasta hace poco se pensaban solo para humanos frente a una terminal ahora agregan una interfaz explícita para agentes automatizados. Es de esperar que otras piezas del stack de desarrollo (proxies locales, servidores de desarrollo, herramientas de logging) sigan el mismo camino de exponer un modo de salida estructurada pensado para ser leído por código, no solo por ojos humanos.
📖 Resumen en Telegram: Ver resumen
Probalo vos: corré cloudflared tunnel --url http://localhost:8000 contra cualquier servidor que tengas levantado y mirá la URL pública aparecer en la terminal en segundos.
Preguntas frecuentes
¿Qué es cloudflared?
Es el cliente de línea de comandos de Cloudflare que crea una conexión saliente entre un servicio local y la red de Cloudflare, sin necesidad de abrir puertos entrantes ni tener una IP pública.
¿Necesito una cuenta de Cloudflare para usar Quick Tunnels?
No. Los Quick Tunnels funcionan sin registro, sin login y sin configurar DNS: esa es la diferencia principal frente a un Named Tunnel.
¿Cuánto dura un Quick Tunnel?
Vive mientras el proceso de cloudflared siga corriendo. Al cerrarlo, o al matar el proceso, la URL deja de funcionar de inmediato.
¿Es seguro exponer mi localhost con un Quick Tunnel?
El tráfico viaja cifrado y filtrado por la red de Cloudflare, pero la URL no tiene autenticación propia: cualquiera que la conozca puede acceder mientras el túnel esté activo. Para datos sensibles, sumá tu propia capa de autenticación.
¿En qué se diferencia de un Named Tunnel?
Un Named Tunnel pide cuenta, dominio propio y configuración, pero a cambio da un hostname fijo y permite reglas de acceso con Cloudflare Access. El Quick Tunnel prioriza la velocidad sobre la persistencia.
¿Sirve para producción?
No está pensado para eso. Su URL cambia en cada ejecución y no tiene garantías de disponibilidad a largo plazo: para producción, Cloudflare recomienda un Named Tunnel.
Referencias
- Quick Tunnels, Cloudflare: página oficial con el comando, las cifras de rendimiento y la nueva salida JSON.
- Cloudflare Tunnel, documentación: referencia completa de Named Tunnels y Cloudflare Access.
- cloudflared, repositorio en GitHub: código fuente y releases del cliente.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Top comments (0)