How to back up Supabase Auth

Supabase Auth is split across two places. Users and identities live in Postgres. Provider settings, redirect URLs, templates, API keys and secrets are project configuration. You need both, followed by an actual login test.

What the database can preserve

A logical database backup can preserve Auth schema data such as users and linked identities, subject to the permissions and options used for the export. A supported Supabase restore-to-new-project operation also transfers Auth user data as part of the database transfer.

However, Supabase notes in its database backups guide that database backups do not contain passwords for custom database roles. Do not assume every credential associated with the project can be recovered from a database artifact.

What needs a separate recovery record

• Email and OAuth provider configuration.
• Provider client IDs and client secrets.
• Site URL and allowed redirect URLs.
• Email templates and SMTP configuration.
• CAPTCHA, rate limits and other Auth settings.
• Project API keys and application environment variables.

The Supabase restore-to-new-project guide explicitly lists Auth settings and API keys among the items that are not copied automatically. Store configuration as code where possible and keep secrets in an approved secret manager, not in the backup document itself.

What failed first in our own implementation

The first useful Auth check was not whether pg_dump exited successfully. It was whether the temporary backup role could actually read auth.users. A role can connect to Postgres and still miss protected Auth rows, producing a clean-looking but incomplete dump.

ReviveDB therefore creates a short-lived role for each backup attempt, gives it read access with RLS bypass, proves that it can read every table including auth.users, and removes it after the job. The access design and live probe document the failure cases we test. Separately, the recovery manifest redacts secret values and turns their names into explicit manual recovery actions instead of pretending they were backed up.

Do not export password material casually

Auth data is highly sensitive. Limit backup access, encrypt artifacts in transit and at rest, audit reads and separate the ability to create backups from the ability to delete them. Avoid ad-hoc CSV exports of user tables: they are easy to copy, hard to govern and do not recreate a working Auth system by themselves.

Document key ownership and rotation. Encryption is not a recovery control if the decryption key disappears before the backup expires. Conversely, retaining keys indefinitely can defeat intended deletion policies. Align key lifecycle with the retention and legal requirements of the backup.

A safe Auth recovery test

1. Restore the database into an isolated project or compatible recovery environment.
2. Compare aggregate user and identity counts without exposing personal data in logs.
3. Restore Auth configuration and secrets through the controlled configuration process.
4. Use dedicated test accounts for password, magic-link and enabled OAuth flows.
5. Verify redirect handling, session creation, token refresh and logout.
6. Confirm row-level security still isolates tenants after authentication.

Avoid sending recovery emails to real customers during a drill. Use a controlled email domain or sink, disable production webhooks and make the recovery environment unmistakably non-production.

Plan for key and URL changes during cutover

A new project may have different API keys and endpoints. Applications, background workers and third-party OAuth callback settings must be updated in a controlled order. Existing sessions may no longer be valid, so decide in advance whether users will need to sign in again and how support will communicate that change.

Auth recovery is an application test

Seeing rows in the Auth schema proves data exists. It does not prove email delivery, OAuth callbacks, token validation or authorization. The acceptance criterion should be a successful end-to-end login followed by an authorized application action.

Put Auth alongside database, Storage and configuration in the Supabase backup and restore checklist. ReviveDB’s backup verification approach is designed around this evidence rather than a backup-job status alone.