> ## Documentation Index
> Fetch the complete documentation index at: https://russel.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# v0.1 status

> What v0.1 includes, what has been tested, what's left, and what comes next.

Status as of **2026-09-30**. v0.1.0 is released. The release tracker is [#56](https://github.com/daschinmoy21/russel/issues/56).

## Scope

v0.1 deploys services to **one server, for one trusted operator**. Rootless Podman containers are the default runtime. MicroVMs (Cloud Hypervisor) are **experimental but working**: they accept the same Russelfile fields as containers and run under the same unprivileged control plane. v0.1 has no multi-user support, no agent sandboxes, and one server only.

## What's in v0.1

| Area | Status | Notes |
| - | - | - |
| Russelfile | ✅ | One port model (#41), `service.args` (#43), checks at load time (#44), `[database]` removed (#40) |
| Deploys pinned to commits | ✅ | `service.name` is the identity (russel-dev#446), all settings come from the Russelfile (russel-dev#447), each deployment records its commit (russel-dev#448) |
| Containers | ✅ | Readiness checks the app itself (russel-dev#462), `service.cpus` applies (russel-dev#468), secrets passed as Podman secrets (russel-dev#457) |
| Apps run unprivileged | ✅ | By default on both runtimes; `user = "root"` opts out (#66) |
| Safe updates | ✅ | Candidate health is watched through proxy-confirmed cutover and drain; failed rollback confirmation retains managed backends ([contract](../../concepts/lifecycle.md#what-zero-downtime-covers)) |
| Dedicated `russel` account | ✅ | The installer runs everything as an unprivileged system account (russel-dev#515) |
| MicroVMs without root | ✅ experimental | `passt` networking (russel-dev#461, #47) |
| MicroVM feature parity | ✅ experimental | `service.args` (russel-dev#463), `[[ports]]` and `[[volumes]]` (#42), `restart = "unless-stopped"` (russel-dev#467), read-only root (russel-dev#469) |
| Example CI | ✅ containers, manual for microVMs | Every container example deploys and answers on each PR (russel-dev#474). The microVM run is started by hand, because building the kernel on a CI runner takes hours (russel-dev#470). |
| Nix GC roots, test isolation | ✅ | #45, #46 |
| Licensing | ✅ | LICENSE, kernel source tarball, dashboard third-party licenses, SECURITY.md, DCO (russel-dev#418, russel-dev#421, russel-dev#424) |

## Tested

* Formatting, clippy, and the full test suite pass on `main`.
* CI deploys every container example against an unprivileged control plane and checks that each answers.
* A local run with KVM deployed all 13 examples as microVMs.
* A fresh-machine test of a release candidate found that containers didn't start under the installed service. v0.1.0 includes the fix ([Changelog](../releases.md)).

## Left for v0.1

| Issue | What's left |
| - | - |
| #55 | Repeat the fresh-machine acceptance test with the v0.1.0 release. If services don't come back after its reboot step, #60 becomes a v0.1 item too. |
| #56 | Close the tracker once the acceptance test passes |

## Known gaps

* **#69:** containers reject an entry point that is a relative symlink, such as busybox applets or `python3 -> python3.x`.
* **#70:** a service name shaped like `<name>_g<hex>` is accepted, and can be confused with the name before `_g` during an update.
* **Uncommitted changes:** `update`, `rollback --rebuild`, and health restarts of a deployment made from a folder with uncommitted changes build what the folder holds now.
* **After a reboot**, containers don't come back on their own (#60).

## After v0.1

The order is v0.1, then agent sandboxes, then v0.2. The lifecycle fixes from the 2026-10-01 audit come before sandbox work. See [Decision: what comes after v0.1](../decisions/post-v0.1-order.md).

* **Agent sandboxes** (#71): isolated environments for AI agents, microVM first, with gVisor or PVM for hosts without KVM. Needs a full Linux guest (`guest = "linux"`, #24, #26, #27).
* **v0.2, production readiness** (#83): replicas and autoscaling on one host (#25, #29, #30), and services that come back after a reboot (#60).
* `destroy` that follows each volume's `keep` setting (#59) is tracked but not yet scheduled.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.