Cloudflare lanzó Worker Previews el 22 de septiembre para ejecutar cada rama de un proyecto en un entorno propio. Los cambios de un agente pueden revisarse en una URL antes de incorporarlos a producción. La mejora resulta especialmente útil cuando varias modificaciones compiten por un único entorno de pruebas.
El anuncio de Cloudflare separa código, configuración, observabilidad y estado por rama. También distingue esta función de las antiguas URL de versión, ahora llamadas Version URLs: apuntar a una versión del código no creaba por sí solo un entorno aislado.
La frontera depende del recurso
La documentación vigente de Previews concreta qué ocurre con las conexiones. Este desglose evita interpretar «entorno propio» como una promesa de separación automática de toda la aplicación:
| Recurso | Comportamiento documentado |
|---|---|
| Durable Objects y Containers | Se aprovisionan recursos específicos para la Preview. |
| KV, D1 y R2 | La separación requiere enlazar recursos distintos. |
| Service bindings a otro Worker | Llaman al despliegue de producción del Worker enlazado. |
| Workflows y colas | No se crea automáticamente un Workflow por Preview; los consumidores de colas no pueden dirigirse a ella. |
Además, las URL de Preview son públicas por defecto. La documentación remite a Cloudflare Access para exigir identificación. Una dirección difícil de adivinar no debe confundirse con un control de acceso.
Qué comprobar antes de darle el entorno a un agente
El paso útil es recorrer las salidas de la aplicación: qué base recibe escrituras, a qué servicio se envían peticiones y qué credenciales se utilizan. Una interfaz puede estar en una Preview mientras una llamada posterior acaba en producción. La tabla permite localizar precisamente esa diferencia, sin necesitar suponer que todo el despliegue es seguro o inseguro en bloque.
También conviene guardar la URL del despliegue concreto cuando se revisa un resultado: la URL estable de la Preview va cambiando con las nuevas entregas. Son referencias distintas para «ver lo último» y «ver exactamente lo revisado».
Las instrucciones requieren Wrangler 4.135.0 o posterior en la dependencia del proyecto. Este artículo analiza la documentación, no una prueba ejecutada por Texploto; no ofrecemos cifras de rendimiento ni ahorro de costes.
Para el paso anterior, organizar el trabajo que encargas al agente, está nuestra explicación de Cursor Projects y proyectos persistentes. La continuidad del trabajo y el aislamiento del entorno son decisiones complementarias.
