_{English · 中文 · 日本語 · 한국어}

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

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.

The documentation for humans and agents is in docs/, one folder per task: a README.md with the facts and a SKILL.md an agent can follow, with its scripts, beside the reference page for each feature.

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

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

Mount an S3, R2 or MinIO bucket with -v s3://bucket/prefix:/data, see volumes.

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

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
go get github.com/smol-machines/smol/sdk/go   # Go

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

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.

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.

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; --allow-host example.com allows the apex and its subdomains. smolvm machine update adds (--allow-host, --allow-host-pattern, --allow-cidr) and removes (--remove-allow-host, a host or pattern as it was added; --remove-allow-cidr) entries, also on a running machine started with an allow list: a grant applies to the next connection or lookup, and a removed host's learned addresses go with it.

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.

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

• Kubernetes: run pods as microVMs through a RuntimeClass.
• GPU and CUDA: Vulkan via virtio-gpu / Venus, and CUDA API remoting.
• Named networks: machines that reach each other by IP.
• Nested virtualization: run KVM, smolvm or QEMU inside a machine.
• Browser display: a machine's desktop in the browser, with keyboard and mouse.
• 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