# Go-live checklist — dorfteich.online (issue #89)

The release pipeline and the Prod stack are ready; going live is the
operator's call. Executed items carry their date; unchecked items block
the DNS switch.

## Release mechanics (in place)

- [x] 2026-07-12 — **Release workflow**: pushing `vX.Y.Z` builds the four
      semver images and publishes a Gitea release whose notes list the
      changes since the previous release and call out database
      migrations. (Notes derive from commit subjects — the repo is
      trunk-based without PRs; the issue's "PR titles" have no source
      here, documented deviation.)
- [x] 2026-07-12 — **Manual gate + Prod deploy**: pushing
      `prod-vX.Y.Z-<suffix>` (the human approval — Gitea 1.22 has no
      environment gates; revisit on 1.23+) verifies the release images
      exist, pins `TAG` in the Prod `.env`, pulls, restarts, and waits
      for readiness. Re-deploys/rollbacks are new suffix tags on the
      target release.
- [x] 2026-07-12 — **Prod stack provisioned** on ONE
      (`/home/DOCKER/dorfteich-prod/`, ports 8120–8122, secrets generated
      on the host, full backup profile: 30 d retention, failure mail).
      The host decision "ONE" is the working default — recorded here; if
      the owner picks different iron at go-live, the stack directory
      moves per the restore runbook's relocation procedure.
- [x] 2026-07-12 — **Test release walked the full gate**: `v0.1.0` built
      and published → `prod-v0.1.0-initial` deployed → readyz green.
- [x] 2026-07-12 — **Rollback tested on Prod**: `v0.1.1` deployed, then
      `prod-v0.1.0-rollback1` returned the stack to `v0.1.0`, readyz
      green (one-release downgrade window per docs/self-hosting).

## Operator items (block the DNS switch)

- [x] **Prod host decision confirmed** (working default: ONE, where
      Test/Int and the registry already live — one host, no BASEL yet).
- [x] **DNS**: point `dorfteich.online` at ONE (today it still points at
      the old VPS `188.245.116.44`).
- [x] **Caddy**: activate the prepared `dorfteich.online` block in
      `/etc/caddy/Caddyfile` on ONE (ports 8120–8122) after DNS,
      `systemctl reload caddy`, verify the Let's Encrypt certificate —
      this also closes the #88 item "ACME exercised on a real domain".
- [x] **First-run setup**: run the wizard on the fresh instance (or set
      the `SETUP_ADMIN_*` preseed in the Prod `.env` before first boot) —
      creates the Site Admin.
- [x] **Prod SMTP**: configure a production relay (wizard step or `.env`);
      the Prod `.env` ships without SMTP on purpose.
- [x] **Legal texts** (#82): paste the real dorfteich.online imprint and
      privacy policy in Administration → Legal pages.
- [x] **Monitors** (#85, done 2026-07-12): a fresh Uptime-Kuma runs on
      ONE (`kuma.101010.cloud`, `/home/DOCKER/uptime-kuma/`, bound to
      127.0.0.1:8130 behind Caddy). All four Prod monitors from
      `deploy/monitoring.md` are live and green (`prod web`,
      `prod api ready`, `prod api degraded` keyword, `prod collab`
      via the `/collab/healthz` fallback). Alerting goes to the existing
      Trinity Matrix room (`!RtztXRBVkQJgUwpGXx`, same channel as the
      website monitoring, target `@stwaidele:trinity.101010.cloud`); a
      test DOWN alert was confirmed delivered. Kuma admin login and the
      Matrix access token live on the host (admin-password.txt); no
      off-host Kuma yet (a host-total outage won't self-report).
- [x] **Backups verified on Prod** (#87, done 2026-07-12): the drill's
      `DRILL_SOURCE_VOLUME` now points at `dorfteich-prod_backups`
      (commit `a35f713`). An on-demand drill against the fresh Prod set
      `20260712-183629` restored green — readyz ok, `2 users, 16 pages`
      (logged on issue #98). Note: the very first Prod backup
      (`20260712-135349`) predated the wizard and had no users, so a
      drill needs a backup taken *after* real content exists — trigger
      "Back up now" once after go-live, as was done here.
- [x] **Off-host mirror** (#84, done 2026-07-12): tunnel fixed, BASEL
      provisioned (`deploy/backup-basel.md`), mirror live on Test AND on
      Prod since the v0.2.0 deploy (first run verified: all sets on
      BASEL, `status.json → mirror.lastRun = succeeded`).
- [ ] Optional hygiene: a dedicated `DEPLOY_SSH_KEY_PROD` secret (the
      workflows currently reuse the host-wide deploy key stored as
      `DEPLOY_SSH_KEY_TEST`).