Cloudflare Containers, reconstruido para escalar sandboxes de agentes, cambia el despliegue estático por el control en tiempo de ejecución
Cloudflare Containers, reconstruido para escalar sandboxes de agentes, ahora se inicia más de seis veces más rápido, según la compañía. El lanzamiento del 30 de septiembre también incorpora selección de imágenes en tiempo de ejecución, dimensionamiento de instancias en tiempo de ejecución e instantáneas del sistema de archivos en beta pública.
El cambio importante no es simplemente un inicio en frío más breve. Cloudflare ha trasladado el control de cada sandbox a un Durable Object, su componente serverless con estado para coordinar solicitudes y estado persistente de aplicaciones. Esa decisión cuestiona el modelo de despliegue estático que dio forma a la primera versión de Cloudflare Containers.
Ahora los desarrolladores pueden permitir que un agente elija el entorno necesario para cada tarea. Un trabajo de programación podría requerir una instancia más grande y una cadena completa de herramientas Linux. Una automatización más pequeña podría utilizar un entorno más ligero. Cuando el trabajo se pausa, el sistema puede guardar el sistema de archivos, detener el cómputo y restaurar el espacio de trabajo más adelante.
Esto sitúa a Cloudflare de forma más directa en un dinámico mercado de infraestructura para agentes. E2B, Modal, Daytona, Vercel y los servicios de nube de hiperescala ya ofrecen distintos enfoques para la ejecución aislada. El argumento de Cloudflare es que un controlador accesible globalmente, un espacio de trabajo Linux aislado y un estado persistente deberían funcionar como una única unidad programable.
La arquitectura parece adecuada para agentes de programación, evaluaciones y flujos de trabajo de larga duración. Sin embargo, la afirmación de un inicio seis veces más rápido procede de Cloudflare, las instantáneas siguen en beta pública y existen varios límites operativos relevantes. La verdadera prueba es si los equipos obtienen un control fiable sin asumir una complejidad excesiva del ciclo de vida.
Cloudflare Containers, reconstruido para escalar sandboxes de agentes, transforma el plano de control
El cambio central de Cloudflare consiste en trasladar la configuración del sandbox desde el momento del despliegue hasta el instante en que un agente inicia una tarea.
En el modelo anterior, una aplicación normalmente declaraba una imagen de contenedor y un tipo de instancia en su configuración de despliegue. Cambiar cualquiera de esos ajustes activaba un lanzamiento a nivel de aplicación. Ese patrón funciona para servicios predecibles, pero los agentes generan cargas de trabajo que varían de una solicitud a otra.
Un agente de reparación de código puede necesitar un repositorio, compilador, gestor de paquetes, navegador y suite de pruebas. Un trabajador de evaluación puede necesitar un entorno limpio y repetible con entradas estrictamente controladas. Otra tarea podría requerir solo un script breve con memoria limitada y sin acceso a internet.
La nueva política de programación durable_object de Cloudflare permite que el código de aplicación tome esas decisiones en tiempo de ejecución. El Durable Object controlador llama a ctx.container.start() y proporciona una configuración de imagen, instantánea e instancia adecuada para esa tarea.
Los tamaños predefinidos disponibles incluyen lite y cuatro configuraciones standard. Los desarrolladores también pueden proporcionar valores personalizados de CPU, memoria y disco dentro de los límites de la plataforma. La política de programación en tiempo de ejecución sustituye una configuración seleccionada centralmente por decisiones para cada sandbox.
La selección de imágenes sigue el mismo modelo. Los desarrolladores declaran imágenes con nombre mediante Wrangler, la herramienta de línea de comandos de Cloudflare para despliegues. La plataforma prepara referencias inmutables y el Durable Object selecciona una al iniciar un sandbox.
Esta disposición permite que una aplicación admita varios roles de agentes sin desplegar una aplicación de contenedores independiente para cada rol. Un coordinador puede dirigir una tarea de investigación ligera hacia una imagen y luego asignar un trabajo de compilación a otra imagen con más recursos.
Cloudflare también presentó cloudflare/debian-trixie, una imagen Debian gestionada que contiene Node.js. Un agente puede partir de esa base, instalar sus herramientas mediante exec() y conservar el espacio de trabajo resultante como una instantánea.
Según el anuncio sobre sandboxes de Cloudflare, la nueva ruta de programación inicia Containers más de seis veces más rápido. La compañía afirma haber eliminado varios pasos de coordinación que anteriormente se situaban entre el Durable Object y el tiempo de ejecución del contenedor.
Esta afirmación requiere una interpretación cuidadosa. Cloudflare no ha presentado una prueba comparativa independiente que contraste imágenes, regiones o tipos de carga de trabajo representativos. La disponibilidad del contenedor también depende del tamaño de la imagen, el comportamiento del punto de entrada, la capacidad y las comprobaciones de estado a nivel de aplicación.
La propia documentación de arquitectura de Cloudflare indica que los inicios en frío suelen situarse entre uno y tres segundos. También señala que el tiempo de inicio varía según la imagen y el trabajo de inicialización que realice. Un programador más rápido no puede eliminar las demoras creadas dentro de la propia imagen.
La plataforma expone una propiedad running antes de que un proceso esté necesariamente listo para aceptar tráfico. Los desarrolladores aún deben comprobar que el puerto esté listo antes de enviar la primera solicitud. Para un agente, «contenedor iniciado» y «espacio de trabajo listo para realizar trabajo útil» siguen siendo mediciones distintas.
Incluso con estas salvedades, la configuración en tiempo de ejecución cambia el modelo operativo del producto. Cloudflare Containers ya no son únicamente servicios desplegados que los agentes utilizan de forma incidental. Se convierten en recursos que un controlador de agentes puede ensamblar, dimensionar, detener y reconstruir en torno a tareas individuales.
Los sandboxes de agentes más rápidos presionan a los modelos de despliegue estático
Las cargas de trabajo de agentes favorecen una infraestructura que puede cambiar de forma entre tareas, no solo una infraestructura que ejecuta una imagen de manera eficiente.
Las plataformas tradicionales de contenedores parten de que los desarrolladores conocen la forma de la aplicación antes del despliegue. Los equipos eligen una imagen, asignación de recursos, política de red y configuración de escalado. Después, un programador crea réplicas que comparten en términos generales esas propiedades.
Los sistemas de agentes alteran ese supuesto. Su siguiente acción depende de las solicitudes de los usuarios, las decisiones del modelo, los resultados de las herramientas y el estado que haya dejado el trabajo anterior. Dos tareas consecutivas dentro del mismo producto pueden necesitar sistemas operativos, dependencias, límites de recursos y permisos de red distintos.
Esa variabilidad genera presión sobre proveedores construidos en torno a una configuración estática de aplicaciones. Los equipos aún pueden desplegar varios servicios y distribuir el trabajo entre ellos. Sin embargo, cada nuevo tipo de carga de trabajo añade otra unidad de despliegue, ruta de lanzamiento, decisión de capacidad y fuente de deriva de configuración.
El modelo en tiempo de ejecución de Cloudflare traslada parte de esa decisión al código de aplicación. El controlador del agente puede elegir una imagen de sandbox y un tipo de instancia después de examinar la tarea. También puede decidir si el sandbox recibe acceso a internet o se inicia a partir de una instantánea almacenada.
Por tanto, el principal adversario no es un proveedor concreto. Es el modelo de despliegue estático que trata cada sandbox de una aplicación como una copia del mismo servicio predefinido.
E2B, Modal, Daytona y Vercel ya abordan este mercado mediante sus propias abstracciones. Algunos enfatizan API de sandbox orientadas a desarrolladores. Otros se articulan en torno a funciones, máquinas virtuales, espacios de trabajo u orquestación de nube más amplia. Los equipos que operan Kubernetes o Firecracker directamente obtienen mayor control, pero también asumen más infraestructura.
El diferenciador de Cloudflare es la relación entre cada contenedor y su Durable Object. Un Durable Object proporciona una identidad estable, código de aplicación, almacenamiento, alarmas y coordinación fuera del entorno Linux. El contenedor aporta cómputo aislado para herramientas que necesitan un sistema operativo convencional.
El bucle de decisión del agente puede seguir activo mientras el espacio de trabajo Linux permanece inactivo. Puede comunicarse con usuarios, conservar el estado de autorización e invocar modelos sin mantener en funcionamiento el sandbox más pesado. Cuando se hace necesario un compilador o servidor de desarrollo, el controlador activa el contenedor.
Cloudflare describe esta separación como mantener el «cerebro» del agente separado de sus «manos». El controlador conserva la intención y el estado, mientras el sandbox ejecuta comandos que pueden fallar, detenerse o requerir sustitución.
Esta separación ofrece beneficios de seguridad además de ventajas operativas. El Durable Object puede mantener credenciales fuera del contenedor y mediar las solicitudes salientes. Un agente no necesita necesariamente acceso directo a cada secreto requerido para una llamada de servicio autorizada.
Cloudflare ya había sostenido que el código de agentes generado dinámicamente requiere un entorno de ejecución aislado. Su anterior modelo de sandbox de código se centraba en Dynamic Workers ligeros para tareas que no requieren un sistema Linux completo.
Containers cubre el lado más pesado de esa división. Admite gestores de paquetes, binarios nativos, repositorios, compiladores, terminales y servidores de desarrollo. Dynamic Workers puede gestionar tareas de ejecución de código más pequeñas con un entorno de ejecución más acotado.
Esto crea una estrategia de ejecución por niveles. Un controlador puede utilizar un sandbox ligero para un flujo de trabajo breve de API y reservar un contenedor para tareas que requieran Linux. La selección en tiempo de ejecución importa porque mantener cada tarea dentro de un contenedor completo desperdicia tiempo de inicio y recursos.
La presión se extiende más allá de los proveedores de sandboxes. Los equipos internos de plataformas suelen mantener grupos de entornos de desarrollo activos para ocultar los retrasos de aprovisionamiento. Los inicios en frío más rápidos y los sistemas de archivos reanudables debilitan el argumento para mantener disponibles grandes grupos inactivos.
Sin embargo, Cloudflare no está eliminando la orquestación. Está reubicando la orquestación en el Durable Object y su código de aplicación. Los equipos aún deben diseñar reglas de admisión, controles de concurrencia, comportamiento de reintentos, autorización, limpieza y observabilidad.
El modelo ganador no será el de la plataforma que informe del menor número de inicio aislado. Será el modelo que minimice el tiempo total desde la decisión de un agente hasta un resultado de tarea verificado.
Eso incluye preparación de imágenes, acceso al repositorio, restauración de dependencias, ejecución de comandos, latencia de red y desmontaje. También incluye la demora humana causada por sesiones fallidas o trabajo perdido.
Para los equipos de ingeniería que comparan opciones, la prueba relevante debería reproducir su flujo de trabajo completo. Una prueba sintética de contenedor vacío no puede representar un repositorio grande, instalación de paquetes, inicio de navegador o una suite de pruebas.
Estas evaluaciones también generan conocimiento de diseño que los equipos deben conservar. Una base de conocimientos de ingeniería con capacidad de búsqueda puede preservar supuestos de pruebas comparativas, decisiones de seguridad y hallazgos de migración junto con la implementación.
Durable Objects convierte los contenedores en cómputo específico para cada tarea
El mecanismo detrás del lanzamiento es un controlador con estado que trata su contenedor como cómputo reemplazable, en lugar de como estado permanente de la aplicación.
Cada Cloudflare Container está asociado con un Durable Object. Las solicitudes llegan primero a un Worker y luego se enrutan a través de ese objeto antes de llegar al contenedor. El Durable Object puede dirigirse a un espacio de trabajo específico y conservar el estado conectado a su identidad.
Con la nueva API, los desarrolladores extienden DurableObject directamente y acceden al contenedor adjunto mediante this.ctx.container. Esto elimina la clase envoltorio que Cloudflare utilizó originalmente para hacer que Containers se pareciera a servicios de sandbox convencionales.
El controlador puede iniciar el contenedor, ejecutar comandos, inspeccionarlo, supervisar salidas, enviar señales a procesos, establecer un tiempo de espera por inactividad y destruir la instancia. Puede combinar esos controles con almacenamiento de Durable Object, alarmas, WebSockets y llamadas a procedimientos remotos.
Consideremos un agente de programación que responde a un informe de errores. El Durable Object puede almacenar el identificador de sesión, el repositorio aprobado, los permisos del usuario y la fase actual de la tarea. Después puede seleccionar una imagen que contenga la cadena de herramientas de lenguaje adecuada e iniciar una instancia apropiada.
El contenedor clona el repositorio, instala dependencias, ejecuta la suite de pruebas y edita archivos. Mientras tanto, el Durable Object puede enviar actualizaciones de progreso mediante un WebSocket y registrar puntos de control fuera del contenedor.
Si el proceso del contenedor termina, el controlador conserva la identidad y los metadatos de la sesión. Puede examinar el fallo, reiniciar desde un estado conocido o informar del problema sin perder toda la interacción.
Cloudflare ejecuta cada contenedor dentro de una microVM Firecracker, una máquina virtual ligera con su propio kernel y red. La imagen del cliente se ejecuta como un contenedor Linux dentro de esa máquina virtual.
La arquitectura de contenedores de la plataforma establece que otras cargas de trabajo de Cloudflare no comparten ese kernel. Este aislamiento importa porque los comandos generados por agentes no deberían ejecutarse directamente dentro de la aplicación que gestiona datos de usuarios de confianza.
La ubicación sigue siendo dinámica. Cloudflare elige capacidad apta donde esté disponible la imagen requerida, y la ubicación se ve influida por el enrutamiento y la velocidad de inicio. No se garantiza que el Durable Object y el contenedor se ejecuten en el mismo lugar.
Esa salvedad importa para los bucles de control sensibles a la latencia. Una identidad accesible globalmente no significa que todas las operaciones se ejecuten junto al usuario, el proveedor del modelo o el sandbox. Los equipos deberían medir toda la ruta de solicitud en las regiones previstas.
La capacidad también puede cambiar entre sesiones. Si un contenedor se detiene y luego se reinicia, Cloudflare puede ubicar el reemplazo en otro lugar. Las aplicaciones no deben tratar la identidad local de una máquina como permanente.
El Durable Object se convierte en la capa de continuidad. Almacena la información necesaria para encontrar, reconstruir o restaurar el espacio de trabajo. La instancia Linux se convierte en un recurso de ejecución que puede desaparecer cuando está inactivo.
Esta arquitectura también admite cargas de trabajo con ramificaciones. Un coordinador puede iniciar varios intentos independientes a partir de la misma base preparada. Cada intento puede probar un modelo, prompt de sistema, conjunto de habilidades o estrategia de reparación diferente.
El controlador puede supervisar esas ejecuciones, comparar resultados y conservar la salida preferida. Los sistemas de aprendizaje por refuerzo pueden utilizar patrones similares para crear entornos controlados, evaluar resultados y restablecer el estado entre pruebas.
El dimensionamiento de instancias en tiempo de ejecución refuerza ese modelo. Un controlador puede asignar más recursos a las compilaciones y reducirlos para comandos más ligeros. Un dimensionamiento estático para toda la aplicación obligaría a los equipos a aprovisionar para la tarea común más grande o a mantener implementaciones separadas.
Sin embargo, la programabilidad transfiere la responsabilidad a la aplicación. El controlador debe impedir que un modelo seleccione recursos sin límites. Debe asignar las solicitudes del agente a políticas aprobadas, en lugar de pasar salidas arbitrarias del modelo a las API de infraestructura.
El mismo principio se aplica a las imágenes. Permitir la selección en tiempo de ejecución no significa permitir que un agente ejecute cualquier imagen no revisada. Cloudflare exige referencias de imágenes declaradas y fijadas por digest, lo que ayuda a mantener las implementaciones reproducibles.
Los equipos deberían mantener una lista de permitidos de imágenes, analizar dependencias, restringir el acceso saliente y separar las credenciales del entorno invitado. Un sandbox reduce la exposición, pero no define la política de seguridad completa.
Desde el punto de vista operativo, el Durable Object debe seguir siendo la fuente de verdad para el estado del ciclo de vida. La API directa de Cloudflare proporciona control, pero las aplicaciones deben decidir cuándo una tarea pasa a ser recuperable, abandonada, completada o segura de reintentar.
Ese es el mecanismo real detrás de sandboxes de agentes más rápidos. La mejora del planificador importa, pero el cambio duradero es un plano de control explícito que sobrevive a cualquier proceso de contenedor individual.
Las instantáneas del sistema de archivos conservan archivos, no sesiones en ejecución
Las instantáneas reducen el trabajo de preparación repetido, pero son puntos de control inmutables del sistema de archivos, no imágenes completas para suspender y reanudar.
Las instantáneas nativas del sistema de archivos de Cloudflare están disponibles en beta pública mediante la política de programación durable_object. Un contenedor en ejecución llama a snapshotContainer() para capturar su sistema de archivos raíz escribible en un momento determinado.
El identificador devuelto contiene un identificador, tamaño y nombre opcional. Los desarrolladores deben guardar ese identificador, a menudo en el almacenamiento de Durable Object, porque la API de Worker no proporciona un comando para listar instantáneas.
Un contenedor posterior puede iniciarse desde el identificador almacenado. Esto hace que un espacio de trabajo de programación sea recuperable después de que se detenga el cómputo original. El repositorio, las dependencias instaladas, las cachés de compilación, los archivos de configuración y las ediciones pueden volver con el sistema de archivos restaurado.
Ese modelo resuelve una discrepancia habitual en la infraestructura de agentes. Iniciar un sandbox vacío puede tardar segundos, mientras que preparar un entorno de desarrollo útil puede llevar minutos. Repetir la instalación de dependencias puede dominar la medición de inicio que los usuarios realmente perciben.
Las instantáneas también proporcionan una base estable para evaluaciones. Un equipo puede preparar un repositorio y una cadena de herramientas, guardarlos y comenzar varios experimentos desde el mismo punto de control. Cada sandbox recibe un entorno escribible independiente tras la restauración.
Esto reduce la deriva de entorno entre intentos. Si dos versiones de un modelo ven distintos estados de dependencias, los resultados de las pruebas se vuelven más difíciles de comparar. Un punto de control compartido e inmutable ayuda a aislar la variable evaluada.
La función también admite proyectos más largos. Un agente puede guardar su espacio de trabajo cuando un usuario se va, detener el cómputo y restaurar los archivos cuando el usuario vuelve. Esto separa la continuidad del sistema de archivos del uso continuo de recursos.
Sin embargo, la palabra “instantánea” puede implicar más de lo que Cloudflare conserva actualmente. La documentación sobre instantáneas indica que el sistema captura todo el sistema de archivos del contenedor, pero no la memoria, los procesos en ejecución ni los sistemas de archivos montados por separado.
Un contenedor restaurado vuelve a ejecutar su punto de entrada. Una compilación en memoria, un depurador activo, un proceso de terminal o un servidor de desarrollo no se reanudan desde la instrucción exacta en la que se detuvieron. La aplicación debe reconstruir esos procesos.
Las instantáneas también están vinculadas a la versión de imagen utilizada para crearlas. Los desarrolladores no pueden restaurar una en una imagen diferente. Cuando cambia una imagen base, el equipo debe crear una nueva instantánea compatible.
Cada identificador de instantánea tiene un tiempo de vida implícito de 30 días. Restaurarla renueva ese período, pero hoy los desarrolladores no pueden configurar un intervalo de retención distinto. Esa limitación hace que las instantáneas no sean adecuadas como archivo indefinido sin un plan externo de preservación.
Las instantáneas son inmutables. Los cambios realizados después de la restauración requieren otra instantánea si el equipo quiere conservarlos. Por tanto, las aplicaciones necesitan políticas de puntos de control que equilibren el valor de recuperación frente al almacenamiento, la latencia y la complejidad operativa.
El estado de beta pública añade otro motivo de cautela. Los equipos de producción deberían validar la creación y restauración de instantáneas ante interrupciones, acceso concurrente, actualizaciones de imágenes y cambios de ubicación regional.
También deberían probar los límites de fallo. Si el contenedor se detiene durante un punto de control, la aplicación necesita un registro claro de qué instantánea sigue siendo válida. Si una tarea modifica un sistema externo, restaurar su sistema de archivos no revierte esa acción externa.
Esta distinción es especialmente importante para los agentes autónomos. Una reversión puede restaurar archivos locales mientras deja sin cambios una solicitud de extracción, una actualización de base de datos, un correo electrónico o un recurso en la nube. Reintentar la tarea a ciegas podría duplicar una acción irreversible.
Por ello, el controlador necesita un registro de tareas fuera del sandbox. Debe registrar operaciones aprobadas, efectos secundarios externos y puntos de control completados. El sistema de archivos por sí solo no puede representar toda la verdad sobre el trabajo de un agente.
Los equipos de seguridad también deben examinar qué conservan las instantáneas. Los repositorios, el código generado, los registros, los paquetes en caché y las credenciales temporales pueden llegar al sistema de archivos escribible. Una instantánea puede retener material sensible durante más tiempo que la sesión en ejecución.
Cloudflare ofrece interceptación de solicitudes salientes y gestión de credenciales externas, lo que puede reducir la exposición de secretos dentro del entorno invitado. Aun así, los desarrolladores deberían verificar que las herramientas no copien tokens en archivos de configuración, historiales de shell o cachés de paquetes.
La dirección de migración de la empresa introduce otra cuestión práctica. Las nuevas funciones, incluida la ruta más rápida y las instantáneas nativas, requieren acceso directo a ctx.container. Cloudflare afirma que mantendrá las clases antiguas Container y Sandbox heredada hasta el 31 de diciembre de 2026.
Según la empresa, las implementaciones existentes seguirán funcionando después de esa fecha, pero esas clases dejarán de recibir actualizaciones. Los equipos que quieran las nuevas capacidades deben migrar su lógica de ciclo de vida a la API directa de Durable Object.
Ese es un cambio de arquitectura significativo, no una opción que todos los equipos puedan activar con seguridad. La API directa expone más del modelo de identidad y coordinación del sistema. También pide a los desarrolladores que asuman explícitamente la responsabilidad de comportamientos antes ocultos por una clase base.
Cloudflare está transformando Sandbox SDK 1.0 en una colección de utilidades en lugar de una superclase. Esto debería permitir a los equipos combinar ayudantes prácticos con control nativo del ciclo de vida. También confirma que Cloudflare quiere que el Durable Object, y no el envoltorio del SDK, defina la abstracción central.
Las próximas pruebas son la fiabilidad, la adopción y la respuesta competitiva
El lanzamiento solo tendrá consecuencias si los sistemas de agentes reales convierten sus nuevos controles en menor latencia de tareas y recuperación fiable.
La primera señal que se debe observar es el rendimiento de producción en cargas de trabajo completas. La mejora de seis veces comunicada por Cloudflare se refiere a su ruta de inicio, pero los desarrolladores necesitan mediciones desde el envío de la tarea hasta que la aplicación está lista.
Las pruebas útiles deberían cubrir imágenes pequeñas y grandes, varias regiones, instantáneas restauradas, sistemas de archivos nuevos y distintos tamaños de instancia. Deberían distinguir la latencia del planificador de la inicialización de imágenes, la restauración de dependencias y la disponibilidad del servicio.
Si esas mediciones muestran retrasos de extremo a extremo consistentemente más cortos, el argumento de Cloudflare se fortalece. Si las ganancias desaparecen una vez que los repositorios y los servidores de desarrollo entran en el flujo de trabajo, la velocidad de inicio se convierte en una ventaja más limitada.
La segunda señal es la fiabilidad de las instantáneas después de que la beta pública llegue a cargas de trabajo exigentes. Los equipos deberían vigilar las tasas de fallo de restauración, la duración de los puntos de control, el comportamiento del almacenamiento, los procedimientos de actualización de imágenes y la recuperación tras sesiones interrumpidas.
La adopción exitosa por parte de agentes de programación sería especialmente reveladora. Cloudflare ya cita a Base44 y Kilo Code como usuarios de entornos aislados para trabajo de agentes. Material anterior de Cloudflare también identificó a Figma Make como cliente de Containers para la ejecución de código no confiable.
Estas referencias de clientes muestran casos de uso reales, pero no aportan datos comparativos de rendimiento. Los informes de ingeniería independientes tendrían más peso que los testimonios de lanzamiento.
El comportamiento de las instantáneas con repositorios grandes también será importante. Los directorios de paquetes y las salidas de compilación pueden crecer rápidamente. Los equipos necesitan entender si las instantáneas siguen siendo rápidas y manejables a medida que los espacios de trabajo crecen a través de puntos de control repetidos.
Si Cloudflare amplía los controles de retención de instantáneas, las API de listado, la observabilidad o las herramientas de migración entre versiones, eso sugeriría que la función avanza hacia un uso de producción más amplio. Las limitaciones persistentes debilitarían la propuesta de espacios de trabajo de larga duración.
La tercera señal es cómo responden los competidores al modelo combinado de controlador y sandbox de Cloudflare. El mercado de sandboxes para agentes incluye proveedores especializados y plataformas de cómputo más amplias, cada uno con fortalezas diferentes.
E2B hace hincapié en entornos cloud diseñados específicamente para agentes. Modal conecta computación aislada en sandboxes con una plataforma serverless más amplia. Daytona se centra en entornos de desarrollo, mientras que Vercel integra capacidades de sandbox con su plataforma de aplicaciones.
Las nubes de hiperescala ofrecen a los equipos un amplio control mediante máquinas virtuales, contenedores, sistemas de identidad y servicios de orquestación. Su desventaja suele ser el trabajo de ingeniería necesario para ensamblar esos componentes en un producto de agentes de baja latencia.
Cloudflare apuesta a que Durable Objects simplifican ese ensamblaje. La identidad, el estado, la comunicación, las políticas y el ciclo de vida pueden residir junto al controlador del sandbox. Su red global proporciona enrutamiento y capacidad preparada.
Una respuesta competitiva podría adoptar varias formas. Otros proveedores podrían añadir una coordinación con estado más sólida, snapshots más flexibles, un dimensionamiento de tiempo de ejecución más granular o una mediación de credenciales más estrecha. También podrían publicar benchmarks que cuestionen las afirmaciones de Cloudflare sobre el arranque.
Si los competidores convergen en un controlador externo con estado, la arquitectura de Cloudflare parecerá visionaria incluso cuando los clientes elijan otra plataforma. Si los desarrolladores prefieren API de sandbox alojadas más simples, el modelo de Durable Object podría parecer demasiado cargado de infraestructura.
La adopción dependerá en parte de cuánto control quieran los equipos de aplicaciones. Una startup que desarrolla un agente de programación puede valorar la programación directa del ciclo de vida. Un equipo que añade una sola función de ejecución de código podría preferir un servicio más prescriptivo con menos decisiones.
Cloudflare debe atender a ambos grupos sin ocultar las capacidades que distinguen a la plataforma. La nueva dirección del SDK intenta conciliar ambas necesidades al ofrecer utilidades en torno a una API nativa, en lugar de otra abstracción obligatoria.
Los incidentes de seguridad serán otra medida decisiva. Los sandboxes de agentes ejecutan comandos no confiables o impredecibles, a menudo con acceso a la red y cercanía a código propietario. Un entorno rápido que filtrara credenciales o permitiera acceso entre inquilinos incumpliría su propósito central.
El uso de microVMs Firecracker por parte de Cloudflare proporciona aislamiento a nivel de kernel entre cargas de trabajo. Aun así, una operación segura también depende de la higiene de las imágenes, los controles de salida, la autorización, el manejo de secretos, el registro y la política de aplicación.
Los equipos deben tratar el modelo como una contención por capas, no como permiso para confiar en código generado por agentes. El Durable Object puede convertirse en el punto de aplicación de políticas, pero los desarrolladores deben implementar y probar esa política.
El lanzamiento también plantea una cuestión más amplia sobre la arquitectura de productos de agentes. ¿Debe el agente vivir fuera del espacio de trabajo y tratarlo como una herramienta reemplazable, o debe ejecutarse dentro de su computadora?
Cloudflare admite ambos patrones. Ejecutar el agente en el Durable Object mantiene disponibles la comunicación y el estado mientras la computación permanece inactiva. Ejecutarlo dentro del contenedor ofrece un modelo de procesos Linux familiar, mientras el objeto lo supervisa desde fuera.
El primer patrón hace explícito el límite entre el cerebro y las manos. El segundo puede simplificar los runtimes de agentes existentes que esperan archivos y procesos locales. La adopción real mostrará qué modelo les resulta más fácil de operar a los desarrolladores.
Cloudflare Containers, reconstruido para escalar sandboxes de agentes, representa más que una mejora en el arranque en frío. Convierte la elección del runtime, la continuidad del sistema de archivos y la política de ciclo de vida en decisiones de nivel de aplicación controladas por estado duradero.
Ese cambio presiona a los despliegues estáticos y las API de sandbox simplistas. También ofrece a los desarrolladores más formas de crear fallos sutiles. La flexibilidad del runtime requiere políticas estrictas, registros de tareas duraderos y benchmarks que midan una preparación útil en lugar de un proceso vacío.
Los equipos que evalúen el lanzamiento deberían empezar con una carga de trabajo real. Midan el arranque desde cero, el arranque restaurado, la disponibilidad de dependencias, la recuperación ante fallos y la finalización total de tareas. Después, prueben si el controlador sobrevive a la pérdida de contenedores sin repetir acciones externas.
Los próximos meses deberían revelar si los snapshots de la beta pública de Cloudflare siguen siendo fiables, si los clientes publican resultados de latencia independientes y si los competidores adoptan controles con estado similares. Esas señales determinarán si esta arquitectura se convierte en una base común para agentes de larga duración o en otra opción especializada en un mercado cada vez más saturado.
