E2B: Running AI-Generated Code in Cloud Sandboxes

The problem E2B targets: untrusted code that must actually run

A model that writes Python is not useful until that Python executes somewhere. Running it in the same process as your application means one `os.system` call or one runaway loop reaches your filesystem, your network and your credentials. E2B exists to move that execution boundary out of your process and into a sandbox the SDK creates on demand. The README describes the project as "open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud."

The intended user is a developer building an agent, a code interpreter feature or a copilot that needs real tool access: shell commands, files, and in the separate packages, code execution and a desktop. The repository is Python-heavy by primary language, but the SDK surface is deliberately symmetric. Every capability in the README ships as both a JavaScript/TypeScript package and a Python package, which matters if your agent backend and your frontend tooling live in different languages.

How the SDK, the sandbox and the packages fit together

The architecture visible from the repository is layered. The top-level `packages/` directory holds the SDKs and the specialised packages; the core `e2b` package gives you `Sandbox.create()` and a `commands.run()` method that returns an object with a `stdout` field. That is the whole loop for shell-style work: create, run, read output, close.

On top of that sit two optional layers. The Code Interpreter package exposes `runCode()` in JavaScript and `run_code()` in Python for executing code and getting structured results back, rather than parsing stdout yourself. The Desktop package exposes mouse, keyboard, screenshot, application and desktop streaming APIs, so an agent can drive a graphical environment instead of a shell.

The build side is worth noting because it tells you how the project is maintained. The Makefile fetches specs from the source-of-truth repositories `e2b-dev/runtime` and `e2b-dev/belt` at commits pinned in `spec/runtime-ref` and `spec/belt-ref`, then runs codegen inside a Docker image built from `codegen.Dockerfile`. The Makefile comments note that when a fetch fails, for example with no GitHub token or no access to the private belt repo, it falls back to the tracked copy in `spec/` with a warning. The SDKs are generated from API specs, not hand-maintained against a live server.

Installing the E2B SDK and running your first sandbox

The README gives a four-step quickstart. Install the SDK for your language first. The JavaScript package is published on npm as `e2b` and the Python package on PyPI as `e2b`.

npm i e2b

or, for Python:

pip install e2b

Next you need an API key. The README says to sign up on the E2B site, get the key from the dashboard, and set it as an environment variable:

E2B_API_KEY=e2b_***

The `e2b_***` value is the README's placeholder for your own key, not a working credential. With the key in the environment, the Python example creates a sandbox as a context manager, runs a shell command and prints its stdout:

from e2b import Sandbox

with Sandbox.create() as sandbox:
    result = sandbox.commands.run('echo "Hello from E2B!"')
    print(result.stdout)  # Hello from E2B!

If you only need shell commands, stop here. If your agent needs to execute generated code and read a value back, the README points to a second package. For Python, `pip install e2b-code-interpreter`, then:

from e2b import Sandbox

with Sandbox.create() as sandbox:
    result = sandbox.commands.run('echo "Hello from E2B!"')
    print(result.stdout)  # Hello from E2B!

The README's JavaScript equivalent of the code interpreter flow imports `Sandbox` from `@e2b/code-interpreter`, calls `runCode('x = 1; x += 1; x')` and reads `execution.text`, which the README shows outputting `2`. For graphical automation, install `@e2b/desktop` on npm or `e2b-desktop` on PyPI; the README example launches `google-chrome` and takes a screenshot.

Where E2B stops being the right tool

The quickstart assumes a hosted control plane. You set `E2B_API_KEY` and call `Sandbox.create()`; the README does not describe a local mode where sandboxes are created without that key. For a laptop demo that is fine. For an air-gapped deployment, a regulated environment that forbids third-party control planes, or a CI job that must not depend on an external service, the default path does not apply and you are pushed to the self-hosting route.

That route is real but narrower than the README's framing suggests. The self-hosting section points to the separate `e2b-dev/infra` repository and its `self-host.md` guide, and states the infrastructure is deployed using Terraform. Its supported cloud provider list marks AWS and Google Cloud as supported, and leaves Azure and "General Linux machine" unchecked. If your infrastructure is on Azure, or you were hoping to run the whole thing on one bare-metal box, the README does not claim that works today.

There is a second boundary. E2B isolates execution, not intent. A sandbox that can reach the network can still exfiltrate data or call an external API on your behalf, and the README does not document network egress policy controls. Treat the sandbox as a containment boundary for the host, not as a content filter for what the model decides to do.

E2B against a container you run yourself

The obvious alternative is a Docker container you manage directly: build an image, run it with resource limits, mount a temporary volume, tear it down. That approach keeps everything inside your own infrastructure and has no API key or vendor dependency. The difference in approach is lifecycle and API surface. With Docker you own image builds, container pooling, timeouts, cleanup and the client protocol your agent talks to. E2B replaces that with a create-and-call SDK: `Sandbox.create()`, `commands.run()`, `runCode()`, and a context manager that closes the sandbox when the block exits.

A second alternative is a general serverless function platform. Those give you isolation and scale, but the execution model is request-shaped: a function runs and returns. An agent session that needs a persistent filesystem across several model turns, or a desktop with a browser open across multiple steps, does not fit that shape without extra work. E2B's model is session-shaped instead, which is the reason the Desktop package can expose a screenshot API at all.

The honest summary is that E2B trades operational control for a smaller integration surface. If your team already runs container infrastructure well and your sandbox needs are simple, the SDK may be an extra dependency rather than a simplification.

Licence, release cadence and what upgrades cost you

The repository is Apache-2.0. That permits commercial use and modification, and it includes a patent grant, which matters if you plan to build a product on top. It does not give you the hosted service; the SDK licence and the service terms are separate things, and nothing in the README speaks to the latter. This is a description of the licence text, not legal advice.

On maintenance, the last push to the default branch was on 2026-09-09, and the most recent releases listed are `[email protected]` and `@e2b/[email protected]`, both dated 2026-09-09. The release history shows the JavaScript and Python SDKs versioned in lockstep, which is a good sign for cross-language consistency but also means a breaking change lands on both at once.

The upgrade cost is concentrated in the generated code. Because the SDKs are produced from fetched API specs through `make codegen`, the public method surface follows the spec rather than hand-written wrappers. When you pin a version, pin it deliberately: the top-level `package.json` uses changesets for versioning and publishing, so version bumps are batched rather than ad hoc. If you self-host, your upgrade path also includes the Terraform infrastructure in `e2b-dev/infra`, which is a separate repository with its own release rhythm.

Editorial conclusion

Adopt E2B when an agent must execute untrusted, model-generated code and you want the isolation handled outside your own process. Do not adopt it when you need a fully offline runtime, since the README's quickstart path assumes an E2B API key and the hosted service. Before committing, verify first that the self-hosting guide in e2b-dev/infra covers your cloud provider: the README lists AWS and Google Cloud as supported, leaves Azure and general Linux machines unchecked, and states the infrastructure is deployed using Terraform.

Frequently asked questions

Official sources

1. e2b-dev/E2B on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases