back to microsandbox

compare

microsandboxvsfirecracker

pick firecracker when you want the low-level vmm and will build the platform around it. [1] pick microsandbox when you want an agent sandbox runtime with the sdk and policy already attached.

firecracker and microsandbox both put workloads in microvms with their own guest kernels. firecracker is the virtual machine monitor used for aws lambda and fargate workloads, with a linux and kvm operating model. [1] it gives an infrastructure team direct control over a deliberately narrow device and api surface.

microsandbox starts one level higher. it uses an embeddable vmm through libkrun, then supplies oci image handling, sandbox lifecycle, language sdks, destination-bound credentials, and network policy as one runtime.

the choice is not which one is a real vm. both are. choose firecracker when assembling the surrounding system is the work you intend to own. choose microsandbox when the application needs to create an agent computer through an sdk.

microsandbox
local + cloud
firecracker
open-source microvm monitor [1]
what it is
complete agent sandbox runtime
virtual machine monitor [1]
maintainer
super rad company
amazon web services [1]
host platform
macOS · Linux · Windows (WHP, preview)
linux with kvm [1]
underlying vmm
libkrun · embeddable and cross-platform
firecracker itself [1]
boot time
320 ms median · microsandbox 0.4.5
808 ms median · same end-to-end harness [2]
programming model
embed an sdk · sandbox per call
vmm api · build the surrounding runtime [1]
oci image support
native · pull from a standard registry
supply a guest kernel and root filesystem [1]
sdks
rust · typescript · python · go · cli
vmm api rather than an agent sandbox sdk [1]
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.
not supplied by the vmm [1]
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.
tap interfaces; the platform supplies policy [1]
snapshots
snapshots capture the disk state of a stopped sandbox.
snapshot and restore primitives for the platform to integrate [1]
operational control
runtime conventions are already chosen
direct control of kernel, rootfs, devices, api, and lifecycle [1]
license
apache 2.0
apache 2.0 [1]

measured release: microsandbox 0.4.5, inferred from benchmark chronology because the raw artifact does not record the binary version; owner confirmation is pending. median of 10 measured runs after 2 warmups; end-to-end wall time from cli invocation to process exit; pre-pulled alpine userspace; bare-metal linux x86_64 on a gcp c3-standard-192-metal host (intel sapphire rapids, ubuntu 24.04, /dev/kvm). microsandbox: 320 ms; docker: 463 ms; firecracker: 808 ms. firecracker used the same alpine userspace and harness; these numbers do not use firecracker's narrower kernel-to-userspace boundary. full harness and raw results.

pick firecracker

choose firecracker when

  • you are building a linux microvm platform and want direct vmm control. [1]
  • you intend to own kernels, root filesystems, networking, lifecycle, and fleet operations. [1]
  • a narrow, infrastructure-level api is the interface you want. [1]
pick microsandbox

choose microsandbox when

  • your application needs a sandbox sdk instead of a vmm api.
  • you want oci images, stopped-sandbox disk snapshots, credentials, and network policy in one runtime.
  • the runtime must also work on macos or windows preview.
  • one sdk. one api. local or cloud is a config change, not a rewrite.

01

what microsandbox adds

firecracker is the right starting point when the platform around the microvm is your differentiator. its api exposes the primitive and leaves the product decisions to you. [1]

microsandbox makes those product decisions explicit: oci images are the input, an sdk owns lifecycle, and host-side policy sits next to the boundary. that trades low-level freedom for a runtime an agent application can call directly.

read the benchmark harness

common questions

does microsandbox use firecracker?

no. microsandbox uses libkrun as its embeddable vmm. both approaches create microvms with their own guest kernels.

is microsandbox a firecracker alternative?

not at the same layer. firecracker is a vmm for teams building infrastructure. [1] microsandbox is a complete sandbox runtime for applications that need to execute untrusted code.

is firecracker open source?

yes. firecracker is published under apache 2.0. [1] microsandbox is also apache 2.0.

can firecracker run oci images directly?

firecracker expects a guest kernel and root filesystem. [1] the image conversion and lifecycle around them belong to the platform you build. microsandbox accepts oci images as a runtime input.

which one runs on a developer mac?

microsandbox runs on macos. firecracker documents linux hosts with kvm. [1]

run it locally.

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

run it locally