> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tryardent.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Settings

> Per-connector defaults, branch initialization SQL, and local Supabase linking

Settings control what each **new branch** looks like for the currently selected connector: which database name appears in connection URLs, what SQL runs after branch creation, and how local tooling points at a branch.

The command group is `ardent settings`.

| Key          | Description                                                                        |
| ------------ | ---------------------------------------------------------------------------------- |
| `default_db` | Default database name used in branch connection strings                            |
| `branch_sql` | SQL, or `@path/to/file.sql`, executed once on every new branch after it is created |

## Branch configuration and anonymization

`branch_sql` gives teams repeatable control over branch contents without maintaining one-off scripts for every developer.

Common uses:

* Redact or anonymize sensitive values on every branch.
* Add fixtures, baseline rows, or organization-specific setup.
* Apply guardrail DDL your app expects in isolated environments.

For security-focused anonymization patterns, see [Security](/security#branch-anonymization).

<Warning>
  `branch_sql` runs on new branches, not on your source database. Keep the SQL idempotent where possible so branch creation is predictable.
</Warning>

## ardent settings list

```bash theme={null}
ardent settings list
```

<Accordion defaultOpen={false} title="Example output">
  ```text theme={null}
  Connector: prod-db
    default_db   myapp
    branch_sql   (not set)   SQL to run on every new branch after creation
  ```
</Accordion>

## ardent settings set

Set the default database name used in branch URLs:

```bash theme={null}
ardent settings set default_db myapp
```

Pass a file for `branch_sql`:

```bash theme={null}
ardent settings set branch_sql @./branch-init.sql
```

<Accordion defaultOpen={false} title="Example output">
  ```text theme={null}
  ✓ Set default_db → myapp
  ```
</Accordion>

## ardent settings remove

```bash theme={null}
ardent settings remove branch_sql
```

<Accordion defaultOpen={false} title="Example output">
  ```text theme={null}
  ✓ Removed branch_sql
  ```
</Accordion>

## Local Supabase linking

If you use Supabase locally, Ardent can point your local Supabase services at an Ardent branch. This is useful when you want local auth, REST, realtime, or edge-function tooling to run against an isolated branch instead of your local Postgres container.

### ardent settings supabase status

Check whether a local Supabase project is currently linked:

```bash theme={null}
ardent settings supabase status
```

If more than one local Supabase project is available, pass the project name:

```bash theme={null}
ardent settings supabase status --project my-app
```

### ardent settings supabase link

Link local Supabase to the current Ardent branch:

```bash theme={null}
ardent settings supabase link
```

Or link to a specific branch:

```bash theme={null}
ardent settings supabase link my-feature --project my-app
```

The CLI checks that local Supabase is reachable before changing configuration. Use `--skip-health-check` only when you know the services are intentionally stopped and you want to update configuration now:

```bash theme={null}
ardent settings supabase link my-feature --skip-health-check
```

### ardent settings supabase unlink

Restore local Supabase to its local database configuration:

```bash theme={null}
ardent settings supabase unlink
```

Use `--project <project>` if the CLI asks you to disambiguate.