E2B es una infraestructura de código abierto que ejecuta el código que genera tu agente de IA dentro de una máquina virtual aislada, para que un rm -rf / alucinado destruya un sandbox de usar y tirar en lugar de tu servidor. Cada sandbox es una microVM de Firecracker con su propio kernel de Linux, arranca en unos 150 milisegundos y se controla desde un SDK de Python o de JavaScript. En esta guía verás por qué un agente que escribe código necesita un sandbox, qué es E2B, cómo ejecutar código generado de forma segura, cómo autoalojarlo y en qué se diferencia de Docker y gVisor. La misma explicación está disponible en inglés.

Puntos clave

  • E2B es una infraestructura de código abierto (licencia Apache 2.0, más de 13 000 estrellas en GitHub) para ejecutar código generado por IA en sandboxes aislados; su lema es «entorno seguro de código abierto con herramientas reales para agentes de nivel empresarial».
  • Cada sandbox es una microVM de Firecracker con su propio kernel de Linux, así que el aislamiento es a nivel de hardware, no solo de proceso. Arranca en unos 150 ms.
  • El SDK de Python (pip install e2b, versión 2.33.0) crea y controla sandboxes; el paquete e2b-code-interpreter (v2.8.1) añade un intérprete con estado y salidas enriquecidas como gráficos.
  • El tiempo de vida por defecto es de 5 minutos, ampliable hasta 24 horas; puedes pausar un sandbox y reanudarlo después con su memoria y su sistema de archivos intactos, hasta 30 días.
  • Es autoalojable con Terraform sobre AWS, Google Cloud, Azure o una máquina Linux, si no quieres depender de la nube gestionada de E2B.

¿Por qué un agente necesita un sandbox?

Un agente de programación no se limita a hablar: escribe código y lo ejecuta. Un agente construido con el SDK de Anthropic o un asistente de datos generan un fragmento de Python, lo corren, leen el resultado y deciden el siguiente paso. Ese bucle es potentísimo y, a la vez, la superficie de ataque más peligrosa de toda la aplicación, porque estás ejecutando código que un modelo probabilístico acaba de inventar.

El riesgo tiene dos caras. La primera es el error honesto: el modelo alucina una orden destructiva, entra en un bucle infinito que agota la memoria o instala una dependencia que rompe el entorno. La segunda es la maliciosa: si el prompt del usuario incluye una inyección, el atacante puede lograr que el agente ejecute código para leer tus variables de entorno, filtrar secretos o pivotar hacia tu red interna. Ejecutar ese código directamente en el proceso del agente, o incluso en el mismo host, es una invitación al desastre.

La respuesta correcta es el aislamiento: el código no confiable se ejecuta en un entorno desechable, sin acceso a tu sistema de archivos, sin tus credenciales y con la red restringida. Si algo sale mal, destruyes el sandbox y no ha pasado nada. Ese es exactamente el problema que resuelve E2B, y la razón por la que un sandbox es tan imprescindible en producción como lo es servir el modelo con vLLM cuando buscas rendimiento.

¿Qué es E2B?

E2B (abreviatura de «environment to business») es una infraestructura de código abierto para ejecutar código generado por IA en sandboxes seguros y aislados en la nube. Su documentación lo resume sin rodeos: «entorno seguro de código abierto con herramientas reales para agentes de nivel empresarial». La pieza clave es que cada sandbox no es un contenedor, sino una microVM de Firecracker.

Firecracker es la tecnología de virtualización ligera que Amazon liberó en 2018 y que hoy sostiene AWS Lambda. Arranca una máquina virtual completa en unos 125 milisegundos con apenas 5 MB de sobrecarga de memoria, así que combina el aislamiento fuerte de una VM (kernel propio, frontera de hardware) con la agilidad que necesita un agente para lanzar y descartar entornos sin parar. E2B envuelve esa tecnología en una API sencilla: pides un sandbox, te lo entrega en unos 150 ms y dentro tienes un Linux completo donde ejecutar comandos, manipular archivos e instalar paquetes.

El proyecto es software libre bajo licencia Apache 2.0 y supera las 13 000 estrellas en GitHub. Puedes usar su nube gestionada (freemium, con facturación por segundo) o autoalojar toda la infraestructura, algo poco habitual en esta categoría. Además del intérprete de código, E2B ofrece un «Desktop Sandbox» con escritorio gráfico pensado para los agentes de uso del ordenador.

¿Cómo ejecutar código generado de forma segura?

La forma más directa de trabajar con E2B es el paquete e2b-code-interpreter, que añade sobre el SDK base un intérprete con estado: mantiene las variables entre llamadas, igual que un cuaderno de Jupyter, y devuelve salidas enriquecidas como tablas o gráficos. Se instala con una orden:

pip install e2b-code-interpreter

Con la clave de API en la variable de entorno E2B_API_KEY, crear un sandbox y ejecutar código son dos líneas. El patrón típico en un agente es: el modelo genera un fragmento de Python, tu código lo pasa a run_code, y el resultado (o el error) vuelve al modelo para que continúe el razonamiento.

from e2b_code_interpreter import Sandbox

    # El sandbox se cierra solo al salir del bloque with
with Sandbox.create() as sandbox:
    # El estado persiste entre llamadas, como en un notebook
    sandbox.run_code("x = 1")
    ejecucion = sandbox.run_code("x += 1; x")
    print(ejecucion.text)  # imprime 2

    # Tambien puedes correr comandos de shell e instalar paquetes
    sandbox.commands.run("pip install pandas")

