Roadmap

This is the order of execution — what we’re building now, what comes next, and what waits for later. It’s distilled from an internal backlog of roughly 290 tracked items, each tied to a design doc and kept honest by a linter that fails the commit when the counts drift. This page is the public view of that machine.

Two ground rules:

• No dates on unshipped work. Dates on a young project’s roadmap age into broken promises. Order is the commitment; the devlog and the release feed show the actual pace. Shipped entries do carry their release and date — that part is history, not a promise.
• This page changes when reality changes. The “last reviewed” stamp at the bottom is checked automatically — if it goes stale, our own CI files an issue against us.

Recently shipped

App upgrades that keep your data — 2026.09.0, 13 Sep 2026. Installed apps now upgrade in place when the catalog has a newer version, keeping their data, and can be reverted to the previous version. Custom apps get a compose editor with the same guarantees, and no change quietly throws away a volume that holds data. The control plane also now comes up on a network with no DHCP server, and moves to a DHCP address when one appears.

Backups that survive losing the box — 2026.08.5, 10 Sep 2026. Point the cluster at a USB disk or a second NVMe and it backs itself up on a schedule: the control plane’s identity and your apps’ data, media libraries aside, sealed so the disk is useless to anyone without your passphrase or recovery code. After a reflash, the setup wizard finds that disk and brings the cluster back as it was, and any app’s data can be restored on its own from that app’s page.

The app catalog earns its launch set — 2026.08.4, 30 Aug 2026. Sixteen apps ship as a benched launch set, each one deployed and checked on the reference Pi + N100 cluster before release, and new apps now arrive on their own — signed and verified — without you flashing anything. Apps with no web page, like a game server, are first-class: they install and get a name on your network instead of pretending to have a page to open.

Fleet updates that behave like a rollout — 2026.08.3, 15 Aug 2026. One node updates first as a canary and has to come back healthy before the rest follow, a few at a time; a failed node is a red cell in a per-node report rather than a wall, and a run going wrong stops itself. Mixed Pi and x86 clusters each get the right image, and “update all” now includes the node running the control plane.

A real URL for every app — 2026.08.2, 10 Aug 2026. Install an app and it comes up under a proper name with a valid certificate — jellyfin.lan.<cluster>.internal, not an IP address and a port number to remember. The cluster runs its own authoritative nameserver for its own domain, mints every app a certificate from the cluster’s own authority, and stands a reverse proxy in front of it on the node where the app actually runs. Apps are reachable over the cluster’s mesh by default; putting one on the wider LAN is a per-app choice you make when you install it. With a Rasputin firewall in front, those names resolve across your whole network with no setup. Proven end to end on real hardware before the release went out.

Security currency, proven on hardware — 2026.08.1, 7 Aug 2026. The continuous machine — scheduled canary builds and CVE watch on every image — turned into a shipped stable: each image moved to its latest upstream base (Buildroot 2025.02.16, OpenWrt 25.12.5) and the whole cluster was brought up end to end on real hardware before the release went out. The update path also gained crash capture on the persistent partition, so a rare failure during an A/B update leaves a backtrace to act on instead of a shrug.

Cluster identity and discovery on real networks — 2026.07.9, 5 Aug 2026. Every cluster now takes its own derived name (<cluster>.local), so two Rasputins coexist on one LAN without a fight — with startup collision detection that surfaces a conflict instead of silently misrouting. Discovery gained fallbacks beyond mDNS (the control plane’s IP and a QR on the trust page; a unicast record served by the firewall), MagicDNS names on the mesh, an IP banner on the firewall console, and a single one-command flasher that takes a blank drive to a seeded, enrolled node — firewall included.

A second BMC transport: Turing Pi — 2026.07.8, 29 Jul 2026. Power and restart for all four slots of a Turing Pi 2 over its REST BMC, configured from Settings with the board’s certificate pinned the first time you see it. Console is deliberately not offered on that board (why), and every node now advertises what its own hardware can actually do — guide.

BMC support: real power control and serial console — 2026.07.5, 27 Jul 2026. Power any node on or off and open its serial console from the web UI, on real hardware rather than a mock — live on the 24-node BitScope rack (devlog #2). Controls appear only where a management path actually exists.

Now

Security, hardened and proven. A threat model over the whole system, static analysis and fuzzing on attacker-reachable parsers in CI, a bill of materials for every shipped artifact, and tamper/downgrade rejection tests on the signed update chain. The work lands in the images themselves — the cluster is hardened when it boots, not by a checklist we hand you afterwards.

Next

The first hour, hardened. The setup wizard’s three deployment modes validated end to end on every major browser and platform — including Linux desktops, where your passkey comes from a password manager, a security key, or your phone rather than from the desktop itself — plus an honest hardware buying guide and a living validated-devices page per node role, so nobody guesses what to order.

Your passkey on every device you own. Add a passkey to the account you already have, give it a name, and revoke it when a device goes away — so a new laptop, phone or desktop enrolls in seconds instead of leaning on a credential that lives somewhere else.

Day-2 trust operations. Rotation and revocation as first-class operations: scheduled node-credential rotation, certificate authority rollover with an operator-paced re-trust flow, immediate revocation, and fleet-wide SSH key management that rolls out canary-first.

Observability, finished. Metrics and logs already flow from every node; what remains is the out-of-box experience — pre-built dashboards per node role and sensible default alerts (node down, disk filling, update available) with zero Grafana homework.

Later

Firewall depth. Deterministic rule ordering and priorities, live WAN status in the UI, and intrusion-detection rules that update independently of image releases.

Roles and audit. Operator/viewer roles enforced on every dangerous action, and an audit history of who did what, when.

Fleet update depth. The rollout itself has shipped; the controls around it follow — hold specific nodes back from a fleet-wide update, stop a run you’ve changed your mind about, and choose which release channel a cluster tracks. The batch-size and failure-budget defaults get tuned against a larger test fleet than any single cluster here can stand in for.

Rasputin hardware. A purpose-built appliance is the long game — but the software proves itself on commodity hardware first. Everything above runs on gear you can buy today, and that stays true.

Continuously

Some things aren’t roadmap items; they’re the drumbeat. Signed releases with A/B rollback. Scheduled canary builds that catch upstream drift before it catches us. CVE watch on every image’s package set. Automated quality and security sweeps on the repos, with a human merging every change. The devlog is where the drumbeat is audible.

Last reviewed: 2026-09-13. If this page and reality disagree, that’s a bug — tell us.