From 2f6ab1ba3b626f9c6ae8aca33857214c9268938c Mon Sep 17 00:00:00 2001 From: david kiania Date: Wed, 10 Jun 2026 20:21:51 +0300 Subject: [PATCH] docs: mark stage-2 (prod reads via dashboard_ro) done MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Prod bridge now reads via dashboard_ro with the refresher on REFRESH_DATABASE_URL (privileged). Both webhooks registered. Updated the as-built banner + §6 safety note accordingly. Co-Authored-By: Claude Opus 4.8 --- docs/STAGING_FLEETOPS_ARCHITECTURE.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/STAGING_FLEETOPS_ARCHITECTURE.md b/docs/STAGING_FLEETOPS_ARCHITECTURE.md index c6f60d6..160cbe5 100644 --- a/docs/STAGING_FLEETOPS_ARCHITECTURE.md +++ b/docs/STAGING_FLEETOPS_ARCHITECTURE.md @@ -6,12 +6,10 @@ developers (mixed technical/ops background — readable without prior context). > **As-built (2026-06-10).** All six surfaces are live: staging `fleetapi` / `fleetops` / > `fleetnow` `.fivetitude.com`, and prod `fleetops.rahamafresh.com` + `/analytics/*` on > `fleetapi.rahamafresh.com`. The dedicated read-only `dashboard_ro` role backs the staging -> bridge; the prod bridge still uses the app role (stage-2 migration to `dashboard_ro` is ready -> but deferred). Migrations 17 + 18 applied. The client's live FleetNow map was unaffected -> throughout. **Remaining operational follow-ups** (no code): register the two Forgejo→Coolify -> webhooks for the *FleetOps-prod* and *FleetNow-staging* apps (FleetOps-staging is done) per -> [`webhook-auto-deploy.html`](../../15_fleetops/docs/webhook-auto-deploy.html) in the fleetops -> repo; review/merge tracksolid PR #17. +> bridge **and now the prod bridge too** (stage 2 done — reads via `dashboard_ro`, the `v_trips` +> refresher keeps a privileged connection via `REFRESH_DATABASE_URL`). Migrations 17 + 18 applied. +> Both Forgejo→Coolify webhooks (FleetOps, FleetNow) registered + active. The client's live +> FleetNow map was unaffected throughout. **Remaining:** review/merge tracksolid PR #17. This document describes how we (a) introduce a **staging environment** under the `fivetitude.com` umbrella so the production FleetNow map is never edited directly, and (b) @@ -180,9 +178,11 @@ not by a separate DB: TABLES`), `EXECUTE` on the `reporting.fn_*` map functions, and `ALTER DEFAULT PRIVILEGES` so future objects are auto-readable ("dynamic"). No write/REFRESH privilege, so accidental writes are impossible. The password is generated on the host into `~/.dashboard_ro.pw` (0600), never - in the repo. **Two-stage:** stage 1 backs the *staging* bridge (done); stage 2 migrates the - *live prod* `fleetapi.rahamafresh.com` connection off the app role onto `dashboard_ro` (which - already grants the full read surface, incl. the live `fn_*` path). + in the repo. **Both stages done:** staging *and* prod bridges now connect reads via + `dashboard_ro`. Because the prod bridge also runs the `v_trips` refresher (which needs write + perms `dashboard_ro` lacks), the refresher uses a **separate privileged connection** — + `REFRESH_DATABASE_URL` (the app/superuser role); `DATABASE_URL` is `dashboard_ro`. Staging + keeps the refresher disabled, so it needs only `dashboard_ro`. - The **`reporting.v_trips` materialized-view refresher is disabled on staging** — production owns it. The refresher needs write perms and is already pg-advisory-lock guarded (key `920_145`, FIX-D02); a read-only staging role would only log errors, so disable it explicitly