Cada sandbox vive por defecto 5 minutos, un límite pensado para que un entorno olvidado no siga consumiendo recursos. Ese tiempo se amplía hasta 24 horas en el plan de pago y, mejor aún, cada vez que reconectas con el sandbox el contador se reinicia. Cuando run_code recibe código que falla, no revienta tu programa: te devuelve el error dentro del objeto de ejecución, justo lo que necesitas para que el agente lo lea y se corrija a sí mismo. Si conectas esto con un servidor de herramientas mediante un servidor MCP, el agente gana un intérprete de código sin que tú expongas tu máquina.

¿Se puede autoalojar E2B?

Sí, y es una de sus grandes diferencias frente a los sandboxes propietarios. Toda la infraestructura de E2B es Apache 2.0, y el repositorio incluye una guía de autoalojamiento basada en Terraform que despliega el plano de control sobre AWS, Google Cloud, Azure o una máquina Linux propia. Esto importa cuando el código que ejecuta tu agente maneja datos sensibles y no quieres que salgan hacia una nube de terceros, o cuando necesitas cumplir requisitos de residencia de datos.

El coste de autoalojar es operativo: ya no gestionas solo tu agente, sino también el orquestador de microVM, el almacenamiento y la red que las aísla. Para muchos equipos, empezar con la nube gestionada de E2B y migrar a un despliegue propio cuando el volumen lo justifique es el camino más sensato. Una capacidad que ayuda en ambos casos es la persistencia: puedes pausar un sandbox y guardar tanto su sistema de archivos como el contenido de su memoria RAM, y reanudarlo más tarde (hasta 30 días después) exactamente en el mismo estado. Pausar cuesta unos 4 segundos por cada GiB de RAM y reanudar apenas 1 segundo, así que un agente de tarea larga puede «hibernar» entre pasos sin perder el contexto de ejecución.

¿E2B, Docker o gVisor?

La pregunta de fondo es cuánto aislamiento necesitas para ejecutar código que no controlas. Las tres opciones se ordenan de menor a mayor frontera de seguridad:

  • Docker (contenedores): comparten el kernel del host mediante espacios de nombres y cgroups. Es ligero y familiar, pero un fallo del kernel o un exploit de escape de contenedor da al código acceso al anfitrión. Para código de confianza va sobrado; para código que acaba de inventar un LLM, es la opción más arriesgada.
  • gVisor: el kernel de aplicación en espacio de usuario de Google. Intercepta las llamadas al sistema del código y las atiende él mismo, sin dejarlas llegar al kernel real. Aísla más que un contenedor normal y pesa menos que una VM completa, a cambio de cierta penalización de rendimiento y de que algunas llamadas al sistema poco comunes no están implementadas.
  • Firecracker (E2B): una microVM con su propio kernel de Linux y una frontera de hardware real. Es el aislamiento más fuerte de los tres, y aun así arranca en unos 125 milisegundos, lo que lo hace viable para el ritmo de un agente.

En resumen: si ejecutas código que un modelo genera a partir de la entrada de un usuario, quieres la frontera de hardware de una microVM, y E2B te la da envuelta en un SDK sin que tengas que montar Firecracker a mano. Docker y gVisor siguen siendo opciones válidas para cargas de más confianza o cuando ya tienes esa infraestructura montada.

Preguntas frecuentes

¿E2B es de pago o gratuito?

Las dos cosas, según cómo lo uses. El código de E2B es libre bajo licencia Apache 2.0, así que puedes autoalojar toda la infraestructura sin pagar licencia. La nube gestionada, que es la vía más cómoda para empezar, es freemium: tiene un plan gratuito con límites (por ejemplo, sandboxes de hasta 1 hora) y planes de pago con facturación por segundo de uso y sesiones de hasta 24 horas. No necesitas tarjeta para probarlo.

¿Necesito E2B si ya uso Docker?

Depende de la confianza que tengas en el código que ejecutas. Docker comparte el kernel del host, de modo que un escape de contenedor compromete la máquina; para código que genera un LLM a partir de entradas de usuario, ese riesgo suele ser inaceptable. E2B usa microVM de Firecracker con kernel propio, un aislamiento mucho más fuerte, y te lo entrega desde un SDK sin que tengas que operar la virtualización tú mismo.

¿En qué lenguajes puede ejecutar código?

El sandbox es un Linux completo, así que en la práctica puede ejecutar cualquier lenguaje que instales en él con sandbox.commands.run. El paquete e2b-code-interpreter trae de fábrica un intérprete con estado optimizado para Python y JavaScript, con salidas enriquecidas como gráficos y tablas, que es lo que la mayoría de agentes de análisis de datos necesitan.

Conclusión

E2B convierte el aislamiento de código no confiable, un problema de infraestructura difícil, en una llamada de dos líneas a un SDK. Sus microVM de Firecracker dan la frontera de hardware que Docker no ofrece, arrancan en unos 150 ms, guardan estado entre llamadas y pueden pausarse hasta 30 días, y todo ello bajo una licencia Apache 2.0 que te deja autoalojarlo cuando la privacidad lo exija. El siguiente paso es pedir una clave de API en e2b.dev, instalar e2b-code-interpreter con pip y darle a tu agente su primer intérprete desechable con Sandbox.create().

Fuentes: [1] Documentación oficial de E2B[1], [2] E2B en GitHub[2], [3] SDK de intérprete de código de E2B[3], [4] Firecracker, la virtualización ligera de AWS[4], [5] gVisor, el kernel de aplicación de Google[5].

Visitas: 1

Fuentes

  1. Documentación oficial de E2B
  2. E2B en GitHub
  3. SDK de intérprete de código de E2B
  4. Firecracker, la virtualización ligera de AWS
  5. gVisor, el kernel de aplicación de Google

Ruta: Agentes de IA en producción: evaluación y fiabilidad