smolvm

Branchable microVMs for AI agents. Embed lightweight virtual machines into your software, portable dev environments, and local sandboxing.

Install

brew install smol-machines/tap/smolvm                  # macOS (Homebrew)
curl -sSL https://smolmachines.com/install.sh | bash   # macOS + Linux

Windows: unzip the windows-x86_64 release and run smolvm.exe (needs the Windows Hypervisor Platform). Coding agents: run smolvm --help after installing to discover every command.

Quick Start

smolvm machine run --net --image alpine -- uname -a          # one-off VM, removed on exit
smolvm machine run --net -it --image alpine -- /bin/sh       # interactive shell

Local

Real VMs with their own kernel, free on your laptop or your own servers. They boot in under a second, and memory is elastic, so the host only commits what the guest uses. Machines persist across restarts, and any OCI image works, including ones you build locally.

smolvm machine create --net --name dev && smolvm machine start --name dev
smolvm machine exec --name dev -- apk add git
docker save myapp | smolvm machine run --image - -- ./app    # local image, no registry

Declare a machine in a Smolfile: image, resources, ports, mounts and network policy in one checked-in file.

Embeddable

Drive machines from your own code with one Machine API. The SDKs run in your process with no daemon, locally or on smol cloud.

npm install smolmachines     # Node / TypeScript
pip install smolmachines     # Python
cargo add smolmachines       # Rust

import { Machine } from 'smolmachines';

const m = await Machine.create({ image: 'python:3.12-alpine', network: true });
const r = await m.exec(['python3', '-c', 'print(2 ** 10)']);
console.log(r.stdout); // 1024
await m.delete();

Source and docs: smol-machines/smol · smolmachines.com/docs/sdk

Branchable

Save a running machine mid-execution, rewind it, or branch it into copies that keep running from the same point. Checkpoints capture RAM, CPU state and disks; branches are copy-on-write children of a live machine.

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 checkpoint --name agent -o agent.checkpoint        # save it, processes and all
smolvm machine create --name agent2 --from agent.checkpoint       # resume later or elsewhere

Rewind to an earlier generation with --from <checkpoint> --at '~N' (see machine checkpoint-log), and stop without losing execution with pause and resume. A checkpoint taken on an arm64 Mac resumes on arm64 Linux, see Moving a running machine from a Mac to Linux. More in Branching and incremental checkpoints.

Portable

Pack a machine, however you set it up, into a single .smolmachine file. Push it to any OCI registry, or run it as a self-contained executable that boots in under 200 ms with nothing to install.

smolvm machine stop --name dev && smolvm pack create --from-vm dev -o dev
smolvm pack push --file dev.smolmachine ghcr.io/you/dev:v1
smolvm pack create --image python:3.12-alpine -o ./python312
./python312 run -- python3 --version

Checkpoints are portable too: restore one on another host or on smol cloud.

Safe

Each workload gets a hardware-isolated VM with its own kernel. Networking is off by default, egress can be limited to named hosts, and code can use a credential without ever reading it.

Safety is a shared responsibility. smolvm provides the boundary: a separate VM and kernel for every workload, with nothing reaching the host unless you allow it. You decide what crosses that boundary. Every folder you mount, port you open, host you allow, and secret or SSH agent you forward becomes something the workload can use, so give an untrusted workload only what it needs.

smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -qO- https://google.com   # blocked
smolvm machine run --net --image alpine --allow-host-pattern registry.npmjs.org -- wget -qO- https://registry.npmjs.org   # exact host only
NOTION_API_KEY=secret_… smolvm machine run --net --image alpine \
  --credential notion=NOTION_API_KEY@api.notion.com -- sh -c 'echo $NOTION_API_KEY'   # a placeholder

See credential substitution and the security model. Use --allow-host-pattern '*.example.com' to allow subdomains only. The older --allow-host example.com continues to allow both the apex and subdomains. A stopped machine's allow list can be changed with smolvm machine update (--allow-host, --allow-host-pattern, --allow-cidr and their --remove- forms).

How It Works

Each workload runs in a hardware-virtualized VM with its own guest kernel on Hypervisor.framework (macOS), KVM (Linux), or the Windows Hypervisor Platform (Windows). libkrun is the VMM and libkrunfw supplies the guest kernel. Images use the OCI format, so anything on Docker Hub, ghcr.io or another registry boots as a microVM, with no Docker daemon.

Defaults: 4 vCPUs, 8 GiB RAM. Memory is elastic via virtio balloon and idle vCPUs sleep in the hypervisor, so over-provisioning costs almost nothing. Override with --cpus and --mem.

Comparison

	smolvm	Containers	Colima	QEMU	Firecracker	Kata
Workload boundary	VM + guest kernel	Namespace + shared kernel	Namespace inside shared VM	VM + guest kernel	VM + guest kernel	VM per container
Boot time	<200ms	~100ms	~seconds	~15-30s	<125ms	~500ms
Architecture	Library (libkrun)	Daemon	Daemon (in VM)	Process	Process	Runtime stack
Per-workload VMs	Yes	No	No (shared)	Yes	Yes	Yes
macOS native	Yes	Via Docker VM	Yes (krunkit)	Yes	No	No
Embeddable SDK	Yes	No	No	No	No	No
Portable artifacts	.smolmachine	Images (need daemon)	No	No	No	No

Platform Support

Host	Guest	Requirements
macOS Apple Silicon	arm64 Linux	macOS 11+
macOS Intel	x86_64 Linux	macOS 11+ (untested)
Linux x86_64	x86_64 Linux	KVM (/dev/kvm)
Linux aarch64	aarch64 Linux	KVM (/dev/kvm)
Windows x86_64	x86_64 Linux	Windows Hypervisor Platform (WHP) enabled

Windows supports portable checkpoints, pause/resume, and branches with --freeze-source. GPU acceleration remains unavailable; see known limitations.

More

• Kubernetes: run pods as microVMs through a RuntimeClass.
• GPU and CUDA: Vulkan via virtio-gpu / Venus, and CUDA API remoting.
• Examples: python, node, docker-in-vm, local-llm, headless-browser, doom.
• Development · User docs at smolmachines.com/docs, written in smol-machines/docs (corrections welcome there; runtime bugs stay here).

smolvm is the open-source runtime behind smol machines, and is not affiliated with other projects named SmolVM.

Apache-2.0 · made by @binsquare · twitter · github