Operations
Operations
Deployment procedure
Regurai deploys via the Lovable Cloud pipeline:
- Author changes (code + docs) in a branch / preview.
- Verify in the Preview environment (
project--<id>-dev.lovable.app). - Run the security scan; target zero critical findings.
- Publish via the Lovable platform — production URL:
project--<id>.lovable.appplus custom domains (www.regurai.com,regurai.com).
No manual npm run build or bunx ...build is required — the harness builds on publish.
Environments
| Environment | URL | Purpose |
|---|---|---|
| Local dev | localhost:5173 | Engineer workstation |
| Preview | project--<id>-dev.lovable.app | Pre-production verification, latest preview build |
| Production | project--<id>.lovable.app + custom domains | Live user traffic |
Environment variables
| Variable | Scope | Notes |
|---|---|---|
VITE_SUPABASE_URL | Browser (build-time) | Public, baked into bundle |
VITE_SUPABASE_PUBLISHABLE_KEY | Browser (build-time) | Public anon key |
SUPABASE_URL | Server (runtime) | Same as VITE version |
SUPABASE_PUBLISHABLE_KEY | Server (runtime) | Used by requireSupabaseAuth |
SUPABASE_SERVICE_ROLE_KEY | Server (runtime) | Never exposed to client |
WEBHOOK_SECRET (per webhook) | Server (runtime) | HMAC key for /api/public/* |
Read server vars via process.env.X inside .handler() — never at module scope.
Infrastructure requirements
- Cloudflare Workers (workerd) with
nodejs_compat. - Supabase project (managed).
- Lovable Cloud secret store.
- TLS / DNS handled by the platform.
Backup procedure
- Database: Supabase performs automated daily backups with point-in-time recovery (PITR) within the retention window of the project's plan.
- Application code: source of truth is the Lovable project / git remote; the latest published build is immutably stored by the platform.
- Documentation snapshots: each published version of the Project Manual can be downloaded as PDF (
/docs→ Download). Archive copies in the firm's GRC document repository at every release.
Disaster recovery
| Scenario | Action |
|---|---|
| Worker outage in one region | Cloudflare automatically reroutes — no action. |
| Edge function regression | Roll back via the Lovable Cloud function tooling. |
| Database corruption / accidental destructive migration | Open a support ticket with Supabase; restore via PITR. Verify with supabase--db_health. |
| Service-role key compromise | Rotate via Supabase admin; redeploy edge functions; investigate audit log; force-revoke active sessions. |
| Complete project loss | Restore from git + Supabase PITR snapshot into a fresh project; reconfigure secrets; redeploy. |
RTO and RPO targets are set per tenant SLA; document them in the firm's BCP, not here.
Incident response
Severity ladder:
- SEV-1 — auth bypass, data exposure, total outage.
- SEV-2 — partial outage, broken governance workflow, degraded MFA.
- SEV-3 — single-page bug, cosmetic regression.
Standard workflow:
- Detect — alert from monitoring, user report, or audit anomaly.
- Triage — assign severity, on-call owner, war-room channel.
- Contain — disable affected feature flag or rollback last release if needed.
- Eradicate — code fix + tests + manual update (changelog entry + impact note in chapter).
- Recover — redeploy, verify in preview, then production.
- Postmortem — within 5 business days, file in
chapters/10-change-management.mdunder Incidents. If architectural, also record an ADR.
For any SEV-1 affecting customer data, also open a gdpr_requests entry where applicable.
Monitoring
| Signal | Where |
|---|---|
| Edge function logs | Lovable Cloud → Edge Functions |
| Server function logs | Worker stdout |
| Audit log entries | /app/audit-log-viewer |
| Login attempts | public.sec_login_attempts |
| DB health | supabase--db_health |
| Security findings | Lovable Project security view |
Scheduled jobs
| Job | Cadence | Endpoint | Owner |
|---|---|---|---|
audit_logs integrity check (Tech-debt #9, follow-up to Incident #5) | Weekly (suggested: Mondays 03:17 UTC) | POST /api/public/hooks/audit-logs-integrity-check (calls public.audit_logs_integrity_summary() and persists a SYSTEM row into audit_logs) | Security |
Scheduling is wired through pg_cron + pg_net. The runbook entry — exact
cron.schedule(...) SQL, alerting hook for status='suspect' runs, and
operator playbook for triaging flagged rows — is a planned Operations
documentation pass and is not yet in production. Until then, the
endpoint and RPC are deployed and can be invoked manually for ad-hoc audits.