Introducción
Un agente de código que necesita compilar un proyecto Python, ejecutar tests y devolver resultados no puede esperar cuatro segundos a que su entorno de ejecución arranque. Ese latencia se multiplica cuando el agente lanza decenas o cientos de sandboxes por sesión, y el modelo clásico de «configurá la aplicación, hacé un deploy, escalá» no resuelve el problema. Cloudflare rediseñó Containers desde la capa de scheduling hasta el runtime para que la infraestructura del sandbox se defina en la misma línea de código que ejecuta la tarea, no en un archivo de configuración desplegado horas antes.
El resultado concreto: la mediana de arranque cayó de poco más de 4 segundos a 648 milisegundos según el benchmark independiente de ComputeSDK, y las pruebas internas de burst generaron cientos de miles de Containers en segundos. Para equipos de infraestructura que orquestan agentes en producción, esto cambia el patrón de operación de «previsión y rollout» a «decisión en tiempo de ejecución».
Qué ocurrió
Cloudflare introdujo una nueva política de scheduling llamada durable_object que traslada la selección de imagen y tipo de instancia desde el momento del deploy al momento en que el Durable Object recibe una tarea. Antes, cada combinación de imagen (por ejemplo, Node.js 20 pequeño o Python 3.12 grande) requería una aplicación Containers separada con su propio namespace y un wrangler deploy dedicado. Un agente que necesitaba dos entornos distintos debía enrutar cada task a la aplicación correcta mediante lógica en el Worker, y agregar un tercer entorno implicaba otro despliegue completo.
Con la nueva política, la imagen y los recursos de cómputo son argumentos que el código pasa al arrancar el sandbox. Una sola clase de Durable Object puede lanzar sandboxes Node.js y Python de distintos tamaños en paralelo. La declaración de imágenes disponibles se hace una sola vez en la configuración del DO, y cada imagen queda expuesta como this.ctx.container.images.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para equipos que operan cargas de agentes (coding agents, evaluaciones de modelos, reinforcement learning), el cambio elimina la necesidad de mantener un catálogo creciente de aplicaciones Containers estáticas. Integraciones existentes como Cursor Cloud Agents, Devin Outposts, la OpenAI Agents API y Claude Managed Agents se benefician directamente: cada workload define su propio entorno sin intervención del equipo de infraestructura por cada nuevo tipo de sandbox.
El impacto operativo más relevante es la eliminación del rollout clásico. Antes, actualizar una imagen implicaba definir grace periods, porcentajes de tráfico gradual y llamar a la API de Cloudflare para reemplazar instancias en ejecución, sin garantía de que un agente no estuviera a mitad de una tarea. Con la política durable_object, un Container corre la imagen con la que arrancó hasta que tu código lo detiene; la siguiente vez que el Durable Object levanta un Container, usa la imagen que el código elija. La estrategia de rollout pasa a ser unas líneas en el DO: podés hacer canary por task ID, rollback inmediato, o simplemente no reemplazar nada hasta que el sandbox termine.
Desde la perspectiva de seguridad, cada sandbox sigue siendo un entorno Linux aislado con su propio Durable Object que controla tráfico saliente y ciclo de vida. La diferencia es que el aislamiento se instancia por tarea en lugar de por aplicación desplegada, lo que reduce la superficie de compartición de estado entre sesiones de distintos usuarios.
Detalles técnicos
El rediseño del runtime eliminó la dependencia del control plano global para el arranque de un Container. El modelo anterior pedía que el control plano resolviera la configuración de la aplicación, buscara capacidad en el pool y coordinara la colocación. Con durable_object, la demanda nace en el Durable Object: la infraestructura busca capacidad primero en la misma máquina, luego amplía la búsqueda dentro de la misma ubicación, y prioriza hosts que ya tienen la imagen o el snapshot en almacenamiento local. Esto último es clave para los snapshots de filesystem: si un sandbox se guardó en el disco de un host, restaurarlo no implica transferir el filesystem desde una capa compartida.
En el benchmark de ComputeSDK, la mediana de arranque cayó a 648 ms. Las pruebas internas de Cloudflare crearon cientos de miles de Containers en segundos bajo condiciones de burst. La API nativa ctx.container del Durable Object ahora expone el control del Container sin una clase wrapper intermedia, y este modelo se traslada a Sandbox SDK 1.0. Los snapshots de filesystem están en beta pública, lo que permite pausar un workspace, guardar su estado y restaurarlo días después sin reejecutar la instalación de dependencias ni la configuración del repositorio.
Para declarar imágenes disponibles y activar la política, la configuración del Durable Object incluye el scheduling policy durable_object y una lista de imágenes habilitadas. Dentro del código del DO:
// Dentro del Durable Object, al recibir una tarea:
if (task.language === «python») {
this.ctx.container.start({
image: this.ctx.container.images[«python-312»],
instanceType: «large»,
snapshot: task.snapshotId ?? undefined,
});
} else {
this.ctx.container.start({
image: this.ctx.container.images[«node-20»],
instanceType: «small»,
});
}
Cada imagen declarada queda disponible como propiedad del namespace images, y el instanceType controla la asignación de recursos sin necesidad de otro despliegue.
Qué deberían hacer los administradores y equipos técnicos
Si ya operan Containers en Cloudflare para cargas de agentes, el primer paso es migrar la configuración del Durable Object al scheduling policy durable_object. En el wrangler.toml o wrangler.jsonc del Durable Object, declará las imágenes que el código va a seleccionar en runtime y eliminá las aplicaciones Containers separadas que antes representaban cada combinación imagen/tamaño. Esto reduce la cantidad de artefactos de despliegue y elimina la lógica de enrutamiento entre aplicaciones en el Worker.
Para cargas que requieren pausar y reanudar workspaces (agentes de código con sesiones largas, pipelines de evaluación), habiliten los snapshots de filesystem en el Durable Object y diseñen la lógica de guardado/restauración dentro del ciclo de vida del DO. Dado que los snapshots están en beta pública, validen el comportamiento con cargas reales antes de depender de ellos en producción. Mantengan un fallback: si el snapshot falla, el sandbox debería poder reconstruirse desde el repositorio original.
Para quienes evalúan la plataforma desde cero, modelen primero las decisiones que el agente toma por tarea (qué imagen, cuántos recursos, qué estado inicial). La ventaja de este modelo aparece cuando esas decisiones son dinámicas; si todos los sandboxes usan la misma imagen y el mismo tamaño, el modelo clásico de aplicación Containers sigue siendo más simple de operar.
Conclusión
Cloudflare movió la frontera de configuración de Containers desde el archivo de despliegue hasta la línea de código que ejecuta la tarea. Para equipos que orquestan agentes en Linux con cargas variables de Python, Node.js u otros toolchains, esto significa que agregar un entorno nuevo es un cambio de código, no un ticket de infraestructura con wrangler deploy. Los 648 ms de arranque mediano y los snapshots de filesystem cierran el ciclo: el sandbox existe solo mientras la tarea lo necesita, se guarda cuando el agente descansa y se restaura sin reconstruir el entorno desde cero. No es una evolución incremental; es un cambio de paradigma en cómo se provisiona infraestructura efímera en la edge.
Fuentes
- https://blog.cloudflare.com/faster-agent-sandboxes/