E2B

e2b · e2b-dev/E2B · ★ 12k · last commit 2026-05-26

Primitive shape

No installable primitives

Summary

E2B — Summary

E2B is an open-source cloud infrastructure service for running AI-generated code in secure isolated sandboxes. It provides JavaScript/TypeScript and Python SDKs that let developers start a sandbox, run commands, execute code, and manage files with just a few lines of code. Sandboxes can run any code via sandbox.commands.run() or execute language code directly with the Code Interpreter SDK (sandbox.runCode()). E2B is cloud-only (with self-hosting via Terraform on AWS/GCP), requires an API key, and is primarily designed for LLM application developers who need safe, isolated execution environments for agent-generated code. Like Daytona and microsandbox in this batch, E2B sits below the agent loop as an execution substrate — it provides no skills, hooks, personas, or orchestration primitives, which makes it fundamentally different from all 11 seed frameworks that operate inside the agent loop.

Overview

E2B — Overview

Origin

E2B (e2b-dev/E2B) was founded as a developer tool for running AI-generated code safely in the cloud. As of May 2026 it has 12,361 stars and 30+ contributors. Licensed Apache-2.0. The E2B org has multiple related repos including e2b-dev/infra (the underlying infrastructure), e2b-dev/code-interpreter (Code Interpreter SDK), and e2b-dev/e2b-cookbook (integration examples).

Philosophy

From the README: "E2B is an open-source infrastructure that allows you to run AI-generated code in secure isolated sandboxes in the cloud."

The core value proposition is simplicity: Sandbox.create() followed by sandbox.commands.run(). There is no complex configuration, no agent framework, no skill injection.

CLAUDE.md Note

E2B ships a CLAUDE.md in the repository root. This is a developer contribution guide, not a user-facing agent behavior specification.

Ecosystem

Core SDK: e2b (Python) / e2b (npm)
Code Interpreter SDK: e2b-code-interpreter / @e2b/code-interpreter — adds runCode() with kernel execution semantics (returns execution objects with stdout, plots, etc.)
Infra: e2b-dev/infra — Terraform infrastructure on AWS/GCP
Cookbook: e2b-dev/e2b-cookbook — examples with OpenAI, Anthropic, LangChain, etc.
Template system: Custom sandbox templates (Docker-based) for custom environments

Self-Hosting

The infrastructure layer is open-source via e2b-dev/infra. Supported cloud providers: AWS, GCP. Azure and general Linux not yet supported (as of README).

Architecture

E2B — Architecture

Distribution

Type: SDK packages (npm + PyPI) + REST API
Install (Python): pip install e2b
Install (TypeScript): npm i e2b
Code Interpreter (Python): pip install e2b-code-interpreter
Code Interpreter (TS): npm i @e2b/code-interpreter
Self-hosting: e2b-dev/infra via Terraform on AWS or GCP

Repo Structure

e2b-dev/E2B/
├── packages/
│   ├── js-sdk/         — TypeScript/JavaScript SDK (npm: e2b)
│   ├── python-sdk/     — Python SDK (pip: e2b)
│   ├── cli/            — E2B CLI
│   └── connect-python/ — gRPC connect library
├── spec/               — OpenAPI spec for E2B REST API
├── supabase/           — Database schema (Supabase)
├── templates/          — Sandbox template definitions
├── CLAUDE.md           — Developer contribution guide
└── DEV.md              — Development setup

Sandbox Architecture

E2B sandboxes are cloud-hosted isolated environments. The exact isolation technology is not specified in the public SDK repo; the infrastructure (e2b-dev/infra) is Terraform-based and runs on AWS or GCP. Each sandbox:

Has a unique ID
Exposes file system, process execution, and network capabilities
Can run any command via commands.run()
Can execute code via runCode() (Code Interpreter SDK) — kernel-based execution returning structured output

Template System

