Comparativa de sandboxes en Puppyone: Docker vs Cloudflare — ¿Cuál encaja con tu agente de IA?
23 de abril de 2026Guanqun @puppyone
Cuando ejecutas agentes de IA en producción, el aislamiento no es opcional. Los agentes ejecutan código, tocan el sistema de archivos y llaman a servicios externos — y sin un sandbox como es debido, una sola salida desafortunada puede causar daños difíciles de revertir.
Puppyone soporta dos entornos de sandbox distintos para cargas de trabajo distintas: una sandbox basada en Docker para ejecución completa y flexible, y una sandbox basada en Cloudflare para cargas rápidas, ligeras y distribuidas globalmente. Este artículo desgrana qué es cada una, en qué se diferencian y cómo elegir la que toca.
¿Qué es una sandbox?
Una sandbox es un entorno de ejecución aislado donde todo lo que hace un agente — ejecutar código, tocar archivos, llamar herramientas — queda contenido y bajo control. Una buena sandbox impone fronteras claras:
- Qué puede leer y escribir el agente
- Qué llamadas de red puede hacer
- Cuánta CPU y memoria puede consumir
- Cuánto tiempo puede correr antes de ser terminado
Ambos tipos de sandbox aplican estas fronteras. Lo interesante es cómo las aplican y qué compromisos trae cada enfoque.
Sandbox Docker vs sandbox Cloudflare: la diferencia de fondo
Toda la comparativa cabe en una frase: la sandbox Docker te da una máquina Linux completa; la sandbox Cloudflare te da un slot para ejecutar JavaScript.
La sandbox Docker se monta sobre contenedores. Cada sandbox es, en la práctica, su propio servidor Linux — puedes instalar paquetes (apt install, pip install), correr cualquier runtime (Python, Node, Go), lanzar subprocesos, leer y escribir un sistema de archivos real, y dejar tareas corriendo durante horas. El precio: un cold start de varios segundos y CPU y memoria reales consumidas mientras existe.
La sandbox Cloudflare se monta sobre V8 Isolates — el mismo modelo de aislamiento que usa Chrome para mantener separadas las pestañas del navegador. Solo puede ejecutar JavaScript / WebAssembly: nada de instalar paquetes, nada de subprocesos, nada de sistema de archivos local, y una ejecución típicamente está limitada a 30 segundos de CPU. A cambio, arranca en menos de 5 milisegundos, mete miles de isolates en una sola máquina y se despliega automáticamente sobre los más de 300 nodos edge de Cloudflare.
| Lo que quieres hacer | Elige |
|---|---|
| Correr scripts de Python, instalar librerías, procesar datos | Docker |
Que el agente edite archivos, genere informes, ejecute git | Docker |
| Tareas que duran de minutos a horas | Docker |
| Responder a una petición en milisegundos | Cloudflare |
| Lógica JavaScript de alta concurrencia (routing, transformaciones, filtrado) | Cloudflare |
| Ejecutar cerca de los usuarios en varias regiones | Cloudflare |
A continuación entramos al detalle de cada una.
La sandbox basada en Docker
Cómo funciona
Cada tarea del agente corre dentro de su propio contenedor — un entorno Linux aislado del host con namespaces y cgroups. Cuando llega una tarea, Puppyone arranca un contenedor limpio a partir de una imagen preconstruida, monta los inputs, asigna un directorio de trabajo y aplica cuotas de recursos. Cuando la tarea termina, el contenedor entero se desmonta. Cada ejecución parte de un estado limpio conocido — sin procesos, archivos ni variables de entorno residuales del run anterior.
Lo que obtienes
Imágenes personalizables. La imagen base por defecto es Ubuntu con Python, Node, Git y curl preinstalados. Si no es suficiente, trae tu propio Dockerfile — Puppyone soporta las instrucciones estándar (FROM, RUN, COPY, WORKDIR, ENV) — y mete los runtimes, herramientas CLI o dependencias privadas que necesite tu equipo. El agente arranca directamente en un entorno preparado a la medida de tu workflow.
Recursos configurables. Por defecto 2 vCPUs y 512 MB de RAM, escalables por tarea hasta 8 vCPUs y 8 GB. Si una sandbox se queda sin memoria, el contenedor se mata limpiamente — el host no se ve afectado.
Duración controlada. Timeout por defecto de 5 minutos por tarea, configurable hasta 24 horas. Para workflows más largos, la sandbox soporta pause / resume — el sistema de archivos y el estado de memoria se snapshotean al pausar y se restauran al reanudar, así no pagas por volver a montar el entorno desde cero.
Control fino del egress de red. Todo el tráfico saliente está bloqueado por defecto. Tú declaras explícitamente qué dominios o puertos puede alcanzar el agente (por ejemplo api.openai.com o *.github.com) — el resto se rechaza. Así es como evitas que un agente comprometido por prompt injection exfiltre datos sin que te enteres.
Workspace cableado a tu sistema de archivos. Cada sandbox monta un namespace dentro del sistema de archivos de Puppyone — no un directorio temporal volátil. Cuando el agente escribe un archivo dentro del contenedor, en la práctica está commiteando un cambio en Puppyone: versionado, con permisos y auditable. Puedes hacer rollback, pasárselo a otro agente o trazarlo hasta la tarea y el paso exactos que lo produjeron.
Facturación por tiempo de vida del contenedor. Pagas por cada segundo que el contenedor existe, esté la CPU haciendo algo o no. Esto premia el patrón "ejecuta y desmonta": arranca la tarea, termínala, mata el contenedor. Si tu agente se pasa la mayor parte del tiempo esperando una respuesta de un LLM o input del usuario, también pagas por esa espera.
Cuándo no encaja
- Caminos de respuesta por debajo de los 100 ms (los cold starts son de segundos, no de milisegundos)
- Miles de peticiones independientes por segundo (cada contenedor consume recursos reales)
- Unas pocas líneas de lógica JavaScript ligera (matar moscas a cañonazos)
Cuándo sí
- Scripts de Python / Node / shell que tocan archivos, usan librerías o generan artefactos
- Workflows multietapa donde cada paso construye sobre el workspace del anterior
- Cualquier tarea que necesite instalar paquetes, compilar código o llamar utilidades del sistema
- En resumen: cualquier cosa que necesite, de verdad, una máquina
Cómo lo soporta Puppyone
La sandbox Docker de Puppyone es API-compatible con E2B — si tu agente ya corre sobre E2B, puedes apuntarlo a Puppyone sin tocar la lógica de negocio. Sandbox.create(), runCode(), commands.run(), I/O de archivos — todo encaja directo. Lo que ganas es que la sandbox y el sistema de archivos son una sola cosa. Ya no tienes que gestionar la cadena incómoda de "archivos en la sandbox → persistir en object storage → sincronizar a la siguiente sandbox". Cada escritura aterriza en el sistema de archivos de Puppyone con historial de versiones, permisos y logs de auditoría — el mismo estado, visible entre tareas, agentes e incluso tipos de sandbox.
La sandbox basada en Cloudflare
Cómo funciona
El código del agente corre dentro de un V8 Isolate sobre la red edge global de Cloudflare — la misma tecnología que usa Chrome para aislar pestañas del navegador. Cada isolate es un contexto de ejecución JavaScript sellado, que arranca en milisegundos (no hay sistema operativo que bootear) y se destruye cuando termina la petición. Las peticiones se enrutan al nodo edge más cercano al usuario, manteniendo la latencia ida y vuelta en decenas de milisegundos.
Lo que obtienes
Cold starts en milisegundos. Un isolate arranca en menos de 5 ms — unos tres órdenes de magnitud más rápido que un contenedor. Puedes permitirte arrancar una sandbox nueva por cada petición sin warm pools ni instancias permanentes.
Solo JavaScript / WebAssembly. Nada de Python, ni shell, ni binarios nativos. Tu lógica es JS/TS o compila a WASM. La mayor parte de los built-ins de Node.js está disponible, pero todo lo que dependa de syscalls (fs, child_process, extensiones C nativas) no lo está.
Tope de 128 MB de memoria, 30 segundos de CPU por petición. Cada petición tiene como máximo 128 MB de memoria y 30 segundos de CPU (configurable hasta 5 minutos en planes de pago). Conviene tenerlo claro: solo cuenta el tiempo activo de CPU — el tiempo esperando un fetch() o una consulta a base de datos no cuenta, así que una petición limitada a 30 segundos de CPU puede mantenerse abierta varios minutos de reloj.
Sin sistema de archivos local. Los isolates son sin estado. Lo que necesite persistir tiene que ir a almacenamiento externo — Cloudflare KV, R2, D1, o tu propia base de datos. Para compartir estado intermedio entre peticiones, lo serializas y lo vuelves a leer, o lo respaldas con un servicio con estado aparte.
Ejecución edge global + autoescalado. Tu código se despliega automáticamente sobre los más de 300 nodos edge de Cloudflare y corre en el más cercano a cada usuario. De cero a decenas de miles de QPS sin planificar capacidad — la plataforma se encarga.
La capa de seguridad de Cloudflare viene gratis. Protección contra DDoS, rate limiting, gestión de bots y terminación TLS están integrados en la red. No tienes que montar una capa aparte.
Facturación solo por milisegundos activos de CPU. Cuando un isolate está esperando un fetch(), una base de datos o un evento de usuario, no pagas. Solo te cobran los milisegundos en los que V8 está realmente ejecutando código. Para cargas dominadas por I/O — agentes que sobre todo llaman a LLMs y agregan respuestas de APIs — el coste de la espera es prácticamente nulo.
Cuándo no encaja
- Tareas que necesiten instalar paquetes, correr Python / shell o ejecutar binarios nativos
- Cargas de petición única que requieran más de unos minutos de CPU
- Workflows que lean o escriban archivos locales o mantengan estado entre peticiones dentro de la sandbox
- Tareas de mucha memoria que pasen de 128 MB
Cuándo sí
- Peticiones de alta concurrencia y corta duración (parsing, transformación, filtrado, routing)
- Hacer de "puerta de entrada" del agente — decidir rápido, extraer parámetros, elegir qué herramienta llamar
- Servicios de baja latencia distribuidos globalmente (gateways API inteligentes, RAG en el edge)
- Código pegamento que une las primitivas de Cloudflare (KV, R2, D1, Queues)
Cómo lo soporta Puppyone
La sandbox de Cloudflare está actualmente en desarrollo y aún no está abierta al público. Estamos integrándola con el sistema de archivos de Puppyone igual que la sandbox Docker: cuando el código JS dentro de un isolate "escribe un archivo", commitea un cambio versionado, con permisos y auditable en Puppyone — y comparte estado con la sandbox Docker. El mismo agente podrá correr cómputo pesado en una sandbox Docker y responder en el edge desde una sandbox Cloudflare, mirando ambos al mismo workspace.
Si tu caso de uso necesita ejecución en el edge, suscríbete a las novedades — te avisamos en cuanto esté disponible.
Comparativa lado a lado
Una vista condensada de todo lo de arriba en una tabla que puedes escanear de un vistazo.
| Dimensión | Sandbox Docker | Sandbox Cloudflare |
|---|---|---|
| Tecnología subyacente | Contenedores Linux (namespaces + cgroups) | V8 Isolates |
| Cold start | 2-10 segundos | < 5 milisegundos |
| Runtime | Python, Node, Go, shell — cualquier binario Linux | JavaScript / TypeScript / WebAssembly |
| ¿Instalar paquetes? | ✅ apt, pip, npm, Dockerfile propio | ❌ Hay que empaquetar antes |
| ¿Lanzar subprocesos? | ✅ | ❌ |
| Sistema de archivos local | ✅ POSIX completo, montado en Puppyone | ❌ Solo almacenamiento externo (KV / R2 / D1) |
| Recursos por defecto | 2 vCPU + 512 MB | 128 MB de memoria |
| Tope de recursos | 8 vCPU + 8 GB (configurable) | 128 MB (fijo) |
| Duración por ejecución | 5 min por defecto, hasta 24 horas | 30 s CPU por defecto, hasta 5 min (de pago) |
| Preservación de estado | Snapshots pause / resume (memoria + FS) | Ninguna (cada petición, isolate nuevo) |
| Modelo de concurrencia | Un contenedor por sandbox (recursos reales) | Miles de isolates por máquina |
| Distribución geográfica | Una región | 300+ nodos edge, routing automático |
| Control de egress | Allowlist de dominios/puertos | Configurado vía Workers |
| Capa de seguridad | La pones tú | DDoS / rate limit / bot / TLS integrados |
| Granularidad de facturación | Por segundo de vida del contenedor (incluye espera) | Por milisegundo activo de CPU (la espera no cuenta) |
| Modelo de proceso | Ejecuta y desmonta | Bajo demanda, sin mantenimiento |
| Compatibilidad de API | Compatible con E2B | API de Cloudflare Workers |
| Estado en Puppyone | ✅ Disponible | 🚧 En desarrollo, todavía no abierta |
| Casos típicos | Procesamiento de datos de 5 min, Python con paquetes, workflows multietapa | Routing en milisegundos, lógica JS de alta concurrencia, APIs en el edge |
| Un agente de 10 minutos, ¿cuál? | Docker, si está calculando de verdad | Cloudflare, si pasa el 90 % esperando a LLMs/APIs |
Cómo elegir
Elegir sandbox no va de cuál es "mejor", va de cómo es realmente tu carga de trabajo. Las cinco dimensiones que vienen cubren prácticamente cualquier decisión real.
1. Lenguaje del runtime
Si tu agente necesita correr Python, shell, Go o binarios nativos (piensa en ffmpeg, pandoc, git) — tiene que ser Docker. Cloudflare solo corre JavaScript / TypeScript / WebAssembly. Ni siquiera puedes hacer pip install.
Si tu lógica de negocio ya es JS / TS y no toca syscalls — cualquiera de las dos vale. Sigue leyendo.
2. Duración de la tarea
| Duración de la tarea | Elige | Por qué |
|---|---|---|
| < 30 s de CPU | Cloudflare | Arranque en milisegundos + cobro por ms — el más barato con diferencia |
| 30 s - 5 min de CPU | Cloudflare (los planes de pago llegan a 5 min) | Sigue dentro del límite |
| Varios minutos a horas | Docker | Cloudflare topa con su techo de CPU |
| Workflows de varios días | Docker + snapshots pause / resume | Congelas el estado y lo retomas más tarde |
3. Estructura de costes (la dimensión que más se elige mal)
Los dos modelos de facturación son fundamentalmente distintos — la misma carga puede costar un orden de magnitud más si eliges mal.
- Docker cobra por el tiempo que el contenedor existe. El contador arranca cuando el contenedor bootea, esté la CPU haciendo algo o no. Esto premia el trabajo corto y denso: arranca la tarea, termínala, mata el contenedor. Si dejas un contenedor inactivo esperando input del usuario o respuesta de un LLM, pagas por esa espera.
- Cloudflare cobra solo por milisegundos activos de CPU. Cuando el isolate está esperando un
fetch(), una base de datos o un stream de respuesta de un LLM, no pagas. Solo se te cobran los milisegundos en los que V8 está ejecutando código.
En concreto:
- Una tarea de procesamiento de datos de 5 minutos (CPU al máximo todo el tiempo) → Docker es más barato
- 10.000 usuarios por segundo, cada uno disparando 50 ms de lógica → Cloudflare es órdenes de magnitud más barato
- Un agente de 30 minutos que pasa el 90 % esperando streams de un LLM → Cloudflare es drásticamente más barato; Docker te factura los 30 minutos completos
No compares precios por hora. Compara qué porcentaje del tiempo de reloj de tu carga se está computando de verdad. Esa proporción decide qué modelo gana.
4. Concurrencia
- Unas pocas a unas decenas de peticiones por segundo → cualquiera vale
- Cientos por segundo de tareas cortas → Cloudflare (miles de isolates por máquina; Docker necesitaría un contenedor por petición concurrente)
- Pocas peticiones por segundo, pero cada una son varios minutos de cómputo → Docker (Cloudflare no aguanta esa duración)
5. Volumen de datos y estado
- Tareas que leen o escriben muchos archivos, generan artefactos de varios GB o mantienen un workspace multietapa → Docker (sistema de archivos real, montado en Puppyone, todo versionado de forma automática)
- Tareas que solo golpean un par de APIs, hacen transformaciones ligeras y vuelcan a almacenamiento externo → Cloudflare (sin sistema de archivos local, pero leer KV / R2 / D1 es rápido)
- Más de 128 MB de memoria → Docker (un único isolate de Cloudflare topa en 128 MB)
¿Sigues sin tenerlo claro? Por defecto, Docker. Sus capacidades son un superconjunto estricto de las de Cloudflare — es prácticamente imposible elegir mal, solo que en escenarios extremos de alta concurrencia o muy intensivos en I/O pagas algo más. Cuando el tráfico crezca lo suficiente como para importar, ya migrarás los caminos calientes a Cloudflare.
La arquitectura ideal, cuando las sandboxes Cloudflare estén abiertas: las dos trabajando juntas. Las sandboxes Cloudflare como puerta de entrada del agente — routing en milisegundos, extracción de parámetros, decisiones ligeras. Cuando la carga necesita cómputo de verdad, se despacha a una sandbox Docker. Cloudflare lleva el camino rápido; Docker, el trabajo pesado; el mismo sistema de archivos de Puppyone une los dos extremos.
Empezar a usar sandboxes en Puppyone
Si tu agente ya está sobre E2B, basta con apuntarlo a Puppyone — Sandbox.create(), runCode(), commands.run() son API-compatibles, no hace falta tocar la lógica de negocio, y de inmediato consigues versionado, permisos y logs de auditoría a nivel de sistema de archivos.
Si empiezas desde cero, la documentación de Puppyone tiene una guía rápida que te monta una sandbox con sistema de archivos versionado en unas pocas líneas de código.
¿Necesitas la sandbox edge de Cloudflare? Suscríbete a las novedades — te avisamos en cuanto esté abierta.