--- title: Vercel Sandbox vs E2B description: "A detailed guide to Vercel Sandbox vs E2B: compute lifecycle, security controls, code execution, pricing, and when to choose each sandbox for your AI agent workloads." url: "https://vercel.com/kb/guide/vercel-sandbox-vs-e2b" published: 2026-03-20 last_updated: 2026-10-27 authors: Vercel install_vercel_plugin: npx plugins add vercel/vercel-plugin --- Code that an AI agent produces is shaped by its inputs, and [prompt injection](https://vercel.com/blog/security-boundaries-in-agentic-architectures) means those inputs can be manipulated by an attacker. If that code shares an execution environment with your application, it inherits your credentials, network access, and filesystem. Sandboxes prevent this by running generated code in an isolated VM where it cannot reach the agent's secrets or your infrastructure. Vercel Sandbox and E2B both provide this isolation. The differences are in what each product builds on top of it. This guide compares both across compute, security, and pricing so you can choose which one fits what you're building. * * * ## Table of contents - [How Vercel Sandbox and E2B compare](#how-vercel-sandbox-and-e2b-compare) - [Where Vercel Sandbox goes deeper](#where-vercel-sandbox-goes-deeper) - [Where E2B goes deeper](#where-e2b-goes-deeper) - [What they cost](#what-they-cost) - [When to choose Vercel Sandbox or E2B](#when-to-choose-vercel-sandbox-or-e2b) - [Get started with Vercel Sandbox](#get-started-with-vercel-sandbox) * * * ## How Vercel Sandbox and E2B compare Vercel Sandbox and E2B both provide isolated environments for agent workloads. Vercel supports persistent sandboxes by default: files and installed packages are saved when a session stops and restored when it resumes. E2B can also preserve running processes and in-memory state across pause and resume. The practical choice depends on which state your workload needs to retain, along with its requirements for execution tools, security controls, and pricing. ### Compute Both products give each sandbox its own Linux kernel, preventing the cross-sandbox escapes that container-based isolation leaves open. | **Concern** | **Vercel Sandbox** | **E2B** | | ------------------ | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | Designed for | Persistent agent environments and high-concurrency code execution. | Stateful agent sessions (Code Interpreter, pause/resume, computer use) | | Concurrency (paid) | 10,000 (Pro/Enterprise) | 100 (Pro), up to 1,100 with add-on | | Billing model | Active CPU (I/O wait excluded) + provisioned memory | Per-second wall-clock time while running | | Isolation | Firecracker microVM (dedicated kernel) | Firecracker microVM (dedicated kernel) | | Code execution | Shell execution via `runCommand()` with full environment access | Jupyter-based Code Interpreter with structured output (charts, tables) + shell execution | | Persistence | Persistent by default (filesystem auto-snapshotted on stop, restored on resume); opt out with `persistent: false` | Pause/resume preserves filesystem + memory state, ~1s resume | | Base environment | Ubuntu-based managed image (`vercel/sandbox/universal`), packages via `apt-get`; legacy runtimes use Amazon Linux 2023 | Debian/Ubuntu, Docker image templates | | Max runtime | 45 min (Hobby), 24 hr (Pro/Enterprise) | 1 hr (Hobby), 24 hr (Pro), indefinite via pause/resume cycles | | vCPU per sandbox | 1, or any even number from 2 to 32 (max 4 Hobby, 8 Pro, 32 Enterprise) | 1, 2, 4, 6, or 8 | | RAM per sandbox | Fixed 2 GB per vCPU (up to 16 GB on Pro, 64 GB on Enterprise) | 512 MB to 8 GB (flexible, decoupled from CPU) | Vercel Sandbox supports 10,000 concurrent sandboxes on Pro and Enterprise. Sandboxes can keep their files and configuration across sessions, so agents can stop when idle and resume later. E2B supports memory-preserving pause and resume; its Pro plan includes 100 concurrent sandboxes, with paid options for more. These are plan limits, not a distinction between disposable and persistent agents.. E2B decouples RAM from CPU count, allowing configurations like 2 vCPUs with 8 GB for memory-heavy workloads that don't need proportional compute. Vercel Sandbox ties RAM to CPU at 2 GB per vCPU, which simplifies configuration and reaches a higher ceiling (up to 64 GB at 32 vCPUs on Enterprise) for workloads that need both. Vercel Sandbox is available in 19 regions across North America, South America, Europe, Africa, and Asia Pacific. You can choose a region for each sandbox or set a project default. E2B’s managed cloud offers US, EU, and APAC regions. Both products provide VM-level isolation. The key difference is what controls exist at the network boundary and how secrets are handled. | **Concern** | **Vercel Sandbox** | **E2B** | | ------------------- | ------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | Credential handling | Secret injection proxy outside sandbox boundary (all plans) | Environment variables or E2B Secrets, which injects credentials into matching HTTPS requests outside the sandbox. | | Network firewall | Domain + CIDR rules, runtime-updatable; deny takes precedence | Domain allow lists + IP/CIDR allow/deny lists; allow takes precedence | | Compliance | SOC 2 Type II (Vercel infrastructure) | Not publicly documented | Vercel Sandbox adds application-layer controls on top of VM isolation. Credential brokering keeps secrets outside the sandbox entirely, and a runtime network firewall controls what outbound connections the sandbox can make. In Vercel Sandbox, denied ranges always override allowed ranges, so a deny rule cannot be accidentally bypassed. E2B inverts this: allow rules take precedence, which means explicitly allowed traffic passes even if a broader deny rule would otherwise block it. E2B also offers a way to keep credentials outside the sandbox through E2B Secrets. Its request injection adds configured secrets to matching outbound HTTPS requests after they leave the sandbox. Environment variables remain an option on both products, but code inside a sandbox can read any secret placed there. See the [credential brokering](#how-credential-brokering-keeps-secrets-outside-the-sandbox) and [network firewall](#how-the-network-firewall-controls-sandbox-egress) deep dives below. E2B provides infrastructure flexibility that Vercel Sandbox does not currently offer. E2B offers Bring Your Own Cloud on Enterprise plans for AWS, Google Cloud, and Azure. Sandboxes run in the customer’s cloud account and VPC, with E2B provisioning and operating the cluster. E2B also offers Embed, a separate customer-operated option. Vercel’s AWS BYOC offering currently covers Vercel Functions; Vercel does not document BYOC deployment for Sandbox. For teams with data residency or compliance requirements that mandate infrastructure control, these options remove the managed-cloud dependency. * * * ## Where Vercel Sandbox goes deeper The comparison tables above show where the two products overlap. The sections below go deeper into the capabilities that are specific to Vercel Sandbox. ### How credential brokering keeps secrets outside the sandbox AI-generated code that needs to call authenticated APIs creates a specific security problem. If you pass API keys into the sandbox as environment variables, the generated code can read them and send them anywhere. [Credential brokering](https://vercel.com/docs/sandbox) solves this by keeping secrets outside the sandbox entirely. A proxy sits outside the sandbox security boundary and intercepts outbound requests. When the sandbox code calls an API endpoint without authentication headers, the proxy injects credentials into the HTTP headers in transit. If the sandbox code tries to set the same headers (to redirect authenticated requests to an attacker-controlled endpoint), the proxy overwrites them. When no transformation rules are configured, TLS passes through end-to-end without interception. Credential brokering transformation rules are available on all plans, including Hobby. We recommend [an architecture](https://vercel.com/blog/security-boundaries-in-agentic-architectures) where the agent harness and its secrets live in one security context (such as a Vercel Function) while generated code executes in a separate sandbox with no access to agent secrets. This separation ensures that even if generated code is malicious, it cannot reach the credentials that drive the agent workflow. E2B passes secrets as environment variables that are visible inside the sandbox. ### How the network firewall controls sandbox egress The [sandbox network firewall](https://vercel.com/docs/sandbox) controls what external services a sandbox can reach. The three available modes are `allow-all` (the default), `deny-all` (blocks everything including DNS resolution), and user-defined rules combining domain and IP range matching. Domain matching works through SNI (the TLS handshake field that identifies the target hostname), and CIDR rules handle IP-range and non-TLS traffic. Denied ranges always take precedence over allowed ranges and domain-based rules. Policies update at runtime through `updateNetworkPolicy()` without restarting running processes, so you can start with `deny-all` and selectively open access to specific APIs as an agent's execution progresses. E2B also provides network controls through domain allow lists and IP/CIDR allow/deny lists, with the opposite precedence model: allow rules take precedence over deny rules. E2B supports domain matching in allow lists only (not deny lists), using Host header inspection on HTTP/80 and SNI on TLS/443. Both products use CIDR-based rules for non-TLS traffic. ### Active CPU billing [Active CPU pricing](https://vercel.com/docs/sandbox) charges only for time the CPU is executing code. Time spent waiting on AI model inference, database queries, API responses, or any other I/O does not count. Active CPU pricing can reduce costs by up to 95% for workloads with bursty or I/O-bound patterns. On Pro, Active CPU costs $0.128 per vCPU-hour. E2B charges per-second for the full wall-clock time a sandbox is running at $0.0504 per vCPU-hour, regardless of CPU activity. Both products bill memory on wall-clock time (Vercel Sandbox at $0.0212/GB-hr, E2B at $0.0162/GiB-hr). The [pricing section](#what-they-cost) includes worked examples. The SDK and CLI are open-source on [GitHub](https://github.com/vercel/sandbox). * * * ## Where E2B goes deeper E2B offers capabilities that fall outside Vercel Sandbox's focus areas. If your project relies on any of these, E2B may be worth evaluating alongside Vercel Sandbox. ### Code Interpreter and stateful execution E2B includes a built-in Code Interpreter that runs a headless Jupyter server inside each sandbox. Code executed through `runCode()` maintains state across calls, so variables, imports, and data loaded in one execution are available in the next. The Code Interpreter supports Python (default), JavaScript/TypeScript, R, Java, and Bash out of the box. Results come back as structured objects. Matplotlib charts are returned as base64-encoded PNG images, and E2B can extract chart data (type, title, axis labels, data points) for client-side re-rendering. Multiple parallel execution contexts per sandbox allow independent stateful sessions. Vercel Sandbox executes code through `runCommand()`, which provides direct shell access. This works well for agent workflows that generate and run complete scripts but does not provide stateful notebook-style execution. ### What gets preserved between sessions Both products can save sandbox state, but what gets saved is different. Vercel Sandbox snapshots capture the filesystem and installed packages. E2B pause/resume captures the filesystem and complete memory state, including running processes and loaded variables. Resuming takes approximately 1 second. That distinction matters for workloads that accumulate expensive in-memory state, such as loaded ML models or parsed datasets. Reconstructing that state from a filesystem-only snapshot means re-running setup code, which can take minutes. E2B's memory-state preservation skips that entirely. Auto-resume allows paused sandboxes to wake on inbound traffic or SDK calls, so per-user sandboxes stay available without running continuously. Vercel Sandbox supports persistent agents by default. A named sandbox keeps its filesystem and configuration across sessions: when a session stops, Vercel saves the filesystem and restores it on resume. Agents can also use Drives to keep working files independently of a sandbox and share or fork them across agents. Vercel does not yet preserve running processes or memory when a session stops. E2B’s pause and snapshots do, which matters when an agent needs to resume an in-memory execution context. ### Desktop Sandbox, Docker, and MCP tools E2B offers a Desktop Sandbox with a full Ubuntu Desktop accessible via VNC for computer use agents that interact with graphical interfaces. Templates support any Docker image as a base (including private registries), and Docker-in-Sandbox enables nested containerization within microVMs. E2B also supports tools from the Docker MCP catalog. MCP (Model Context Protocol) is a standard for connecting AI agents to external services, and these tools run as Docker containers inside sandboxes. Vercel Sandbox can boot from a managed image or a custom OCI image stored in Vercel Container Registry. It also supports installing and running Docker containers inside a sandbox, including containerized services used during development and testing. E2B offers a packaged Desktop Sandbox and integrations for Docker-based MCP tools; those are the more relevant differences for desktop and tool workflows. * * * ## What they cost The table below compares the paid tiers where each product first supports production-level SDK concurrency. | **Metric** | **Vercel Sandbox (Pro, $20/mo)** | **E2B (Pro, $150/mo)** | | ------------------- | ---------------------------------- | ---------------------------------------------- | | CPU billing | Active CPU only ($0.128/vCPU-hr) | Per-second wall-clock ($0.0504/vCPU-hr) | | Memory billing | Provisioned ($0.0212/GB-hr) | Provisioned ($0.0162/GiB-hr) | | I/O wait cost | $0 (excluded from CPU billing) | Full CPU rate (billed as running time) | | Billing granularity | Milliseconds | Seconds | | Paid concurrency | 10,000 sandboxes | 100 sandboxes (up to 1,100 with add-on) | | Free tier | 5 hrs Active CPU/mo, 10 concurrent | $100 one-time credits, 20 concurrent, 1 hr max | Vercel's free 5 hours are Active CPU time (recurring monthly), so actual wall-clock time depends on CPU utilization. E2B’s $100 one-time credit covers approximately 604 running hours at its listed default configuration of 2 vCPUs and 4 GiB of memory, before any other applicable charges. ### Cost examples The examples below compare equivalent sandbox configurations on each product. Vercel Sandbox bills CPU at $0.128/vCPU-hr only during execution, and memory at $0.0212/GB-hr for the full wall-clock duration. E2B bills CPU at $0.0504/vCPU-hr and memory at $0.0162/GiB-hr, both for the full duration. **2 vCPU, 4 GB RAM** (Vercel default config; E2B with matched memory) | **Scenario** | **Wall clock** | **Active CPU** | **Vercel Sandbox** | **E2B** | | -------------------------- | -------------- | -------------- | ------------------ | ------- | | Quick AI code eval | 10 min | 2 min | ~$0.02 | ~$0.03 | | Long-running with I/O wait | 1 hr | 10 min | ~$0.13 | ~$0.17 | **At scale** (2 vCPU, 4 GB, 1,000 sandboxes/day for 30 days) | **Scenario** | **Per sandbox** | **Monthly usage** | **\+ Base plan** | **Monthly total** | | -------------------------------------- | --------------- | ----------------- | ---------------- | ----------------- | | **Vercel** (30s wall clock, 10s CPU) | ~$0.001 | ~$43 | $20 | **~$63** | | **E2B** (30s wall clock) | ~$0.001 | ~$41 | $150 | **~$191** | | **Vercel** (2 min wall clock, 30s CPU) | ~$0.005 | ~$149 | $20 | **~$169** | | **E2B** (2 min wall clock) | ~$0.006 | ~$166 | $150 | **~$316** | The monthly total includes both usage charges and the base plan cost. * * * ## When to choose Vercel Sandbox or E2B The right product depends on which state your agent must retain and which tools you want built in. | **If your workload looks like...** | **Choose** | **Why** | | ------------------------------------------------------------------ | -------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Persistent coding agents and isolated code execution. | Vercel Sandbox | Persistent filesystem by default, 10,000 concurrent sandboxes on Pro, Active CPU billing, credential brokering, and network controls. | | Running untrusted code that calls authenticated APIs | Vercel Sandbox | Credential brokering keeps secrets outside the sandbox; egress firewall limits what code can reach | | Cost-sensitive workloads at scale with I/O-heavy patterns | Vercel Sandbox | $20/mo base + millisecond Active CPU billing vs $150/mo base + per-second wall-clock | | Notebook-style code execution with variables retained across calls | E2B | Built-in Jupyter-based Code Interpreter with structured results and live execution state | | Agent workloads needing in-memory state preserved between uses | E2B | Memory-state preservation across restarts (Vercel persistence restores the filesystem, not memory) | | Computer-use agents needing a ready-made desktop SDK | E2B | Desktop Sandbox with VNC and desktop controls | Choose based on the state and tools your agent needs. Vercel Sandbox supports persistent agent workspaces, custom images, Docker, and high concurrency with Active CPU billing. Its filesystem survives across sessions, and the 24-hour session limit does not cap a persistent sandbox’s total lifetime. E2B also preserves running processes and memory when paused or snapshotted, and offers a built-in Code Interpreter and packaged Desktop Sandbox. * * * ## Get started with Vercel Sandbox Try it now with `npx sandbox create --connect` or [sign up for a free account](https://vercel.com/signup). Pro plans start at $20/month with 10,000 concurrent sandboxes. ## Related Documentation - [Vercel Sandbox](/docs/vercel-sandbox) ## More Vercel Sandbox guides - [Running Docker on Vercel](/kb/guide/docker): Run Docker on Vercel for HTTP apps and background workers, store images in Vercel Container Registry, and test containers with Vercel Sandbox. - [How to use Vercel Container Registry](/kb/guide/how-to-use-vercel-container-registry): Push, store, and pull OCI container images with Vercel Container Registry, then deploy them to Vercel Functions and Vercel Sandbox. - [Vercel Sandbox vs CodeSandbox](/kb/guide/vercel-sandbox-vs-codesandbox): A detailed guide to Vercel Sandbox vs CodeSandbox: compute isolation, credential brokering, Active CPU billing, Docker support, persistent environments, and when to choose each product for your AI workloads.