smolvm
microvmmicrovm-toolopen sourceA cross-platform CLI that runs OCI images as libkrun with secure defaults, network off, mounts opt-in, packable into portable .smolmachine files.
smolvm is a cross-platform CLI (macOS/Linux/Windows) that runs OCI images as libkrun , each with its own guest kernel on HVF, KVM, or WHP, and can pack a running VM's state into a single portable .smolmachine file. A code audit found it does implement a genuine second wall, a seccomp allowlist, Landlock, a per-VM uid drop, cgroups, and no_new_privs, but that wall is fully wired only in the privileged multi-tenant serve path on x86_64 Linux. The CLI machine run leaves seccomp and Landlock default-off, pack run applies none of it, and on macOS the hardening is stubbed to no-ops. So the host-side confinement you actually get depends on the launch path.
Strengths
- Cross-platform microVMs from OCI images (macOS/Linux/Windows) via libkrun
- network off by default; volume mounts opt-in
- Portable .smolmachine artifacts capture full VM state
Limitations
- Host-side confinement depends on launch path, CLI `machine run` and `pack run` are unhardened
- The seccomp/Landlock/uid-drop second wall is fully wired only in the privileged multi-tenant `serve` path on x86_64 Linux
- On macOS the second-wall hardening is stubbed to no-ops
Files & editor
desktop-remoteFiles live in the microVM; Remote-SSH in or edit inside. Volume mounts are opt-in.
How you get your project into the environment and edit it. Shared-kernel routes bind-mount host files for your desktop editor; own-kernel routes keep files in the guest, so a desktop editor attaches over remote, or you edit inside. Mounts and remote editing.
VMM second wall
VMM second wall: partialseccomp, Landlock, and per-VM uid drop, but only fully wired in the privileged serve path.
The second wall confines the VMM itself, so a compromised device backend can't own the host. It's separate from the hardware boundary every microVM already has. The two walls, explained.