Custom sandbox templates can be created from Docker images. Templates define the base environment (packages, tools, system state) for sandboxes. Template IDs are passed to Sandbox.create().

Connect Protocol

The connect-python package suggests gRPC/Connect protocol for internal communications between SDK and sandbox. The JS SDK uses HTTP-based transport.

Required Runtime

API key from e2b.dev (cloud) or self-hosted E2B API
Python ≥ 3.7 (Python SDK) or Node.js (JS SDK)

Components

E2B — Components

Python SDK Core API

from e2b import Sandbox

# Sandbox lifecycle
sandbox = Sandbox.create()                         # create sandbox
sandbox = Sandbox.create(template="python")        # custom template
sandbox.commands.run("echo hello")                 # run shell command
sandbox.files.read("/path/to/file")                # read file
sandbox.files.write("/path/to/file", content)      # write file
sandbox.close()                                    # destroy sandbox

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

JavaScript SDK Core API

import Sandbox from 'e2b'

const sandbox = await Sandbox.create()
const result = await sandbox.commands.run('echo "Hello from E2B!"')
console.log(result.stdout)
await sandbox.kill()

Code Interpreter SDK (separate package)

from e2b_code_interpreter import Sandbox

with Sandbox.create() as sandbox:
    execution = sandbox.run_code("x = 1; x += 1; x")
    print(execution.text)   # "2"
    # execution.results[0] = structured result with type, data, display_data

Adds kernel-based execution (Jupyter-compatible), structured output types, and support for plots/data visualization output.

CLI (`e2b`)

From the packages/cli/ directory — provides commands for:

Template management (create, build, push custom templates)
Authentication (e2b login)
Sandbox management

Templates

Pre-built templates available: python, node, debian, and others
Custom templates: Dockerfile-based via e2b.Dockerfile or e2b template build
Template IDs are passed to Sandbox.create(template="...")

REST API

Full OpenAPI spec in spec/ directory. All SDK operations map to REST API calls. Endpoint: api.e2b.dev.

Supabase Integration

Database backend (Supabase) manages user accounts, API keys, template registry, and usage tracking.

Prompts

E2B — Prompts

E2B ships no agent prompt files, skills, hooks, or slash-commands. It is a cloud execution infrastructure, not an agent behavior framework.

Verbatim: Core Python SDK Usage (README)

from e2b import Sandbox

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

Technique: Imperative SDK call — not a prompt. The agent's LLM prompt happens entirely upstream in the application code; E2B receives the output of agent reasoning (code to execute) rather than participating in the reasoning itself.

Verbatim: Code Interpreter Usage (README)

from e2b_code_interpreter import Sandbox

with Sandbox.create() as sandbox:
    execution = sandbox.run_code("x = 1; x += 1; x")
    print(execution.text)  # outputs 2

Technique: Kernel-based code execution with structured output. The Code Interpreter SDK adds Jupyter-compatible execution semantics on top of the base sandbox.

Verbatim: CLAUDE.md (Developer Contribution Instructions)

From the repo's CLAUDE.md (developer tooling, not user-facing):

# E2B Development Guide

[Developer instructions for contributing to the E2B SDK codebase]

The CLAUDE.md exists to guide AI coding agents working on E2B's own codebase — it is not a prompt injected into agents using E2B.

Assessment

E2B, like Daytona, is pure infrastructure. The pattern of "install SDK → create sandbox → run code" is the entire user-facing interface. No prompt engineering, no skill injection, no hook system.

Uniqueness

E2B — Uniqueness & Positioning

differs_from_seeds

E2B is architecturally orthogonal to all 11 seed frameworks. Seed frameworks operate inside the agent loop — they inject skills, hooks, personas, MCP tools, or spec files into the agent's behavior. E2B provides the execution environment where agent-generated code safely runs. Among seeds, the isolation_mechanism field captures the clearest delta: all seeds use none/git-worktree/git-branch; E2B provides cloud-hosted container isolation. E2B also has zero prompting primitives (no skills, commands, hooks, subagents) — its entire value is the execution API. The closest conceptual analog in the seeds is claude-flow's "run code in a subagent" pattern, but even that uses in-process execution rather than a remote isolated sandbox.

