Cloud Parts

smolvm

A young, embeddable microVM runtime that boots any OCI image as a real VM on a Mac, Linux or Windows laptop, and can save, branch and pack running machines.

What it is
MicroVMs
Type
Open source
Made by
smol machines
License
Apache 2.0 (the hosted smol cloud is a paid service)
Facts checked
6 October 2026
Website Source code

What it is

smolvm is a command-line tool and Rust library that runs each workload in its own small virtual machine with its own Linux kernel. It uses the host’s built-in hypervisor (Hypervisor.framework on macOS, KVM on Linux, the Windows Hypervisor Platform on Windows), with the libkrun library as the virtual machine monitor and a guest kernel from libkrunfw. libkrun is linked into the smolvm binary and its SDKs, so there is no daemon. It boots ordinary OCI images, from Docker Hub or a local docker save, without a Docker daemon. Machines default to 4 vCPUs and 8 GiB, but memory is returned through a virtio balloon, so the host commits only what the guest uses. Networking is off unless you ask for it, egress can be limited to named hosts, and secrets can be substituted on the way out so the guest never reads them.

What sets it apart is moving machines around. A running machine can be checkpointed (memory, CPU state and disks) and restored later, even from an arm64 Mac onto arm64 Linux, or branched into copy-on-write copies that keep running from the same point. smolvm pack turns a machine into a single .smolmachine file that you push to an OCI registry or run as a self-contained executable, which the project says boots in under 200 ms. The same company sells smol cloud, a hosted service that runs the same machines (from $0.04 per machine-hour plus usage). For Kubernetes, smolvm ships an experimental containerd shim v2 so a RuntimeClass can run each pod as a microVM, and it can host a whole k3s cluster (through k3d) inside one VM. The project is very new: the repository was created in December 2025, reached 1.0 in June 2026, and shipped seven releases on October 4 and 5, 2026 alone.

Why teams pick it

  • Native on macOS (Apple Silicon), Linux and Windows, with the same OCI images and no daemon to install
  • Checkpoint, branch and pack running machines, which suits agent sandboxes and forking prepared environments
  • Embeddable: SDKs for TypeScript, Python and Rust drive local machines or smol cloud through one Machine API
  • Secure defaults: no network unless enabled, per-host egress allow lists and credential substitution

Watch out for

  • Very young and mostly one author’s work, with releases sometimes several times a day; expect changes and rough edges
  • The Kubernetes shim is experimental: validated with k3s, it can’t start sandboxes on containerd 2.3 or later, and nodes that enforce AppArmor need a per-pod opt-out
  • No GPU passthrough: GPUs reach the guest through Vulkan (virtio-gpu) or CUDA API remoting, and not at all on Windows; Intel Macs are untested
  • Boot-time figures and comparisons come from the vendor, and the name collides with unrelated projects called SmolVM

Alternatives

What all microvms have in common →
FirecrackerOpen sourceThe open-source microVM monitor AWS built for Lambda: a full VM boundary that boots in under 125 ms.Kata ContainersOpen sourceA container runtime that starts each pod inside its own lightweight VM, so Kubernetes and Docker keep working but every pod gets its own kernel.

How it fits with other technologies

Run, branch and pack a machine · bash

smolvm machine run --net --image alpine -- uname -a      # one-off VM, removed on exit

smolvm machine create --net --name agent --image alpine
smolvm machine start --name agent --branchable
smolvm machine branch --from agent --name try-1          # live copy-on-write child

smolvm machine stop --name agent
smolvm pack create --from-vm agent -o agent              # writes agent.smolmachine
smolvm pack push --file agent.smolmachine ghcr.io/you/agent:v1

See it in a real stack

No architecture uses smolvm yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

ArticleKubernetes in a microVMsmol machines docsThe vendor’s own guide to two ways of combining Kubernetes with microVMs: a containerd shim and RuntimeClass that start each pod as its own VM (marked experimental, with its known blockers listed), or a whole k3s cluster, through k3d, inside one VM. Useful for the concrete details, such as per-pod overhead, the /dev/kmsg device the kubelet needs and why Docker’s storage must sit on ext4, but written to sell smolvm.
All resources →
Where it came from2025–2026

smolvm’s pitch is letting AI agents run code safely on a developer’s own machine. The usual sandbox, a container, shares the host’s kernel. On a Mac it is worse: Docker Desktop runs every container inside one shared Linux VM. MicroVM monitors such as Firecracker gave each workload its own kernel but needed Linux with KVM and didn’t run natively on macOS.

smolvm, started by BinBin He (@BinSquare on GitHub), who still writes most of its commits, was built on libkrun, an existing open-source library that embeds a minimal monitor in a program on both KVM and macOS. The repository was created in December 2025, v0.1.0 followed in January 2026 and v1.0.0 in June 2026, alongside a hosted service, smol cloud. The project frames its goal as “time to ready” rather than boot time alone: the whole wait before useful work, including image pulls and dependency installs, which prepared .smolmachine artifacts and branches are meant to skip.

In July 2026 version 1.6.0 added a containerd shim for Kubernetes, and a release that month made a full k3d cluster start inside one machine once the guest exposed /dev/kmsg, the kernel log device the kubelet refuses to start without.

Why it’s built this way

A library, not a daemon
Linking libkrun into the binary and SDKs means an application can start VMs in-process, with nothing to install or keep running on the host.
OCI images as the input
Developers already build container images, so any image from a registry or a local build boots as a VM without a new packaging format to learn.
Branch and checkpoint running machines
For agents and reinforcement-learning rollouts, forking a prepared, running machine is cheaper than booting and installing from scratch each time.

Timeline

  1. 2025

    Repository created in December

  2. 2026

    v0.1.0 in January; v1.0.0 in June

  3. 2026

    v1.6.0 adds an experimental containerd shim for Kubernetes (July)

Sources9 · facts checked 6 October 2026

Improve this page on GitHub