E2B vs Vercel Sandbox (2026)

An agent in a sandbox reaches other systems through a built in MCP gateway that runs inside the sandbox and exposes more than 200 tools from the Docker MCP Catalog (Airtable, GitHub, Browserbase, Exa and others) or custom MCP servers through one interface. Credentials are passed as secrets that resolve at egress instead of living in the sandbox.

Sourcedocs.e2b.dev/mcp-gatewayread 2026-11-03

Credentials reach outside services without entering the sandbox. The firewall's credentials brokering adds an authorization header to outbound requests for named domains, with matchers on path, method, query and headers, request proxying sends chosen traffic through a proxy the customer runs, and Box Mount presents Box content to the agent as local files. The tools an agent calls with those credentials are the customer's own code, and the product carries no integration catalog or tool framework.

Sourcevercel.com/docs/sandbox/concepts/firewallread 2026-11-05

There is no workflow logic in E2B itself. The customer brings its own orchestration framework, and E2B provides the machine an agent's steps run on (commands, background processes, code contexts), not a runtime that sequences, branches, retries or routes those steps. Forking a sandbox copies its state, which is compute, not workflow logic.

Sourcee2b.dev/llms.txtread 2026-11-03

There is no workflow logic in the product. Commands run blocking or detached from the customer's code, and lifecycle hooks run setup when a sandbox is created or resumed. Multi agent sandboxes give each agent its own Linux user and private home directory and share files through groups, which separates agents inside one machine without sequencing, routing or retrying their work.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

A sandbox can start without the customer's code calling it. With auto resume set, a paused sandbox resumes when activity arrives, so an agent served from a sandbox starts on an inbound request, and E2B's guides deploy agent gateways this way, for example OpenClaw answering Telegram. Sandbox lifecycle events are also pushed to the customer's webhook, signed. There is no scheduler.

Sourcedocs.e2b.dev/sandbox/auto-resumeread 2026-11-03

Work reaches a sandbox only when the customer's code or the CLI calls it. A stopped persistent sandbox resumes on the next SDK call that needs a running machine, and exposed ports serve traffic at a public URL while a session runs, but no schedule, webhook or inbound event starts or wakes a sandbox on its own.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

There is no retrieval structure over the customer's content, since E2B runs the agent's code. Files uploaded to a sandbox or volume are storage the agent's code can read, not an index a query returns, and the MCP gateway's tools reach outside knowledge sources owned by others.

Sourcee2b.dev/llms.txtread 2026-11-03

No retrieval index or knowledge base over the customer's content comes with Sandbox. Files on the sandbox disk, Vercel Drives and S3 buckets mounted through FUSE are storage the agent's code reads, and any search or embedding layer runs as the customer's own code inside the microVM.

Sourcevercel.com/docs/sandboxread 2026-11-05

An agent's working state carries across sessions. A paused sandbox resumes exactly as it was, with filesystem and memory, running processes and loaded variables, and is kept until it is killed. Snapshots and forks copy that state, volumes, in private beta, keep files across sandboxes, and code contexts keep interpreter variables between executions, which the agent's code reads to continue its task. This is machine state the developer manages, with no memory layer of stated types or scope that can be reviewed, edited or deleted as memory.

Sourcedocs.e2b.dev/sandbox/persistenceread 2026-11-03

Sandboxes are persistent by default. When a session stops, its filesystem is snapshotted automatically and the next SDK call resumes from it, snapshots can be kept for a set period or indefinitely, and Vercel Drives, in public beta, keep files across sandbox runs and can be shared between agents. The product does not remember anything for the agent. An agent keeps notes on a drive only when the application gives it file tools and instructions to do so, and running processes restart on resume.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

There is no approval step, consent checkpoint or escalation to a person for work inside an E2B sandbox. Egress control (allow and deny lists for each sandbox, a proxy the customer runs that fails closed, and access tokens on public URLs) limits what an agent's code can reach, but that is isolation the developer configures, not a point where a person reviews the agent's action.

Sourcee2b.dev/enterpriseread 2026-11-03

Sandbox has no approval step, review queue or escalation to a person. The firewall can switch a running sandbox to deny all or narrow its allowed domains without a restart, which limits what an agent's code can reach but does not hold an action until someone reviews it.

Sourcevercel.com/docs/sandbox/concepts/firewallread 2026-11-05

E2B holds SOC 2 Type II, with the report under NDA in its trust center at trust.e2b.dev, and signs HIPAA Business Associate Agreements on Enterprise plans. Its controls protect the sandbox. Every sandbox is its own Firecracker microVM with its own kernel, egress can be allowed or denied for each sandbox, secrets are injected at the egress proxy so no sandbox holds them, and public sandbox URLs can require an access token. Who inside a customer's organization can do what has no published control yet, since E2B lists single sign on, SCIM and role based access as planned.

Sourcee2b.dev/securityread 2026-11-03

Vercel's infrastructure holds SOC 2 Type II. Access to sandboxes follows Vercel's team roles (Owner, Member, Developer, Security, Billing, Viewer and Contributor) and, on Enterprise, project roles for administrators, developers and viewers, with permission groups for finer grants, and the SDK authenticates with project scoped OIDC tokens or access tokens. Each sandbox runs in its own Firecracker microVM with a dedicated kernel, and the firewall restricts egress by domain or address range and injects credentials so code inside never holds them.

Sourcevercel.com/docs/rbac/access-rolesread 2026-11-05

