Repository navigation
chore: production deploy - #7549
Open
supabase-cli-releaser[bot] wants to merge 26 commits into
Open
supabase-cli-releaser[bot] wants to merge 26 commits into
supabase-cli-releaser[bot] wants to merge 26 commits into
Conversation
supabase-cli-releaser
Bot
commented
Nov 10, 2026
supabase-cli-releaser
Bot
commented
Contributor
- 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>
supabase-cli-releaser
Bot
requested review from
a team and
supabase-oss
as code owners
November 10, 2026 02:15
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<br/>on this machine"] --> port{{"api port<br/>reads the first byte"}}
ctr["auth, studio,<br/>functions, db"] -- "via loopback" --> port
lan["lan peer"] --> port
port -- "tls hello" --> https["https<br/>the api, for anyone"]
port -- "anything else" --> who{"from loopback?"}
who -- "no" --> closed["closed<br/>nothing sent back"]
who -- "yes" --> named{"stack Host?"}
named -- "no" --> misdirected["421"]
named -- "yes" --> plain["plain http<br/>the api, /email templates<br/>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 branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.