E2B: a code sandbox for agents
Table of contents
E2B is open-source infrastructure that runs the code your AI agent generates inside an isolated virtual machine, so a hallucinated rm -rf / destroys a throwaway sandbox instead of your server. Each sandbox is a Firecracker microVM with its own Linux kernel, boots in about 150 milliseconds and is controlled from a Python or JavaScript SDK. In this guide you will see why a code-writing agent needs a sandbox, what E2B is, how to run generated code safely, how to self-host it and how it differs from Docker and gVisor. The same explanation is available in Spanish.
Key takeaways
- E2B is open-source infrastructure (Apache 2.0 licence, over 13,000 stars on GitHub) to run AI-generated code in isolated sandboxes; its tagline is "open-source, secure environment with real-world tools for enterprise-grade agents".
- Each sandbox is a Firecracker microVM with its own Linux kernel, so isolation is at the hardware level, not just the process level. It boots in about 150 ms.
- The Python SDK (
pip install e2b, version 2.33.0) creates and controls sandboxes; thee2b-code-interpreterpackage (v2.8.1) adds a stateful interpreter with rich outputs such as charts. - The default lifetime is 5 minutes, extendable to 24 hours; you can pause a sandbox and resume it later with its memory and filesystem intact, for up to 30 days.
- It is self-hostable with Terraform on AWS, Google Cloud, Azure or a Linux machine, if you do not want to depend on E2B’s managed cloud.
Why does an agent need a sandbox?
A coding agent does not just talk: it writes code and runs it. An agent built with the Anthropic SDK or a data assistant generates a snippet of Python, runs it, reads the result and decides the next step. That loop is extremely powerful and, at the same time, the most dangerous attack surface in the whole application, because you are executing code that a probabilistic model has just invented.
The risk has two faces. The first is the honest mistake: the model hallucinates a destructive command, enters an infinite loop that exhausts memory or installs a dependency that breaks the environment. The second is malicious: if the user’s prompt contains an injection, the attacker can get the agent to run code that reads your environment variables, exfiltrates secrets or pivots into your internal network. Running that code directly in the agent’s process, or even on the same host, is an invitation to disaster.
The right answer is isolation: untrusted code runs in a disposable environment, with no access to your filesystem, none of your credentials and a restricted network. If something goes wrong, you destroy the sandbox and nothing has happened. That is exactly the problem E2B solves, and the reason a sandbox is as indispensable in production as serving the model with vLLM is when you want throughput.
What is E2B?
E2B (short for "environment to business") is open-source infrastructure to run AI-generated code in secure, isolated cloud sandboxes. Its documentation puts it bluntly: "open-source, secure environment with real-world tools for enterprise-grade agents". The key point is that each sandbox is not a container but a Firecracker microVM.
Firecracker is the lightweight virtualization technology Amazon open-sourced in 2018 and which today underpins AWS Lambda. It boots a full virtual machine in about 125 milliseconds with just 5 MB of memory overhead, so it combines the strong isolation of a VM (its own kernel, a hardware boundary) with the agility an agent needs to spin up and discard environments non-stop. E2B wraps that technology in a simple API: you request a sandbox, it hands it to you in about 150 ms, and inside you have a full Linux where you can run commands, manipulate files and install packages.
The project is free software under the Apache 2.0 licence and has over 13,000 stars on GitHub. You can use its managed cloud (freemium, with per-second billing) or self-host the entire infrastructure, which is unusual in this category. Beyond the code interpreter, E2B offers a "Desktop Sandbox" with a graphical desktop aimed at computer-use agents.
How do you run generated code safely?
The most direct way to work with E2B is the e2b-code-interpreter package, which adds a stateful interpreter on top of the base SDK: it keeps variables between calls, just like a Jupyter notebook, and returns rich outputs such as tables or charts. It installs with a single command:
pip install e2b-code-interpreter
With the API key in the E2B_API_KEY environment variable, creating a sandbox and running code takes two lines. The typical pattern in an agent is: the model generates a Python snippet, your code passes it to run_code, and the result (or the error) goes back to the model so it can continue reasoning.
from e2b_code_interpreter import Sandbox
# The sandbox closes itself when the with block exits
with Sandbox.create() as sandbox:
# State persists between calls, like in a notebook
sandbox.run_code("x = 1")
execution = sandbox.run_code("x += 1; x")
print(execution.text) # prints 2
# You can also run shell commands and install packages
sandbox.commands.run("pip install pandas")
Each sandbox lives for 5 minutes by default, a limit designed so that a forgotten environment does not keep consuming resources. That time extends to 24 hours on the paid plan and, better still, every time you reconnect to the sandbox the counter resets. When run_code receives code that fails, it does not blow up your program: it returns the error inside the execution object, exactly what you need for the agent to read it and correct itself. If you wire this into a tool server through an MCP server, the agent gains a code interpreter without you exposing your own machine.
Can you self-host E2B?
Yes, and it is one of its big differences from proprietary sandboxes. All of E2B’s infrastructure is Apache 2.0, and the repository includes a self-hosting guide based on Terraform that deploys the control plane on AWS, Google Cloud, Azure or your own Linux machine. This matters when the code your agent runs handles sensitive data and you do not want it leaving for a third-party cloud, or when you need to meet data-residency requirements.
The cost of self-hosting is operational: you no longer manage just your agent, but also the microVM orchestrator, the storage and the network that isolates them. For many teams, starting on E2B’s managed cloud and migrating to a self-hosted deployment when volume justifies it is the most sensible path. One capability that helps in both cases is persistence: you can pause a sandbox and save both its filesystem and the contents of its RAM, then resume it later (up to 30 days on) in exactly the same state. Pausing costs about 4 seconds per GiB of RAM and resuming barely 1 second, so a long-running agent can "hibernate" between steps without losing its execution context.
E2B, Docker or gVisor?
The underlying question is how much isolation you need to run code you do not control. The three options rank from the weakest to the strongest security boundary:
- Docker (containers): they share the host kernel through namespaces and cgroups. It is lightweight and familiar, but a kernel bug or a container-escape exploit gives the code access to the host. For trusted code it is more than enough; for code an LLM just invented, it is the riskiest option.
- gVisor: Google’s user-space application kernel. It intercepts the code’s system calls and services them itself, without letting them reach the real kernel. It isolates more than a normal container and weighs less than a full VM, at the cost of some performance penalty and of a few uncommon system calls not being implemented.
- Firecracker (E2B): a microVM with its own Linux kernel and a real hardware boundary. It is the strongest isolation of the three, and it still boots in about 125 milliseconds, which makes it viable for an agent’s pace.
In short: if you run code a model generates from user input, you want the hardware boundary of a microVM, and E2B gives it to you wrapped in an SDK without you having to stand up Firecracker by hand. Docker and gVisor remain valid options for more trusted workloads or when you already have that infrastructure in place.
Frequently asked questions
Is E2B paid or free?
Both, depending on how you use it. E2B’s code is free under the Apache 2.0 licence, so you can self-host the entire infrastructure without paying any licence fee. The managed cloud, which is the most convenient way to start, is freemium: it has a free plan with limits (for example, sandboxes of up to 1 hour) and paid plans with per-second billing and sessions of up to 24 hours. You do not need a card to try it.
Do I need E2B if I already use Docker?
It depends on how much you trust the code you run. Docker shares the host kernel, so a container escape compromises the machine; for code an LLM generates from user input, that risk is usually unacceptable. E2B uses Firecracker microVMs with their own kernel, a much stronger isolation, and hands it to you from an SDK without you having to operate the virtualization yourself.
Which languages can it run code in?
The sandbox is a full Linux, so in practice it can run any language you install in it with sandbox.commands.run. The e2b-code-interpreter package ships a stateful interpreter optimised for Python and JavaScript out of the box, with rich outputs such as charts and tables, which is what most data-analysis agents need.
Conclusion
E2B turns the isolation of untrusted code, a hard infrastructure problem, into a two-line SDK call. Its Firecracker microVMs give the hardware boundary Docker does not offer, boot in about 150 ms, keep state between calls and can be paused for up to 30 days, all under an Apache 2.0 licence that lets you self-host it when privacy demands it. The next step is to request an API key at e2b.dev, install e2b-code-interpreter with pip and give your agent its first disposable interpreter with Sandbox.create().
Sources: [1] Official E2B documentation[1], [2] E2B on GitHub[2], [3] E2B code interpreter SDK[3], [4] Firecracker, AWS lightweight virtualization[4], [5] gVisor, Google’s application kernel[5].
Sources
Source code
Access all the source code for this post on GitHub.
View on GitHub
