Microsandbox - una máquina virtual que se siente y funciona como un contenedor

• microsandbox ofrece ejecución segura de código no confiable de usuarios y de IA con aislamiento a nivel de máquina virtual
• Supera las desventajas de las VM y contenedores tradicionales con arranque ultrarrápido (menos de 200 ms), compatibilidad con contenedores OCI y autoalojamiento
• Maximiza la eficiencia de integración para desarrolladores y herramientas de IA con SDK para varios lenguajes de programación y herramientas CLI
• Es adecuado para una amplia variedad de casos de uso en IA y desarrollo, como ejecución de código, entornos de desarrollo, análisis de datos, automatización web y hosting de aplicaciones
• Todo el trabajo puede gestionarse por proyecto, con soporte para instalación global en el sistema y entornos de ejecución con persistencia o aislamiento por sesión

---

• microsandbox es una plataforma open source autoalojada diseñada para ejecutar de forma segura código no confiable de usuarios o de IA (por ejemplo, agentes de IA, código enviado por usuarios o código experimental)
• La ejecución local tradicional tiene vulnerabilidades de seguridad; los contenedores ofrecen aislamiento incompleto por compartir el kernel; las VM tradicionales arrancan lento; y la nube carece de flexibilidad
• microsandbox ofrece aislamiento real de procesos basado en microVM (máquinas virtuales ultraligeras), al tiempo que brinda la misma velocidad de inicio que los contenedores y una experiencia amigable para desarrolladores
• Se diferencia por su arranque en menos de 200 ms tras la configuración inicial, compatibilidad con imágenes de contenedor (OCI), integración de IA basada en MCP y control sobre el uso de infraestructura propia

Resumen de características principales

• Bulletproof Security: basado en microVM, ofrece seguridad a nivel de máquina virtual que bloquea de raíz las vulnerabilidades de los contenedores, como el escape del kernel
• Instant Startup: el tiempo de arranque inicial es inferior a 200 ms, lo que permite una velocidad de inicio de ejecución de código extremadamente corta frente a las VM
• Self-Hosting & Full Control: puede implementarse y operarse directamente en entornos locales o servidores propios sin depender de la nube
• Compatibilidad con OCI: puede ejecutar directamente imágenes de contenedor estándar, por lo que es compatible con flujos de trabajo existentes de Docker y contenedores
• AI-Ready (soporte MCP): puede integrarse y ampliarse naturalmente con IA basada en MCP como Claude y Agno

Flujo de trabajo para desarrollo y ejecución rápida

1. Iniciar el servidor

• Es posible iniciar el servidor de microsandbox y configurar el entorno de desarrollo con comandos simples
• El servidor también actúa como servidor MCP, por lo que puede invocarse directamente desde herramientas de IA como Claude

2. Instalar el SDK

• Hay SDK de microsandbox disponibles para lenguajes principales como Python, JavaScript y Rust
• También ofrece soporte para lenguajes adicionales (mediante la extensibilidad del SDK), lo que amplía las posibilidades de integración para desarrolladores e IA

3. Ejecutar código de forma segura

• Es posible elegir y ejecutar por separado entornos sandbox para distintos lenguajes como Python, JavaScript y Rust
• Cada sandbox funciona como un entorno de ejecución independiente, garantizando la seguridad del sistema incluso al ejecutar código externo
• Los ejemplos del SDK facilitan implementar procesos asíncronos y automatizados de ejecución segura de código

Gestión de entornos basada en proyectos

• Se crean y gestionan archivos Sandboxfile (archivos de configuración) por proyecto, en un flujo similar al de un package manager amigable para desarrolladores
• Se pueden agregar múltiples entornos sandbox (por ejemplo, con distintos lenguajes o configuraciones) a un proyecto para gestionarlos por versión o entorno
• Al ejecutar un sandbox de proyecto, los archivos y cambios de instalación se conservan automáticamente en el directorio local (./menv)
• Hay una opción de sandbox temporal (al cerrar la sesión, se eliminan por completo todos los registros y estados, manteniendo el aislamiento)

Instalación global de sandboxes en el sistema

• Es posible instalar y registrar como ejecutables independientes los entornos o aplicaciones que se usan con frecuencia
• Desde la terminal se puede entrar directamente al entorno sandbox con un solo comando, incluso sin estar en la ruta del proyecto
• Se pueden asignar nombres a cada sandbox y operar varias configuraciones diferentes, manteniendo también el estado de la sesión

Casos de uso principales

Ejecución de código de IA y entornos de desarrollo

