Should we push config.toml too?

[tadeegan]

Improve documentation

A large amount of supabase functionallity is controlled by config.toml. If we want to manage a staging enviornment that mirrors the prod one, how can we push the config.toml with correct envs? Should we use supabase config push in ci?

So far I tried something like:

name: Deploy Migrations to Staging

on:
  push:
    branches:
      - develop
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest

    env:
      SUPABASE_ACCESS_TOKEN: ${{ secrets.SUPABASE_ACCESS_TOKEN }}
      SUPABASE_DB_PASSWORD: ${{ secrets.STAGING_DB_PASSWORD }}
      SUPABASE_PROJECT_ID: xxx
      DEPLOY_URL: staging.xxx.co

    steps:
      - uses: actions/checkout@v3

      - uses: supabase/setup-cli@v1
        with:
          version: latest

      - run: supabase link --project-ref $SUPABASE_PROJECT_ID
      - run: supabase db push
      - run: supabase config push

[msacket]

Good question. I'm thinking this should also include supabase functions deploy

[sweatybridge]

Yup, you can commit config.toml to git and run supabase config push as well as supabase functions deploy.

Sometimes you also want to setup different configs for local and prod. In that case, you can declare the a separate remote. For eg.

[auth]
enable_signup = false

[remotes.prod]
project_id = "<prod-project-ref>"

[remotes.prod.auth]
enable_signup = true

This way when you link to production project on CI, the config in [remotes.prod] block will be pushed instead.

[tadeegan]

Are there docs on how this remotes works? How do I name my project "prod"?