Routine Fleet Operations
- Type: Index
- Status: Current
- Scope: Managed NixOS fleet
- Canonical sources:
Justfile;justfiles/deploy.just;justfiles/hosts.just;justfiles/maintenance.just; service-specific runbooks linked below- Last verified: Source commit
556df88494686003b1c4f20c8e0b99b5afc16a6e(2026-09-12)- Review triggers: Changes to public
justrecipes, fleet inventory, deployment wrappers, monitoring, backups, maintenance services, or incident runbooks
Use this page to choose a current procedure and to begin routine inspection
without changing fleet state. Run commands from the nixos-config checkout
unless a runbook says otherwise.
Before changing anything
-
Confirm the machine and, on Electra, its active hardware specialisation:
hostname cat /etc/nixos-specialisation 2>/dev/null || true -
Check the repository and fleet view:
git status --short just fleet-status -
Use the relevant runbook before a command that activates configuration, changes credentials, writes storage, updates firmware, or repairs a service.
just fleet-status fetches origin, evaluates the configured host set, and
probes each host over SSH. An unreachable row is an observation, not proof that
the machine or its services are down. Use the monitoring runbook when that
distinction matters.
Read-only starting points
| Question | Command | Notes |
|---|---|---|
| What hosts and declared capabilities exist? | just inventory |
Use just inventory me or a hostname to filter. |
| Which generation and revision is each reachable host running? | just fleet-status |
Covers Nix metadata; Beszel owns live resource and health metrics. |
| What would a local build change? | just build-diff |
Builds without activation and preserves the detected specialisation for comparison. |
| What changed in the current generation? | just diff-last-update |
Add detailed to include dependency changes. |
| Which rollback generations exist? | just generations |
Shows the most recent ten and Electra specialisations where present. |
| Did automatic update or garbage collection last succeed? | just auto-update-last-run; just nixos-gc-last-run |
Reads systemd result metadata. |
| Is an automatic-update hold active? | just auto-update-hold-status |
Check on the host being maintained. |
| Are Backrest and its snapshots visible? | just backup-status; just backup-snapshots |
Visibility is not restore verification. |
| Is Ollama active on this host? | just ollama-status |
Reports when the unit is not defined. |
just --list is the authoritative command index. A recipe's presence does not
mean it applies to every host.
Choose a procedure
- Change or activate NixOS configuration: Safe Testing and Deployment
- Investigate an alert, failed service, or route: Monitoring and Service Investigation
- Verify a backup or recover an individual path: Backup Verification and Partial Restore
- Recover a host or restore substantial state: Full-Host Recovery
- Diagnose an automatic update or a stopped post-switch service: Auto-Update Incident Response
- Move a service, its data, or its public route: Service Migration and Cutover
- Repair Electra boot trust or TPM unlock: Electra Boot-Trust and TPM Recovery
- Package an upstream service: Wrapper-Repository Packaging
The Engineering Handbook tracks the remaining Phase 4 contributor guidance.
Safety boundary
Read-only inspection can still contact the Git remote, evaluate the flake, or contact other hosts. It does not authorise a deployment or repair. In particular:
just gc,just firmware-update, backup restore recipes, secret recipes, update recovery recipes, and every deploy/switch recipe change state.just testchanges the running system until reboot or explicit recovery even though it does not make the build the boot-profile generation.- A service being active is not proof that its user-facing path works; use the success checks in the relevant runbook.
If an inspection fails
Preserve the command, exit status, relevant journal interval, host, current revision, and active specialisation. Do not immediately garbage-collect or restart unrelated services: those actions can remove rollback material or destroy useful evidence. Continue with the monitoring or incident runbook that owns the affected subsystem.