back to microsandbox

compare

microsandboxvse2b

pick e2b for managed cloud memory persistence or its enterprise byoc deployment. [2][5] pick microsandbox for an embedded runtime on employee devices, local full snapshots, and a hosted cloud option through the same CLI and SDKs. [20][21][22]

e2b uses firecracker microvms; microsandbox uses libkrun. both give sandboxes a separate guest kernel. [6][24] both offer a managed cloud, so hosting alone is not the deciding factor.

e2b also publishes an apache-2.0 runtime and an Embed evaluation package for a single linux/kvm machine. [3] microsandbox runs locally without a service stack, supports managed settings on employee devices, and switches to hosted cloud through backend configuration. microsandbox cloud is in private beta with access by request. [20][22]

microsandbox
local + cloud
e2b
managed agent sandboxes [1]
hosting model
local runtime · microsandbox cloud (private beta, access by request) [20]
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/kvm for self-hosted runtime; remote clients on other hosts [3]
local execution
local runtime; offline after dependencies and images are provisioned [23]
Embed evaluation stack on a linux/kvm host [3]
daemon required
none, embeds as a library
hosted service or self-operated runtime services [3]
image workflow
oci images from any registry, pulled at runtime
custom templates built into reusable sandbox snapshots [9]
state between runs
local snapshots save disk state, or disk, memory, and running processes with --full. cloud currently supports disk snapshots from stopped persistent sandboxes and disk restore. [21]
pause and resume preserve memory and filesystem; filesystem-only mode is also available [5]
employee-device deployment
administrator settings deployed to employee devices with Jamf or Intune; supported CLI and SDK releases apply managed overrides [22]
enterprise byoc runs in your aws or gcp account; Embed targets linux/kvm [2][3]
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 request transforms 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 · ruby · cli
python · javascript and typescript [1]
control plane
no control plane needed locally · hosted microsandbox cloud [20]
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
apache 2.0
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 in a managed cloud service 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.
  • employees need local sandboxes with administrator-managed settings. [22]
  • you want destination-bound credentials and a network floor enforced host-side.
  • you need local disk and full memory snapshots, with a separate hosted cloud option. [20][21]

01

e2b cloud, byoc, Embed, and microsandbox cloud

e2b's enterprise byoc offering places sandbox compute in your aws or gcp account while e2b manages the cluster. self-hosting its runtime is a separate operational choice. [2] Embed packages the stack for single-machine evaluation; its documentation describes it as an evaluation package, not a production deployment pattern. [3]

microsandbox offers a local runtime and its own hosted cloud. deploying that local runtime to employee devices is different from a vendor-managed byoc cluster. cloud uses an API key and the same CLI and SDK surface, with documented feature differences. [20][22]

02

memory snapshots and migration

e2b pause and resume preserve filesystem and memory state. [5] local microsandbox full snapshots save disk, memory, and running processes; restoring creates a new sandbox. compatible runtime and resource settings are required, and application connections must reconnect. [21]

microsandbox cloud captures disk snapshots from stopped persistent sandboxes and restores them into new sandboxes. local full checkpoints and branching do not transfer to the cloud backend. check this before moving an agent that depends on hosted memory resume. [20][21]

03

sandboxing agents on employee devices

use Jamf or Intune to distribute microsandbox and a protected managed.json. supported releases apply administrator overrides to new backend instances, above user configuration and CLI or SDK choices. existing sessions keep their settings; local administrators can remove policy or replace the runtime. [22]

for disconnected environments, provision runtime dependencies, SDK packages, and approved images before the device goes offline. local execution needs no cloud account. [23]

common questions

is microsandbox an e2b alternative?

yes. both provide microvm sandboxes and managed cloud options. microsandbox also runs as an embedded local runtime on employee devices, with disk and full memory snapshots. [20][21][22][24]

is e2b open source?

yes. the e2b runtime is apache-2.0, including its orchestrator and service stack. [3] microsandbox's local runtime is also apache-2.0.

does microsandbox run offline?

yes, after provisioning runtime dependencies, SDK packages, and images. no cloud account is needed for local execution. [23]

does e2b support byoc or my own cloud?

yes. e2b documents enterprise byoc on aws and gcp, managed by e2b. self-hosting its open-source stack is separate. [2][3] microsandbox's employee-device deployment runs its local runtime under your device policy; it is not the same managed byoc offering. [22]

can e2b run locally?

yes. E2B Embed is an evaluation package for a single linux host with KVM, running a local service stack. [3] microsandbox embeds the runtime without that service stack and also supports macos and windows preview.

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