The Stateless Machine: Architecture of a Volatile NixOS Workstation

Most NixOS configs describe what a system has. volnixos is built around what a system doesn’t have: a persistent root filesystem. Every boot starts from nothing. Every piece of durable state you want to survive a reboot has to be explicitly named. The config is the proof that this is a workable production machine, not a thought experiment.

This is the architectural walkthrough.

Layer 1: the ephemeral root

The root filesystem is a tmpfs. On every boot it’s empty. The impermanence module then bind-mounts a curated list of paths from /persist back into the root tree: dotfiles, SSH keys, the nix store’s database, browser profiles, anything that needs to survive. Everything else: gone on reboot.

The discipline this enforces: if you install something outside of Nix, it disappears at the next boot. There’s no accumulated state, no unknown packages, no config files that drifted from their declared values. The running system matches the flake, always.

The trap most people hit first: mount path canonicalization. impermanence uses bind mounts under the hood. If a path in your persistence list resolves to a symlink (typical with ~/.config/something that XDG redirected), nixos-rebuild fails with a non-obvious error. The rule: paths in the persistence list must be canonical (realpath-resolved), not symlinked aliases.

Layer 2: secure boot and encrypted secrets

Lanzaboote handles UEFI Secure Boot. The boot chain is measured and locked to known-good states. sops-nix handles secrets: age-encrypted files in the repo, decrypted to tmpfs at activation time using a host key stored on /persist. The result: secrets are in git (encrypted), they’re available at runtime (decrypted to tmpfs), and they’re never on the persistent disk in plaintext.

Layer 3: MicroVM network gateways

The machine runs two network gateways as microvm.nix guests under cloud-hypervisor:

• Tor MicroVM — a transparent proxy that routes traffic through Tor when active
• Tailscale MicroVM — a Tailscale router that keeps the mesh VPN isolated from the host

Both run as VM guests, not containers. The reasoning: a compromised Tor routing process in a container still has access to the host’s network stack. In a MicroVM it doesn’t.

The cloud-hypervisor backend was chosen over QEMU for the gateway VMs specifically: it has a smaller attack surface and faster boot, which matters when these VMs start on login.

Layer 4: the AI stack

The machine has an RTX 4050 (6GB VRAM) and runs a local AI stack declared in the flake:

• CUDA-accelerated Ollama for local model inference
• Open WebUI bound to 127.0.0.1:8080
• GPU-passthrough Fooocus for image generation
• memd + noctalia-claude-plugin for the agent workflow layer

The key constraint: 6GB VRAM is not enough for large models. The stack is tuned for the sweet spot of models that fit (7B at full precision, 13B quantized) with the assumption that heavier work goes to API-backed agents via Claude Code.

Layer 5: the desktop

niri is the Wayland compositor, a scrollable-tiling window manager. Noctalia v5 is the shell layer: a bar, desktop widgets, a panel system, and a JSON theme engine. The theme engine is what makes the noctalia-claude-plugin’s orb and pulse work: they consume the palette that Noctalia exposes and color themselves accordingly.

What it’s for

The wiki calls this a “portfolio, not a distro.” The config targets specific hardware and specific workflows (AI coding, security research, development). It’s published because the decisions made here, particularly around impermanence, MicroVM isolation, and the agent tool stack, are non-obvious and the failure modes are painful.

Browse: wiki.infernalcode.com · Source: github.com/lowcache/volnixos