Cloudflare deja compartir previews de sandbox por Tunnel: por qué esto sí acelera verificar agentes
Cloudflare activó previews públicos desde `sandbox.tunnels` el 29 de mayo de 2026. La señal útil no es solo otra URL efímera: es poder exponer un servicio dentro del sandbox sin `exposePort()`, y además fijarlo con named tunnels cuando un agente necesita una dirección estable para validar o reintentar.
Por qué importa
Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.
Una de las fricciones más tontas cuando un agente genera una app o un panel dentro de un sandbox es esta: el proceso queda corriendo, pero enseñárselo a otra persona o a otro sistema sigue siendo más manual de lo que debería. El cambió de Cloudflare del 29 de mayo de 2026 ataca justo ese hueco con sandbox.tunnels.
La idea parece simple: exponer un puerto interno del sandbox en una URL pública. Lo útil de verdad es cómo lo hace. Según el changelog, Cloudflare usa cloudflared dentro del propio sandbox, así que puedes compartir el servicio sin configurar exposePort() ni montar un dominio personalizado.
Qué cambia en la práctica
La novedad parte en dos escenarios.
1. Preview rápido para verificar
El changelog dice que sandbox.tunnels.get(port) crea por defecto un quick tunnel sobre *.trycloudflare.com. Cloudflare remarca que no hace falta cuenta, DNS ni dominio propio. Para un loop agentic eso importa porque reduce el paso de “ya corre” a “ya lo puedo revisar”.
Ese patrón encaja muy bien cuando:
- un agente levantó una app temporal;
- necesitas compartirla con QA o con otro builder;
- quieres reproducir un bug visual;
- o simplemente comprobar si el servicio responde antes de seguir con otro paso.
2. URL estable para validación persistente
La parte fuerte viene después. El mismo release añade named tunnels vía sandbox.tunnels.get(port, { name }). Ahí ya no recibes una URL aleatoria nueva en cada corrida, sino una dirección persistente sobre tu zona.
Ese detalle cambia el valor del feature. Deja de ser solo “mira esta preview” y pasa a ser “usa esta URL estable para volver a probar, reintentar o automatizar”.
Dónde sí le veo intención de búsqueda cualificada
Este tipo de release conversa con búsquedas muy concretas:
cloudflare tunnel sandbox previewpreview url agent sandboxworkers dev sandbox tunnelnamed tunnel cloudflare sandbox
No es tráfico de curiosidad. Es gente intentando resolver el último tramo entre generar algo en un contenedor y verificarlo sin abrir más infraestructura.
Lo que la documentación deja claro y muchos pasarán por alto
La referencia de Tunnels mete dos límites importantes:
sandbox.tunnelsrequiere RPC transport;- Cloudflare posiciona los quick tunnels como ayuda de desarrollo, mientras que para producción recomienda
exposePort()con dominio propio.
Eso evita leer el release como si fuera una bala de plata. El quick tunnel sirve para desarrollo rápido y .workers.dev. Si ya estás montando algo con expectativas de uptime o de tráfico real, toca separar preview de producción.
El detalle operativo que más me interesa
Hay una línea del changelog que vale más que el titular: cuando llamas sandbox.destroy(), Cloudflare también derriba el Tunnel y el registro DNS asociado. Eso recorta una deuda fea de automatización: no dejar previews colgando cuando el sandbox ya murió.
Para un sitio como Agente IA, donde hablamos mucho de loops reales y no solo de demos, eso sí cambia la conversación. Un agente no solo puede crear una preview. Puede crearla y dejarla limpia al terminar.
Cómo lo usaría mañana
Yo lo dividiría así:
quick tunnelpara verificación humana o visual inmediata;named tunnelcuando el flujo necesita una URL estable para revisar varias veces;- dominio propio o
exposePort()cuando ya dejaste de estar en modo preview.
También lo conectaría con una política simple: si el agente debe comprobar una UI antes de dar por bueno un cambió, que publique el sandbox, comparta la URL y solo entonces cierre la tarea. Ese patrón conversa bien con Cloudflare Artifacts para agentes, porque una cosa resuelve estado/versionado y la otra resuelve cómo enseñas lo que ya está corriendo.
Si todavía estás en la etapa de montar tu primer loop, Instala tu propio agente te da la base antes de meter previews, sandboxes y validaciones públicas.
La lectura corta es esta: Cloudflare no solo abrió otro puerto bonito; acercó la verificación pública al mismo lugar donde el agente ya ejecuta. Para builders que viven de iterar, mostrar y corregir rápido, eso sí mueve el flujo.