Local microVMs need a host-level evaluation
Microsandbox puts an application interface around local microVMs for untrusted workloads. The useful question is whether that model fits your host and workload. Our recorded run establishes a source-build obstacle in one environment; it does not establish whether a packaged installation works or whether its isolation meets your requirements.
The README describes microVMs created as child processes, without a required setup server or long-running daemon. It documents OCI images, CLI lifecycle commands, snapshots, live forks and SDK examples in TypeScript, Rust, Python, Go and Ruby. These are documented capabilities, not features exercised by our run.
What our recorded run establishes
Our stored run began on 10 October 2026 at 03:12:29.379 UTC, using commit 245701ad43fdae2785a9246f9046cf2f897e7a24. Its configuration recorded 3 CPUs, 12 GB memory and image lab-rust:1. That label does not establish the actual Rust or Python runtime version.
| Stage | Recorded result | What it establishes |
|---|---|---|
| Dependency setup | Exit 0 in 17 seconds; parser count 788 | The setup step completed and its tail shows dependency downloads. It does not prove CLI installation. |
| Build command | Exit 101 after 621 seconds | Linking microsandbox-py (lib) failed because the linker could not find -lpython3.11. |
| Test command | Exit 101 after 349 seconds | Linking microsandbox-py (lib test) failed with the same missing library. The supplied output establishes no failed assertion count. |
| Installed binary and VM workload | No supplied result | CLI operation, guest startup and workload behavior remain unverified by this run. |
The checkout summary recorded 2,454 files, approximately 548,279 source lines, 131.8 MB and 13 CI workflow files. Detection found no Dockerfile or top-level tests directory. That directory signal does not mean the repository has no tests. The stored test count and audit result are null; there is no supported passing-test total, advisory total or audited-package coverage to report.
Both unsuccessful commands reached a Python binding linker error. The evidence supports checking the required Python 3.11 link library and build configuration before retrying this source path. It does not show that packaged Microsandbox is broken, that every build target failed, or that test assertions would fail after linking. No new execution was performed for this review.
Packaged setup is a separate path
The README lists CLI installers and package-manager routes, including npm i -g microsandbox, followed by msb run ubuntu. The existing page's npx microsandbox run debian invocation was not exercised in our recorded run and is not the installation route shown in the supplied README. Treat packaged installation and source compilation as separate checks.
The documented host requirements are Apple Silicon on macOS, KVM enabled on Linux and WHP enabled on Windows. Confirm those requirements on the actual deployment host before evaluating workloads. The README also says the first create() pulls an uncached image, while later runs reuse the cache. Dependency download time in our source run is not a measurement of that image pull or of VM startup.
Agent integration has more than one documented route. The project supplies Agent Skills and an MCP server; an application can also use its SDK. A separate MCP server is therefore required for the documented MCP integration, not for every agent use case.
Startup and secret claims remain untested here
The README claims average boot times under 100 milliseconds and specifies that boot time refers to guest boot on an M1 machine. That scope excludes a general promise about cold image downloads, complete job startup or every supported host. Our run measured none of those workloads.
The README's Ruby example configures allowed hosts, ports and a host-bound secret. Its stronger secret-safety language is a project claim. Our record contains no secret-isolation assessment, hostile-code workload or network-escape test. Hardware virtualization alone does not establish how a particular application's mounts, credentials and outbound access behave.
Two issue reports need different treatment
Issue 1377 remains open in the supplied extract. Its reporter reproduced an automatic RAM-backed /tmp on msb 0.6.8, on a macOS arm64 host with the libkrun backend, and cited unchanged logic in v0.6.9. The reported default is one quarter of guest memory, clamped between 1 and 512 MiB unless another mount targets /tmp. The reproduction shows a 20 GiB root-disk request alongside a 512 MiB /tmp.
That report is a reason to inspect scratch capacity for your workload. It is not a measurement from our October run or proof that the same default persists in every later version. Keep root-disk capacity and /tmp capacity as separate deployment checks.
Issue 1422 reported that adding the first source-backed secret through modify().secret(...).restart().apply() persisted the binding without enabling TLS interception in v0.6.10. The reported consequence was an unchanged placeholder reaching the upstream API, not disclosure of the host secret. The supplied issue history says it was closed as completed in #1432 on 21 September 2026. It should not be listed as an open defect. The extract does not identify the first packaged release containing the fix, and our run did not verify that path.
Version evidence and alternatives
The supplied v0.6.15 release page lists directory-mount ownership fallback, Windows DNS handling, read-only mount handling and Windows file-copy changes. Its release commit is bb03217. Our measured commit is 245701a; these are different revisions. The release extract does not establish that v0.6.15 is the latest release at the time of this review.
For a lower-level Linux VMM, Firecracker uses KVM and exposes an API for configuring microVMs. Its own documentation makes overall security conditional on a well-configured Linux host. For integration through a container manager, Kata Containers supplies a containerd shimv2 runtime and documents Kubernetes deployment. These are architecture choices supported by their primary-source extracts, not measured performance comparisons.
How to read the scores
The scores are editorial assessments of the supplied evidence. They do not measure security, adoption or compatibility. For each category, 1 means substantial obstacles or little usable evidence, 2 means limited evidence or unresolved constraints, 3 means a documented path with material validation gaps, 4 requires strong documentation or verification for the relevant scope, and 5 requires broad corroboration with few material gaps. Unknowns prevent a high rating; they do not prove poor product quality.
Setup receives 2/5 because our source path stopped at linking and packaged setup was not verified. Documentation receives 3/5 because the README provides host requirements, installation routes and examples, while this review did not validate the wider documentation or every example. Community receives 2/5 because the supplied material shows issue handling and a README showcase but does not establish adoption or support responsiveness. Maturity receives 2/5 because the project explicitly warns of beta changes and our run supplies no runtime validation.
For an evaluation, choose the documented installation route on your intended host, record the CLI and SDK versions, confirm an installed binary can execute a small workload, and inspect the storage and network settings that workload needs. Those results would answer the runtime questions this source-build record leaves open.