nix-takeover is in public alpha
NixOS at scale, with deployments an operator confirms instead of surprises.
What it does
Most fleet tools assume they own the inventory, or treat a deploy as something that should finish by restarting services on its own. ntk takes the opposite position on both. It reads whatever inventory you already have — files, scripts, CI, or whatever else owns the list of machines — resolves configurations by hostname or optional ntk.rules, builds each unique selected system once, and makes the exact result available to a lightweight agent on each host.
The part I care most about is that deployments are staged. ntk deploy plans, builds, checks impact, pushes, and stages the new system profile. It does not restart services. You inspect the pending deployment with ntk status and run ntk confirm when you are ready to switch — or ntk cancel or ntk rollback when you are not.
A normal session
Enrolling a host and shipping it a new generation looks like this:
ntk validate --coverage shows which NixOS configuration each host will get. ntk trust accept web-01 enrolls the agent key after you check the endpoint, and ntk validate --connectivity verifies the agents are reachable and trusted. Then ntk deploy stages, ntk status inspects, and ntk confirm switches the staged systems into service.
The deploy form stays composable. Filtering hosts through jq and piping the JSONL rows into ntk deploy works, and the explicit typed pipeline — ntk hosts | ntk plan | ntk build | ntk push | ntk activate — lets you inspect or store intermediate steps. plan resolves without building, so you can see what a change implies before paying for it.
Status and limits
ntk is in public alpha, versioned in the 0.1.0-alpha.* line, and the API should be considered unstable. This release targets existing NixOS hosts that already use flakes. The ntk bootstrap, ntk-bootstrap-install, and ntk iso first-install and bare-metal flows are experimental. SOPS onboarding, deployment-secret rotation, and agent-key onboarding and rotation are basic or incomplete.
The deploy, stage, inspect, confirm, cancel, and rollback path is implemented and covered by process-isolated fleet integration tests, MicroVM end-to-end tests, and manual real-hardware tests. Do not start with critical machines, and keep out-of-band recovery access. The CLI supports x86_64-linux; the agent supports x86_64-linux and aarch64-linux.
Try it
Add ntk as a flake input with inputs.ntk.url = "gitlab:shepherd-softworks/nix-takeover", use ntk.packages.${system}.ntk for the CLI and ntk.nixosModules.ntk-agent for the agent, or run it without installing: nix run gitlab:shepherd-softworks/nix-takeover#ntk -- --help.