Local microVMs target code you do not trust
Microsandbox creates a small virtual machine as a child process of the calling application. The README positions it for AI agents, user code, plugins, CI jobs, development environments, scrapers, and automation. There is no required control-plane server or long-running daemon. A TypeScript, Rust, Python, Go, or Ruby program can choose an OCI image, CPU count, memory limit, network policy, mounts, and command, then stop the sandbox when the work is finished.
The CLI mirrors common container habits: run a command, create a named sandbox, execute inside it, stop or start it, manage images, inspect configuration, and watch CPU, memory, or network metrics. OCI compatibility means familiar images can come from Docker Hub, GHCR, or another registry. Detached mode supports longer sessions, and named volumes cover state that should outlive one process. This is a usable application interface over virtualization, rather than a raw virtual-machine monitor.
Five SDKs avoid a permanent sandbox service
Published installation paths cover npm, Cargo, uv, Go modules, and Ruby. The same builder pattern appears across languages, while the first create() call downloads an uncached image. That makes local development simple once host virtualization works. It also means the first job depends on registry access, image size, cache capacity, and any policy around what registries developers may contact.
Network settings can limit allowed hosts and ports. The Ruby example also binds an environment secret to an approved host, with the design keeping the actual value on the host and substituting it into permitted outbound traffic. That is a useful model for an agent that needs one API without receiving the credential directly. It deserves adversarial testing because the entire reason to choose a microVM is that code inside it is untrusted.
What happened when we ran it
Our Rust sandbox installed 776 packages in 47 seconds at commit bb03217. The checkout contained 1,769 files, about 323,474 source lines, and occupied 120 MB. We found 10 CI workflow files, no Dockerfile, and no top-level tests directory. Installation completed, but source compilation did not reach a usable msb binary.
The build ran for 347 seconds before Cargo exited with code 101. rust-lld said it could not find the system library cap-ng, and the linker then failed while compiling microsandbox-cli. Tests failed after 110 seconds for the same missing cap-ng library while compiling the microsandbox-node library test. The log establishes one missing native dependency in our fresh Debian container. It does not show whether any test assertion would have failed after linking.
Hardware support is broad but conditional
Linux requires KVM, Windows requires Windows Hypervisor Platform, and the documented macOS route requires Apple Silicon. Those conditions exclude ordinary locked-down containers, many cloud guests without nested virtualization, and Intel Macs. The project calls itself cross-platform because it supports 3 host families, but each family has a different virtualization backend and failure surface. A successful laptop trial does not certify a CI runner or production host.
The README reports average boot time under 100 milliseconds from project benchmarks, but our lab did not measure VM startup. We also did not run hostile code, inspect device exposure, test network escapes, or validate secret isolation because the build stopped at linking. Teams choosing it for security should review the threat model, guest kernel, mount rules, egress enforcement, update process, and behavior when the host application crashes.
/tmp and late-added secrets have concrete beta gaps
Open issue 1377 documents an automatic RAM-backed /tmp for OCI sandboxes, sized at one quarter of guest memory and capped at 512 MiB. In the report, a 20 GiB root disk still leaves /tmp at 512 MiB. Build tools frequently stage files there, so a large configured root overlay may not prevent ENOSPC. A proposed pull request adds an opt-out, but the issue remained open when researched.
Issue 1422 covers a narrower security path in v0.6.10. Creating a sandbox with a source-backed secret enabled TLS interception, while adding the first secret later through modify() persisted the binding without enabling interception. The placeholder then reached the upstream service unchanged. The latest release was v0.6.15, yet the issue was still open, so confirm the behavior in the exact SDK and runtime pair you plan to ship.
August releases show speed and churn
GitHub recorded 7,945 stars, 75 combined issues and pull requests, and a push on August 27, 2026. Version 0.6.15 was released on August 24 with Windows DNS work, read-only mount handling, directory ownership fallback, and packaging updates. Current pull requests cover network observers, proxy support, mount deny lists, lifecycle APIs, and runtime bootstrap. This is active engineering around areas that affect isolation and operations.
The same activity also supports the beta warning. Microsandbox is moving across CLI behavior, SDK lifecycle, networking, filesystems, and platform backends at once. It is worth prototyping when an embedded local VM is a better fit than a Kubernetes sandbox service. Pin CLI and SDK versions together, test the host you will deploy, and keep a path to disable execution if the isolation assumptions fail review.