Operator-facing reference for institution administrators. The full operator boot guide lives in the repository at docs/release/RC1_OPERATOR_BOOT_GUIDE.md; this page is the quick reference.

Twelve-step daily-ops checklist

1. Install the snap (or boot the node image).
2. Start services in dependency order — snapd handles this automatically.
3. Export DOCKER_HOST=unix:///var/snap/datab-app/common/run/docker.sock if running docker from a plain shell.
4. Run ensure-postgres-role.sh after any credential rotation.
5. Health-curl every service: backend 8080, Atlas 8090, Orula 11444, Gu 11445.
6. Tail JSONL audit + reward logs at /var/snap/datab-app/common/{orula,gu}/{audit,reward}.jsonl.
7. Use the operator console (datab-os-mobile) for daily monitoring.
8. Service logs: snap logs datab-app.<service>.
9. Run doctor.sh when anything looks off.
10. Set DATAB_INTERNAL_API_KEY on first deploy. Rotate per institutional policy.
11. Rollback procedure: snap revert datab-app + restore-watcher for DB.
12. File issues via hello@databsystems.com with the doctor.sh output attached.

Disruptive actions — confirm before running

• Reboot via /api/system/reboot. Operator console confirms before triggering.
• Shutdown via /api/system/shutdown. Same.
• Backup trigger via /api/backup/trigger. Idempotent; safe to retry.
• Restore: import or select an authenticated .pgdump.enc artifact in the admin Backup & Restore surface, prepare the restore, then confirm RESTORE. The restore-watcher consumes the emitted restore.request file.

What operators should NOT do

• Run docker against the host socket — the snap uses its own socket.
• Edit Postgres data directly. Use the API.
• Disable datab-app.flyway. Migrations are how the schema stays consistent across upgrades.
• Run snap revert without checking the changelog. See Changelogs first.