glitchtip: pin image to 6.1.6 for reproducibility; HANDOFF observability complete

deploy/glitchtip/README.md

@@ -43,7 +43,8 @@ Supabase's Kong gateway on 8000; no public surface). Reach it either by:
 
 - Resources: the capped stack needs roughly 1.5-2 GB RAM. On a small host add
   swap first.
-- Reproducibility: pin the `glitchtip/glitchtip` image to a release tag in
-  `docker-compose.yml` for production (it ships as `latest` so a fresh clone
-  runs without edits).
-- Updates: `docker compose pull && docker compose up -d` (re-runs `migrate`).
+- Reproducibility: the `glitchtip/glitchtip` image is pinned to a release tag
+  in `docker-compose.yml` (currently `6.1.6`). Bump it deliberately rather than
+  tracking `latest`.
+- Updates: edit the pinned tag, then `docker compose pull && docker compose up -d`
+  (re-runs `migrate`).

deploy/glitchtip/docker-compose.yml

@@ -11,9 +11,9 @@
 # Then register the first user (open http://localhost:GLITCHTIP_PORT), create an
 # organization + project, copy its DSN into the app's SENTRY_DSN, restart the app.
 #
-# Reproducibility: pin `glitchtip/glitchtip` to a release tag for production
-# (see https://gitlab.com/glitchtip/glitchtip for versions); `latest` is used
-# here so a fresh clone runs without edits.
+# Reproducibility: the `glitchtip/glitchtip` image is pinned to a release tag
+# (bump it deliberately, then `docker compose pull && up -d`). See
+# https://gitlab.com/glitchtip/glitchtip for versions.
 name: glitchtip
 
 services:
@@ -39,7 +39,7 @@ services:
     mem_limit: 128m
 
   migrate:
-    image: glitchtip/glitchtip:latest
+    image: glitchtip/glitchtip:6.1.6
     command: ./manage.py migrate
     restart: 'no'
     env_file: [.env]
@@ -51,7 +51,7 @@ services:
         condition: service_healthy
 
   web:
-    image: glitchtip/glitchtip:latest
+    image: glitchtip/glitchtip:6.1.6
     restart: unless-stopped
     mem_limit: 768m
     env_file: [.env]
@@ -72,7 +72,7 @@ services:
         condition: service_completed_successfully
 
   worker:
-    image: glitchtip/glitchtip:latest
+    image: glitchtip/glitchtip:6.1.6
     command: ./bin/run-celery-with-beat.sh
     restart: unless-stopped
     mem_limit: 640m

docs/HANDOFF.md

@@ -39,7 +39,7 @@ Branch `main`. Took backlog item 2. Design-first: owner chose self-hosted Glitch
 
 **Deployed (`c89e4d9`, run 26260262561 success); inert in prod** (`SENTRY_DSN` unset). Phase 1 was a safe no-behavior-change deploy.
 
-**Phase 2 = a REPRODUCIBLE repo artifact, not droplet surgery (owner steer).** Instead of hand-building containers on the specific droplet, the GlitchTip backend is now committed at `deploy/glitchtip/` (`docker-compose.yml` + `.env.example` + README), self-contained (its OWN Postgres + Redis, shares nothing with the app stack), `127.0.0.1`-bound, memory-capped, one-command `docker compose up -d` (migrate runs first via `service_completed_successfully`). Any self-hoster gets it the same way; the app stays generic (`SENTRY_DSN` works with this OR Sentry SaaS OR nothing). A 2GB swapfile was added to the production droplet (was RAM-tight: 3.8G, no swap) + persisted in fstab. **Phase 2 is now LIVE on prod:** the GlitchTip stack runs from `/opt/hackerspace-ops/deploy/glitchtip` bound to `127.0.0.1:8100` (port 8100 not 8000 to avoid Supabase Kong; the committed compose default was fixed to 8100 in `ad4b9f5`), web/worker/redis/postgres healthy, ~2.3G RAM available + light swap. `SENTRY_DSN=http://<key>@localhost:8100/1` is set in `.env.production`, app restarted. Ingest proven: a verification event POSTed in the seam's exact request shape returned HTTP 200 + an event id (so DSN + auth + event format + GlitchTip ingest all work; the app uses the identical request from `buildEvent`, so real server errors now land automatically). Open registration locked off (`ENABLE_OPEN_USER_REGISTRATION=False`). Dashboard viewed via SSH tunnel `-L 8100:127.0.0.1:8100`. A first hand-rolled bring-up attempt was scrapped after a psql-quoting bug; the committed compose superseded it. Observability item 2 = DONE (both phases).
+**Phase 2 = a REPRODUCIBLE repo artifact, not droplet surgery (owner steer).** Instead of hand-building containers on the specific droplet, the GlitchTip backend is now committed at `deploy/glitchtip/` (`docker-compose.yml` + `.env.example` + README), self-contained (its OWN Postgres + Redis, shares nothing with the app stack), `127.0.0.1`-bound, memory-capped, one-command `docker compose up -d` (migrate runs first via `service_completed_successfully`). Any self-hoster gets it the same way; the app stays generic (`SENTRY_DSN` works with this OR Sentry SaaS OR nothing). A 2GB swapfile was added to the production droplet (was RAM-tight: 3.8G, no swap) + persisted in fstab. **Phase 2 is now LIVE on prod:** the GlitchTip stack runs from `/opt/hackerspace-ops/deploy/glitchtip` bound to `127.0.0.1:8100` (port 8100 not 8000 to avoid Supabase Kong; the committed compose default was fixed to 8100 in `ad4b9f5`), web/worker/redis/postgres healthy, ~2.3G RAM available + light swap. `SENTRY_DSN=http://<key>@localhost:8100/1` is set in `.env.production`, app restarted. Ingest proven: a verification event POSTed in the seam's exact request shape returned HTTP 200 + an event id (so DSN + auth + event format + GlitchTip ingest all work; the app uses the identical request from `buildEvent`, so real server errors now land automatically). Open registration locked off (`ENABLE_OPEN_USER_REGISTRATION=False`). Dashboard viewed via SSH tunnel `-L 8100:127.0.0.1:8100`. Verified in the GlitchTip UI: issue SH-1 `VerificationError` with tags `surface=phase2-verify` / `environment=production` (running GlitchTip 6.1.6). The committed compose image is now PINNED to `glitchtip/glitchtip:6.1.6` (was `latest`) for reproducibility. A first hand-rolled bring-up attempt was scrapped after a psql-quoting bug; the committed compose superseded it. Observability item 2 = DONE (both phases).
 
 ---