Skip to main content
Settings control what each new branch looks like, per connector: the database name in its URL, and SQL that runs right after it’s created.

​
branch_sql: shape every new branch

branch_sql is how teams make every branch come up ready — without each developer keeping their own setup script. Common uses:
  • Redact or anonymize sensitive values on every branch.
  • Add fixtures or baseline rows.
  • Apply DDL your app expects in test environments.
For anonymization patterns, see Security.
branch_sql runs on new branches, never on your source database. Keep it safe to run more than once where you can, so branch creation stays predictable.

​
ardent settings list

​
ardent settings set

For branch_sql, pass SQL inline or point at a file with @:
Give each script a name with --hook, and control order and context:
Remove a named script with ardent settings remove branch_sql --hook <name>.

​
ardent settings remove

​
Local Supabase linking

If you run Supabase locally, Ardent can point its services — auth, REST, realtime, storage — at an Ardent branch instead of the local Postgres container. Useful when you want the full local stack running against isolated, real data.

​
ardent settings supabase status

Is a local Supabase project linked right now?
If you have several local Supabase projects, name one with --project <id> (the Supabase CLI project id). Link local Supabase to the current branch:
Or to a specific branch:
The CLI checks that local Supabase is running before it changes anything. Use --skip-health-check only if you’ve stopped the services yourself. Put local Supabase back on its own local database:
--project <id> and --skip-health-check work here too.