The record covers the sandbox, not the agent. Every lifecycle event is available through an events API and delivered as a signed webhook, sandbox metrics report CPU and memory use, template builds keep logs, and on Enterprise OpenTelemetry metrics and logs export to the customer's OTLP endpoint. Prompts, tool calls, retrieved knowledge and outputs cannot be inspected step by step in E2B, since the agent's reasoning runs outside the sandbox, and there is no audit log of user actions apart from the runtime.

Sourcee2b.dev/enterpriseread 2026-11-03

Each sandbox has a dashboard page with its configuration, an activity log of lifecycle events and its snapshots, the CLI lists every session a sandbox has run, and the Observability tab charts CPU and memory per sandbox, with alert monitors on Observability Plus. Command output streams through the SDK, and request proxying can route chosen traffic through a customer proxy for logging. What an agent decided between commands is not recorded, since the agent's loop runs in the customer's code.

Sourcevercel.com/docs/sandbox/concepts/persistent-sandboxesread 2026-11-05

Three deployment modes share the same SDK, CLI and API. E2B Cloud defaults to Google Cloud us-west1, and AWS us-west-2 and us-east-1 and Google Cloud europe-west1 and asia-southeast1 are available on request on every plan. With BYOC on AWS, Google Cloud or Azure on Enterprise, the data plane runs in the customer's own cloud account. E2B Embed packages the Apache-2.0 runtime for a single node self hosted install, and a private cloud option is in development.

Sourcedocs.e2b.dev/faq/egress-ip-rangesread 2026-11-03

Sandboxes run in 19 regions, chosen per sandbox or set as a project default, with iad1 as the default, and snapshots and drives stay in the region they were created in. Secure Compute sends a sandbox's internet traffic through static IPs and reaches the customer's own AWS VPC over VPC peering. Sandboxes run only on Vercel's infrastructure.

Sourcevercel.com/docs/sandbox/pricingread 2026-11-05

Starting points ship with the platform, including sandbox templates for Claude Code, a desktop, Docker and web app stacks, a cookbook of examples ready to run, setup guides for more than thirty agents and frameworks, and open source reference apps, Surf, a computer use agent, and Fragments, a builder that turns a prompt into an app. These are environments and examples a developer builds from, not a browsable catalog of agents a customer adopts.

Sourcedocs.e2b.dev/llms.txtread 2026-11-03

The default universal image ships Node.js, Python and coding agents, rebuilt nightly from open source definitions, and one CLI command starts OpenCode, Pi, Claude Code or Codex inside a sandbox. Integrations cover Cursor Cloud Agents, Devin Outposts, Herdr, Hermes and Paseo, frameworks such as the AI SDK, LangChain, Mastra, Flue and TanStack AI, and the OpenAI Agents API. These are configured third party agents and building blocks, not prebuilt agents of Vercel's own.

Sourcevercel.com/docs/sandbox/ecosystemread 2026-11-05

Compute is what E2B provides for agents, with the customer bringing its own model and orchestration framework. Sandboxes connect to any LLM and to agents and frameworks such as Claude Code, Codex, the OpenAI Agents SDK, the Vercel AI SDK, LangChain, CrewAI, Mastra and Google ADK. E2B imposes no model, so model choice stays with the customer.

Sourcee2b.dev/llms.txtread 2026-11-03

The customer chooses the agents and models that run in a sandbox. Any coding agent or framework can run inside it and model calls happen in the customer's code, and Vercel's examples route them through its optional AI Gateway with many providers or the customer's own keys. Sandbox itself imposes no model.

Sourcevercel.com/docs/sandbox/ecosystemread 2026-11-05

Outside systems can call E2B through Python and JavaScript/TypeScript SDKs, a CLI, a REST API described by a published OpenAPI 3.1 specification, and custom sandbox templates the customer builds, tags and versions. A public MCP server serves E2B's documentation to agents.

Sourcee2b.dev/llms.txtread 2026-11-03

Outside code drives sandboxes through the open source @vercel/sandbox JavaScript and TypeScript SDK, the Python SDK in the vercel package and the sandbox CLI, covering creation from images or snapshots, commands, files, network policy updates, snapshots, drives, tags and listing. Authentication uses Vercel OIDC tokens or access tokens, so sandboxes can be driven from Vercel Functions, other clouds or CI systems.

Sourcevercel.com/docs/sandbox/sdk-referenceread 2026-11-05

There are no fixtures, scoring, quality gates or comparison of agent runs. E2B is where evaluations and reinforcement learning run, not how they are scored. It lists reinforcement learning among its workloads and runs NVIDIA NeMo Gym environments in sandboxes, but the datasets, reward functions and scoring belong to the customer's framework.

Sourcee2b.dev/llms.txtread 2026-11-03

There are no test cases, scoring or quality gates of the product's own. Harbor runs Terminal Bench and other benchmark trials in sandbox microVMs, and Scale AI's AgentEnv evaluates agents in separate environment and agent sandboxes, but those harnesses do the scoring, not Sandbox.

Sourcevercel.com/docs/sandbox/ecosystemread 2026-11-05

Agents control real desktops hosted by E2B. E2B Desktop sandboxes are Ubuntu machines with an XFCE desktop and preinstalled applications, and the Desktop SDK gives the agent screenshots, mouse, keyboard and scroll, with a live VNC stream so a person can watch. A cloud browser can also run in a sandbox, and Surf is E2B's open source computer use agent built on it.

Sourcedocs.e2b.dev/use-cases/computer-useread 2026-11-03

No browser or desktop for an agent to drive comes with the product. The managed images carry language runtimes, coding agents and utilities, and an agent that needs a browser has to install and run one itself inside the microVM.

Sourcevercel.com/docs/sandbox/concepts/imagesread 2026-11-05