pick docker sandboxes when the agent needs its own docker daemon. [1] pick microsandbox when the sandbox runtime belongs inside your product.
docker sandboxes gives each coding agent a microvm, a private docker daemon, a filesystem, and a network. [1] that is a direct fit when the agent's job is building containers or using a supported coding-agent workflow.
microsandbox also gives untrusted work its own kernel, but the integration shape is different. your application embeds the runtime through an sdk or cli. there is no bundled docker daemon and no account is needed for local execution.
both products treat credentials as a host-side concern. docker documents proxy substitution for declared destinations. [2] microsandbox uses the canonical destination-bound model and keeps its caveat adjacent in the table below. private beta. access is by request.
microsandbox
local + cloud
docker sandboxes
local microvms for coding agents [1]
isolation
hardware-isolated microvm · its own kernel
microvm per sandbox [1]
container workflows
oci images are the input; no docker daemon is bundled
a private docker daemon is included in every sandbox [1]
host platforms
macOS · Linux · Windows (WHP, preview)
macos, windows, and supported linux hosts [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.
host-side proxy substitutes stored credentials for declared destinations [2]
programming model
sdk and cli · embeds in your process
sbx cli and supported agent integrations [1]
workspace
sandbox filesystem created through your application
persistent workspace attached to the coding agent [1]
license and governance
apache 2.0
sbx cli is free to use; organization governance is a paid subscription [1]
pick docker sandboxes
choose docker sandboxes when
the agent needs a private docker daemon to build or run containers. [1]
you want docker's supported agent integrations and sbx cli workflow. [1]
you need its documented host coverage across macos, windows, and supported linux. [1]
pick microsandbox
choose microsandbox when
your product creates and controls the sandbox through an embedded sdk.
you want local execution with no account or background daemon.
one sdk. one api. local or cloud is a config change, not a rewrite.
contact us to evaluate running microsandbox inside your own environment.
01
moving from docker sandboxes
the agent-workspace model carries over, but the control point moves into your application. replace the sbx cli launch with an sdk call that creates a microsandbox from an oci image, runs the command, reads the result, and removes the sandbox.
keep docker sandboxes for workflows that require docker-in-docker. microsandbox accepts oci images as input, but it does not promise a private docker daemon inside every sandbox.
common questions
what is the difference between docker sandboxes and microsandbox?
docker sandboxes centers a coding agent inside a microvm with its own docker daemon. [1] microsandbox centers an embeddable sdk that your application uses to create own-kernel sandboxes.
does docker sandboxes use a microvm?
yes. docker documents a microvm per sandbox, with its own docker daemon, filesystem, and network. [1]
does docker sandboxes keep credentials outside the sandbox?
for declared services, docker documents a host-side proxy that substitutes credentials into matching outbound requests. [2] its registry-credential modes have separate behavior, so review that page for the exact scope.
can microsandbox run docker images?
microsandbox runs standard oci images. it does not bundle a private docker daemon, so choose docker sandboxes when building containers inside the sandbox is essential.