Microsandbox: Virtual Machines that feel and perform like containers

Original Article ↗ Hacker News Discussion ↗

Purpose and Main Use Cases

  • Designed as “Docker for microVMs”: easy creation and management of lightweight VMs with container-like UX.
  • Primary target: running untrusted or semi‑trusted code (e.g., AI agents, LLM tools, testing networks, user-submitted JS) with stronger isolation than containers.
  • Intended both for local development and self‑hosted backend infrastructure, including long‑lived sandboxes and pools of pre‑warmed VMs.

Architecture, Performance, and Capabilities

  • Uses libkrun underneath (Firecracker-like, KVM/Hypervisor.framework–based microVMs) with virtio-fs and overlayfs for copy‑on‑write filesystems.
  • Startup is reported in the low hundreds of milliseconds; runtime overhead mainly around I/O and filesystem (overlayfs) and depends on libkrun improvements.
  • Full Linux VMs: any Linux executable should work; Python/Node/JVM etc. are just prebuilt environments, not limits.
  • GUI support and VNC/Wayland-style passthrough are considered possible but not yet implemented.

Networking and Data Access

  • Networking works today but is acknowledged as immature; uses libkrun’s default TSI and may feel inflexible.
  • Planned: alternative user‑space networking stack, better documentation, and examples.
  • Sandboxes can access the network and listen on ports; scope settings can restrict access (e.g., prevent local network access), but docs are currently thin.
  • Current data exchange: via an SDK and server executing commands and returning results; file streaming is planned.

Platform Support and Ecosystem

  • Supports Linux and macOS (via Hypervisor.framework); Windows support is “work in progress,” leading some to question claims of full cross‑platform parity.
  • Does not yet expose an OCI runtime interface like runc/crun, though OCI images can be used (e.g., from Docker Hub).

Comparisons and Alternatives

  • Compared against Docker, Kata Containers, Cloud Hypervisor, Firecracker, gVisor, native containers, Orbstack, and OS‑level sandboxes (macOS, Windows Sandbox).
  • Positioning: more opinionated, easier UX for AI builders and local/self‑hosted use than Kata/Firecracker; unlike cloud services (E2B, Daytona), it is self‑hosted only.
  • Acknowledged that containers are easier to run everywhere (no nested virt requirement), but VMs offer stronger isolation.

Security and Critiques

  • Marketed as a secure sandbox, but users point out VM escapes exist; project owner agrees some language (e.g., “bullet proof”) should be toned down.
  • Broader thread debate:
    • Containers on a shared kernel are seen as fundamentally weaker for hostile multitenant workloads.
    • VMs reduce attack surface by moving syscall handling into a guest kernel, but the VMM/hypervisor also becomes a critical boundary.
    • Some argue real assurance would require systematic exploit testing and formal threat modeling; others stress defense‑in‑depth and smaller, hardened VMMs.

Developer Experience and Limitations

  • Sandboxfile YAML used to declare resources and config; multi‑stage builds are work in progress.
  • SDKs exist for many languages but some are currently just generated “hello world” stubs.
  • Users request: clearer contributor guides for new languages, better networking examples, instructions for customizing images with common libraries, Terraform/Pulumi integration, and non–“curl | bash” installation.

Miscellaneous

  • Thread veers into a long side discussion about why traditional VMs (e.g., VirtualBox on Windows) are slow to start; consensus is that the delay is largely implementation‑specific rather than inherent to virtualization, and that microVMs/unikernels can boot in milliseconds.