Cloudflare lanza Worker Previews: un entorno aislado por cada rama de Git

Cloudflare ha presentado Worker Previews, una función que levanta un entorno aislado y con URL estable por cada rama de Git de un Worker. Cada preview tiene su propia configuración y su propio estado, con observabilidad acotada a ese entorno, y se crea con npx wrangler preview. La compañía dice que se pueden ejecutar cientos en paralelo bajo el mismo Worker sin que se pisen entre ellos ni toquen el tráfico de producción.

El motivo declarado es el desarrollo dirigido por agentes. Los agentes de código producen cambios más grandes y en mayor volumen, y las pruebas tienen que seguir el ritmo sin convertirse en el cuello de botella. Cloudflare coloca los previews como el bucle de retroalimentación de su ciclo de vida de desarrollo con agentes, donde cada cambio es atómico, se despliega por separado, se puede observar y se puede revisar.

El problema real es el estado

Durable Objects sigue un modelo singleton: una instancia es dueña del almacenamiento de un object ID concreto. Un preview que compartiera el namespace de producción podría escribir sobre instancias vivas. Wrangler crea un namespace de Durable Object y una app de Container nuevos por preview, así que una migración fallida o un cambio de esquema se quedan dentro de esa rama. El desarrollador exporta la clase, añade la migración y la alcanza vía ctx.exports: en producción resuelve al namespace de producción y en un preview al suyo.

La configuración funciona como una rama que parte de main. Los equipos definen una base en un bloque previews del fichero de Wrangler con variables, secretos y bindings —por ejemplo, apuntar un bucket R2 a almacenamiento de staging en lugar de producción— y cada preview arranca de ahí y puede cambiar ajustes sueltos, como una base de datos concreta o una clave de API de prueba, sin afectar a producción, a la base ni a otros previews. Si el Worker está conectado a Workers Builds, cada push genera un preview automático y actualiza el mismo entorno en marcha.

Los previews pueden servirse desde un dominio propio del tipo feature-login.previews.example.com para que cookies, CORS y redirecciones OAuth se comporten como en producción, y se pueden cerrar con Cloudflare Access. Cloudflare describe además un bucle de agente que combina Browser Run, Playwright MCP y el servidor MCP de Workers Observability: abre el preview en un navegador headless, recorre un flujo como el login, captura pantallas o una sesión reproducible, cruza las peticiones fallidas con los eventos de traza y después parchea, redespliega y verifica.

Qué no queda cubierto

Los previews no son lo mismo que los Wrangler environments, que obligan a desplegar y gestionar un Worker aparte por entorno, ni que las antiguas preview URLs de Worker, ahora renombradas Version URLs: esas apuntan a versiones subidas, no están aisladas por rama y solo alcanzan recursos de producción. Quien tenga algo montado sobre ellas debería revisarlo.

Las limitaciones actuales son varias. Un service binding desde un preview sigue llamando al despliegue de producción del Worker enlazado, así que las aplicaciones multi-Worker no están aisladas del todo. Los previews pueden enviar mensajes a Queues pero no consumirlos, y aislar ejecuciones de Workflows exige configuración aparte. Tampoco hay soporte completo para previews de larga duración pensados para staging y QA, aunque Cloudflare dice que los equipos de la beta los pidieron y que están en la hoja de ruta.

Cloudflare afirma haber usado la función internamente para construir CloudflareOS, su plataforma open source para conectar agentes con servicios como Google, GitHub y Slack, desplegando un preview por cada cambio en revisión. Supermemory y Ramp aparecen citados como usuarios tempranos. El anuncio no incluye ningún dato de rendimiento ni comparativa, así que el ahorro de tiempo que promete el enfoque de agentes hay que comprobarlo en cada casa.