Cloudflare rediseña Containers para agentes: arranque 6 veces más rápido

Cloudflare ha reestructurado la infraestructura de Containers para la carga que generan los agentes de IA: los sandboxes aparecen bajo demanda, uno por tarea, y tienen que estar listos al instante. En el benchmark independiente ComputeSDK, el tiempo de arranque mediano bajó de 4,049 segundos a 648 milisegundos (6,2 veces). En la prueba propia de la compañía, una sola cuenta levantó 100 000 contenedores en 5,387 segundos en seis ubicaciones. Con ello llegan también la selección de imagen y recursos directamente desde el código y los snapshots del sistema de archivos en beta pública.

La imagen y el hardware los elige el código, no el despliegue

Hasta ahora, Containers giraba en torno a la aplicación: la imagen y los recursos de cómputo se fijaban en el despliegue y se distribuían de forma centralizada. Para un sandbox de agente, eso resulta incómodo. Según la tarea, necesita herramientas, volumen de recursos y archivos iniciales distintos, y puede vivir unos minutos, quedarse dormido entre peticiones o restaurarse varios días después.

El modelo anterior exigía una aplicación distinta para cada combinación de imagen y tipo de instancia, con su propio espacio de nombres de Durable Objects y su enrutamiento en un Worker. Un sandbox pequeño con Node.js y un entorno grande de Python para compilaciones suponían dos despliegues. La nueva política de planificación `durable_object` lo reduce a una condición `if`: en la configuración de wrangler se declaran las imágenes disponibles (por ejemplo, node y python), y al arrancar, el Durable Object pasa a `ctx.container.start()` la imagen, el tipo de instancia (digamos, standard-1 o standard-2) y un indicador de acceso a internet. Un entorno nuevo se obtiene ahora modificando el código, no con un nuevo despliegue.

Lo mismo ocurre con la distribución de actualizaciones. Desaparecen los periodos de gracia, los splits porcentuales y las llamadas a la API de configuración: el contenedor se ejecuta con la imagen con la que arrancó hasta que el código lo detiene, y el siguiente arranque usa la imagen que elija el código. De ahí salen un despliegue canary para el 5% de los sandboxes nuevos según el hash del ID del Durable Object, la fijación de los proyectos activos a la imagen actual, la migración en un punto de control y el rollback mediante un simple cambio de imagen para los lanzamientos futuros.

Por qué el primer comando se ejecuta más rápido

Antes, el arranque de un contenedor pasaba por un plano de control global: este analizaba la configuración de la aplicación, buscaba capacidad y coordinaba la ubicación. Ahora la demanda surge en el nivel del Durable Object. La infraestructura busca primero hueco en la misma máquina, después amplía la búsqueda dentro de la ubicación y da prioridad a los hosts donde la imagen o el snapshot ya están en local.

También se ha eliminado lo superfluo una vez que el contenedor llega al host: en lugar de arrancar una máquina virtual desde cero, el entorno de ejecución restaura una VM sin asignar preparada de antemano, reutiliza la configuración de red y del sistema de archivos, agrupa las operaciones repetitivas y no espera a servicios que el primer comando no necesita. Resultados del benchmark Burst TTI (100 sandboxes simultáneos, medición del lado del cliente):

• mediana: 4,049 s → 648 ms (6,2 veces más rápido); • percentil 95: 5,839 s → 910 ms (6,4 veces); • percentil 99: 6,717 s → 1129 ms (5,9 veces).

Aparte, Cloudflare ha publicado la imagen `cloudflare/debian-trixie`, con Debian Trixie Slim y Node.js 24.20.0 LTS. Un agente puede arrancar un sandbox Linux sin Dockerfile, sin compilar ni subir una imagen, y luego clonar un repositorio e instalar paquetes con `exec()`. Como la imagen la controla la propia Cloudflare, se distribuye de antemano a los hosts adecuados y, al arrancar, no se descarga ni se descomprime nada.

Snapshots: guardar el espacio de trabajo y volver a él

Incluso un arranque rápido no elimina la configuración: clonar, instalar dependencias y configurar la toolchain suele llevar más tiempo que arrancar el propio contenedor. Para eso llegan a beta pública los snapshots nativos del sistema de archivos. El método `snapshotContainer()` guarda el espacio de trabajo y `start()` con el parámetro `containerSnapshot` lo restaura.

Los snapshots son inmutables y reutilizables, por lo que sirven en dos escenarios. El primero: un mismo espacio de trabajo continúa entre sesiones. Un agente de programación guarda el repositorio, las dependencias, las cachés de compilación y los cambios cuando el usuario se va, y los recupera al día siguiente.

El segundo: un punto de control común para muchos sandboxes. Resulta útil para evaluar agentes, cuando se ejecuta la misma tarea con distintos prompts de sistema, skills, modelos o versiones del agente y todo lo demás debe permanecer igual. Un solo snapshot lanza muchos entornos aislados con la misma base y elimina la deriva del entorno en los resultados.

También funciona en cadena: el agente arranca con debian-trixie, configura el entorno con `exec()` y guarda el resultado como snapshot.

A quién le conviene

Estos son los escenarios para los que se ha rehecho la plataforma: agentes de programación con repositorios, gestores de paquetes, compiladores y servidores de desarrollo; evaluaciones con un estado inicial conocido; sistemas de aprendizaje por refuerzo que crean, evalúan y reinician un gran número de entornos; y tareas largas en las que hay que conservar los archivos.

Base44 (un entorno de desarrollo aislado para cada aplicación, con vista previa en vivo) y Kilo Code (un entorno independiente para cada sesión de agente en la nube) ya construyen sus productos sobre Containers. Hay integraciones con Cursor Cloud Agents, Devin Outposts, OpenAI Agents API y Claude Managed Agents. El modelo se traslada también a Sandbox SDK 1.0, y la API nativa `ctx.container` incorpora más funciones para que el Durable Object gestione el contenedor sin una clase envoltorio.

Para los equipos que desarrollan productos con agentes, la conclusión práctica es esta: si mantiene aplicaciones separadas para cada stack, puede consolidarlas en una sola clase Durable Object que elija la imagen en tiempo de ejecución. Para evaluaciones y RL conviene crear un snapshot de referencia y lanzar ejecuciones paralelas a partir de él. Para sesiones de larga duración encaja el esquema de «snapshot al pausar, restauración al volver». Las cifras de los 100 000 contenedores son preliminares, por lo que es mejor comprobar la carga real con su propio perfil.