One command.Either runtime.

Containers for speed. VMs for isolation.

$ curl -fsSL https://russel.dev/install.sh | sh
View on GitHub
Russel dashboard

Isolated, reproducible, portable.

Hardware isolation without the weight, zero-drift builds, and one path to prod.

Isolation

Hardware microVMs

KVM + Cloud Hypervisor. Sub-2s boot, virtio-fs, TAP networking, hardware page-table isolation.

BOOT < 1.8s
Reproducibility

Deterministic builds

Content-addressed closures — bit-for-bit reproducible. Binary cache, hermetic sandbox, no host mutation.

DRIFT 0%
Velocity

Dual-engine switching

One flag switches runtime. Rootless Podman ↔ microVM via live socket handover. Zero downtime.

SWAP 420ms
Sovereignty

Self-hosted · Apache 2.0

Bare metal, edge, or cloud you own. No external APIs. TOML-declared, fully local.

NO LOCK-IN

Source to serving, one graph.

Parse the manifest, build a closure, dispatch to a microVM or a container, then publish a route.

CONTROL PLANERUNTIMEdeploypushrussel-cliGit repoResolveBuildmicroVMContainerIngress
02Hermetic buildProduces a content-addressed closure. Hash-verified, cache-accelerated, identical on every machine.

Isolation costs — measured.

Spawn-to-ready on bare metal. Compare KVM microVMs against rootless Podman.

Go server · standard HTTP baseline

Spawn-to-ready
Milliseconds · lower is better
WARMRussel container · 8.6× vs Podman
Russel microVM · KVM1,975ms
Russel container874ms
Podman baseline7,504ms

Totals are spawn-to-ready. microVM includes Cloud Hypervisor init, virtiofs, and guest kernel boot. Container is a direct rootfs bind. Lower is better.

One surface, both runtimes.

Declarative Russelfile.toml or imperative russel-cli. Same control plane for containers and microVMs.

Manifest

Isolation
# Deploy via control plane
./russel-cli deploy . --runtime microvm -p 8080:3000 --vm-id prod-api --cpus 2 --mem 512M
[+] Resolving artifact…
[+] Building closure a89f…
[+] Booting Cloud Hypervisor (2 vCPU, 512M)
[+] TAP ready · 10G virtio-net
prod-api LIVE → http://127.0.0.1:8080