Positioning Within This Batch

E2B is the simplest and most developer-accessible sandbox in this batch:

vs Daytona: E2B is simpler API, more developer-friendly, less enterprise; Daytona has more features (snapshots, volumes, computer-use, SSH, VPN, dashboard)
vs microsandbox: E2B is cloud-only; microsandbox is local/embeddable with no network dependency
vs brood-box: E2B is cloud API; brood-box is local CLI that wraps any agent in a microVM
vs arrakis: E2B is managed cloud; arrakis is self-hosted with MCP + snapshot/restore + VNC

Distinctive Opinion

Running AI-generated code in the cloud via a simple SDK call (Sandbox.create() + sandbox.commands.run()) is safer and more reliable than running it locally, and the developer experience should be as simple as pip install e2b.

Explicit Antipatterns

Running AI-generated code directly on the host machine
Complex setup for basic code execution isolation

Observable Failure Modes

Cloud dependency: Requires network + E2B API key; no offline mode
Latency: Cloud round-trips add overhead vs local execution
Self-hosting complexity: AWS/GCP Terraform infra required; no simple local alternative in this repo
Template build time: Custom templates take time to build and push; cold starts from non-cached templates are slower
Resource limits: Cloud quotas and API rate limits apply

Cross-References in This Batch

VibeKit (vibekit) ships @vibe-kit/e2b as one of its pluggable sandbox backends — E2B is a first-class VibeKit provider
Daytona is the most direct enterprise competitor

Workflow

E2B — Workflow

Standard Workflow

1. Get API key (sign up at e2b.dev)
2. Set E2B_API_KEY environment variable
3. Install SDK (pip install e2b / npm i e2b)
4. Create sandbox → execute code → destroy sandbox

Phases

Phase	What Happens	Artifact
1. Auth	API key validated	Session token
2. Sandbox Create	Cloud sandbox allocated from template	Sandbox ID + connection
3. Command / Code Execution	`commands.run()` or `run_code()` sends code to sandbox	ExecutionResult (stdout, stderr, exit_code)
4. File Operations	Read/write/list files in sandbox filesystem	File contents
5. (Optional) Network	Expose ports, access running services	URL / port mapping
6. Sandbox Destroy	`sandbox.close()` / `sandbox.kill()` frees resources	(none)

Context Manager Pattern (Python)

with Sandbox.create() as sandbox:
    # sandbox is automatically destroyed on exit
    result = sandbox.commands.run("python -c 'print(1+1)'")

Approval Gates

None. E2B is a fully programmatic API — no human-in-the-loop gate exists in the framework itself.

Template Creation Workflow

1. Create e2b.Dockerfile (standard Dockerfile)
2. e2b template build
3. Get template ID
4. Use in Sandbox.create(template="<id>")

Long-Running Sandbox Pattern

Sandboxes have a configurable timeout. For long-running agent sessions, the timeout can be extended or the sandbox can be kept alive via heartbeat calls.

Memory Context

E2B — Memory & Context

State Model

Sandboxes are stateless by default — each Sandbox.create() starts from a clean template. The sandbox filesystem persists only for the duration of the sandbox session.

Persistence Options

Within a session: All files written to the sandbox filesystem persist until sandbox.close() / sandbox.kill()
Long-running sandboxes: Timeout can be configured; sandbox stays alive across multiple SDK calls
Snapshot/restore: Not explicitly documented in the public SDK README; the infrastructure layer may support this

Context to/from Agents

E2B provides no context injection mechanism. The application using E2B SDK is responsible for:

Crafting prompts to the LLM
Parsing LLM output to extract code
Sending that code to E2B for execution
Feeding execution results back to the LLM

