Una URL distinta no garantiza que un entorno de prueba esté separado de producción. Si su configuración sigue apuntando a la base de datos real, usa una clave de API activa o llama a un servicio de producción, una prueba puede cambiar datos o activar acciones fuera del entorno de revisión.
Los Worker Previews, que Cloudflare lanzó en septiembre, crean entornos para ramas con código, configuración, URL, observabilidad y estado propios. La propuesta facilita revisar un cambio antes del despliegue. Sin embargo, el aislamiento depende de los recursos que recibe cada preview y de los límites que la plataforma todavía tiene.
Comprueba adónde apunta cada recurso
El preview parte de una configuración base que el equipo define por separado de la de producción. Las variables, los secretos y los vínculos a recursos pueden tener valores propios; también se puede modificar la configuración de un preview para usar, por ejemplo, una base de datos de prueba o una clave de API de prueba.
Durable Objects y Containers reciben espacios de nombres y aplicaciones aislados por preview. Esto evita que el estado de una rama cambie directamente las instancias que se usan en producción. Para los demás recursos, el equipo debe revisar el vínculo configurado: un nombre de entorno distinto no crea copias de bases de datos, buckets o API externas por sí solo.
También hay límites entre Workers. Hoy, un service binding llamado desde un preview todavía puede llegar al Worker vinculado en producción. Cloudflare dice que está trabajando para mantener todo el recorrido dentro de previews correspondientes. Hasta que eso cambie, una prueba que atraviesa esa conexión debe considerar la posibilidad de ejecutar código o generar efectos en el servicio real.
Elige el entorno según el riesgo de la prueba
Un preview desechable sirve para revisar un cambio de rama cuando los datos y las credenciales pueden separarse o recrearse. Un entorno de staging persistente sirve para pruebas que necesitan conservar el estado durante más tiempo, pero exige reglas de limpieza, acceso y mantenimiento. Para probar solo una versión específica del código usando recursos de producción, las Version URLs tienen otro propósito: no aíslan recursos y no se recomiendan para revisar ramas o pull requests.
Antes de compartir el enlace, enumera los efectos posibles de la prueba: escrituras, envío de mensajes, cobros, correos, llamadas externas y migraciones. Para cada uno, decide si el preview debe usar un recurso propio, una simulación o una credencial limitada. Desactiva lo que no sea necesario para la revisión.
Prueba el límite, no solo la página
Abre el preview con una cuenta de prueba y revisa sus registros y las llamadas a los recursos vinculados. Confirma que los datos de prueba no aparezcan en el entorno real y que ninguna acción sensible se active fuera de la rama. Que la interfaz se vea bien no demuestra que los recursos detrás de ella también estén aislados.
Esta revisión es especialmente importante cuando el preview ejecuta migraciones u operaciones con estado persistente. Si hay un servicio compartido en el recorrido, usa datos desechables, una copia controlada o limita la prueba a consultas de lectura. Registra también qué ajustes se heredan de la configuración base para que una rama nueva no reciba por error un secreto de producción.
Worker Previews reduce el trabajo necesario para crear entornos separados, pero no elimina la necesidad de elegir qué recursos y efectos están permitidos. Los criterios para aprobar un preview deben incluir adónde van sus datos y llamadas, además de la dirección que el equipo abrirá en el navegador.
Si tu equipo está ante una decisión parecida, escríbeme por LinkedIn o por WhatsApp.
