Superminaren/hackerspace.sh
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: HANDOFF observability Phase 2 complete (GlitchTip live on prod, DSN wired)

Browse Source
This commit is contained in:
Moheeb Zara
2026-05-22 01:09:16 -07:00
parent ad4b9f5a12
commit 65458b71ec
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/HANDOFF.md
+1 -1
View File
@@ -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. **Remaining:** bring the stack up (the documented one-command), register the first user + project to get the DSN, set `SENTRY_DSN` in `.env.production`, restart, verify a capture. A first hand-rolled bring-up attempt was scrapped after a psql-quoting bug; the committed compose supersedes it.
**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).
---