¿Qué es OpenSandbox?
OpenSandbox es un servidor y un conjunto de SDK para crear entornos aislados donde un agente de IA puede ejecutar comandos, editar archivos, ejecutar código generado o manejar un navegador o un escritorio. Lo arrancas en local sobre Docker y pasas a Kubernetes con la misma API de ciclo de vida, con SDK para Python, TypeScript, Java/Kotlin, C#/.NET y Go, una CLI llamada osb y un servidor MCP para clientes como Claude Code y Cursor.
Nació en Alibaba (los paquetes aún llevan los nombres com.alibaba y @alibaba-group) y ahora es un proyecto de la Agentic AI Foundation, en la organización opensandbox-group. La versión 1.1.1 salió el 9 de octubre de 2026 y la 1.2.0 va por su segunda release candidate.
El aislamiento es configurable, no fijo: contenedores normales por defecto, con gVisor, Kata Containers o Firecracker como runtimes seguros, políticas de salida por sandbox y un Credential Vault que inyecta los secretos en las peticiones salientes para que la carga de trabajo nunca los vea.
¿Merece la pena OpenSandbox?
OpenSandbox resuelve un problema distinto al de srt de Anthropic o OpenShell de NVIDIA. Esos confinan a un agente que se ejecuta en tu máquina; OpenSandbox reparte, a través de una API, máquinas nuevas y desechables a agentes que se ejecutan en cualquier sitio. Es la contrapartida autoalojada de los sandboxes de código alojados que muchos productos de agentes alquilan por segundos, y ha reunido unas 16.200 estrellas en GitHub en diez meses.
Las cifras principales son de los propios mantenedores, que publican el método junto a ellas. En un clúster de Kubernetes de Alibaba Cloud con dos nodos de 192 CPU cada uno, los sandboxes Firecracker en caliente a partir de una instantánea precompilada estuvieron listos en 64 ms de mediana en una ejecución en serie y en 125,4 ms en el p99 con diez creaciones simultáneas. Con 20 creaciones simultáneas contra un pool de 20 plazas solo 51 de 100 intentos tuvieron éxito, algo que el informe dice sin rodeos. Son cifras del camino en caliente con los artefactos en caché; el primer uso cuesta más.
El modelo de seguridad premia el cuidado y castiga los valores por defecto. Sin un runtime seguro, un sandbox es un contenedor normal, así que un exploit del kernel en código generado llega al host; gVisor, Kata o Firecracker cierran ese hueco, pero cada uno necesita su propia configuración de nodos. Si server.api_key está vacío, el servidor funciona sin ninguna autenticación, y en Docker o Kubernetes hay que poner OPENSANDBOX_INSECURE_SERVER=YES para permitirlo, lo que al menos hace que la decisión sea deliberada. Las imágenes de las versiones se firman con Cosign, y la documentación pide fijarlas por digest.
El proyecto avanza rápido: 153 incidencias y pull requests abiertas, una release candidate de la 1.2 dos semanas después de la 1.1.1 y una especificación de protocolo pensada para que otros construyan runtimes sobre ella. Para un equipo que ya usa Kubernetes y paga facturas por segundo de sandboxes para evaluaciones de agentes o rollouts de aprendizaje por refuerzo, ese ritmo es una ventaja; para un solo agente de programación en un portátil es mucha más maquinaria de la que hace falta.
Dónde se gana su sitio
Un equipo de ML que ejecuta evaluaciones nocturnas de agentes con Harbor
Dar a cada uno de varios miles de ensayos su propio entorno limpio
Usar pools de recursos y creación por lotes en Kubernetes para que cada ensayo tenga un sandbox nuevo que se destruye al terminar. El coste son los nodos de tu clúster, no tarifas por segundo a un proveedor de sandboxes alojados.
Una empresa SaaS que añade un intérprete de código a su agente de cara al cliente
Ejecutar Python escrito por el modelo para muchos inquilinos sin que uno escape hacia otro
Ejecutar los sandboxes con Firecracker o gVisor, definir políticas de salida por sandbox e inyectar las claves de API a través del Credential Vault. Define server.api_key antes de exponer el servidor; por defecto está abierto.
Un desarrollador que prueba Claude Code o Codex CLI de forma aislada
Dejar que un agente de programación trabaje en un repositorio dentro de un contenedor desechable
Arrancar el servidor con uvx opensandbox-server sobre Docker y seguir el ejemplo de Claude Code; minutos hasta el primer sandbox, aunque srt hace este trabajo en un portátil con mucha menos configuración.
Antes de decidirte
- Puesta en marcha
- Necesita Docker y Python 3.10 o superior: uvx opensandbox-server init-config ~/.sandbox.toml --example docker, después uvx opensandbox-server y pip install opensandbox. Kubernetes usa un operador; Firecracker necesita nodos con virtualización.
- Integraciones
- SDK para Python, TypeScript, Java/Kotlin, C#/.NET y Go, la CLI osb, un servidor MCP (pip install opensandbox-mcp) con herramientas de sandbox, comandos y archivos, y ejemplos para Claude Code, Codex CLI, Playwright, Chrome, escritorios y Harbor.
- Datos y privacidad
- Funciona en tu propia infraestructura bajo Apache 2.0; la exportación de métricas a OpenTelemetry es opcional; imágenes firmadas con Cosign y con procedencia; no hay avisos de seguridad publicados en GitHub.
- Coste a escala
- El software es gratis; el coste son tus nodos. El benchmark de los mantenedores usó dos nodos de Kubernetes con 192 CPU y unos 742 GiB de memoria cada uno para ejecutar un pool Firecracker de 20 plazas.
- Límites
- Los runtimes seguros, la entrada y la salida necesitan configuración aparte; las credenciales de endpoint de secureAccess solo funcionan con el gateway de ingress de Kubernetes; la tasa de éxito cayó a 51 de 100 creaciones cuando la concurrencia igualó el tamaño del pool.
Lo bueno
- La misma API desde Docker en local hasta un clúster de Kubernetes
- Aislamiento con Firecracker, gVisor o Kata, además de pausa y reanudación
- Credential Vault mantiene los secretos reales fuera del sandbox
- SDK en cinco lenguajes, una CLI y un servidor MCP
Lo malo
- Contenedores normales salvo que configures un runtime seguro
- El servidor funciona sin autenticación si no se define una clave de API
- Las cifras de velocidad en caliente son de los propios mantenedores, en nodos grandes
- Configurar Kubernetes y Firecracker es trabajo de operaciones de verdad
Ideal para
Equipos de plataforma que ejecutan evaluaciones de agentes, rollouts de RL o ejecución de código multiinquilino y quieren los sandboxes en su propia infraestructura.
Alternativas a OpenSandbox
OpenSandbox: preguntas frecuentes
- ¿Merece la pena OpenSandbox?
- Una alternativa autoalojada a los sandboxes de código alojados, que compensa el trabajo con Kubernetes cuando necesitas miles de entornos de agente efímeros en tus propias máquinas. Le damos un 4.1 sobre 5.
- ¿Cuánto cuesta OpenSandbox?
- Gratis y de código abierto bajo Apache 2.0; los mantenedores no ofrecen edición de pago.
- ¿Qué inconvenientes tiene OpenSandbox?
- Contenedores normales salvo que configures un runtime seguro; el servidor funciona sin autenticación si no se define una clave de API; las cifras de velocidad en caliente son de los propios mantenedores, en nodos grandes; configurar Kubernetes y Firecracker es trabajo de operaciones de verdad.
- ¿Para quién es OpenSandbox?
- Equipos de plataforma que ejecutan evaluaciones de agentes, rollouts de RL o ejecución de código multiinquilino y quieren los sandboxes en su propia infraestructura.
- ¿Cuánto cuesta OpenSandbox para un equipo o en producción?
- El software es gratis; el coste son tus nodos. El benchmark de los mantenedores usó dos nodos de Kubernetes con 192 CPU y unos 742 GiB de memoria cada uno para ejecutar un pool Firecracker de 20 plazas.
- ¿Es OpenSandbox seguro para los datos de la empresa?
- Funciona en tu propia infraestructura bajo Apache 2.0; la exportación de métricas a OpenTelemetry es opcional; imágenes firmadas con Cosign y con procedencia; no hay avisos de seguridad publicados en GitHub.
- ¿Cuáles son las mejores alternativas a OpenSandbox?
- Las alternativas más cercanas que hemos analizado son NVIDIA OpenShell y Anthropic Sandbox Runtime (srt).
Respuestas comprobadas el 26 oct 2026.