This is the public plan. Timings are indicative for a part-time, open-source pace and will move as people get involved — treat them as sequencing, not promises. Each milestone maps to one or more epics.
| Milestone | Theme | Status |
|---|---|---|
| M0 | Walking skeleton (end-to-end thread) | ✅ Shipped |
| M1 | Detection + local inference | ✅ Shipped |
| M2 | Portal: inventory + live feed | ✅ Shipped |
| M3 | Topology view + categories | ✅ Shipped |
| M4 | Packaging (NixOS, OCI) + auth hardening | ✅ Shipped |
| M5 | Kubernetes plane (controller + node-agent) | ✅ Shipped |
| M6 | Supervised self-healing (PARR) | ✅ Shipped (P1–P4, hosts); ◑ K8s executor landed, k3d verification pending |
| M7 | Alert routing + dashboards | 🚧 Next |
✅ M0–M3 — Skeleton, detection, portal, topology
The foundation is in place and verified end to end: the Cargo workspace
(ravn-core, ravn-agent, ravn-server), deterministic detection taps (journald,
failed-unit over D-Bus, config drift, auth/SSH, NixOS generations), local LLM
explanations, NATS transport with a SQLite offline buffer, and the React portal —
fleet inventory, a live severity-coded event feed with a detail drawer, and the
topology view that groups the fleet by a label of your choosing (now with a
per-kind icon, so a cluster and a host read differently at a glance).
✅ M4 — Packaging + auth hardening
Deployable and safe by default: a Nix flake with services.ravn.agent and
services.ravn.controlPlane modules, OCI images + docker-compose, hardened
enrollment (bootstrap tokens → per-agent mTLS), portal user OIDC + RBAC, and
systemd-sandboxed inference.
✅ M5 — Kubernetes plane
Ravn watches Kubernetes the same way it watches hosts, detection-only: a read-only
controller Deployment over the Events API and a node DaemonSet agent, with
OIDC / TokenReview ingest auth, control-plane inference for K8s events, deploy
manifests + a Helm chart, and a kind/k3d end-to-end test. Cluster signals and host
signals share one ravn-core type system and read alike in the portal.
◑ M6 — Supervised self-healing (PARR), on hosts
The big one. Detection closes the loop — under human control by default. Shipped for Linux/NixOS hosts; the Kubernetes execution surface has now landed on the M6 hardening branch and is pending k3d end-to-end verification (see P5 below). The loop runs through five phases; here is the honest per-phase status.
- ✅ P1 — Prepare / Act / Reflect / Review (PARR), manual-approval-only. A detected fault is matched against a curated, typed remediation template; the control plane proposes a fix. On approval it issues an Ed25519-signed command; the agent pulls it and a privileged actuator (privsep) carries it out. Matching is deterministic — the LLM is never in the propose/act path (it explains, it never decides; no LLM-generated commands, ever).
- ✅ P2 — Autonomy. Default-deny policy engine + risk tiers, circuit breaker, and a kill switch. An optional policy can auto-approve low-risk actions.
- ✅ P3 — Safety net. Verify and rollback (including NixOS generation rollback) and an at-most-once idempotency ledger.
- ✅ P4 — Knowledge base. Retrospectives accumulate into per-environment markdown with deterministic recall, so the fleet gets better at explaining itself over time.
- ◑ P5 — Breadth & K8s execution. The in-cluster Kubernetes executor now
exists (#146): it pulls
signed
CommandEnvelopes, re-verifies the Ed25519 signature in-cluster, and runs the typeddelete_pod/restart_deployment/pod_statecapabilities under least-privilege namespaced RBAC, with the same precondition/verify/rollback loop as the host actuator. Landed on the M6 hardening branch; the full k3d end-to-end heal (detect → propose → approve → execute → verify) is pending verification on a real cluster before release. Approval via alert sinks (Slack/ntfy actionable buttons) remains future work.
Durability. The remediation audit trail is now persisted to Postgres (#143) — every state transition (proposal → decision → command → result) is written to an append-only
remediation_recordstable, so the audit history survives a control-plane restart. (The restart-survival E2E test runs against a live Postgres.)
The host loop runs on one machine via the demo:
a NixOS host, a k3d cluster (detection-only), GPU-accelerated local explanations
(AMD ROCm / NVIDIA / CPU), and a live kill → propose → approve → heal loop on the host.
🚧 M7 — Alert routing + dashboards
What. Production polish.
How. External alert sinks (ntfy, webhook, email, Slack) with routing rules by severity/category — not yet wired: there is no alert-routing backend endpoint today, and the portal does not yet expose routing configuration. Plus richer portal dashboards. Beyond this: more detection taps, more remediation templates, more models.
The model-eval harness (ravn-eval) is a separate track and now produces a
reproducible scored comparison table across several small models from a
committed fixture corpus (failed units, OOMKills, auth anomalies, drift) with
reference explanations, scoring faithfulness + actionability + latency/RAM — runnable
in the Nix sandbox with no model via recorded backends
(#157). Remaining: publishing
the results as a site page and capturing live (non-recorded) numbers.