• Cuando la IA automatiza tareas reales como compilar, ejecutar y depurar código fuente, proporciona rápidamente entornos de desarrollo aislados y reproducibles
• Es ideal para automatización de código como generación de web apps, corrección de errores y prototipos

Análisis de datos

• Permite usar de forma segura dentro del sandbox bibliotecas principales de ciencia de datos como NumPy, Pandas y TensorFlow
• Es ideal para flujos de análisis que requieren proteger datos personales o información sensible

Agentes de navegación web

• La IA puede realizar de forma segura tareas automatizadas como navegar sitios web, enviar formularios, iniciar sesión y extraer datos
• Es útil para recopilación de contenido, comparación de precios y pruebas automatizadas

Hosting instantáneo de aplicaciones

• Permite compartir de inmediato como servicios herramientas, demos, calculadoras o visualizaciones creadas por usuarios
• Cada app funciona en un espacio aislado independiente y admite creación y finalización rápidas de entornos temporales

Arquitectura del sistema

• El usuario invoca el SDK de microsandbox desde su propia lógica de negocio
• Solicita al proceso servidor (microsandbox server) la entrega y ejecución de código no confiable
• Dentro del servidor, cada solicitud de ejecución se procesa en una microVM separada y aislada de las demás
• Cada microVM puede configurarse con entornos independientes de Python o Node

Política open source

• Distribuido como open source bajo Apache License 2.0

[GN⁺]

Opiniones en Hacker News

• Me gustaría ver una calificación de seguridad formal para contenedores
  1. Curar una lista de todas las vulnerabilidades conocidas de contenedores
  2. Ejecutar cada vulnerabilidad en varios entornos de seguridad, como basados en permisos, jail, Docker, emuladores, etc.
  3. La idea sería puntuar qué porcentaje del total de exploits fue bloqueado
     Con un enfoque así, tal vez los contenedores simples basados en permisos o jail quedarían cerca de 0%, Docker por encima de 50%, y Microsandbox cerca de 100%
     Parece que ayudaría a resolver esa curiosidad instintiva detrás de preguntas como “¿por qué no usar simplemente jail?”
     También sería divertido “demostrar” cuál contenedor alcanza el 100% si se levantan contenedores honeypot en la web abierta y se recompensa con efectivo o cripto a quien logre hackearlos
     Con vulnerabilidades recientes como Rowhammer o Spectre, quizá también haga falta redefinir la seguridad misma de la computación convencional y en la nube
     Al final, la motivación es obtener ideas sobre cómo desarrollar contenedores 100% seguros sin emulación completa y sobre cómo asegurar los servicios base del SO
• En entornos multi-tenant, el problema no son las “vulnerabilidades de contenedores”, sino la estructura fundamental de compartir el kernel
  Si existe una vulnerabilidad de LPE (Local Privilege Escalation) en el kernel, eso lleva directamente a un escape de contenedor
  Normalmente no se marca como escape de contenedor, pero en la industria, si hay un LPE del kernel, se da por hecho que la seguridad del contenedor ya quedó rota
• Frente a contenedores maliciosos, es imposible construir un entorno completamente seguro con runtimes de contenedores basados en el kernel de Linux
  La alternativa visible es restringir de forma masiva el uso de syscalls (API) dentro del sandbox, pero en ese caso el contenedor deja de ser una plataforma de propósito general y aparece la incomodidad de tener que reajustarlo caso por caso
  Por eso está la postura de que hace falta virtualización
  A menos que aparezca un SO sólido y memory-safe, no parece haber otra vía; e incluso si existiera ese SO, todavía no está claro si sería más rápido que correr una MicroVM sobre Linux como host
• Ojalá también mostraran la configuración de la máquina
  En Docker o systemd, el nivel de seguridad cambia muchísimo según la configuración
  Creo que hace falta un gran dataset experimental sobre qué configuración lleva a qué nivel de riesgo/seguridad
• En realidad, los contenedores ya operan como honeypots con recompensa en efectivo/cripto
  En la práctica, los entornos reales de producción ya son objetivo de ataque de muchísimos hackers
  Un modelo de incentivos así puede ser divertido, pero la competitividad del objetivo y el incentivo económico real probablemente serían mucho menores que en un entorno real
