Home

Working with branches

Learn how to develop and manage your Supabase branches

This guide covers how to work with Supabase branches effectively, including migration management, seeding behavior, and development workflows.

Migration and seeding behavior

Migrations are run in sequential order. Each migration builds upon the previous one.

The preview branch has a record of which migrations have been applied, and only applies new migrations for each commit. This can create an issue when rolling back migrations.

Using ORM or custom seed scripts

If you want to use your own ORM for managing migrations and seed scripts, you will need to run them in GitHub Actions after the preview branch is ready. The branch credentials can be fetched using the following example GHA workflow.

.github/workflows/custom-orm.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
name: Custom ORMon:  pull_request:    types:      - opened      - reopened      - synchronize    branches:      - main    paths:      - 'supabase/**'jobs:  wait:    runs-on: ubuntu-latest    outputs:      status: ${{ steps.check.outputs.conclusion }}    steps:      - uses: fountainhead/action-wait-for-check@v1.2.0        id: check        with:          checkName: Supabase Preview          ref: ${{ github.event.pull_request.head.sha || github.sha }}          token: ${{ secrets.GITHUB_TOKEN }}  migrate:    needs:      - wait    if: ${{ needs.wait.outputs.status == 'success' }}    runs-on: ubuntu-latest    steps:      - uses: supabase/setup-cli@v1        with:          version: latest      - run: supabase --experimental branches get "$GITHUB_HEAD_REF" -o env >> $GITHUB_ENV      - name: Custom ORM migration        run: psql "$POSTGRES_URL_NON_POOLING" -c 'select 1'

Rolling back migrations

You might want to roll back changes you've made in an earlier migration change. For example, you may have pushed a migration file containing schema changes you no longer want.

To fix this, push the latest changes, then delete the preview branch in Supabase and reopen it.

The new preview branch is reseeded from the ./supabase/seed.sql file by default. Any additional data changes made on the old preview branch are lost. This is equivalent to running supabase db reset locally. All migrations are rerun in sequential order.

Seeding behavior

Your Preview Branches are seeded with sample data using the same as local seeding behavior.

The database is only seeded once, when the preview branch is created. To rerun seeding, delete the preview branch and recreate it by closing, and reopening your pull request.

Developing with branches

You can develop with branches using either local or remote development workflows.

Local development workflow

  1. Create a new Git branch for your feature
  2. Make schema changes using the Supabase CLI
  3. Generate migration files with supabase db diff
  4. Test your changes locally
  5. Commit and push to GitHub
  6. Open a pull request to create a preview branch

Remote development workflow

  1. Create a preview branch in the Supabase dashboard
  2. Switch to the branch using the branch dropdown
  3. Make schema changes in the dashboard
  4. Pull changes locally using supabase db pull
  5. Commit the generated migration files
  6. Push to your Git repository

Managing branch environments

Switching between branches

Use the branch dropdown in the Supabase dashboard to switch between different branches. Each branch has its own:

  • Database instance
  • API endpoints
  • Authentication settings
  • Storage buckets

Accessing branch credentials

Each branch has unique credentials that you can find in the dashboard:

  1. Switch to your desired branch
  2. Navigate to Settings > API
  3. Copy the branch-specific URLs and keys

Branch isolation

Branches are completely isolated from each other. Changes made in one branch don't affect others, including:

  • Database schema and data
  • Storage objects
  • Edge Functions
  • Auth configurations

Next steps