smolvm v1.16.2 puts an OCI image behind its own kernel
smolvm takes an image you might otherwise run as a container and boots it as a Linux virtual machine. Each workload gets a guest kernel through Hypervisor.framework on macOS, KVM on Linux, or Windows Hypervisor Platform. The CLI still feels container-like: run an ephemeral command, open a shell, create a persistent machine, mount a directory, forward a port, or pull an image from an OCI registry. Docker itself is not required to boot a registry image.
A Smolfile records the image, CPU and memory allocation, network policy, mounts, ports, environment, startup commands, and health behavior in TOML. Unknown keys fail instead of being ignored. The default machine asks for 4 virtual CPUs and 8 GiB of RAM, with memory returned through ballooning when the guest does not use it. Those defaults are generous for a small utility, so shared developer machines should set explicit limits rather than copy the first example unchanged.
Branches preserve running memory and disk state
A branch is a copy-on-write child of a running machine, including its processes, memory, and disk. That is different from creating another container from the same static image. A prepared workload can call smolvm-branch-ready, pause at a known point, and then fan out children that continue from that state. Durable checkpoints save the same kind of state for later restoration, while .smolmachine files package a stopped environment for an OCI registry.
This model fits coding agents, test workers, and workloads with an expensive warm-up. It also increases the state you must manage. A branchable process, its checkpoint files, image cache, writable storage, and any forwarded capability all become part of the run. Release v1.16.2 devotes most of its notes to checkpoint reuse, verification, concurrent save and restore, cache recency, and branch cleanup. That concentration tells you where the hard engineering sits.
What happened when we ran it
Our fresh Rust container installed 338 packages in 46 seconds. The source build then completed successfully in 272 seconds. cargo test finished in 159 seconds with 2,200 passed and 0 failed. Build and test took 431 seconds together, while the entire measured sequence took 477 seconds. Nothing in those steps required a secret, and no failure was hidden behind a timeout.
The checkout was compact on disk but not small in code: 523 files, about 239,070 source lines, and 10.1 MB before dependencies. We found 7 CI workflow files, a dedicated tests directory, and no Dockerfile. Those are repository signals, not a runtime benchmark. Our unprivileged sandbox result proves the Rust code built and its available tests passed; it does not prove that a particular laptop exposes KVM, WHP, a correctly entitled macOS hypervisor binary, or a usable GPU path.
The VM boundary does not secure the whole host
Networking starts disabled, and an allow-list can restrict destinations after --net is enabled. Host directories appear in the guest only when mounted, while SSH agent forwarding avoids copying private keys into the VM. Still, the forwarded socket lets the guest request signatures. The README correctly treats mounts, ports, host services, network access, and the SSH agent as added authority. A VM cannot protect a secret that you deliberately hand through its boundary.
The local product is also not presented as a hardened multi-user control plane. The invoking host account, host OS, hypervisor, libkrun, and smolvm remain trusted. CUDA remoting uses host processes and a shared GPU, so its isolation is process-level rather than a separate hardware boundary. Release archives publish SHA-256 checksums, but they are not signed and have no provenance attestations. The installer can proceed when it cannot download the checksum file, which may conflict with a strict workstation policy.
Windows, macOS, and Kubernetes still differ
Windows x86_64 can run Linux guests when WHP is enabled, but GPU acceleration, machine branching, and checkpoints are unavailable there. Open issue #965 reports that release 1.8.2 could fail with exit 127 when a non-elevated extraction lost Linux symlinks; Developer Mode or an administrator shell was the reported workaround. That issue predates v1.16.2, so test the current release on the actual Windows policy rather than treating the older report as a present diagnosis.
macOS has different rough edges. Issue #1192 reports that combining --oci-cache with a mounted volume failed to boot on v1.14.1 and v1.14.2. Issue #1207 describes a VM disappearing during a sustained Kubernetes workload on v1.13.1 and v1.14.3 without an error or exit reason. Kubernetes users also have issue #889, which reports that the containerd shim cannot start pods on containerd 2.3 or newer. All three remain open, so platform-specific smoke and soak tests belong before rollout.
September activity is high and the queue is busy
GitHub recorded 6,173 stars, 80 open issues and pull requests, and a push on September 20, 2026. The open total split into 31 issues and 49 pull requests when fetched. Release v1.16.2 had shipped two days earlier. That is a busy project with code moving through review, not a finished appliance whose behavior can be inferred from one version number.
The clean 2,200-test run makes smolvm easy to justify as a trial. The deciding work happens after compilation: confirm the host virtualization backend, run the exact mount and network policy, interrupt jobs to check cleanup, and soak the workload long enough to catch process loss. For a local coding-agent sandbox, those checks are reasonable. For a shared service with hostile tenants, smolvm itself says the host needs another isolation layer.