back to microsandbox

compare

microsandboxvsdocker

pick docker to package and ship applications you trust. [1] pick microsandbox to give untrusted code its own kernel.

docker and microsandbox can start from the same oci image, but they draw the boundary in different places. docker engine runs containers through a long-running daemon, and its isolation depends on host-kernel namespaces and control groups. [1][3] microsandbox runs each workload in a hardware-isolated microvm with its own guest kernel.

that makes docker the natural fit for packaging services and joining the container ecosystem you already operate. microsandbox is for the moment an agent, user, or third party can choose the code that runs, and a shared host kernel is not the boundary you want.

the image does not need a rewrite when the boundary changes. microsandbox keeps the oci workflow, then adds an embeddable sdk, destination-bound credentials, and a host-enforced network floor. private beta. access is by request.

microsandbox
local + cloud
docker
container runtime [1]
isolation model
hardware microvm · separate kernel
linux containers · host-kernel namespaces and control groups [3]
daemon required
none, runs in your process
dockerd · long-running background service [1]
boot time
320 ms median · microsandbox 0.4.5
463 ms median · same harness [2]
container escape risk
hardware microvm boundary between guest and host
container isolation can be incomplete with kernel vulnerabilities or unsafe capabilities and mounts [3]
image format
any oci image
any oci image [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.
environment variables or mounted files are visible in the container [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.
container networking primitives that you assemble into policy [1]
host platforms
macOS · Linux · Windows (WHP, preview)
linux native; docker desktop uses a linux vm on macos and windows [1]
designed for
ai agents · untrusted code execution
application packaging and deployment [1]
ecosystem fit
runs oci images without a docker daemon
docker tooling, registries, compose, and kubernetes workflows [1]
cloud access
local runtime · private beta. access is by request.
self-managed or used through a container platform [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 docker

choose docker when

  • you are packaging a service for deployment. [1]
  • the docker, compose, or kubernetes workflow is the product requirement. [1]
  • you trust the code inside the container and want broad ecosystem compatibility. [1]
pick microsandbox

choose microsandbox when

  • an agent, user, or third party can choose the code that runs.
  • you want an own-kernel boundary without giving up oci images.
  • you need destination-bound credentials and a host-enforced network floor.
  • you want a daemon-free sdk embedded in your application.

01

what microsandbox adds

microsandbox is not a replacement for docker as an application delivery system. keep docker where the job is building, shipping, and operating trusted services. use microsandbox where the job is executing code whose author and intent are outside your trust boundary.

the handoff can stay image-based. pull the same oci artifact, create a sandbox through the sdk, and apply the credential and network policy at the host boundary. one sdk. one api. local or cloud is a config change, not a rewrite.

read the benchmark harness

common questions

is microsandbox a docker alternative?

for untrusted code execution, yes. both can run oci images, but docker is a container engine for application packaging while microsandbox gives each workload its own guest kernel.

does docker isolate untrusted code?

docker isolates processes with host-kernel namespaces and control groups. its security guide says kernel vulnerabilities or unsafe capabilities and mounts can make that isolation incomplete. [3] decide whether that boundary matches the code you plan to run.

can microsandbox run docker images?

microsandbox runs oci images from standard registries. you keep the image workflow without running dockerd inside or beside your application.

when should i keep docker?

keep docker for packaging trusted applications, compose workflows, and container platforms. [1] add microsandbox where generated or user-supplied code needs a stronger boundary.

run it locally.

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

run it locally