E2B only handles step 3 (execution). The feedback loop between LLM and execution is the application's responsibility.

Code Interpreter Kernel State

The Code Interpreter SDK maintains kernel state within a session — variables defined in one run_code() call are available in subsequent calls on the same sandbox:

sandbox.run_code("x = 42")
result = sandbox.run_code("print(x)")   # prints 42

This is within-session in-memory state, not cross-session persistence.

No Framework-Level Memory

E2B has no vector database, no SQLite memory store, no session handoff mechanism at the framework level. Each new sandbox starts fresh.

Orchestration

E2B — Orchestration

Multi-Agent Support

Yes — multiple sandboxes can be created concurrently (each is independent). The application using the E2B SDK controls parallelism. E2B itself provides no orchestration layer.

Isolation Mechanism

Cloud-hosted container/VM (proprietary infrastructure). Each sandbox is isolated — dedicated filesystem and process namespace. The exact underlying technology is not documented in the public SDK repo; e2b-dev/infra (Terraform) handles the actual compute.

Execution Mode

On-demand / event-driven: Sandbox created on API call, used, then destroyed. No persistent daemon per user. The Code Interpreter SDK can maintain a long-running kernel within a session.

Orchestration Pattern

None built-in. The application using E2B decides how many sandboxes to create and how to coordinate them. E2B provides isolation primitives but no coordination.

Multi-Model

No. E2B is model-agnostic. The LLM integration is the application's responsibility; E2B only executes code.

Consensus Mechanism

None.

Git Automation

No git operations in the core SDK. Agents can run git commands inside sandboxes via sandbox.commands.run("git ...").

Observability

stdout/stderr: Every command execution returns stdout and stderr
Execution results: Code Interpreter SDK returns structured output with types (text, data, plots)
Dashboard: e2b.dev/dashboard shows API key usage and sandbox statistics (managed only)

Sandboxes as Agent Tools

E2B sandboxes are typically used as tools within a larger agent framework. Common pattern:

# LLM generates code
code = llm.generate(prompt)
# Execute in E2B sandbox
result = sandbox.run_code(code)
# Feed result back to LLM
next_prompt = f"Execution result: {result.text}"

This makes E2B a building block for ReAct-style or tool-use agent loops, not a framework itself.

Ui Cli Surface

E2B — UI & CLI Surface

CLI Binary

Binary name: e2b
Location: packages/cli/ in the monorepo
Is thin wrapper: No — communicates with E2B API
Key subcommands: login, template build, template push, template list, sandbox management

Web Dashboard

URL: e2b.dev/dashboard
Features: API key management, usage statistics, template registry, sandbox monitoring
Stack: unknown (managed service frontend)

SDK REPL / Interactive

No built-in REPL. Usage is programmatic via SDK in application code.

IDE Integration

None. E2B is a pure API/SDK — no VS Code extension or IDE plugin.

Observability

Per-execution results: Every commands.run() and run_code() returns stdout/stderr/exit_code
Structured output (Code Interpreter): Results include type information (text, data, error, display_data) and can return matplotlib/plotly figures
Timeout handling: Configurable per-sandbox timeout with automatic cleanup

Notable: Code Interpreter Output Types

The @e2b/code-interpreter SDK returns rich execution objects:

const execution = await sandbox.runCode('import matplotlib.pyplot as plt; plt.plot([1,2,3])')
console.log(execution.results)    // [{ type: 'display_data', png: '...' }]
console.log(execution.logs)       // { stdout: [...], stderr: [...] }

This is distinct from a simple stdout stream — it captures Jupyter-kernel-style rich outputs.

Related frameworks

same archetype · same primary tool · same memory type

Daytona ★ 72k

A9 Sandbox substrate

Provide secure, elastic, sub-90ms sandbox compute infrastructure for running AI-generated code, accessible via multi-language…

CUA ★ 17k

A9 Sandbox substrate

