back to microsandbox

use case / coding agents

give the coding agent a computer. not your computer.

an agent that can run code can wreck a laptop. give it a disposable microvm instead. it edits, builds, and tests inside its own kernel, and your workstation stays yours.

dithered close-up of code on a laptop screen

01

you can't review code that doesn't exist yet

agents write and run code in the same minute. static review can't catch it, and prompt rules can't contain it. the reliable place to stop a bad command is a boundary the agent can't reach: the machine itself.

02

one small computer per task

create a sandbox in milliseconds, let the agent work, then throw the computer away. nothing survives unless you chose to keep it.

name the machine for the task, give it only the image and limits it needs, and remove it when the task ends.

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.

03

the network is part of the boundary

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.

so a curious agent can't wander your private network while it works.

04

credentials stay tied to approved destinations

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.

05

the same task can move to managed capacity

one sdk. one api. local or cloud is a config change, not a rewrite.

private beta. access is by request.

06

bring the tools your agent actually needs

choose an oci image, memory limit, and network policy for the task. microsandbox does not require a specific agent or editor.

the agent works with the compilers, package managers, and test tools in that image without gaining access to the developer's host.

how it works

one computer per coding task

01

choose the workspace

pick the oci image, resource limits, and network policy the task needs.

02

start one sandbox

the task gets its own microvm, guest kernel, process tree, memory, and filesystem.

03

let the agent work

editing, building, testing, and destructive commands all happen inside that machine.

04

remove the machine

when the task ends, remove the sandbox and start the next task clean.

see it work

one local task, then remove it

bash
msb run alpine --name agent-task --memory 1G --no-net -- sh -lc 'uname -a && id'
msb rm --force agent-task

know the limits

  • the runtime does not decide which repository paths an agent may edit; mount and copy only what the task needs.
  • a destination on your credential allow-list receives the real value and can misuse or reflect it.
  • managed capacity is invite-only today.

evaluate the alternatives

start locally in one command. no daemon, no root, no account.