• Me da curiosidad por qué los VM tradicionales tardan tanto en arrancar (start)
  Por ejemplo, al ejecutar una VM en Windows, uno espera varios segundos antes de que empiece a correr cualquier cosa
  Y con “no correr nada” me refiero al estado antes de ejecutar programas de usuario, incluso antes de que empiece la primera instrucción del firmware
  Incluso hay una espera larga antes de vaciar el archivo de disco virtual o antes de que aparezca la ventana de la VM
  Me pregunto por qué pasa eso
  • Arrancar un kernel de Linux en menos de 1 segundo es totalmente posible con optimización
    Pero con un kernel estándar hay bastantes operaciones que toman tiempo, como timeout o polling
    En sistemas UEFI/CSM también consume bastante tiempo preparar el hardware virtual e inicializar el entorno del sistema
    Se supone que WSL2 usa un kernel especial para quitar sobrecarga innecesaria
    También influyen el arranque de varios servicios del SO, la preparación del sistema de archivos, la caché y la configuración de red
    En el enfoque tradicional se cargan por separado el bootloader → initramfs → SO principal
    Si se quiere reducir el tiempo de arranque al extremo, se usa un método como Amazon Firecracker, que carga directamente en memoria una imagen de VM preinicializada
    Introducción a Firecracker MicroVM
    En Windows, la velocidad de arranque también cambia según el hipervisor que se use, como HyperV
    El UEFI de HyperV es bastante lento, y muchas distribuciones de Linux no ofrecen un kernel mínimo optimizado
  • Haría falta más información sobre qué software de VM estás usando
    En VirtualBox, por ejemplo, el fenómeno que describes se ve claramente, y en versiones antiguas no existía ese retraso
    Podría no ser una limitación esencial de las “VM tradicionales”, sino un problema de ese software en particular
  • No necesariamente es así
    En general, las VM son lentas porque emulan incluso componentes innecesarios
    Si pudieras crear un hipervisor enfocado en velocidad de arranque e ignorar compatibilidad legacy, sería posible arrancar en solo 125 ms, como Firecracker
  • En Linux, una causa principal de la lentitud al asignar memoria a una VM es hacerlo en páginas de 4 KB cuando se asignan varios GB
    Si se asigna en unidades de 1 GB, podría volverse dramáticamente más rápido
    Probablemente Windows también tenga algo parecido
  • Puede ser un problema de VirtualBox
    Yo he tenido experiencias de conectarme en 10 segundos por XRDP a Ubuntu 22 GUI en Hyper-V, y en menos de 3 segundos por SSH a Ubuntu 22 Server
• Señalan la ironía de que, cuando hay que ejecutar código no confiable, las instrucciones de instalación digan “haz pipe del script remoto directo a Bash”
  Aun así, la idea base en sí es sumamente interesante
  • Al principio no entendí a qué se referían, pero también es posible descargar el script de instalación aparte y verificarlo manualmente
    Pronto habrá un método oficial de distribución
• Agradecen por compartir el proyecto e indican que son el creador de microsandbox
  El objetivo es hacer que crear microVMs sea tan fácil como contenedores Docker
  Si tienen dudas, bienvenidas en cualquier momento
  • Ya lo estoy usando bastante bien como librería de Python, pero me gustaría mantener vivo el sandbox a través de varias invocaciones separadas
    A veces aparece un error como “Sandbox is not started. Call start() first”
    El patrón en la documentación oficial es async with, pero en mi caso quiero instanciar una vez por clase y seguir reutilizándolo desde varios métodos
    Me gustaría conocer una forma recomendada o buenas prácticas para eso
  • Estoy construyendo una red de pruebas para software distribuido/descentralizado (Valet Network), y parece que microsandbox sería muy útil
    Me da curiosidad cómo funciona la red
    Por ejemplo, ¿se puede restringir una microVM para que solo acceda a IP públicas?
    Es decir, ¿se puede impedir que la microVM acceda a IP de red local?
  • Proyecto realmente genial, mis respetos para appcypher
    Me pregunto si la funcionalidad integrada de MicroVM ofrece una interfaz de runtime OCI
    Quisiera saber si se puede usar también en Docker/Podman en lugar de runc/crun
  • Le di una revisión rápida al readme y tengo preguntas que me gustaría que explicaran más
    ¿Cómo puede ser tan rápido?
    ¿Qué trade-offs tiene frente a una VM tradicional?
    ¿Hay margen para que se comprometa el aislamiento de la VM?
    ¿Se puede levantar una GUI?
    ¿Lo ven como el nuevo Vagrant?
    ¿Cómo se hace la entrada/salida de datos?
  • Se ve bastante limpio
    Si entendí bien, ¿con esto también se podría levantar un backend al vuelo como si fuera un servidor?
    La lista de lenguajes soportados impresiona lista de lenguajes soportados por microsandbox
    Me gustaría que la guía de contribución fuera más detallada guía para contribuidores
