Same build, same config, same CLI.
Only the isolation changes.
Everything in one Russelfile
Runtime, resources, routing and secrets, versioned next to your code. Apps run unprivileged by default.
name · Service id: 1–128 of A–Z, a–z, 0–9, _ and -.
Isolation you pick per service
Containers share the host kernel. microVMs get their own, behind a hardware boundary.
Switch in one line
Redeploy, and the new version takes traffic before the old one drains.
# Russelfile.toml - type = "container" + type = "microvm"
Isolation costs, measured.
Against rootless Podman, same host.
× = times faster than rootless podman
Up to 10.4× faster.
9.5× even with a kernel per VM.
Most of the gap with Podman is build time. microVM time includes Cloud Hypervisor init, virtio-fs and the guest kernel boot; the container is a direct rootfs bind.
bare metal · warm cache
Yours to run.
Reproducible, self-hosted, reversible.
Builds that never drift
Every service is a hash-pinned Nix package, bit-for-bit the same on your laptop and the server.
- build
- nix
- pin
- commit + Russelfile
Runs on machines you own
Bare metal, an edge box, or a cloud account you control.
- container
- any VPS, rootless Podman
- microvm
- needs /dev/kvm
- gen 1 container● serving
- gen 2 container● serving
- build failed rolled_back● serving
- gen 3 microvm● serving
Every deploy is a generation
Pinned to its commit and Russelfile, runtime included. A failed redeploy rolls itself back.
- kept
- last 20 generations
- undo
- russel rollback api
The control plane can go down.
Your services don't notice.
russel-ctrl builds, deploys and supervises, but it never sits in the request path. Workloads run detached, Traefik routes from files on disk, and a restarted ctrl re-adopts whatever is still running.
- +0.0s3 services serving
Skip the cluster.
Keep the box.
Russel sits between a Compose file and a cluster: your machines, your isolation choice, one config.
| Russel | Docker Compose | Kubernetes | Coolify / Dokploy | Managed PaaS | |
|---|---|---|---|---|---|
| Runs on hardware you own | |||||
| microVM per service | one line | Kata add-on | provider decides | ||
| Rootless by default | opt-in | opt-in | n/a | ||
| Reproducible builds | Nix, hash-pinned | image tags | image tags | image tags | buildpacks |
| Zero-downtime cutover | |||||
| One-command rollback | |||||
| Config lives in | one Russelfile | YAML + Dockerfile | manifests + charts | web UI | dashboard |
| Moving parts to run | russel-ctrl | Docker daemon | a cluster | Docker + panel | none, billed |
Managed PaaS = Vercel, Render, Fly and the like. Defaults as shipped; most gaps can be closed with enough setup.
Agent sandboxes.
Coming next.
Hand a coding agent its own machine on your server. It does the work, you keep the result, and the machine disappears.
Try every idea at once
One prompt, several sandboxes. Each attempt gets its own machine; you keep the one that works and the rest are deleted.
retry the payment call
fake the clock in the test
lock the cart before checkout
kept sbx-3 · patch exported to your branch · sbx-1, sbx-2 deleted
Bring the agent you already use
It stays on your machine, logged in as you, and works in the sandbox over SSH. Nothing to install or log in to inside.
- Claude Code
- Codex
- opencode
- Droid
- Copilot CLI
- Command Code
- Antigravity
- Amp
Tested first with Claude Code, Codex and opencode. Logos belong to their owners.
Keep it or throw it away
Sandboxes are deleted when the job is done. Keep one instead and its files, tools and caches are there next time, or snapshot it and fork a fresh copy.
- default
- deleted when done
- keep
- files, tools, caches
- fork
- from any snapshot
- sbx-8
- after-depssnapshot
- sbx-9● kept
Toolchains stored once
Sandboxes take their tools from the Nix store on your server. Ten attempts on the same stack share one copy; only their files are their own.
- shared
- toolchains, read-only
- sees
- only what it needs
- own
- workspace and caches
Step in next to it
SSH into the same sandbox the agent is using to look around, try the app, or take over. It keeps running after you both leave.
- access
- ssh, same as the agent
- stays up
- until its ttl or you delete it
You choose what it can reach
Pick a network profile per sandbox. Your server, its control plane and other sandboxes are off-limits by default.
- network
- offline, packages, git, web
- ports
- private unless you share
One file, one command.
Try it.
Describe the service in a Russelfile.toml, then russel apply it. Change the options to see both update.
[service]name = "api"source = "."port = 3000memory = "256mb"type = "microvm"cpus = 2[ingress]host = "api.example.com"port = 8080[service.env]LOG_LEVEL = "info"DATABASE_URL = "secret://DATABASE_URL"
Coming soon.
What we’re building next.
Hardened containers
Run untrusted code under gVisor on any VPS, no /dev/kvm required.
- russelfile
- isolation = "gvisor"
- runtime
- runsc systrap, fails closed
Deploy on git push
Push to a branch and Russel builds and deploys it, with signed webhooks and no CI to set up.
- trigger
- signed webhook
- release
- migrations run before traffic moves
Replicas
Run N copies of one service behind a single hostname, then create and destroy them from load.
- routing
- Traefik multi-backend
- scale
- manual, then autoscale
Live resize
Give a running microVM more vCPUs or memory without a reboot or a redeploy.
- microvm
- cpu + memory hotplug
- container
- first-class cpus limit
Full Linux guests
Boot a Linux userspace with systemd inside the guest instead of the minimal busybox init.
- russelfile
- service.guest = "linux"
- microvm
- volumes + extra ports
Metrics
See CPU, memory, restarts and deploy times for every service, and scrape them with Prometheus.
- endpoint
- GET /metrics, Prometheus format
- dashboard
- live CPU + memory per service