Skip to content
Get a quote

Supabase setup questionHow do I get a Supabase staging environment and stop testing on production?

Your app has real users now, and every change still gets tried on the live database. Supabase Branching gives you a separate copy to test on, but it doesn’t copy everything. Here’s what to set up first, or hand it over at a fixed price.

Short answer

Use Supabase Branching: a persistent branch for staging, or a preview branch for each pull request. A branch connected to GitHub builds its database structure from the migrations in your repository; every branch starts with no data by default and gets placeholder sign-in secrets. So get your schema into migrations first, then add a seed file and branch secrets. Watch the cost: branches bill by the hour and aren’t covered by the Spend Cap.

Set it up in this order

  1. 01

    A persistent branch for staging

    “recommended for environments like staging, QA, or development” Supabase, Branching

    Persistent branches stay until you delete them. Preview branches are deleted when their pull request is merged or closed, which suits testing one change. For staging, use a persistent branch.

  2. 02

    Get your schema into migrations first

    “The database schema isn't cloned.” Supabase, Branching

    A branch connected to GitHub builds its database from the migrations in your repository. If your tables were made by clicking in the dashboard, there’s usually nothing to build from yet: turn the current schema into a migration file (Supabase’s CLI can do this) and commit it.

  3. 03

    Seed test data; never copy production

    “By default, new branches do not start with any data or storage objects from your base project.” Supabase, Branching

    New branches start empty. Add a seed file with test accounts and sample rows, so staging doesn’t need real customers’ data. For a persistent staging branch, seeding has to be switched on in your Supabase config file.

  4. 04

    Set branch secrets, or sign-in breaks

    “Auth secrets, such as OAuth provider secrets and SMTP passwords, get placeholder values instead.” Supabase, Branching

    On a branch, sign-in provider secrets and SMTP passwords are placeholders. Set the real values as branch secrets, or social sign-in and auth emails fail on staging.

  5. 05

    Know what it costs

    “Branches are not covered by the Spend Cap.” Supabase, Branching usage

    There’s no fixed fee for a preview branch: you pay for the compute it uses, by the hour, and that usage counts toward your plan’s quota. Branches sit outside the Spend Cap, so delete the ones you don’t need.

  6. 06

    The other option: a second project

    Some teams use a second Supabase project as staging instead. It’s easy to picture, but you keep its schema in step yourself, through the same migrations.

Checked against the vendor’s docs on : Supabase docs: Branching; Supabase docs: Manage branching usage.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

Related: Supabase email rate limit exceeded · Supabase project paused · Supabase RLS fixes · Supabase security review before launch

Questions

More on this error

Will staging send emails to real people?

Only if it has real people to email. A branch starts with no users, and if your project uses its own email server, the branch gets a placeholder password until you set the real one as a branch secret. Use test accounts in your seed file so staging only emails addresses you control.

Can I copy production data into staging?

Supabase starts branches empty by default to protect production data. A seed file with made-up records is the safer way to get realistic test data.

Can you set it up for me?

You create the branches and pay Supabase, since the account and billing are yours. We turn your current schema into migrations, write the seed file and list the branch secrets to set, as a pull request you review.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; we reply by email, usually within one business day.

Describe your problem All fixes