Skip to main content
Skip to main content
FormaOS

Operational Runbooks

How FormaOS handles backup, recovery, and operational continuity. Written for the security reviewers and auditors who ask for it in writing.

Database backup

  • Production Postgres runs on Supabase managed infrastructure with automated daily snapshots retained for at least 7 days on paid tiers, and continuous point-in-time recovery (PITR) available for the past 7 days at any second.
  • Logical migration history is versioned insupabase/migrations/and applied through the Supabase CLI, so every schema change is reproducible from source.
  • Storage buckets (audit exports, evidence uploads) are bucket-level RLS-policied and the underlying object store provides 99.999999999% durability.

Recovery procedure

  1. Confirm the incident scope and the point-in-time recovery target timestamp before any restore begins.
  2. Restore a new Supabase project from the PITR snapshot. The managed restore preserves RLS policies, triggers, and indexes.
  3. Diff the restored schema against the migration head; replay missing migrations if any drift exists.
  4. Cut DNS / app config to the recovered project. Production health probes (/api/health, /api/health/integrity) must return green before traffic is restored.
  5. Post-mortem within 5 business days, documented under the incident-response runbook below.

Incident response

The full incident-response lifecycle, severity classification, and customer-notification expectations live on the dedicated page below. This section is the pointer to it.

Incident response runbook

Health & integrity checks

  • GET /api/health: overall liveness probe used by uptime monitors.
  • GET /api/health/integrity: public data-integrity check summary, confirming the database and storage are reachable. Used by external trust reviewers.
  • GET /api/health/detailed: operator-only detailed checks behind an operator token.