smolvm

Verzweigbare microVMs für KI-Agenten. Bette leichte virtuelle Maschinen in deine Software ein, portable Entwicklungsumgebungen und lokales Sandboxing.

Installation

curl -sSL https://smolmachines.com/install.sh | bash   # macOS + Linux

Windows: Entpacke das windows-x86_64-Release und führe smolvm.exe aus (benötigt die Windows Hypervisor Platform). Coding-Agenten: Führe nach der Installation smolvm --help aus, um alle Befehle zu entdecken.

Schnellstart

smolvm machine run --net --image alpine -- uname -a          # einmalige VM, wird beim Beenden entfernt
smolvm machine run --net -it --image alpine -- /bin/sh       # interaktive Shell

Lokal

Echte VMs mit eigenem Kernel, kostenlos auf deinem Laptop oder deinen eigenen Servern. Sie booten in unter einer Sekunde, und der Speicher ist elastisch, sodass der Host nur das bereitstellt, was der Gast tatsächlich nutzt. Maschinen bleiben über Neustarts hinweg erhalten, und jedes OCI-Image funktioniert, auch selbst gebaute.

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    # lokales Image, keine Registry

Deklariere eine Maschine in einer Smolfile: Image, Ressourcen, Ports, Mounts und Netzwerkrichtlinie in einer eingecheckten Datei.

Einbettbar

Steuere Maschinen aus deinem eigenen Code mit einer einzigen Machine-API. Die SDKs laufen in deinem Prozess ohne Daemon, lokal oder auf 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();

Quellcode und Dokumentation: smol-machines/smol · smolmachines.com/docs/sdk

Verzweigbar

Speichere eine laufende Maschine mitten in der Ausführung, spule sie zurück oder verzweige sie in Kopien, die vom selben Punkt aus weiterlaufen. Checkpoints erfassen RAM, CPU-Zustand und Festplatten; Branches sind Copy-on-Write-Kinder einer laufenden Maschine.

smolvm machine create --net --name agent --image alpine
smolvm machine start --name agent --branchable
smolvm machine branch --from agent --name try-1                   # laufendes Copy-on-Write-Kind
smolvm machine checkpoint --name agent -o agent.checkpoint        # speichern, inklusive Prozesse
smolvm machine create --name agent2 --from agent.checkpoint       # später oder anderswo fortsetzen

Spule mit --from <checkpoint> --at '~N' zu einer früheren Generation zurück (siehe machine checkpoint-log), und stoppe ohne Verlust der Ausführung mit Pause und Resume. Mehr in Branching und inkrementellen Checkpoints.

Portabel

Verpacke eine Maschine, wie du sie auch eingerichtet hast, in eine einzige .smolmachine-Datei. Lade sie in eine beliebige OCI-Registry hoch oder führe sie als eigenständig ausführbare Datei aus, die in unter 200 ms bootet, ohne dass etwas installiert werden muss.

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 sind ebenfalls portabel: Stelle einen auf einem anderen Host oder auf smol cloud wieder her.

Sicher

Jede Workload erhält eine hardware-isolierte VM mit eigenem Kernel. Netzwerk ist standardmäßig deaktiviert, ausgehender Datenverkehr kann auf benannte Hosts beschränkt werden, und Code kann ein Credential verwenden, ohne es jemals zu lesen.

Sicherheit ist eine gemeinsame Verantwortung. smolvm stellt die Grenze bereit: eine separate VM und einen eigenen Kernel für jede Workload, wobei nichts den Host erreicht, es sei denn, du erlaubst es. Du entscheidest, was diese Grenze überschreitet. Jeder Ordner, den du mountest, jeder Port, den du öffnest, jeder Host, den du erlaubst, und jedes Secret oder jeder SSH-Agent, den du weiterleitest, wird für die Workload nutzbar – gib einer nicht vertrauenswürdigen Workload also nur, was sie braucht.

smolvm machine run --net --image alpine --allow-host registry.npmjs.org -- wget -qO- https://google.com   # blockiert
smolvm machine run --net --image alpine --allow-host-pattern registry.npmjs.org -- wget -qO- https://registry.npmjs.org   # nur exakter Host
NOTION_API_KEY=secret_… smolvm machine run --net --image alpine \
  --credential [email protected] -- sh -c 'echo $NOTION_API_KEY'   # ein Platzhalter

Siehe Credential-Substitution und das Sicherheitsmodell. Verwende --allow-host-pattern '*.example.com', um nur Subdomains zu erlauben. Das ältere --allow-host example.com erlaubt weiterhin sowohl die Apex-Domain als auch Subdomains. Die Allow-List einer gestoppten Maschine kann mit smolvm machine update geändert werden (--allow-host, --allow-host-pattern, --allow-cidr und deren --remove--Varianten).

Funktionsweise

Jede Workload läuft in einer hardware-virtualisierten VM mit eigenem Gast-Kernel auf Hypervisor.framework (macOS), KVM (Linux) oder der Windows Hypervisor Platform (Windows). libkrun ist der VMM und libkrunfw liefert den Gast-Kernel. Images verwenden das OCI-Format, sodass alles von Docker Hub, ghcr.io oder einer anderen Registry als microVM bootet, ohne Docker-Daemon.

Standardwerte: 4 vCPUs, 8 GiB RAM. Der Speicher ist über virtio balloon elastisch und inaktive vCPUs schlafen im Hypervisor, sodass Überprovisionierung fast nichts kostet. Überschreibe mit --cpus und --mem.

Vergleich