fix(cli): reload kong after db reset by 7ttp · Pull Request #6017 · supabase/cli

7ttp · 2026-07-31T04:59:33Z

TL;DR

fixes /auth/v1/* (and any gateway route) returning 502 forever after supabase db reset, which was happening because the reset restarts auth/storage/
realtime/pooler but Kong's nginx keeps dialling their old cached container IPs for the life of its process. Now sorted by running an in-place kong reload after the satellite restarts (the same pattern functions serve uses), so the gateway re-resolves the moved containers while staying up the whole time

skipped cleanly, when Kong is absent/stopped, loud failure instead of a silent broken gateway
otherwise.

ref:

closessupabase db reset can leave Kong routing to a stale container IP, causing 502 on /auth/v1/* #6016

…ves upstream addresses

Coly010

Nice fix for the 502-after-reset issue, love it. Left two comments below — nothing major, just want to make sure they're deliberate before this merges.

AlbinoGeek · 2026-08-01T07:32:56Z

Man you rock. I reported this yesterday and you already solved it. @7ttp
I would have, but I read the PR policy and saw I had to wait haha.

7ttp · 2026-08-01T08:03:02Z

Man you rock. I reported this yesterday and you already solved it. @7ttp I would have, but I read the PR policy and saw I had to wait haha.

haha :) thanks a ton for reporting! 💚
also yeah its currently available in our beta channel
https://github.com/supabase/cli/releases/tag/v2.111.1-beta.2

Please do let us know, if you find anything else

AlbinoGeek · 2026-08-01T09:07:28Z

@7ttp Dumb question, how do I opt-in to the beta channel without having to manually install each version? Is there some documentation on that? (I don't really care the method, I use brew, dnf, uv, bunx, whatever.)

7ttp · 2026-08-01T09:36:57Z

@7ttp Dumb question, how do I opt-in to the beta channel without having to manually install each version? Is there some documentation on that? (I don't really care the method, I use brew, dnf, uv, bunx, whatever.)

totally not dumb at all :)

npm/bunx (the reliable one rn): we publish a beta dist-tag — bunx supabase@beta ...
resolves the newest beta on every run or maybe js do npm i -g supabase@beta
brew: brew install supabase/tap/supabase-beta auto-tracks via brew upgrade
scoop on windows: scoop install supabase-beta, same idea

dnf's the one real gap we attach .rpms to each github release but there's no dnf repo to subscribe to, so nothing to auto-track, bunx is the way on fedora.

supabase --version after installing confirms the channel ya took off :)

PS: it's not undocumented tho/btw the install sec of the repo README lists all three channel variants,
thereforeee that's ur docs link 😄

## TL;DR fixes custom auth email templates silently reverting to GoTrue's built-in defaults after `db reset`, `functions serve` (every hot reload) and `branch switch` `kong reload` re-renders nginx.conf from Kong's default template, dropping the `:8088` email-templates server that only bring-up's `--nginx-conf` defines. Every reload now hands that template back.... Third pass on this argument: - PS: first complete one: supabase#5906 added it to `functions serve`'s reload supabase#5976 reverted it for Go parity ("reload reuses the prefix bring-up prepared" it doesn't) and - supabase#6017's new `db reset` reload (fixing issue supabase#6016's 502s) shipped bare on the same assumption. Fixing Go's call sites too removes the parity argument, so this can't be reverted on parity grounds a fourth time. supabase#6017's DNS re-resolution is unchanged. verified 502→200 on a rotated container IP with the new argv. Broken stacks self-heal on the next reset. A template-less container (only one never created by `supabase start`, written unconditionally since the start) now fails the reload loudly, fatal in `db reset`, stderr warning in `functions serve`/`branch switch`...... <details><summary>repro / before vs after</summary> Real stack, kong's `StartedAt` never changes (container never restarted): 0. after supabase start listeners=[8000 8001 8088 8443 8444] template=custom ✓ 1. after BASELINE db reset listeners=[8000 8001 8443 8444] template=REFUSED → built-in default 2. after FIXED db reset listeners=[8000 8001 8088 8443 8444] template=custom ✓ - supabase#6016 non-regression: warm 200 → rotate auth IP → 502 502 502 → new reload → 200, :8088 intact. </details> ## ref: - closessupabase#6059

…tudio E2E `Start supabase` flake) (#49198)  _Requested by **Ivan Vasilov** · [Slack thread](https://supabase.slack.com/archives/C063LNYJJKS/p1787058646458219?thread_ts=1787058646.458219&cid=C063LNYJJKS)_ **Before:** the root `package.json` pins the Supabase CLI at `supabase: ^2.76.10`, and `pnpm-lock.yaml` resolves it to `2.76.14`. **After:** it pins `supabase: ^2.114.0`. This bumps the Supabase CLI that `pnpm run e2e:setup:cli` and `pnpm run setup:cli` shell out to, so local dev and the E2E workflows boot the local stack with a CLI from this month instead of one from ~38 minor releases ago. **How:** a one-line version change to the `supabase` devDependency in the root `package.json`. Nothing else in the repo changes — no workflow, config, or test changes. ### ⚠️ This PR is incomplete: `pnpm-lock.yaml` still needs regenerating `pnpm-lock.yaml` is **not** updated in this PR, so `pnpm install --frozen-lockfile` will fail until someone runs: ```bash pnpm install --lockfile-only ``` and pushes the result to this branch. The lockfile could not be regenerated in the environment this PR was authored in: pnpm re-resolves `apps/studio`'s `"@std/path": "npm:@jsr/std__path@^1.0.8"` on every install, and `npm.jsr.io` is not reachable from there (`ERR_PNPM_FETCH_403`). Treat this PR as needing one extra commit before it can go green. ### Why `^2.114.0` and not `^2.115.0` `2.115.0` is the current `latest` on npm, but it was published only hours ago, and `pnpm-workspace.yaml` sets `minimumReleaseAge: 4320` (3 days) with `supabase` not in `minimumReleaseAgeExclude`. Pinning `2.115.0` today would fail the repo's own supply-chain check. `2.114.0` (2026-08-12) is the newest release that satisfies that policy. ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? Dependency bump. **Speculative** — this is an experiment, not a confirmed fix. ## What is the current behavior? The `Selfhosted Studio E2E Tests` workflow has been failing on `master` at the `Start supabase` step. Recent runs: - https://github.com/supabase/supabase/actions/runs/32092940311 - https://github.com/supabase/supabase/actions/runs/32131961447 In the Slack thread, Ivan Vasilov suggested trying a newer CLI and Alaister Young endorsed giving it a go. ## What is the new behavior? The workflow runs `supabase start` with CLI 2.114.0 instead of 2.76.14. The question this PR is trying to answer is simply **"does a newer CLI help this flake?"** It is not a diagnosis and not a claimed fix. If CI still fails at `Start supabase` on this branch, the bump can be kept or dropped on its own merits and the investigation continues elsewhere. ## Additional context **Verification status:** none locally. The bump was not exercised locally — this repo checkout has no `node_modules` (see the lockfile note above), so `pnpm typecheck`, `pnpm lint`, and `pnpm test:studio` were not run, and neither was `supabase start`. CI on this PR is the only signal. **Call-site compatibility check.** CLI 2.99/2.100 moved to a new TypeScript shell with a stricter argument parser: command-specific flags must now come *after* the subcommand. Both call sites in the root `package.json` already use that order, so no script changes are needed: ``` supabase stop --all --no-backup --workdir ./e2e/studio supabase start --exclude studio,mailpit --workdir ./e2e/studio ``` **Changelog entries between 2.76.14 and 2.114.0 that touch `supabase start` or local config.** Listed so reviewers know what changed in the range — **not** as a claim about what is failing in CI: - **2.112.0** — `supabase start` no longer hangs when analytics migrations fail; the analytics container exits and retries instead of booting against an unmigrated database ([#6093](supabase/cli#6093)). - **2.112.0** — `supabase start` reuses existing volumes instead of failing when they already exist ([#6037](supabase/cli#6037)); Kong reloads after `supabase db reset` ([#6017](supabase/cli#6017)); custom auth email templates survive `db reset` ([#6065](supabase/cli#6065)); `supabase start` works on SELinux-enforcing hosts ([#6000](supabase/cli#6000)). - **2.106.0 — behavior change worth watching.** `[api].auto_expose_new_tables` now resolves to `false` when unset, and local start/reset revokes default Data API privileges for newly created `public` tables, sequences, and functions ([#5524](supabase/cli#5524)). Neither `supabase/config.toml` nor `e2e/studio/supabase/config.toml` sets this key, so this default applies. If E2E specs create `public` objects and then read them through the Data API, they may need explicit `GRANT`s (the deprecated escape hatch is `auto_expose_new_tables = true`). - **2.106.0** — when the CLI detects a coding-agent environment, or `--agent yes` is passed, commands default to JSON output ([#5532](supabase/cli#5532)). `e2e:setup:cli` already passes `--output json` to `supabase status` explicitly, so this should be a no-op here. - **2.100.0** — stricter flag ordering, covered above. - **2.112.0** — `functions deploy` no longer forwards `NPM_AUTH_TOKEN` into Docker bundling ([#6005](supabase/cli#6005)). Not used by these workflows. - **2.107.0** — pg-delta is the default schema diff engine for `db diff` / `db pull` on new projects ([#5511](supabase/cli#5511)). - Many bundled Docker image bumps across the range (`supabase/postgres` 17.6.1.087 → later patches, `postgres-meta`, `vector` 0.28.1 → 0.53.0, Studio image), plus `fix(analytics): wait for logflare before starting vector` (2.84.3) and `fix: use correct docker.sock binding with vector` (2.84.7). Full comparison: supabase/cli@v2.76.14...v2.114.0 --- _Generated by [Claude Code](https://claude.ai/code/session_0143DrDMGnSSwuHebTPJv7ZY)_ --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>

- extends: supabase#6017 - follows the same pattern as: supabase/supabase#47846

fix(cli): reload kong after db reset restarts services so it re-resol…
e61ef9a
…ves upstream addresses

7ttp requested a review from a team as a code owner July 31, 2026 04:59

7ttp self-assigned this Jul 31, 2026

Coly010 requested changes Jul 31, 2026
View reviewed changes

Comment threadapps/cli-go/internal/db/reset/reset.go Outdated
Comment threadapps/cli-go/internal/db/reset/reset_test.go

nit: surface kong reload output and recovery hint on reset failures
7f28d99

Coly010 approved these changes Jul 31, 2026
View reviewed changes

Coly010 added this pull request to the merge queue Jul 31, 2026

Merged via the queue into supabase:develop with commit 08be342Jul 31, 2026
30 checks passed

7ttp deleted the fix/db-reset-restart-kong branch August 1, 2026 08:03

supabase-cli-releaserBot mentioned this pull request Aug 4, 2026
chore: production deploy #6056
Merged

7ttp mentioned this pull request Aug 4, 2026
fix(cli): keep kong email templates #6065
Merged

avallete mentioned this pull request Aug 7, 2026
docs(release): notes for v2.112.0 #6114
Closed

claudeBot mentioned this pull request Aug 18, 2026
chore(deps): bump Supabase CLI to ^2.114.0 (speculative: Selfhosted Studio E2E Start supabase flake) supabase/supabase#49198
Merged

rytkhs mentioned this pull request Aug 23, 2026
Supabase CLIを更新し、db reset後のKong接続エラーを解消する rytkhs/event-pay#555
Open
7 tasks

7ttp mentioned this pull request Aug 25, 2026
fix(cli): cap kong dns cache ttls #6324
Merged

pullBot pushed a commit to chizee/cli that referenced this pull request Aug 25, 2026
fix(cli): cap kong dns cache ttls (supabase#6324)
38f31b4
- extends: supabase#6017 - follows the same pattern as: supabase/supabase#47846

Navigation Menu

Uh oh!

fix(cli): reload kong after db reset - #6017

fix(cli): reload kong after db reset#6017
Coly010 merged 2 commits into
supabase:developfrom
7ttp:fix/db-reset-restart-kong

7ttp commented Jul 31, 2026

Uh oh!

Coly010 left a comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AlbinoGeek commented Aug 1, 2026

Uh oh!

7ttp commented Aug 1, 2026

Uh oh!

AlbinoGeek commented Aug 1, 2026

Uh oh!

7ttp commented Aug 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

7ttp commented Jul 31, 2026

TL;DR

ref:

Uh oh!

Coly010 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

AlbinoGeek commented Aug 1, 2026

Uh oh!

7ttp commented Aug 1, 2026

Uh oh!

AlbinoGeek commented Aug 1, 2026

Uh oh!

7ttp commented Aug 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants