A dark floor with a glowing red neon grid, representing isolated compute cells that agents run inside.
E2B gives each agent its own isolated cell of compute, so untrusted code runs without touching your systems.

E2B is an open-source runtime that gives AI agents secure sandboxes to run code. It solves a safety problem: when a language model writes code and you execute it, that code is untrusted. Running it on your own machine or server risks damage, data leaks, or abuse. E2B runs each sandbox in a Firecracker microVM, the same lightweight virtualization technology behind AWS Lambda, so model-generated code executes in a strongly isolated environment that you create and destroy on demand. It ships Python and JavaScript SDKs and is most often used for code interpreting and agentic code execution.

Where it sits in the stack

E2B sits between your agent and raw compute. Your agent decides what code to run; E2B spins up an isolated microVM, runs the code there, and streams results back. Your own infrastructure never executes the untrusted code directly.

Your agent
LLM Code interpreter Data analysis agent Decides what code to run
E2B SDK
Python SDK JavaScript SDK Create and control sandboxes
Sandbox
Code execution Filesystem Shell commands Isolated per session
Isolation
Firecracker microVM Same tech as AWS Lambda

Installation

E2B provides an SDK for both Python and JavaScript. For a code interpreter, install the code-interpreter package. The python-dotenv package loads your API key from a .env file.

bash
pip install e2b-code-interpreter python-dotenv

For JavaScript or TypeScript projects, install the equivalent package with npm.

bash
npm i @e2b/code-interpreter dotenv

Get an API key from the E2B dashboard and place it in a .env file in your project root.

bash
E2B_API_KEY=your_api_key_here

Running code in a sandbox

The core pattern creates a sandbox, runs code inside it, and reads the output. This Python example follows the official quickstart: load the key, create the sandbox, and execute a snippet.

python
from dotenv import load_dotenv
load_dotenv()

from e2b_code_interpreter import Sandbox

sbx = Sandbox.create()
execution = sbx.run_code("print('hello world')")
print(execution.logs)

Each sandbox is a full Linux environment, so an agent can install packages, write files, and process data. This example runs a small data task and reads the result.

python
from dotenv import load_dotenv
load_dotenv()

from e2b_code_interpreter import Sandbox

sbx = Sandbox.create()

code = """
import statistics
values = [12, 8, 5, 20, 15]
print("mean:", statistics.mean(values))
print("stdev:", round(statistics.stdev(values), 2))
"""

execution = sbx.run_code(code)
print(execution.logs)

You can also run raw shell commands inside the sandbox. The base sandbox exposes a commands.run method for terminal commands.

python
from e2b import Sandbox

sandbox = Sandbox.create()
result = sandbox.commands.run("ls -l")
print(result)

How a sandbox request flows

The lifecycle of an agent code-execution step is short and repeatable. The sandbox exists only as long as you need it.

Step 1 Agent writes code The model produces a snippet to run.
→
Step 2 Create sandbox The SDK spins up a fresh Firecracker microVM.
→
Step 3 Execute Code runs in isolation and produces logs or files.
→
Step 4 Return and close Results go back to the agent; the sandbox is torn down.

How it compares

Several products give agents somewhere safe to run code. E2B’s focus is fast, disposable microVM sandboxes for code execution. The table compares it with Daytona, Modal, and a plain container.

E2BDaytonaModalPlain container
IsolationFirecracker microVMmicroVM sandboxgVisor sandboxNamespace only
Primary useAgent code executionAgent code executionServerless functionsGeneral workloads
Cold startSub-secondAbout 27 msSub-secondVaries
Open sourceYesYesNoYes
Best forCode interpretersRegulated enterprisesBatch and GPU jobsFull manual control

When not to use it

E2B is not the right tool in every case.

  • Your code is fully trusted. If you wrote the code yourself and control every input, the isolation overhead buys you little. Run it in your normal environment.
  • You need long-running services. Sandboxes are built for short, disposable tasks. A persistent web service or database belongs on standard infrastructure like Modal or a managed host.
  • You have strict data-residency rules and cannot use a hosted service. The managed E2B service runs code in its cloud. If code and data must stay in your own network, self-host the open-source runtime or evaluate a competitor with that guarantee.
  • You only need heavy GPU batch jobs. For large training or inference workloads, a compute platform designed for GPUs is a better fit than a code sandbox.

Further reading

Sources