chore: production deploy by supabase-cli-releaser[bot] · Pull Request #7549 · supabase/cli

supabase-cli-releaser · 2026-11-10T02:15:40Z

chore(stack): bump realtime to v2.154.1-r0 (chore(stack): bump realtime to v2.154.1-r0 #7543)
chore(stack): bump storage to v1.90.2-r0 (chore(stack): bump storage to v1.90.2-r0 #7544)
chore(api): sync Management API OpenAPI spec (chore(api): sync Management API OpenAPI spec #7541)
chore(stack): bump realtime to v2.155.0-r0 (chore(stack): bump realtime to v2.155.0-r0 #7547)
chore(stack): bump realtime to v2.156.0-r0 (chore(stack): bump realtime to v2.156.0-r0 #7548)

This bumps realtime from v2.154.0-r0 to v2.154.1-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.154.1-r0 Planned after supabase/slim-services published v2.154.1-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps storage from v1.90.1-r0 to v1.90.2-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.90.2-r0 Planned after supabase/slim-services published v1.90.2-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This PR was automatically created to sync the generated `@supabase/api` package with the latest Management API OpenAPI document. Changes were detected in the upstream OpenAPI documents exposed by `https://api.supabase.com/api/v1-json` and `https://api.supabase.com/api/v2-json`. --------- Co-authored-by: jgoux <1443499+jgoux@users.noreply.github.com> Co-authored-by: Julien Goux <hi@jgoux.dev>

This bumps realtime from v2.154.1-r0 to v2.155.0-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.155.0-r0 Planned after supabase/slim-services published v2.155.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps realtime from v2.155.0-r0 to v2.156.0-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.156.0-r0 Planned after supabase/slim-services published v2.156.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This PR was automatically created to sync the generated `@supabase/api` package with the latest Management API OpenAPI document. Changes were detected in the upstream OpenAPI documents exposed by `https://api.supabase.com/api/v1-json` and `https://api.supabase.com/api/v2-json`. Co-authored-by: jgoux <1443499+jgoux@users.noreply.github.com>

This bumps storage from v1.90.2-r0 to v1.91.0-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.91.0-r0 Planned after supabase/slim-services published v1.91.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

…7545) ## TL;DR stops the stack refusing to start when `[storage.analytics]` is enabled or vector buckets are declared ## whats hurting? `supabase start` on the stack exits w `storage.analytics.enabled is unsupported by the experimental stack` or `storage.vector settings are unsupported by the experimental stack`while the legacy backend starts fine with the same config ## now fixed by? dropping both checks, so the stack accepts analytics and seeds vector buckets on first start like the legacy backend the settings the stack still rejects now have their error messages documented > [!NOTE] > `/storage/v1/iceberg` still returns 404 locally, left for a separate decision ## ref: - closes: CLI-2582

This bumps storage from v1.91.0-r0 to v1.92.0-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.92.0-r0 Planned after supabase/slim-services published v1.92.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps storage from v1.92.0-r0 to v1.92.2-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.92.2-r0 Planned after supabase/slim-services published v1.92.2-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps postgres from 17.11.0.018-r0 to 17.11.0.019-r0. https://github.com/supabase/slim-services/releases/tag/postgres-17.11.0.019-r0 Planned after supabase/slim-services published 17.11.0.019-orioledb-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This adds postgres 17.11.0.019-orioledb-r0 as a new release line. https://github.com/supabase/slim-services/releases/tag/postgres-17.11.0.019-orioledb-r0 Planned after supabase/slim-services published 17.11.0.019-orioledb-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps postgres from 15.19.0.018-r0 to 15.19.0.019-r0. https://github.com/supabase/slim-services/releases/tag/postgres-15.19.0.019-r0 Planned after supabase/slim-services published 17.11.0.019-orioledb-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps storage from v1.92.2-r0 to v1.92.3-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.92.3-r0 Planned after supabase/slim-services published v1.92.3-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps realtime from v2.156.0-r0 to v2.156.1-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.156.1-r0 Planned after supabase/slim-services published v2.156.1-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps storage from v1.92.3-r0 to v1.94.0-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.94.0-r0 Planned after supabase/slim-services published v1.94.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps realtime from v2.156.1-r0 to v2.156.2-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.156.2-r0 Planned after supabase/slim-services published v2.156.2-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

I moved plan-gate handling out of each command into shared code. Since #7271, `mapHttpError` attaches `entitlement` from the Management API's `entitlement_required` body, so the upgrade hint, the `cli_upgrade_suggested` event and the `plan_limit` classification now all come from that one field, with no per-command wiring and no extra requests. **Changed:** - **One hint and one event per gated denial, wired or not**: the text error renderer prints the upgrade hint before the error message, and `withCommandTelemetry` captures `cli_upgrade_suggested` (same name, same `{feature_key, org_slug}` payload) after the command, just before `cli_command_executed`. Commands that never had wiring, such as `branches unpause`, now get both. `vanity-subdomains check-availability` now fires the event too; its no-event exception only existed for parity with the removed Go CLI. - **No per-command gate code or follow-up lookups**: I deleted the `gateMapError`/`suggestUpgrade` wrapping at `branches create`/`update`, the four `domains` commands and the three `vanity-subdomains` commands. `branches update` no longer fetches the project and org entitlements after a 4xx, since the persistent-branch 402 carries the envelope. Only the SSO commands keep the entitlements lookup. - **`plan_limit` from the envelope**: an error carrying `entitlement` classifies as `plan_limit` whatever its class declares, so gated denials from `branches unpause`, `domains get`/`create`/`activate`/`reverify` and `vanity-subdomains get` move from `api_status` to `plan_limit` (fingerprint suffix `:api_status` becomes `:plan_limit`). **Note:** the event moved from mid-handler to post-run. Payload and identity stay the same; it uses the same capture context as `cli_command_executed`. ## Linear - part of GROWTH-1050

## TL;DR `stack start` now supports `[api.tls]`, serving https on the api port with legacy's cert while containers keep plain http over loopback. ## whats introduced? - one port, both protocols. a tls hello gets https from anyone, plain http is served only to loopback, and any other peer is closed with nothing sent back - host urls move to https (`API_URL`, auth links, studio's public url, the functions banner), while containers and `pg_net` keep their plain runtime urls - legacy's embedded cert by default, or your own `cert_path` and `key_path`. the cert must cover `127.0.0.1` and is checked before anything starts, then saved with the stack for `storage` commands - every start and restart that serves tls on docker or podman ends with the db container reading a reply only this stack and this start can give. if containers don't reach the api from loopback, start fails with `unsupported networking` and stops the stack - works on docker desktop, colima and podman machine on macos. linux docker and podman deliver containers from a bridge or host address, so a tls start fails there - tls on or off applies on the next `stack start`, and without it nothing changes ## visual rep: ```mermaid flowchart LR host["cli, sdk, browser on this machine"] --> port{{"api port reads the first byte"}} ctr["auth, studio, functions, db"] -- "via loopback" --> port lan["lan peer"] --> port port -- "tls hello" --> https["https the api, for anyone"] port -- "anything else" --> who{"from loopback?"} who -- "no" --> closed["closed nothing sent back"] who -- "yes" --> named{"stack Host?"} named -- "no" --> misdirected["421"] named -- "yes" --> plain["plain http the api, /email templates and the start check"] https -. "/email" .-> hidden["404"] classDef t fill:transparent class host,ctr,lan,port,https,who,closed,named,misdirected,plain,hidden t ``` ## ref - closes: CLI-2584 - supersedes: #6803

## Summary Adds `supabase config convert`, which rewrites `supabase/config.toml` as `supabase/config.jsonc` and removes the TOML file. - **Lossless or nothing.** Values come from the TOML parser. The JSONC output is re-parsed and compared with the source before anything is written; if they differ, the command refuses and leaves `config.toml` untouched. - **Same document.** Keys and `env()` strings are unchanged. `$schema` comes from the `#:schema` directive, or the current schema URL when there is none. - **Comments survive.** Comments are carried to the matching member. Commented-out TOML examples (as in the `init` template) become commented-out JSONC inside the right table, and each one can be uncommented on its own. Any comment that has to move is reported. - **Warnings before writing.** It prints the minimum CLI version that reads `config.jsonc`, with an undo command. `--dry-run` shows the result without writing. Running it on a project that already uses JSON exits 0 and does nothing. - **VS Code.** When `.vscode/settings.json` exists, it trusts the Supabase schema domain without overriding a value already set. `init`'s settings merge now keeps comments in that file. - **Schema.** The CLI config JSON schema sets `allowTrailingCommas: true`, so VS Code doesn't flag the trailing commas the converter writes. The converter lives in `@supabase/config/internal`. The TOML scanner moved out of `config-edit.ts` into `toml-scan.ts` so both can share it. ## Linked issue CLI-2867

This PR was automatically created to sync the generated `@supabase/api` package with the latest Management API OpenAPI document. Changes were detected in the upstream OpenAPI documents exposed by `https://api.supabase.com/api/v1-json` and `https://api.supabase.com/api/v2-json`. Co-authored-by: jgoux <1443499+jgoux@users.noreply.github.com>

…7571) ## TL;DR fixes edge functions on the stack connecting to the database as the `supabase_admin` superuser instead of `postgres` ## whats hurting? on the stack, `SUPABASE_DB_URL` inside a function pointed at `supabase_admin`, while the legacy backend and deployed functions get `postgres` so a function could run superuser only sql locally that fails once deployed tables a function created were also owned by `supabase_admin`, so migrations and `db query` as `postgres` could not alter them ## now fixed by? the stack hands functions a `postgres` role url, on `supabase start` and on `functions serve` a stack created before this picks it up on its next `stack start`, while `stack restart` keeps the saved value ## ref: - missed in: #6684

This bumps realtime from v2.156.2-r0 to v2.157.0-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.157.0-r0 Planned after supabase/slim-services published v2.157.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Towards FUNC-954

This bumps realtime from v2.157.0-r0 to v2.158.0-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.158.0-r0 Planned after supabase/slim-services published v2.158.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps realtime from v2.158.0-r0 to v2.158.1-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.158.1-r0 Planned after supabase/slim-services published v2.158.1-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

This bumps realtime from v2.158.1-r0 to v2.159.0-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.159.0-r0 Planned after supabase/slim-services published v2.158.3-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

## TL;DR The idle-race listener tests now build their namespace and network on the live clock, so a busy port registry can no longer hang their setup. - `Orchestrator.integration.test.ts › idle races through a real listener › keeps serving a request admitted before the idle timer fires, from the same generation`: the test timed out at 30s before it ever woke `api`. Its setup builds `Network.layer` under `TestClock`, and that layer opens the host-wide `ports.sqlite`. When a parallel test file holds the registry while it switches to WAL, the open retries a busy error on `Schedule.spaced`. A `TestClock` never advances that schedule, so the setup waits forever. The fix builds the namespace and network inside `TestClock.withLive`, while the idle timers stay on the test clock. ## ref spotted in: https://github.com/supabase/cli/actions/runs/43022568228/job/130529128277 --- _Generated by [Claude Code](https://claude.ai/code/session_01MBEk1LwFZcUPPWEHj5HHqU)_ Co-authored-by: Claude <noreply@anthropic.com>

#7590) ## TL;DR If the listener resets the connection before the api.tls start check probe writes its request, the probe now reports a close instead of "can't reach". - `Owner.integration.test.ts › checks container reach under api.tls after every start and restart, and keeps it on a database recompose`: the test got `containers can't reach the api port … Engine exited with 141` when it expected `unsupported networking`. The cause is in the probe script. When a loopback-only listener reset the connection before the `printf >&3` write, bash died of SIGPIPE, and that exit was mapped to the unreachable outcome. Users could get the same wrong diagnosis. The probe now ignores SIGPIPE and reports a failed write as a close, so `readApiTlsCheck` returns `closed`. The new probe test resets each connection on accept and holds the request until the reset arrives. It fails on the old script every time. ## ref spotted in: https://github.com/supabase/cli/actions/runs/43023235482/job/130533022484 --- _Generated by [Claude Code](https://claude.ai/code/session_01MBEk1LwFZcUPPWEHj5HHqU)_ --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Julien Goux <hi@jgoux.dev>

## TL;DR `supabase start` now doubles the bulk service health budget (30s → 60s) when Logflare or Vector is started, and gives both containers a 60s health start period so Docker keeps probing them every second until they first pass. - `start.health.e2e.test.ts › starts Vector against a real Logflare and reaches healthy`: `start` failed with both `supabase_analytics_*` and `supabase_vector_*` unhealthy (`connection refused`), even though the container logs show Logflare up and Vector's API bound moments before the wait ended. Logflare runs its migrations before serving `/health`, and Vector's entrypoint waits for Logflare before starting, so the two boot in series and a slow Logflare boot used up the shared 30s wait. - Both containers also outlived their 10s health start period, after which Docker probes only every 10s, so their health status lagged real readiness by up to 10s each, in series. A 60s start period keeps the 1s `--health-start-interval` probes running through the boot, so health turns `healthy` about a second after each service answers. Engines without start-interval support keep the 10s cadence. - `start/SIDE_EFFECTS.md` documents both. ## ref spotted in: https://github.com/supabase/cli/actions/runs/42607394881/job/129126733423 --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Julien Goux <hi@jgoux.dev>

… (#7584) ## TL;DR adds `[api] db_pool` to `config.toml` so local `supabase start` and the stack can size the PostgREST connection pool. ## whats introduced? `db_pool` sets the pool size, 1 or more, and is passed to PostgREST as `PGRST_DB_POOL` on both `supabase start` and the stack. when it is unset nothing is passed, so existing projects keep the pool they have today. `SUPABASE_API_DB_POOL` overrides it like any other config key, and a `0` fails at load naming the file or env var it came from. it stays local, so `config push`, `config pull` and `config diff` never touch the linked project's pool. ## why? the stack and the slim images bake in a pool of 2, so local tests firing concurrent Data API calls queue behind two connections. setting `api.db_pool` only printed an unknown key warning, with no way to change it. ## ref - closes: #7566

…) (#7577) ## Summary `cli_command_executed` doesn't say which config file format a project uses, so there's no way to see how many projects have moved to `config.jsonc`. This adds a `config_format` property (`toml`, `json` or `jsonc`) to the event. - `CliConfigValues.load` records it through the existing `recordCommandTelemetry` sink once the config file is read, the same place `config_key` is recorded - The value comes from the file extension, because the parsed document's `format` is `json` for both `.json` and `.jsonc` - It's recorded on failures too, including a file that fails to parse (taken from the error's `path`), so error rates can be split by format - Commands that never load the project config, and projects without a config file, omit it - `apps/cli/docs/analytics.md` documents the new property ## Linked issue Closes CLI-2988

… the release (#7542) ## Current Behavior The setup-cli smoke test fails a v3 job when setup-cli installs from the GitHub release instead of npm. Because that job runs inside the release workflow, the whole release run goes red: the "released" Slack message is skipped and a generic "release failed" message is sent, even though every channel published and the fallback installed the right version. ## Expected Behavior A fallback to the GitHub release emits a warning annotation and the job stays green. The fallback is also exported as a workflow output, passed through `release-shared.yml` to `release.yml`, and added as a notice to the "released" Slack message, so the signal is kept without marking the release as failed. The dedicated fallback job still checks that the fallback path works, and a fallback that installs the wrong version still fails the version check. The workflow change needs a cherry-pick to active `v*.x` branches.

This bumps storage from v1.94.0-r0 to v1.94.2-r0. https://github.com/supabase/slim-services/releases/tag/storage-v1.94.2-r0 Planned after supabase/slim-services published v1.94.1-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

…7592) Without the stack opt-in, `supabase start --runtime native` reaches the legacy `start`. That command fails with a bare `Unrecognized flag: --runtime`, which gives no clue that the flag belongs to the stack backend. When the legacy backend rejects a flag that the stack version of the same command accepts, the error now names the opt-in: ``` Unrecognized flag: --runtime in command supabase start Hint: --runtime needs the stack backend. Set SUPABASE_EXPERIMENTAL_STACK=1, or set stack = true under [experimental] in your project config and leave SUPABASE_EXPERIMENTAL_STACK unset. ``` - The CLI builds the root that the stack opt-in would select and passes it to the parse-error formatters. The hint appears only when that root's command at the same path accepts the rejected flag. - This covers every stack-only flag on `start`, `stop` and `status` without a hand-kept list. A flag that neither backend accepts gets no hint. - Text and JSON output both carry the hint. Error codes are unchanged.

## TL;DR fixes the stack replaying `supabase/roles.sql` on a later start and running it as `supabase_admin` ## what's missing? adding or dropping a service between starts ran `roles.sql` again, so a plain `create role` failed with `role "…" already exists` it also ran as `supabase_admin` instead of `postgres`, so a migration using a schema from `roles.sql` failed with `permission denied for schema` ## now fixed by? the stack runs it once on first setup, as `postgres`, like the legacy backend <details><summary>visual rep</summary> ```mermaid flowchart TD A["roles.sql create role app_user; create schema app"] --> B["first supabase start"] B -- before --> C["runs as supabase_admin app owned by supabase_admin"] C -.-> D["migration: create table app.t permission denied for schema app"] B -- now --> E["runs as postgres app owned by postgres"] E --> F["migration: create table app.t ok"] B --> G["stop, then start with another service set"] G -- before --> H["roles.sql runs again"] H -.-> I["role app_user already exists start fails"] G -- now --> J["roles.sql already applied start ok"] classDef t fill:transparent classDef bad fill:transparent,stroke-dasharray:5 4 class A,B,C,E,F,G,H,J t class D,I bad ``` </details> ## ref: - missed in: #6684

Bumps `@supabase/typegen` to 0.3.3, which pulls in `@supabase/postgrest-typegen` 0.8.0. That release infers column nullability for functions that `RETURNS TABLE`, so `supabase gen types` emits more accurate return types for those functions. The `minimumReleaseAgeExclude` entries in `pnpm-workspace.yaml` move to the new versions. Release notes: [typegen 0.3.3](supabase/sdk#354), [postgrest-typegen 0.8.0](supabase/sdk#353).

…ses (#7594) ## Summary - Reject `db.major_version = 13` at config validation with a dedicated message that points to the Postgres upgrade guide and names Postgres 17 as the target, alongside the existing 12.x message. Accepted values are now 14, 15 and 17. - Delete the Postgres 13.3 initial schema dump and the 13 branch in local database setup. - Drop the mapping that sent 13 to the Postgres 15 image. - `supabase start` and `supabase db start` print a stderr `WARNING:` when `db.major_version = 14`: Postgres 14 reached end of life on November 12, 2026, and the CLI will drop support for it soon. The warning names Postgres 17 as the upgrade target, links the upgrade guide, and prints before the already-running check, so it shows up on every start. ## Context The CLI ships no Postgres 13 image, so a v13 config already booted Postgres 15 with the 13.3 schema loaded on top. Stack mode already rejects anything other than 15 or 17. Postgres 14 support will be removed in a follow-up once the remaining projects have upgraded.

A config that still uses a removed key, such as an old `[inbucket]` section, makes `supabase start` fail. The error says the key is unsupported, but it ends with the generic "Try rerunning the command with --debug" tip, which doesn't help fix the config. `CliConfigRemovedKeyError` now carries its own suggestion, which replaces that tip in text and JSON output. A config with one removed key prints: ``` inbucket in supabase/config.toml is no longer supported. Use local_smtp instead. Update supabase/config.toml, then rerun the command. ``` A config with several removed keys prints: ``` supabase/config.toml uses config keys that are no longer supported: inbucket: use local_smtp instead. auth.external.slack: use auth.external.slack_oidc instead. Update supabase/config.toml, then rerun the command. ``` - Removed keys are named by their dotted path instead of TOML table syntax (`inbucket`, not `[inbucket]`), so the message reads the same for `config.toml` and `config.jsonc`. The file name already comes from the loaded path. - Legacy `start` and the stack backend's `start`, `install`, `update` and `outdated` pass the suggestion through from the config error. - It stays a hard error with exit 1. Error codes are unchanged.

This bumps realtime from v2.159.0-r0 to v2.160.0-r0. https://github.com/supabase/slim-services/releases/tag/realtime-v2.160.0-r0 Planned after supabase/slim-services published v2.160.0-r0. This branch is rewritten from develop whenever a newer relevant release arrives. Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>

Bumps `@supabase/typegen` to 0.3.4, which pulls in `@supabase/postgrest-typegen` 0.8.1. On PostgreSQL 14, `supabase gen types` now infers which view columns and `RETURNS TABLE` function columns are non-null, as it already did on PostgreSQL 15 and later. Before, every such column on a PostgreSQL 14 database was typed as nullable. Output on PostgreSQL 15 and later is unchanged. The `minimumReleaseAgeExclude` entries in `pnpm-workspace.yaml` move to the new versions. Release notes: [typegen 0.3.4](supabase/sdk#358), [postgrest-typegen 0.8.1](supabase/sdk#357).

…7602) The Docker `idle and wake` e2e occasionally fails with `Engine command 'start' did not finish within 30s` and empty stderr, which does not say whether the engine stalled before or after starting the process. When `start` times out, the launch error now includes the container's status, start time, pid, and engine error from `docker inspect`, so the next failure shows where it stalled.

…fixtures (#7601) The Management API sync makes `external_email_magic_link_disabled` a required field in the auth config response, so replayed fixtures without it fail to decode and `config push` exits 1. Adding the field to the recorded and scenario fixtures first lets the sync PR pass; unknown fields are ignored by the current schema, so this is safe before the sync lands.

This PR was automatically created to sync the generated `@supabase/api` package with the latest Management API OpenAPI document. Changes were detected in the upstream OpenAPI documents exposed by `https://api.supabase.com/api/v1-json` and `https://api.supabase.com/api/v2-json`. Co-authored-by: jgoux <1443499+jgoux@users.noreply.github.com> Co-authored-by: Julien Goux <hi@jgoux.dev>

supabase-cli-releaser Bot and others added 5 commits November 9, 2026 13:33

supabase-cli-releaser Bot requested review from a team and supabase-oss as code owners November 10, 2026 02:15

supabase-cli-releaser Bot added the do not merge Approve to apply; do not merge. label Nov 10, 2026

supabase-cli-releaser Bot requested a review from Coly010 November 10, 2026 02:15

supabase-cli-releaser Bot and others added 15 commits November 10, 2026 09:23

github-merge-queue Bot deployed to config-release November 11, 2026 11:16

View deployment

supabase-cli-releaser Bot and others added 4 commits November 11, 2026 11:20

feat(cli): experimental compute - add secrets scope field (#7531)

4231a82

Towards FUNC-954

github-merge-queue Bot deployed to config-release November 11, 2026 13:10

View deployment

supabase-cli-releaser Bot and others added 7 commits November 11, 2026 22:31

github-merge-queue Bot deployed to config-release November 12, 2026 09:20

View deployment

Coly010 and others added 8 commits November 12, 2026 09:44

github-merge-queue Bot deployed to config-release November 12, 2026 12:11

View deployment

supabase-cli-releaser Bot and others added 5 commits November 12, 2026 12:21

Navigation Menu

Repository navigation

chore: production deploy - #7549

chore: production deploy#7549
supabase-cli-releaser[bot] wants to merge 44 commits into
mainfrom
develop

supabase-cli-releaser Bot commented Nov 10, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

Conversation

supabase-cli-releaser Bot commented Nov 10, 2026

Uh oh!

This branch was successfully deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants