Describe the bug
supabase init on CLI v2.108.0 generates a [local_smtp] section — the CLI's own renameDeprecatedSMTP logic (in apps/cli-go/pkg/config/config.go) treats [inbucket] as deprecated in favor of [local_smtp]. But the hosted Branching config parser (used by the GitHub integration when creating preview branches, and when deploying to the production branch on merge) rejects local_smtp:
failed to parse config: decoding failed due to the following error(s):
'config.config' has invalid keys: local_smtp
So the standalone CLI emits a config section its own hosted branching backend can't decode — the two are on different config-schema versions. The config step fails before migrations run, so the preview branch ends in MIGRATIONS_FAILED with an empty database (no supabase_migrations.schema_migrations, 0 public tables). On a merge to the production branch, the same parse failure blocks the production deploy.
To Reproduce
supabase init with CLI 2.108.0 → the generated config.toml contains [local_smtp].- Enable Branching + the GitHub integration on a Pro project; open a PR.
- The Supabase preview branch is created but ends in
MIGRATIONS_FAILED. The PR's Supabase check comment shows a Branch Error: 'config.config' has invalid keys: local_smtp, with Configurations / Migrations / Seeding all skipped.
- Query the branch DB → 0 public tables, no migration history.
Expected behavior
The hosted branching config parser should accept the same config.toml the current CLI generates — i.e. accept [local_smtp]. Failing that, the branching backend should apply the same inbucket→local_smtp rename shim the CLI already ships, and/or the error should name the cause ("CLI is ahead of the branching config schema; use [inbucket]") instead of a bare invalid keys.
Workaround
Rename [local_smtp] → [inbucket] in config.toml. The hosted branching backend accepts [inbucket], and the current CLI still parses it locally (with a deprecation warning), so it satisfies both.
Environment
- CLI: 2.108.0
- Branching: enabled via the GitHub integration, Pro plan
- Postgres 17
Related
Describe the bug
supabase initon CLI v2.108.0 generates a[local_smtp]section — the CLI's ownrenameDeprecatedSMTPlogic (inapps/cli-go/pkg/config/config.go) treats[inbucket]as deprecated in favor of[local_smtp]. But the hosted Branching config parser (used by the GitHub integration when creating preview branches, and when deploying to the production branch on merge) rejectslocal_smtp:So the standalone CLI emits a config section its own hosted branching backend can't decode — the two are on different config-schema versions. The config step fails before migrations run, so the preview branch ends in
MIGRATIONS_FAILEDwith an empty database (nosupabase_migrations.schema_migrations, 0 public tables). On a merge to the production branch, the same parse failure blocks the production deploy.To Reproduce
supabase initwith CLI 2.108.0 → the generatedconfig.tomlcontains[local_smtp].MIGRATIONS_FAILED. The PR's Supabase check comment shows a Branch Error:'config.config' has invalid keys: local_smtp, with Configurations / Migrations / Seeding all skipped.Expected behavior
The hosted branching config parser should accept the same
config.tomlthe current CLI generates — i.e. accept[local_smtp]. Failing that, the branching backend should apply the sameinbucket→local_smtprename shim the CLI already ships, and/or the error should name the cause ("CLI is ahead of the branching config schema; use[inbucket]") instead of a bareinvalid keys.Workaround
Rename
[local_smtp]→[inbucket]inconfig.toml. The hosted branching backend accepts[inbucket], and the current CLI still parses it locally (with a deprecation warning), so it satisfies both.Environment
Related
local_smtpname)databasePoolMode, breaks on branches/projects that omit it #5726 (same class: strict decode on the hosted side breaking on config the CLI emits)