• Les sorprende que en los últimos años hayan aparecido tantas opciones de VM ultraligeras, casi desechables
  En el pasado habían sufrido con VM lentas y pesadas
  Quieren compararlo con Orbstack en macOS, en especial con la función “Linux machines”
  También se preguntan si en Orb se reutiliza una sola VM
  • Sitio de Orbstack
  • Documentación de Orbstack Linux machines
• Felicitaciones
  Arrancar una VM en milisegundos es una mejora muy importante
  Pero algo parecido ya se puede lograr con CloudHypervisor y Firecracker
  Donde los contenedores le ganan a las VM es en rendimiento en tiempo de ejecución
  Lo que vuelve lentas a las VM es la emulación de dispositivos de IO
  Especialmente en cargas tipo agentes de IA, parece que la sobrecarga se sentiría a nivel de la aplicación
  Me da curiosidad cómo piensan resolver los problemas de rendimiento
  • Es una observación acertada
    Microsandbox usa libkrun, y libkrun usa virtio-mmio para block, vsock y virtio-fs con el fin de reducir la sobrecarga de rendimiento
    Firecracker es esencialmente similar, y el proyecto E2B usa Firecracker para manejar cargas agentic AI
    Por ahora no hay grandes planes de mejora de rendimiento aparte de temas del sistema de archivos
• Personalmente, la tecnología de contenedores me da la impresión de expandir demasiado el SO
  Basta con ejecutar el comando mount para ver a qué me refiero
  Queda expuesta información que originalmente debería estar oculta, y eso reduce la utilidad de comandos simples ya existentes
  Un problema más serio es que el usuario puede tocar directamente estructuras de datos internas
  Es como darles a los usuarios permisos completos de peek y poke
  La idea de los contenedores es buena, pero mientras no se rediseñe el kernel, el enfoque actual es un parche temporal
  • No entendí bien el comentario
    ¿Podrías explicar qué tiene de tan crítico ejecutar mount dentro del contenedor?
    ¿Los montajes del host realmente quedan expuestos al contenedor?
    Yo pensaba que normalmente eso solo pasa cuando conectas explícitamente volúmenes u otras cosas al contenedor
• Se ve muy interesante y dan ganas de probarlo enseguida
  Yo también le he sacado mucho provecho a CodeSandbox SDK y E2B, así que me interesa saber en qué se diferencia de ambos y hacia dónde apunta
  También quisiera saber si usa Firecracker internamente
  • Microsandbox no ofrece una solución en la nube
    Es una estructura para alojarlo por cuenta propia
    Igual que E2B, busca facilitar que sandboxes basados en microVM se ejecuten en entornos locales (Linux, macOS, Windows próximamente) y que el paso a producción sea simple
    Usa libkrun en vez de Firecracker
  • Lo que más quería saber era si usaba Firecracker; ese era mi interés principal
    Me preocupa el mantenimiento de las soluciones microVM y si se les seguirá haciendo auditoría de seguridad de forma constante
    Como Firecracker y la configuración de imágenes OCI son complicados, agradezco que aparezcan alternativas
    Kata container también es difícil de manejar
• Este tipo de proyectos siempre me llama la atención
  La mayor ventaja de los contenedores es que se pueden correr rápido sin especificar recursos concretos como tamaño de disco o núcleos de CPU
  También se puede hacer diff del estado con la image y ver qué cambios hizo un programa al sistema mientras corría
  Sería bueno poder lograr un sandboxing más seguro con VM diminutas que conserven esa simplicidad
  A veces uso bwrap, pero no es una herramienta adecuada para línea de comandos
  • Los recursos (capacidad de disco, CPU, etc.) se pueden declarar una sola vez en un archivo YAML
    También se puede hacer con plantillas o generación remota/automática
• Un poco fuera del tema, pero estoy trabajando en un proyecto donde sí o sí debo ejecutar código JavaScript no confiable
  Gracias a microsandbox, tengo esperanza de poder aislar y ejecutar ese código de forma segura
  Incluso el retraso de arranque de 200 ms podría resolverse con un pool de sandboxes en vivo
  Como tiene compatibilidad OCI, también podría ofrecerse todo el entorno de sandbox
  Me pregunto si de verdad este es un buen caso de uso y si no hay una alternativa mejor
  • También valdría la pena considerar runsc/gVisor
    El motor runsc puede ejecutarse también dentro de Docker/Docker Desktop
    Eso sí, gVisor tiene un rendimiento de alrededor de 1/3 del de Docker en temas como procesamiento paralelo de red
  • Justamente este tipo de caso es la aplicación ideal de microsandbox
    Como no encontré una alternativa mejor, terminé creando microsandbox yo mismo