Unified SDK for building, benchmarking, and deploying agents that interact with full OS GUIs via isolated VMs.

OpenSandbox ★ 11k

A9 Sandbox substrate

Protocol-first general-purpose sandbox platform for AI applications with multi-language SDKs and pluggable isolation backends.

Microsandbox ★ 6.3k

A9 Sandbox substrate

Spawn hardware-isolated microVMs as child processes directly from application code, with no server setup, in under 100ms.

CubeSandbox ★ 5.9k

A9 Sandbox substrate

Sub-60ms KVM microVM sandboxes for AI agents with E2B drop-in compatibility and <5MB memory overhead.

sandcastle (mattpocock) ★ 5.1k

A9 Sandbox substrate

Container-isolated TypeScript SDK for orchestrating AI coding agents with Docker/Podman/Vercel Firecracker sandboxes and…

Distribution

Type: npm-package
License: Apache-2.0
Install: one-liner
Version: main branch, 2026-05-26

Surfaces

CLI binary: e2b
Local UI: No
Tech stack: none (web dashboard at e2b.dev/dashboard is managed-only)

Components

Commands: 0
Skills: 0
Subagents: 0
Hooks: 0
MCP servers: 0
MCP tools: 0
Scripts: 0
Templates: 0

Workflow

Phases: 6
Approval gates: 0
Spec format: none
Spec storage: none
Delta or full: none

Orchestration

Multi-agent: Yes
Pattern: parallel-fan-out
Isolation: sandbox-api
Consensus: none
Prompt chaining: No

Multi-model

Multi-model: No
BYOK: Yes

Execution

Mode: event-driven
Crash recovery: No
Compaction: No
Session handoff: No
Streaming: Yes

Memory

Type: none
Persistence: session
Search: none
State files: 2 files

Quality

TDD: No
TDD mechanism: none
Self-review: none

Git / Observability

Auto commit: No
Auto PR: No
Auto merge: No
Worktree/feat: No
Audit log: No
Audit format: none
Replay: No

Tools

Targets: 5
Portability: high

Signals

Stars: 12k
Last commit: 2026-05-26
Contributors: 30
Maintainer: active
Quality score: 1/10

Summary

E2B — Summary

Overview

E2B — Overview

Origin

Philosophy

CLAUDE.md Note

Ecosystem

Self-Hosting

Architecture

E2B — Architecture

Distribution

Repo Structure

Sandbox Architecture

Template System

Connect Protocol

Required Runtime

Components

E2B — Components

Python SDK Core API

JavaScript SDK Core API

Code Interpreter SDK (separate package)

CLI (e2b)

Templates

REST API

Supabase Integration

Prompts

E2B — Prompts

Verbatim: Core Python SDK Usage (README)

Verbatim: Code Interpreter Usage (README)

Verbatim: CLAUDE.md (Developer Contribution Instructions)

Assessment

Uniqueness

E2B — Uniqueness & Positioning

differs_from_seeds

Positioning Within This Batch

Distinctive Opinion

Explicit Antipatterns

Observable Failure Modes

Cross-References in This Batch

Workflow

E2B — Workflow

Standard Workflow

Phases

Context Manager Pattern (Python)

Approval Gates

Template Creation Workflow

Long-Running Sandbox Pattern

Memory Context

E2B — Memory & Context

State Model

Persistence Options

Context to/from Agents

Code Interpreter Kernel State

No Framework-Level Memory

Orchestration

E2B — Orchestration

Multi-Agent Support

Isolation Mechanism

Execution Mode

Orchestration Pattern

Multi-Model

Consensus Mechanism

Git Automation

Observability

Sandboxes as Agent Tools

Ui Cli Surface

E2B — UI & CLI Surface

CLI Binary

Web Dashboard

SDK REPL / Interactive

IDE Integration

Observability

Notable: Code Interpreter Output Types

Related frameworks

CLI (`e2b`)