NixOS Build & Deployment Pipeline
Establish a reusable, security-conscious NixOS build and deployment workflow that separates controller, builder, and target roles without making the fleet dependent on a single unrecoverable path.
Nova is the initial central builder and is currently a Fedora 44 host with Nix installed. The work is deliberately implementable before Nova's planned NixOS migration: Fedora-specific builder management must be documented now, while the later migration preserves the established builder interface and recovery contract.
The intended normal flow is:
controller local source snapshot -> Nova build -> explicitly selected NixOS target activation
The controller evaluates an explicitly captured local working-tree snapshot; Nova performs eligible builds; the resulting closure is transferred to the selected target, where test, boot, or switch retains its normal NixOS semantics. The implementation must support safe testing of uncommitted changes, including a documented policy for intentionally included untracked files.
Goals:
- move eligible expensive builds away from service hosts while protecting Nova's existing CI and remediation workload;
- establish a dedicated, least-privilege remote-builder identity and separate per-client build credentials from deployment, Forgejo, CI-publication, and cache-push authority;
- keep builder, controller, CI, and target capabilities distinct;
- support declarative opt-in remote-build clients and a deliberate, explicit-target deployment interface;
- retain emergency local-build, rollback, and target-side recovery paths;
- remove only unnecessary Forgejo write authority after auditing legitimate private-input, auto-update, and hosted-service access;
- extend the existing Nova-backed Forgejo/Attic workflow without granting CI target activation authority.
Implementation begins with Nova's Fedora builder boundary, then credential distribution and reusable NixOS client configuration, followed by Vega/Lyra proof, controller-to-target deployment, fleet generalisation, hardening, credential cleanup, durable wiki/runbook documentation, and CI refinements. Each delivery must include validation appropriate to its risk; deployment-affecting changes require a real canary and a no-op follow-up before closure.
