GSP / engineering

Operate the GSP website integration

Deploy the existing app safely, retain evidence and recover the exact state.

Documentation version 6.0.0 · 2026-09-07

Single-host architecture

This release uses one durable SQLite database and server-local state with atomic transactions. Run one authoritative persistent instance. It is not a stateless or horizontally scaled service. The async engineering worker performs bounded subprocess runs and recovers expired leases.

Launch gates

Production requires an HTTPS PUBLIC_ORIGIN, publication approval and a configured TLS SMTP relay. Staff actions additionally require an MFA-verified session. These settings do not themselves prove domain ownership, inbox delivery or legal sufficiency.

Backup and restore

The SQLite database and private MFA encryption key must be backed up together. Stop writes during the operator state-bundle action. Store backups as secrets: they contain customer and account state. Do not put them in a public download or source repository.

python tools/state_bundle.py backup --database /data/site.sqlite3 --output /secure/garmo-state.zip
python tools/state_bundle.py verify /secure/garmo-state.zip
python tools/state_bundle.py restore /secure/garmo-state.zip --destination /empty-private-state --confirm

What to monitor

Check health/live and health/ready, engineering queue state and expired leases, errors, notification backlog and SMTP bounce/delivery behavior. Route failures to an operated incident process. The status page describes measured local release coverage; it is not a fabricated uptime dashboard.

Before serving customers

Run the hosted browser suite, cross-browser/device checks, accessibility and security review, sustained workload/load tests, restoration drill, retention approval, native-handshake tests and external mail delivery verification against the actual deployed origin.

Discuss a release-specific integration