Skip to content
ReviveDB

A Supabase disaster recovery plan for the project you actually run

A recovery plan is more than a database copy. Keep an independent, checked recovery point for the data and project components your product relies on.

  1. Supabase project

    Capture from the source

  2. Recovery point

    Stored outside Supabase

  3. Restore or download

    Use it when the normal route is unavailable

A recovery plan covers more than one kind of change

The right recovery point gives you a known place to return to, whether a change affected data, access or the project itself.

  • A damaging change

    A bad migration, accidental deletion or application bug changes data that you need to recover.

  • Project or account loss

    The project is deleted, ownership changes or the account needed for the normal recovery route becomes unavailable.

  • A provider incident

    Supabase or a dependent service has a wider incident, so recovery tools inside the same platform may not be reachable.

What makes a recovery plan usable

A useful recovery point needs separation, evidence and enough context to act under pressure.

  • An independent copy

    The recovery point is kept outside the source platform and remains available through another route.

  • Restore evidence

    The database is restored and compared. Other project assets are checked for completeness.

  • Recovery context

    A manifest records what is recoverable and which manual actions remain.

See what is backed up

How a Supabase project is brought back

Restore your data, files and Functions together, then check your app before moving traffic.

  1. 1

    Choose the last known-good recovery point

    Use monitoring, deploy history and audit evidence to bound the incident. Record the selected time and the data that may need to be recreated after it.

  2. 2

    Prepare an isolated target

    Create a new project without production traffic. Keep scheduled jobs, outbound webhooks and customer email disabled while recovery is being tested.

  3. 3

    Restore the database and Auth

    Apply roles, schema and data in the required order. Compare tables, rows, grants, policies and Auth identities with the recovery-point inventory.

  4. 4

    Restore Storage and Functions

    ReviveDB recreates buckets, uploads their files and deploys captured Functions through one restore action in the dashboard.

  5. 5

    Replace project-specific values

    Supply new API keys and secret values, then update OAuth callbacks, DNS, webhooks and external-service allowlists. These values do not belong in a backup.

  6. 6

    Test the application before cutover

    Verify sign-in, private and public downloads, database writes, Functions and background work. Move traffic only after the checks pass and side effects are deliberately enabled.

Keep a checked copy of your Supabase project

Connect a project and create an independent recovery point outside Supabase.