Skip to main content
Skip to main content
FormaOS

Operational Runbooks

How FormaOS handles backup, recovery, and operational continuity. Companion page to /security and /trust for procurement and audit reviews.

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 via Supabase MCP or the supabase CLI — 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 PITR target timestamp via the internal incident channel.
  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 operational pointer.

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 (database + storage reachable). Used by SOC 2 scanners and external trust reviewers.
  • GET /api/health/detailed — operator-only detailed checks behind a founder token.