back to microsandbox

compare

microsandboxvse2b

pick e2b for a fully managed, hosted sandbox service with memory snapshots. [1][2][3][5] pick microsandbox when you want the same microvm boundary as an embeddable runtime you run locally, in our cloud, or inside your own perimeter.

e2b and microsandbox solve the same core problem: running code you did not write, safely. both give each workload its own guest kernel inside a microvm, so this is not a containers-versus-vm argument. e2b uses firecracker for that boundary. [6] the honest difference is shape. e2b is a managed cloud service you call through an sdk or api. [1] microsandbox is a runtime you embed and run yourself, on your laptop, in our cloud, or inside your own environment.

if you want a hosted service to handle capacity and you are happy calling a remote api, e2b is a capable choice, and its infrastructure is apache-2.0 if you later want to self-host it. [3] if you want to run the boundary yourself, develop offline, embed it as a library with no daemon, or keep everything inside a perimeter you control, that is what microsandbox is built for.

below is the full e2b vs microsandbox comparison, including where e2b is genuinely ahead. our managed cloud: private beta. access is by request. local microsandbox is free and open source today.

microsandbox
local + cloud
e2b
managed agent sandboxes [1]
hosting model
local runtime · private beta. access is by request.
managed service · documented byoc and self-hosting [2][3]
isolation
microvm with its own kernel (libkrun)
microvm with its own kernel (firecracker) [6]
host platform
macOS · Linux · Windows (WHP, preview)
linux sandbox reached through an sdk or api [1]
runs offline
yes, fully local
byoc supports aws and gcp; self-hosting source is public [2][3]
daemon required
none, embeds as a library
managed service reached through an sdk or api [1]
image workflow
oci images from any registry, pulled at runtime
custom templates built into reusable sandbox snapshots [9]
state between runs
snapshots capture the disk state of a stopped sandbox.
pause preserves memory and filesystem state; current docs say resume takes about one second [5]
credentials
credentials are destination-bound. the sandbox works with a placeholder; the real value is substituted host-side into supported intercepted outbound requests, only for destinations on your allow-list. an approved destination still receives the real credential and could reflect or misuse it, so scope your allow-lists accordingly.
environment variables are visible inside the sandbox; public-beta per-host rules can inject headers through the egress proxy [7][8]
network policy
by default, sandboxes can reach the public internet. private, host-local, link-local, and metadata destinations are blocked. egress can be reduced to an allowlist or disabled entirely. in the cloud, the non-public block cannot be lifted, even by you.
internet on by default, with per-sandbox allow and deny lists, domain filtering, and public-beta per-host request transforms [8]
native sdks
rust · typescript · python · go · cli
python · javascript and typescript [1]
control plane
you run it, or we do in our cloud
e2b operates it; documented byoc retains e2b cloud for platform and cluster management [2]
pricing
free locally · private beta pricing is published
free hobby, paid pro, and enterprise plans plus usage costs [4]
license
local: apache 2.0 · private beta. access is by request.
apache-2.0 infrastructure repository · hosted service [3]
pick e2b

choose e2b when

  • you want a fully managed service and would rather not operate capacity. [1]
  • you need memory snapshots and resume of a running sandbox today. [5]
  • a hosted api is exactly the integration shape you want. [1]
pick microsandbox

choose microsandbox when

  • you want to develop and run offline, with no account and no remote api.
  • you want to embed the runtime as a library, with no background daemon.
  • you need the same runtime to run inside your own cloud or perimeter, not just a vendor's.
  • you want destination-bound credentials and a network floor enforced host-side.
  • you want one runtime and one sdk from laptop to cloud.

01

moving from e2b

if you already run on e2b, the mental model carries over: create a sandbox from an image, run code, read the output, and remove it. the biggest change is that microsandbox can run that flow locally with no account. one sdk. one api. local or cloud is a config change, not a rewrite.

the state model needs an explicit decision. if your application depends on e2b's live memory resume, keep that dependency visible in the migration plan. [5] microsandbox snapshots are the disk state of a stopped sandbox, not a live memory image, so a restored workload starts in a fresh microvm.

read the benchmark harnesssee microsandbox pricing

common questions

is microsandbox an e2b alternative?

yes. both run untrusted, ai-generated code in microvms with their own kernel. e2b uses firecracker for a managed service. [1][6] microsandbox is the embeddable, local-first option you can also run in your own perimeter.

is e2b open source?

e2b's infrastructure repository is apache-2.0 and includes a self-hosting path. [3] running it yourself means operating the e2b infrastructure and its services.

does microsandbox run offline?

yes. once the image is pulled, microsandbox runs a sandbox with no network and no account. the normal e2b integration reaches its managed service through an sdk or api. [1]

can i self-host e2b, and how is that different from microsandbox?

you can self-host e2b from its apache-2.0 repository, or use its documented byoc path for aws and gcp. [2][3] microsandbox is designed to be run by you from the start, local first, with no control plane required.

which is cheaper?

running microsandbox locally is free. e2b is a usage-based managed service with a free hobby tier and paid plans above it. [4] for managed cloud, compare the pricing pages directly.

run it locally.

put the boundary on your own machine before you choose anything else.

run it locally