Handbook
Operate 301 — Production and reliability
Purpose: operate Fleet with clear trust boundaries, day-two procedures, and incident ladders.
Updated
| Audience | Production operators, SRE-adjacent owners, security reviewers |
| Effort | ~1–3 hours to read core pages; ongoing runbook use |
| Prerequisites | Build 201 topics you actually deploy (Caddy, templates, etc.) |
| Success | You can answer “who may execute code on this host?”, restart Fleet safely, and walk a symptom → check → fix path |
At a glance
- You will: lock down trust boundaries, run day-two checks, and navigate incidents with explicit ladders.
- Tone: assume production — prefer checklists and explicit rollback over tutorial pacing.
- Pair with:
CHANGELOG.mdhost-operator notes when cutting releases.
| Topic | Page |
|---|---|
| Trust boundaries + bearer hygiene | Security |
Day-two checks (systemctl, SQLite, rotations) |
Operations runbook |
| Dispatcher diagrams + data paths | Architecture |
| Symptom → fix ladders | Troubleshooting · start at symptom headings |
Release scripts + git-self-update interplay |
Upgrade & remote operations |
| Backup / DR posture | Backup, restore & DR |
| Telemetry, SLOs, alerting | Observability & SLOs |
| Production / enterprise go-live | Enterprise deployment checklist |
Release notes (CHANGELOG.md) complement this section—particularly ### Host operator blocks paired with docs/host-operator-steps.json and scripts/fleet-host-upgrade-hints.sh when upgrading bare-metal installs.