E2B
Open-source Firecracker sandboxes for AI agents, billed per second while they run, with pause, resume and fork.
What is E2B?
E2B gives each AI agent session its own Firecracker microVM with its own kernel. Code creates a sandbox from a template (a pre-booted snapshot built from a Dockerfile-like recipe), runs commands, edits files and opens ports, then kills it or pauses it with memory and disk intact to resume or fork later. Agents drive it through the e2b SDKs for JavaScript and Python (2.64.0 since 13 November 2026), a CLI, and Code Interpreter and Desktop SDKs.
FoundryLabs, Inc., trading as E2B and founded in 2023, charges a plan fee (Hobby free, Pro $150 a month) plus per-second usage for the vCPU and RAM a running sandbox is given. The runtime is Apache-2.0 (e2b-dev/runtime) and so is the SDK monorepo, though the published npm and PyPI packages declare MIT. E2B Cloud runs on Google Cloud; BYOC on AWS, GCP or Azure is Enterprise-only.
The open-source E2B Embed package runs the whole stack on one Linux host with KVM. E2B says it passed two billion sandbox starts in October 2026. It's CPU-only; Daytona and Modal add GPUs, and boat sells cheaper flat-price VMs.
Our review
4.0A heavily used agent sandbox, and the one in this category you can most easily walk away from: the runtime is Apache-2.0, and E2B Embed runs it on a single box you own. The pricing model is fair on paper. You pay per second for the vCPU and RAM a running sandbox is given, at exactly Daytona's rates, and a paused sandbox keeps its memory and disk without a compute charge, indefinitely. The catches are the $150 a month Pro fee you need for runs longer than an hour or for more than 10 at once, and speed: on StarSling's October run it came 10th of 15 on a real dependency install and mid-pack on CPU. There are no GPUs. Community chatter is mostly builders naming it as their default backend; the GitHub issues are SDK edge cases, notably timeouts and JavaScript and Python drifting apart, not outages.
Pros
- + Open source where it counts: the Apache-2.0 runtime, E2B Embed for one KVM host, and BYOC on AWS, GCP or Azure, all behind the same SDK and API
- + Pause keeps memory and disk, costs no compute, and has no time limit; fork clones a running sandbox; auto-pause and auto-resume stop idle agents billing
- + Mature, heavily used JavaScript and Python SDKs (about 12M npm and 9.5M PyPI downloads in the last 30 days), plus Code Interpreter and Desktop SDKs
Cons
- − Hobby caps continuous runtime at 1 hour and 10 concurrent sandboxes; Pro costs $150 a month before usage and adds no credit
- − Slow on StarSling's October run: 72.9 s for the Mastra cold install (10th of 15) against 44.35 s on boat and 39.32 s on Daytona's VMs
- − CPU-only, and billed on what a sandbox is given, not what it uses: an idle running 4 vCPU / 8 GiB sandbox still costs $0.3312 an hour
Reviewed by SeekDeploy Editorial · updated 2026-11-15. Reviews are independent — we don’t accept payment for coverage or ratings.
Should you use E2B?
A good fit if you're…
- Agent products running many short code-execution or tool-call sandboxes from JavaScript or Python, who want a well-trodden SDK and a microVM per task
- Agents that wait a lot: pause keeps memory and running processes, costs no compute and never expires, and auto-resume wakes the sandbox on the next call
- Teams that want an exit: the same API on E2B Cloud, in your own AWS, GCP or Azure account (Enterprise BYOC), or on one KVM host with the Apache-2.0 E2B Embed
Probably not for you if you're…
- Anything needing a GPU: E2B sandboxes are CPU-only, BYOC included
- Build-heavy work where wall-clock time matters: StarSling's October run put it 10th of 15 on a cold dependency install
- Long-running agents on a hobby budget: past one hour of continuous running you need Pro at $150 a month before usage
Pick something else if…
- your agents keep big Linux VMs busy for hours and you want a much lower flat price and faster installs, and EU-only regions are fine → boat
- you need Windows, macOS or GPU sandboxes, or dedicated and bring-your-own-compute regions, at the same per-second rates with no plan fee → Daytona
- your agents' work is Python- and GPU-heavy, or you'd rather pay for CPU actually used than for what a sandbox is given → Modal
Gotchas to know before you commit
- Every sandbox times out after 5 minutes unless you set timeoutMs / timeout, and the default onTimeout is 'kill': state is gone and can't be resumed. Set onTimeout: 'pause' (and autoResume) for anything you want to keep.
- Compute is billed on allocated vCPU and RAM for as long as a sandbox runs, even while the agent waits on a model. Pause idle sandboxes or rely on short timeouts; paused ones cost no compute and don't count toward the concurrency limit.
- The default size is documented inconsistently: the billing docs say 2 vCPU / 512 MiB, the pricing page 2 vCPU / 4 GiB. Read cpuCount and memoryMB from getInfo() before you budget. Custom sizes are set when you build a template (cpuCount, memoryMB).
- In the Python Code Interpreter SDK, run_code(timeout=N) is enforced at about twice N because the transport sums read and write deadlines (issue #1881, open as of 2026-11-15).
- Pausing takes about 4 seconds per GiB of RAM (resume about 1 second), so an 8 GiB sandbox needs roughly half a minute to pause. The EU region is a shared cluster you get by contacting support, and only after adding a payment method.
E2B pricing
A plan fee (Hobby $0, Pro $150 a month) plus per-second usage for the vCPU ($0.0504/h) and RAM ($0.0162/GiB/h) a running sandbox is allocated; disk is included and paused sandboxes pay no compute. It gets expensive in two places: the $150 Pro fee, needed for any sandbox that runs longer than an hour without pausing, and large sandboxes left running while the agent waits.
- $100 one-time usage credit, no card needed
- 10 concurrent sandboxes; 1 new sandbox a second
- 10 GiB disk included
- Limit: 1 hour of continuous runtime per sandbox (pausing resets it)
- Limit: Pricing page lists the default CPU and RAM only; custom sizes are a Pro feature
- Limit: With no payment method, running out of credit blocks every project in the workspace
- 24 hours of continuous runtime
- 100 concurrent sandboxes; 5 new sandboxes a second
- Custom sandbox CPU and RAM; 20 GiB disk included
- Limit: No usage credit included
- Limit: Concurrency add-ons: 600 sandboxes for +$500 / month, 1,100 for +$1,000 / month
- vCPU $0.000014/s ($0.0504/h)
- RAM $0.0000045/GiB/s ($0.0162/GiB/h)
- Disk included; paused sandboxes pay no compute
- Limit: Billed on allocated vCPU and RAM while running, busy or idle
- Limit: No GPU option on any plan
- BYOC in your AWS, GCP or Azure account, operated by E2B
- SOC 2 Type II, HIPAA BAA, multi-day sessions, 500+ concurrent
- Limit: Pricing page: from a $2,000 / month commit; its Markdown version says a $3,000 monthly minimum
What it costs in practice
| One agent, workdays | ~$208 / month One 4 vCPU / 8 GiB sandbox running 8 h a day for 22 days = 176 h × (4 × $0.0504 + 8 × $0.0162 = $0.3312) = $58.29 usage, plus $150 for Pro, since Hobby stops a sandbox after an hour of continuous running and lists custom sizes as Pro-only. Pausing whenever the agent waits cuts the usage part, not the fee. |
|---|---|
| Code-interpreter calls | ~$109 / month 1,000 short sandboxes a day at the documented default of 2 vCPU / 512 MiB, each running 2 minutes = 1,000 h a month × ($0.1008 + $0.0081 = $0.1089) = $108.90 on Hobby with a card, once the $100 credit is gone. Average concurrency is about 1.4, well under Hobby's 10. The pricing page's calculator assumes 4 GiB instead, which makes it $165.60. |
| Ten agents, workdays | ~$733 / month 10 sandboxes at 4 vCPU / 8 GiB, 8 h × 22 days = 1,760 h × $0.3312 = $582.91, plus $150 for Pro = $732.91. The same usage on Daytona is the same $582.91 with no plan fee, and about $63 on boat. |
Estimates in USD from list prices. Your bill depends on usage, region, and discounts.
Health & activity
From e2b-dev/E2B. Counts cover the last 90 days unless noted.
Downloads
- npm ·
e2b12M last 30 days - PyPI ·
e2b9.5M last 30 days
Benchmarks
Mastra cold install (StarSling sandbox benchmarks)
Source: StarSling hpc-sandbox-benchmarks, run 37073680030Wall-clock time for a cold dependency install of the Mastra repository on a 4 vCPU / 8 GiB sandbox, median across 12 sandboxes · s, lower is better
- Namespace37.2 s
- Daytona (VM)39.3 s
- Blaxel42 s
- boat44.4 s
- Modal (VM)46.4 s
- Vercel Sandbox59 s
- Modal (gVisor)70.9 s
- E2B72.9 s
How this was measured
Third-party run by StarSling, a CI-runner company that isn't one of the providers ranked. It requests 4 vCPU / 8 GiB / 40 GB disk from every provider and reports medians with cluster-bootstrap intervals; the raw dataset and methodology are public. StarSling marks this run partial (800 of 840 cells), but E2B has no coverage gaps. E2B ranks 10th of 15, statistically tied with Modal (gVisor), tama and Freestyle; on the Better-Auth build in the same run it was 11th (100.1 s against boat's 47.72 s). On E2B, 4 vCPU / 8 GiB is a custom size, which the pricing page lists as a Pro feature. Eight of 15 providers shown; copied from the leaderboard on 2026-11-15.
Versions: E2B sandbox (Firecracker) as of 2026-10-03
Published Oct 3, 2026 · source
Node.js web tooling (StarSling sandbox benchmarks)
Source: StarSling hpc-sandbox-benchmarks, run 37073680030V8 Web Tooling Benchmark throughput on a 4 vCPU / 8 GiB sandbox, median across 5 fresh sandboxes (10 trials) · runs/s, higher is better
- Brezel30.1 runs/s
- boat28.1 runs/s
- Namespace24.9 runs/s
- Daytona (VM)21.5 runs/s
- Modal (VM)15.5 runs/s
- Vercel Sandbox12.7 runs/s
- Modal (gVisor)12.6 runs/s
- E2B11.1 runs/s
How this was measured
Same run and methodology as the table above, using the versioned Phoronix Test Suite profile. E2B ranks 7th of 15, statistically tied with tama, Blaxel, Modal (VM), run.cloud, Vercel Sandbox and Modal (gVisor). StarSling lists E2B's hourly cost for this size as $0.3312, the same as Daytona (VM). Eight of 15 providers shown; copied from the leaderboard on 2026-11-15.
Versions: E2B sandbox (Firecracker) as of 2026-10-03
Published Oct 3, 2026 · source
What the community says
Most E2B talk on Hacker News is from builders who name it as the sandbox their agent product runs on, or as the yardstick other sandbox launches get compared against, plus the E2B Embed self-hosting release. The GitHub issues are almost all SDK bugs in the JavaScript and Python clients, many found with offline reproducers rather than in production.
What people like
- The default sandbox people build on · 5 sources
Builders describe running each agent job in a fresh E2B sandbox (Doozy), wiring it in as one backend of a self-hosted sandbox router (Plimsoll), or using it for large agent experiments. One commenter notes Amp's Orbs run on it.
- VM isolation is the bar others are measured against · 3 sources
When new sandbox products launch, commenters ask how their isolation compares with E2B's, and point out that a fresh microVM per task limits the blast radius of untrusted code, even if it's less efficient.
- Open source you can run elsewhere · 4 sources
People point out the runtime is Apache-2.0 and runs on GCP, AWS, Azure or any Linux box with KVM; E2B Embed was posted twice, and a Show HN runs the unmodified E2B SDK against other infrastructure.
What people complain about
- Timeouts and dropped streams behave unexpectedly · 4 sources
Reported bugs: run_code(timeout=N) is enforced at about twice N in Python, timeout=0 is silently replaced with the 300-second default, a sandbox ending mid-stream surfaces a raw transport error, and stopping a file watch reports a timeout.
- The JavaScript and Python SDKs drift apart · 8 sources
A run of issues finds the two SDKs validating, parsing or ignoring the same input differently: chart deserialisers, secret and volume name checks, MCP server config keys and .dockerignore handling in template builds.
- Client bugs that break basic calls · 3 sources
Passing a logger to the JavaScript SDK made every API call fail on Node, the Code Interpreter corrupted Unicode split across chunks, and file reads with an unknown format silently return nothing.
Written by Petra Lindqvist on Nov 15, 2026 after reading 33 relevant Hacker News comments, threads and GitHub issues from Aug 17, 2026 to Nov 15, 2026. Each point links to the discussions behind it, and the count shows how many sources raised it. This is a reading of public discussion, not a survey.
On Hacker News · 5 threads, 13 comments mentioning it
- E2B CEO: Sandboxes are dead2 points · 0 comments · Oct 16, 2026
- Show HN: SandrPod – run the unmodified E2B SDK against your own infrastructure2 points · 0 comments · Sep 2, 2026
- E2B Embed1 points · 1 comments · Oct 6, 2026
- Show HN: Run your agents across E2B, Daytona and more. steer them from anywhere1 points · 0 comments · Oct 13, 2026
- E2B Embed1 points · 0 comments · Sep 30, 2026
Most-reacted new GitHub issues · 46 opened in the window
- [Bug]: run_code(timeout=N) is enforced at ~2*N seconds — the pyqwest transport derives one deadline by summing read+write0 reactions · 3 comments · Sep 17, 2026
- [Bug]: Desktop SDK getApplicationWindows returns [''] when no window matches0 reactions · 3 comments · Nov 11, 2026
- Clarify effective network-policy proof semantics after sandbox creation (SDK 2.52.0)0 reactions · 3 comments · Oct 7, 2026
- [Bug]: Code Interpreter corrupts Unicode split across response chunks0 reactions · 2 comments · Oct 5, 2026
- JS SuperChart deserializer reads data instead of elements, and Result never deserializes charts0 reactions · 2 comments · Sep 7, 2026
Alternatives to E2B
Daytona
Hosting & DeploymentSandboxes for AI agents (containers, VMs, Windows, macOS and GPUs), billed per second for what you reserve.
Modal
Hosting & DeploymentServerless Python and containers on CPU and GPU: functions, inference, batch jobs and agent sandboxes, billed per second.
boat
Hosting & DeploymentPersistent Ubuntu VMs for AI agents, billed per second, running in EU data centres.
Fly.io
Hosting & DeploymentRun full containers close to users, with real VMs and a global Anycast network.
Spotted something wrong or out of date? Flag a correction on GitHub. Health and community data refresh on the 1st and 15th of every month.