mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 01:15:03 +03:00
2013ebf417f01930f2b954fb3aa4ee8c463f88d1
2260
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Katerina Skroumpelou
|
2013ebf417 |
docs: drop alpha labels and pin server and middleware imports to a major (#51031)
## Problem `@supabase/middleware` ships as 1.0.0. The docs still label the `pipeline` entry form of `withSupabase` alpha, and several snippets import `npm:@supabase/server` and `npm:@supabase/middleware` with no version or with a `^0.5.0` pin. A snippet without a version leaves readers and tools to guess one, and a guessed version fails on deploy. ## Solution - Removes the alpha wording from the middleware reference intro and usage examples, the server frameworks partial, and the Bring your own MCP guide. The `@supabase/server` 1.6.0 floor stays. - Pins every `npm:@supabase/server` and `npm:@supabase/middleware` import in the guides to a major range, `@1`, following the `npm:@supabase/supabase-js@2` convention in Managing dependencies. - Bumps the authenticated-mcp-server example to middleware `^1.0.0` and server `^1.9.0`. ~~Blocked by supabase/middleware#49. The `@1` range resolves once 1.0.0 is on npm.~~ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated authentication, API key, and MCP examples to use versioned Supabase server and middleware packages. * Clarified that pipeline and nested composition behave the same, and that both require `@supabase/server` 1.6.0 or later. * Removed alpha-status labels from `withSupabase` guidance while retaining the 1.6.0 minimum-version requirement. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Andrey A.
|
e811d984ad | docs(auth): inline the Remix code in the OAuth troubleshooting (#50854) | ||
|
Andrey A.
|
c8b665caf2 | feat(self-hosted): add api gateway logic for functions (#46810) | ||
|
Steven Eubank
|
ad0ed2cdbc |
Update docs based on SRE Agent findings (#50910)
## Problem SRE Agent running against a project which is read-only due to disk being full. ## Solution The SRE agent struggled to find the information which is now included in this PR. <!-- ## Preview links If relevant, include links to changed pages for easy review access. Copy the preview base URL from the Vercel bot comment on this PR. Use the following table as an example template. | Site | Live | Preview | Search for | | -------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------- | | WWW | [/blog/your-post](https://supabase.com/blog/your-post) | [/blog/your-post](https://zone-www-dot-com-git-branch-name-supabase.vercel.app/blog/your-post) | unique phrase from the change | | Docs | [/docs/guides/your-page](https://supabase.com/docs/guides/your-page) | [/docs/guides/your-page](https://docs-git-branch-name-supabase.vercel.app/docs/guides/your-page) | unique phrase from the change | | Studio | [/dashboard](https://supabase.com/dashboard) | [/dashboard](https://studio-git-branch-name-supabase.vercel.app/dashboard) | unique phrase from the change | | Design system | [/design-system](https://supabase.com/design-system) | [/design-system](https://design-system-git-branch-name-supabase.vercel.app/design-system) | unique phrase from the change | | UI library | [/library](https://supabase.com/library) | [/library](https://ui-library-git-branch-name-supabase.vercel.app/library) | unique phrase from the change | | Knowledge base | [/kb/guides/your-page](https://supabase.com/kb/guides/your-page) | [/kb/guides/your-page](https://kb-git-branch-name-supabase.vercel.app/kb/guides/your-page) | unique phrase from the change | --> <!-- ## Additional context Optionally add any other context or screenshots. --> ## Review instructions - https://supabase.com/docs/guides/api/rest/postgrest-error-codes - https://supabase.com/docs/guides/observability/advanced-log-filtering - https://supabase.com/docs/guides/platform/database-size ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added guidance for recognizing platform-related PostgreSQL errors, including read-only mode, disk exhaustion, connection-pool limits, and database restarts or failovers. * Added SQL queries for grouping PostgreSQL errors and reviewing recent error events while filtering out selected platform-level codes. * Clarified that read-write transaction settings apply only to the current session, and that background writes resume automatically after read-only mode ends. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Saxon FletcherandClaude Opus 5.5
|
a9c594a820 |
chore(library): rename mcp-server block to mcp (#50999)
Renames the `mcp-server` Library block to `mcp`. Installing it now creates `supabase/functions/mcp`, so the server is served at `/functions/v1/mcp`. - Block, Edge Function folder, and docs page renamed (`/docs/headless/mcp`) - Headless App block now installs its tools into `supabase/functions/mcp` and configures `[functions.mcp]` - Links in the BYO MCP and MCP authentication guides updated - Permanent redirects keep `/r/mcp-server.json` and `/docs/headless/mcp-server` working - `public/r` rebuilt <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * The MCP Server block is now named `mcp` across its documentation, installation links, and setup instructions. * Updated function endpoints and deployment commands to use `/mcp`. * Added permanent redirects from the previous `mcp-server` documentation and install URLs to their new locations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com> |
||
|
Danny White
|
6b7c91a773 |
docs(pipelines): clarify ClickHouse setup and form copy (#51009)
## Problem The ClickHouse destination guide leaves parts of resource setup unclear. The pipeline form suggests the `default` ClickHouse user and database even when a dedicated user and database are prepared. ## Solution - Clarify the ClickHouse setup path, connection details, engine choice, and query example in the guide. - Align the pipeline form's labels, examples, and help text with that setup path. - Include **Start pipeline** in the BigQuery guide before the cost confirmation and **Create and start pipeline**. ## Review instructions 1. Open **Database → Pipelines**, add a pipeline, and choose **ClickHouse**. Check the endpoint label, user and database examples, and table engine help. 2. Read the [ClickHouse destination guide](https://supabase.com/docs/guides/database/replication/pipelines/clickhouse), especially **Prepare ClickHouse resources** and **Configure ClickHouse as a destination**. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the BigQuery guide to explain the pipeline validation, cost review, and start steps. * Expanded the ClickHouse guide with destination setup requirements, engine behavior, and querying guidance for current-state views and append-only history. * **User Experience** * Clarified ClickHouse connection field labels and descriptions, password visibility controls, and table-engine options in the setup form. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Pamela Chia
|
07c75e84fc |
fix(docs): repair internal content links (#51050)
I fixed stale links in six Docs pages. Guide links now include the Docs base path, and links to the old Database Hooks route point directly to the Dashboard Webhooks page. ## To test - Open the Logs ingest guide in the Docs preview and follow the updated guide links. Each destination should load. - Open each affected Docs page in the preview and follow its Webhooks link. The Dashboard Webhooks page should load after sign-in. ## Linear - fixes GROWTH-1301 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated webhook setup and troubleshooting links to point to the Integrations Webhooks dashboard. * Updated Postgres configuration and log-setting links to use current documentation paths. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Wen Bo Xie
|
ed6217a169 |
docs: clarify how owners and admins authorize MCP clients for enterprise auth (#50832)
The enterprise-managed MCP authentication guide said an organization owner authorizes the MCP client from the Authorized Apps page. That page only lists and revokes apps that are already approved, so readers had no way to follow the instruction. Approval actually happens when an owner or admin connects the MCP client through the standard sign-in flow and approves it for the organization on the consent screen. Both roles can grant that approval, not only owners. This updates the prerequisites, the validation step, the "why use it" summary, and the security considerations to: - Name owners and admins as the roles that can authorize the client - Describe the consent-screen approval as the way to authorize it - Point to Authorized Apps as the place to review or revoke approved clients |
||
|
Joshen Lim
|
fea8b8b41d |
Update copy RE disk configuration changes and cooldown (#50844)
## Context Reverts copy changes from the following PRs: - Docs: https://github.com/supabase/supabase/pull/42184 - FE: https://github.com/supabase/supabase/pull/47646 Our platform's disk management configuration limitation still follows the 4 hour cooldown at the moment, doesn't align with AWS's 4 changes in 24 hours rule just yet. This is just to prevent any confusion for now, and we'll need to update the copy again once behaviour matches AWS on our BE <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Disk changes are now subject to an approximately four-hour cooldown after each modification, replacing the previous limit of four changes in a rolling 24-hour period. * Disk management screens now show the cooldown status, remaining wait time, and next available update time. * Updated platform guides and troubleshooting instructions to reflect the cooldown and explain available recovery options. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Kody Jacksonandkodster28-happy-hour
|
708bfa7ad1 |
[docs] Fix broken links to '/guides/' paths (#50870)
## Problem There are several broken links within docs that reference `/guides/...`. These need to be updated to `/docs/guides/` to resolve correctly. ## Solution Updated links to resolve correctly ## Preview links If relevant, include links to changed pages for easy review access. TBD, waiting on build (unclear if this happens for external contributions). ## Review instructions 1. Navigate to the pages in the live/preview. 2. Click the links that were updated. ## Checklist Check all before review: - [x ] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated internal documentation links across API, Auth, Database, Functions, and troubleshooting guides to use the `/docs` paths. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: kodster28-happy-hour <kody@catholicestateplanning.com> |
||
|
Timothy LimandClaude Sonnet 5
|
80761d2521 |
docs(troubleshooting): Add guide for NXDOMAIN errors (#50969)
## Problem We get several tickets related to NXDOMAIN errors ## Solution Add guide to troubleshoot the issue, providing typical scenarios and workarounds ## Checklist Check all before review: - [X] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [X] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs [style guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide) Used `/write-the-docs` and then manually modified several things <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added troubleshooting guidance for `NXDOMAIN` errors when connecting to a project, covering possible causes, checks, and next steps. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
Wen Bo Xie
|
0eb08cb9f0 |
docs: prepare scoped personal access tokens docs for GA (#50839)
Scoped personal access tokens are leaving alpha. Remove the pre-GA framing and update pages that assumed every token carries full account access. - Personal Access Tokens guide: remove the public alpha / early access admonition. Add a section on using a scoped token with the Supabase CLI: the browser flow of `supabase login` creates a classic token, while SUPABASE_ACCESS_TOKEN or `supabase login --token` uses a scoped one, and commands that connect with the database password aren't limited by the token's permissions. - Management API introduction: replace "PATs carry the same privileges as your user account" with the scoped vs. classic distinction and link to the guide's permission tables. - MCP guide: the CI setup now asks for a scoped token limited to the connected project and links to the MCP tool permissions table. - API keys guide: replace the internal "fine-grained token" permission ID with the names shown in the dashboard (API Keys, Read), and note that `reveal=true` in the example also needs API Key Secrets (Read). - Managing environments: recommend a scoped token for the GitHub Actions deploy workflow. |
||
|
Danny White
|
b03448ec59 |
docs(pipelines): improve Snowflake setup guidance (#50715)
## Problem The Snowflake guide leaves several setup details open to interpretation, particularly how roles are used and which RSA key content belongs in Snowflake versus the Dashboard. This PR is stacked on #50751 so the documented role location, private-key upload, and **Start pipeline** action match the updated creation sheet. The full stack starts with #50708, which moves the guide to its nested Pipelines path. ## Solution Clarifies the setup sequence, explains the default and optional role behaviour, distinguishes `rsa_key.pub` from `rsa_key.p8`, and makes the destination field guidance more direct. ## To test - [Snowflake guide](https://docs-git-dnywh-docsimprove-snowflake-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/snowflake) ## Review instructions 1. Read the setup path from **Prepare Snowflake resources** through **Configure Snowflake as a destination**. 2. Confirm the role guidance explains what happens when the Dashboard field is empty. 3. Confirm it is clear which key file is registered in Snowflake and which file is pasted or uploaded in the Dashboard. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the Snowflake guide with clearer setup steps and requirements for roles, ownership, key handling, account IDs, and Dashboard settings. * Expanded guidance on append-only history, current-state queries, dynamic-table freshness and costs, stream and task recovery, type serialization, and the effects of schema changes on historical data. * Renamed the pipeline setup button to **Start pipeline**. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Leandro Pereira
|
c6b92060d2 |
docs(realtime): realtime permissions (#50735)
All changes are related to Realtime permissions that I observed on support tickets recently: - Migrations can't have `ALTER TABLE realtime.messages`. That's is not allowed and breaks migrations. - Missing realtime.messages partitions are usually due to lack of connections - Errors like "must be owner of table messages" are misleading Closes REAL-1125 ## Additional context https://supabase.slack.com/archives/C01G8CC0X9D/p1789981286693829 and SU-479680 ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified Realtime authorization restrictions, supported RLS policy management, and the existing RLS configuration for `realtime.messages`. * Documented broadcast partition creation, connection requirements, and warning behavior when partitions are unavailable. * Added troubleshooting guidance for ownership errors, including migration rollback implications and supported remedies. * Added instructions for inspecting message partitions and diagnosing missing, expired, or unavailable partition configurations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Sean Geoghegan
|
a21111b7e0 |
docs: Clarify private flag for broadcast from database (#50192)
## 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? Doc update ## What is the current behavior? The description of the private flag for broadcast from database functions is inconsistent and a bit confusing. ## What is the new behavior? Use the same language on both examples and clarify the default, and what true and false map to. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified the meaning of boolean privacy flags in realtime SQL examples: `true` indicates Private (the default), while `false` indicates Public. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Sean Geoghegan
|
830c06d494 |
docs: clarify authorisation window when policies change (#50695)
## Solution Clarifying the authorisation window for RLS/access checks on channels in Realtime. <!-- ## Preview links If relevant, include links to changed pages for easy review access. Copy the preview base URL from the Vercel bot comment on this PR. Use the following table as an example template. | Site | Live | Preview | Search for | | -------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------- | | WWW | [/blog/your-post](https://supabase.com/blog/your-post) | [/blog/your-post](https://zone-www-dot-com-git-branch-name-supabase.vercel.app/blog/your-post) | unique phrase from the change | | Docs | [/docs/guides/your-page](https://supabase.com/docs/guides/your-page) | [/docs/guides/your-page](https://docs-git-branch-name-supabase.vercel.app/docs/guides/your-page) | unique phrase from the change | | Studio | [/dashboard](https://supabase.com/dashboard) | [/dashboard](https://studio-git-branch-name-supabase.vercel.app/dashboard) | unique phrase from the change | | Design system | [/design-system](https://supabase.com/design-system) | [/design-system](https://design-system-git-branch-name-supabase.vercel.app/design-system) | unique phrase from the change | | UI library | [/library](https://supabase.com/library) | [/library](https://ui-library-git-branch-name-supabase.vercel.app/library) | unique phrase from the change | | Knowledge base | [/kb/guides/your-page](https://supabase.com/kb/guides/your-page) | [/kb/guides/your-page](https://kb-git-branch-name-supabase.vercel.app/kb/guides/your-page) | unique phrase from the change | --> <!-- ## Additional context Optionally add any other context or screenshots. --> ## Review instructions Provide a clear numbered procedure that the PR reviewer can walk through. 1. For example, `Open the live and preview links side-by-side.` 2. For example, `See the issue is fixed.` ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [ ] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that Realtime authorization policy changes may not affect already-connected clients until their JWT expires or a new JWT is provided. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
c3c741c20e |
docs: warn about postgres.js pipelining on Supavisor transaction mode (#50712)
Re-does #50082 against the redesigned `connecting-to-postgres.mdx` (see [Slack discussion](https://supabase.slack.com/archives/C04JR9DBNQL/p1789991651381399?thread_ts=1788980733.712609&cid=C04JR9DBNQL)). What changed vs. #50082: - `connecting-to-postgres.mdx`: the pipelining caution now lives in the new **Transaction mode limitations** section (the old "Pooler transaction mode" prose it was in got redesigned), and is a short redirect to the Postgres.js guide rather than a full explanation. - `postgres-js.mdx`: keeps the full warning, the `{ prepare: false }` workaround, and now explains *why* pipelining can't just be turned off (`max_pipeline: 0` breaks `sql.begin()`, tracked in porsager/postgres#1189), plus a "contact support" prompt for anyone still stuck, and a note that Supavisor v2.10 will add native pipelining support. - Drops the standalone troubleshooting page from #50082 — the team wasn't confident enough yet to officially point everyone at the `postgres.js` patch, so support is the escalation path for now instead. - Re-adds the `Rule003Spelling.toml` allow-list entry for "pipelining" (not present on `master`). 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that query pipelining is unsupported in transaction mode and may cause hangs or mismatched results. * Documented Postgres.js pipeline behavior, recommended workarounds, and planned native support in a future Supavisor release. * Updated the Postgres.js connection example to disable prepared statements for improved compatibility. * Added a support contact link for assistance with transaction-mode pipeline issues. <!-- end of auto-generated comment: release notes by coderabbit.ai --> ## Preview * pipelining mentioned in the Supavisor TX mode: https://docs-git-docs-postgres-js-pipelining-warning-supabase.vercel.app/docs/guides/database/connecting-to-postgres#pooler-transaction-mode * pipelining mentioned in more detail in TX mode limitations: https://docs-git-docs-postgres-js-pipelining-warning-supabase.vercel.app/docs/guides/database/connecting-to-postgres#transaction-mode-limitations * `postgres.js` pipelining warning with even more details: https://docs-git-docs-postgres-js-pipelining-warning-supabase.vercel.app/docs/guides/database/postgres-js --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> |
||
|
Joey Lei
|
d15634ae58 |
updated guidance for logs pricing, revised manage logs usage pages, introduction of the grace period(#49656)
Supabase Logs is moving to usage-based pricing. We're announcing changes early so impacted projects have time to adjust before billing begins when the grace period through early 2027. |
||
|
Steven Eubank
|
8ab2197eb8 |
Rename capacity monitor to resource monitor (#50849)
## Problem Capacity felt like a misleading naming for some users ## Solution renaming to resource monitor, to remove confusion with things like AWS capacity. And also leaves some room for interpretation that resource issues worth reporting are not always related to capacity. It could ust be interest in increase consumption. User expectations based on terminology will never be perfect though. ## Preview links https://supabase.com/docs/guides/observability/automate-with-agents/usage?queryGroups=agent-setup&agent-setup=prompt | Docs | [/docs/guides/your-page](https://supabase.com/docs/guides/observability/automate-with-agents/usage?queryGroups=agent-setup&agent-setup=prompt) <!-- ## Additional context Optionally add any other context or screenshots. --> ## Review instructions Provide a clear numbered procedure that the PR reviewer can walk through. 1. For example, `Open the live and preview links side-by-side.` 2. For example, `See the issue is fixed.` ## Checklist Check all before review: - [ ] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [ ] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Renamed “Capacity monitor” to “Resource monitor” across the guide, navigation, and monitoring prompt labels. * Updated the guide to link to the resource-report trigger documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
4998a137ec |
docs: correct function-to-function call rate limit for Edge Functions (#50806)
Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Kalleby Santos <105971119+kallebysantos@users.noreply.github.com> |
||
|
Lukas Bernert
|
f1b7c0aa4d |
docs: update compute size selection screenshots (#50798)
## Problem The Compute & Disk sizes screenshot is outdated after the changes from . https://supabase.com/docs/guides/platform/compute-and-disk#compute The screenshot still shows architecture, core-counts, and CPU labels. Fixes PROD-656 ## Solution A new screenshot has been provided to reflect the latest state of Studio. ## Review instructions Review the screenshot under: /docs/guides/platform/compute-and-disk#compute It should depict what the Studio shows under /dashboard/project/_/settings/infrastructure . Test dark & light mode. | Site | Live | Preview | Search for | | -------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------- | | Docs | [/docs/guides/platform/compute-and-disk#compute](https://supabase.com/docs/guides/platform/compute-and-disk#compute) | [/docs/guides/platform/compute-and-disk#compute](https://docs-git-docs-update-compute-size-screenshot-supabase.vercel.app/docs/guides/platform/compute-and-disk#compute) | N/A (screenshot) | ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [ ] If I wrote a new docs topic or edited an existing topic, I used the /write-the-docs or /edit-the-docs skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide |
||
|
Steven EubankandClaude Sonnet 4.6
|
4730e3a640 |
docs: remove Generalist monitoring agent (#50784)
The Generalist is too broad and doesn't do any one thing well. Removing it to focus on dogfooding the four targeted agents (Health, Security, Performance, Capacity) before revisiting a combined agent. https://github.com/supabase/supabase/pull/50396 new PR since this one became messy with many upstream changes ## Problem I don't like the generalist ## Solution I am removing the generalist <!-- ## Preview links If relevant, include links to changed pages for easy review access. Copy the preview base URL from the Vercel bot comment on this PR. Use the following table as an example template. | Site | Live | Preview | Search for | | -------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | ----------------------------- | | WWW | [/blog/your-post](https://supabase.com/blog/your-post) | [/blog/your-post](https://zone-www-dot-com-git-branch-name-supabase.vercel.app/blog/your-post) | unique phrase from the change | | Docs | [/docs/guides/your-page](https://supabase.com/docs/guides/your-page) | [/docs/guides/your-page](https://docs-git-branch-name-supabase.vercel.app/docs/guides/your-page) | unique phrase from the change | | Studio | [/dashboard](https://supabase.com/dashboard) | [/dashboard](https://studio-git-branch-name-supabase.vercel.app/dashboard) | unique phrase from the change | | Design system | [/design-system](https://supabase.com/design-system) | [/design-system](https://design-system-git-branch-name-supabase.vercel.app/design-system) | unique phrase from the change | | UI library | [/library](https://supabase.com/library) | [/library](https://ui-library-git-branch-name-supabase.vercel.app/library) | unique phrase from the change | | Knowledge base | [/kb/guides/your-page](https://supabase.com/kb/guides/your-page) | [/kb/guides/your-page](https://kb-git-branch-name-supabase.vercel.app/kb/guides/your-page) | unique phrase from the change | --> <!-- ## Additional context Optionally add any other context or screenshots. --> ## Review instructions Simply removing generalist: https://supabase.com/docs/guides/observability/automate-with-agents <img width="305" height="339" alt="image" src="https://github.com/user-attachments/assets/bb537038-799f-4ec6-a357-c4cb3c552cba" /> So generalist will be no mas ## Checklist Check all before review: - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Removed the combined Generalist monitoring guide and its navigation entry. Separate guides for health, security, performance, and usage monitoring remain. * The Generalist agent card and combined monitoring prompt are no longer available. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
Andrey A.
|
564eab8ad7 | chore(self-hosted): update 2026-09-23 - 0.8.2 (#50790) | ||
|
Stephen Morgan
|
e7e76ca0da |
fix: misleading privatelink dns copy (#50771)
Somewhat urgent update to documentation based on new AWS behavior. Will include additional details when we properly support custom DNS for privatelink <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the PrivateLink endpoint creation guide’s Option A steps and numbering. The DNS record note now stands on its own, without referencing a removed step. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny White
|
59e2122833 |
docs(pipelines): nest destination guides (#50708)
## Problem Pipeline destination guides live beside the Pipelines overview, so their sidebar hierarchy and URLs do not reflect that they belong to Pipelines. ## Solution Moves the BigQuery, ClickHouse, DuckLake, and Snowflake guides under `/database/replication/pipelines/`, redirects the old URLs in both docs preview (`apps/docs/next.config.mjs`) and production (`apps/www/lib/redirects.js`), and updates internal documentation links. The matching Studio changes, including destination-aware links from the creation sheet, will follow in a separate PR. ## To test - [Pipelines overview](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines) - Destination guides: [BigQuery](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/bigquery), [ClickHouse](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/clickhouse), [DuckLake](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake), [Snowflake](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/pipelines/snowflake) - [Old Snowflake URL](https://docs-git-dnywh-docsnest-pipeline-destinations-supabase.vercel.app/docs/guides/database/replication/snowflake) ## Review instructions 1. Open the Pipelines overview and confirm the four destination guides appear beneath Pipelines in the sidebar. 2. Open each destination guide and confirm its nested URL and content load correctly. 3. Open the old Snowflake URL and confirm it redirects to its new location. ## Checklist - [x] I have read [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) - [x] If I wrote a new docs topic or edited an existing topic, I used the `/write-the-docs` or `/edit-the-docs` skill, which references [WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md) and the docs [CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md) guide <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Moved BigQuery, ClickHouse, DuckLake, and Snowflake replication guides to a dedicated pipelines section and updated related navigation and links. * **Bug Fixes** * Added permanent redirects so existing links to the four destination guides continue to work. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny WhiteandJoshen Lim
|
05a45dd1ed |
feat(studio): rename Replication to Pipelines (#50637)
## What kind of change does this PR introduce? Feature and docs update. ## What is the current behavior? The Dashboard lists Pipelines destinations under Database > Replication. Read replicas have moved to Infrastructure, but the temporary notices remain on the destinations page and new destination sheet. Closes PIPE-1021. ## What is the new behavior? The canonical Dashboard routes are Database > Pipelines, while legacy Replication list and detail URLs permanently redirect to the equivalent Pipelines routes. Navigation, command palette, shortcuts, pipeline links, docs, and current marketing copy use Pipelines. Read-replica notices and their obsolete dismissal state are removed. | Before | After | | --- | --- | | <img width="1024" height="759" alt="Replication Database Agua Basket Supabase" src="https://github.com/user-attachments/assets/53f9f565-1ed1-43e9-a7d9-b66b2a47e948" /> | <img width="1024" height="759" alt="2540" src="https://github.com/user-attachments/assets/14ab2d61-d01c-483f-9d4f-0ac286dae159" /> | The Management API, pipeline behaviour, replication logs, and Postgres replication terminology remain unchanged. ## To test - Open `/project/<ref>/database/pipelines` and confirm the Database navigation, page header, and pipeline breadcrumb say Pipelines. - Open `/project/<ref>/database/replication?source=bookmark#destinations` and a legacy pipeline detail URL. Confirm each redirects to the matching Pipelines URL while preserving parameters and fragments. - From the Pipelines page, open Add destination. Confirm no read-replica migration notice appears. - Open the Pipelines guide and confirm its Dashboard steps lead to Database > Pipelines. ## Before merge - [ ] Get changelog entry reviewed https://github.com/supabase/changelog/pull/262 and prepare to merge simultaneously <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added dedicated **Database > Pipelines** pages for pipeline lists and details. - Added permanent redirects from legacy Replication URLs to their corresponding Pipelines pages. - Read replica management links now open **Settings > Infrastructure**. - **Documentation** - Updated Pipelines setup, monitoring, troubleshooting, and usage guidance to reference the current dashboard locations. - Updated Realtime guidance to use **Database > Publications**. - **Updates** - Renamed dashboard navigation, breadcrumbs, commands, and keyboard shortcuts from **Replication** to **Pipelines**. - Removed the “Read replicas have moved” notification. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Miranda Limonczenko
|
7ce4ee53ae |
chore(docs) Retire supa-mdx-lint (#50602)
Closes [DOCS-1289](https://linear.app/supabase/issue/DOCS-1289/get-the-linter-to-fix-what-it-flags-or-retirereplace-the-linter) Stacked on #50600, which points contributors at the authoring skills. Merge that one first. ## Problem Contributors experienced friction with the linter. They felt nickle and dimed for tiny nits and felt detracted from the work itself. PRs would become noisy with tiny one-word suggestions. Additionally, our homegrown linter is not very intelligent, causing frequent overrides. ## Solution This removes the linter entirely in favor of directing contributors to use SKILLS instead. The removal entails... - **CI.** Delete the three `docs_lint` workflows: the PR check, the external-PR comment companion, and the nightly `--fix` bot. Drop the stale `zizmor.yml` ignore entry for the deleted workflow. - **Tooling.** Delete `supa-mdx-lint.config.toml` and the 14 rule files. Drop the `lint:mdx` script and the `@supabase/supa-mdx-lint` dependency from docs, learn, and ui-library, and regenerate the lockfile. - **Content.** Remove the 181 directives. A separate commit carries Prettier's reformatting of the tables and blank lines those comments had suppressed, so the deletion commit stays readable. No prose changes. - **Style guide.** The word list states each rule directly instead of describing what the linter flagged. Every term survives, including the phrase groups that mirrored `Rule004ExcludeWords`. - **Skills.** `write-the-docs`, `edit-the-docs`, and `review-the-docs` drop `pnpm lint:mdx` from their self-review commands and check the word list directly. `ask-the-docs`'s CI reference drops both workflows. ## Manual testing 1. Run `git grep -i supa-mdx-lint -- . ':!pnpm-lock.yaml'`. No matches. 2. Run `pnpm install --frozen-lockfile --lockfile-only`. It passes, so the lockfile matches the three trimmed manifests. 3. Run `git diff master...HEAD --name-only --diff-filter=ACMR | grep -E '\.(md|mdx)$' | xargs npx prettier --config prettier.config.mjs --check`. All changed markdown passes. 4. Open the [reformatted filter table](https://docs-git-docs-retire-mdx-linter-supabase.vercel.app/docs/guides/observability/logs#filter-events) on the preview and compare it with [production](https://supabase.com/docs/guides/observability/logs#filter-events). The table renders the same. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Documentation guidance now uses manual prose and terminology review with the shared word list. * Clarified storage configuration and common Realtime channel mistakes. * Improved table formatting, text wrapping, and selected reference links. * Updated documentation authoring and review guidance. * **Chores** * Retired automated MDX linting from workflows and local validation commands. * Removed lint-suppression markers throughout documentation without changing instructions. * Added targeted documentation review guidance for pull requests. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Andrey A.
|
d7ff2c29e7 | fix(self-hosted): make setup.sh work for non-root sudo users (#50653) | ||
|
Andrey A.
|
8ed27fdb50 | docs(auth): forward Set-Cookie headers on server-side OAuth redirect (PKCE) (#50722) | ||
|
Kostas Botsasandcoderabbitai[bot]
|
e1e16d4a18 |
docs(troubleshooting): document custom roles in troubleshooting guide (#50510)
## 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? Docs ## Additional context Explicitly mention custom roles in the troubleshooting guide for password authentication failure <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added troubleshooting guidance for using custom PostgreSQL roles with direct connections, dedicated pooling, and shared pooling. - Documented temporary authentication failures that may occur after resetting a custom role’s password when using shared pooling. - Added guidance to verify the password directly and retry shared-pooler connections with bounded retries. - Added a link to password-rotation documentation for further details. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> |
||
|
|
b0bb496977 |
[bot] Sync from supabase/troubleshooting (#50656)
This PR syncs the latest troubleshooting guides from the supabase/troubleshooting repository. --------- Co-authored-by: github-docs-bot <github-docs-bot@supabase.com> Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> |
||
|
|
7f0f3c32b5 |
docs(troubleshooting): add realtime messages not arriving guide (#49618)
## 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? Docs update. ## What is the current behavior? ## What is the new behavior? Realtime messages not arriving troubleshooting. ## Additional context Just a guide for customers to see why their message could not be arriving when using Realtime. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a comprehensive Realtime troubleshooting guide for messages that do not arrive. * Covers connection failures, Broadcast messages, `postgres_changes`, Presence, subscription status, project settings, permissions, authentication, filters, proxies, rate limits, topics, publications, triggers, and configuration checks. * Includes diagnostic guidance for client- and database-originated events, WebSocket connections, database partitions, and Presence authorization and timing. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Ali Waseem <waseema393@gmail.com> |
||
|
Nik RichersandNik Richers
|
6bec90a744 |
docs: unpublish Multigres Public Alpha docs (#50662)
## I have read the CONTRIBUTING.md file. YES ## What kind of change does this PR introduce? Revert. Removes the Multigres Public Alpha docs section that was published in #49020. Linear: MUL-1621 (follow-up to MUL-452). ## What is the current behavior? - Overview guide live at `/docs/guides/database/multigres` - Compatibility stub live at `/docs/guides/database/multigres/compatibility` - Database sidebar has a Multigres section - Features table lists Database / Multigres / `public alpha` - Database "What you get" cards render for Multigres ## What is the new behavior? Clean revert of #49020: overview and compatibility pages removed, sidebar entry removed, features table row removed, "What you get" cards removed. The unrelated `ContentListings` optional-`href` support this PR introduced is also reverted since nothing else uses it yet. Docs go back up once Sugu gives the go-ahead to re-publish (tracked in MUL-1621). ## Additional context - `pnpm --filter docs exec vitest run lib/content-listings.test.ts` — 20 passed <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Removed Multigres documentation, navigation links, feature listings, and related references. - Updated the JavaScript client library link in the getting-started guide. - Corrected the High Availability badge’s “Read more” link. - **Content Listings** - Content listing entries now require links and consistently render as linked items. - Non-linked listing items are no longer displayed as static content. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Nik Richers <nik@validmind.ai> |
||
|
|
e357ec8f9f |
docs(cli): update local development workflow docs for pg-delta default diffing (#49280)
## 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? Docs update. ## What is the current behavior? Linear: [CLI-1618](https://linear.app/supabase/issue/CLI-1618/update-cli-workflow-docs-for-pg-delta-default-diffing) Four docs pages lag the shipped CLI behavior now that `pg-delta` is the default diff engine for projects created by a recent `supabase init`: - **CLI workflows** claims `db diff` compares `supabase/schemas/` against migrations. Under `pg-delta`, declarative files are never the `db diff` baseline (and `[db.migrations].schema_paths` no longer changes it) — the declarative flow goes through `supabase db schema declarative sync`. The cleanup guidance describes `migra`-era output. - **Declarative database schemas** teaches the old `db diff -f` + `schema_paths` flow throughout, and its known-caveats list is the `migra` issue list. - **Managing environments** still presents `--use-migra` as an "experimental flag" for a "more concise" diff — inverted now. - **Backup and restore (migrating within Supabase)** and the CLI workflows guide both steer users to `db diff`/`db pull` with `--schema auth,storage`. Under `pg-delta`, `--schema` layers an extra exclude policy on top of the Supabase profile: it can only narrow a diff, never re-include managed schemas, and managed-schema selections can even fail closed (e.g. `--schema auth` when a trigger function lives in `public`). Unfiltered diffs are the supported path. ## What is the new behavior? All claims verified against the CLI source at current `develop` — including supabase/cli#6300, which upgraded the engine to `@supabase/pg-delta` 1.0.0-alpha.46 — against the pinned pg-delta package source (profile rules, format defaults, coverage doc), and against a live dogfood run of the documented workflows on `develop` `38f31b4` (two OSS corpus projects, warm shadow cache). - **`cli-workflows.mdx`**: adds a "Which diff engine you're on" note (`pg-delta` for new `supabase init` projects, `migra` for existing ones until they opt in by adding `[experimental.pgdelta] enabled = true`; per-run fallbacks `--use-migra` on `db diff` / `--diff-engine migra` on `db pull`); corrects `db pull` and `db diff` mechanics (shadow built from migrations vs. live database; the baseline history record is offered, not unconditional); switches the declarative flow to `supabase db schema declarative sync`; reworks the cleanup section around pg-delta output (uppercase keywords at max width 180, `format_options`, per-unit migration files with numeric segment suffixes, the `-- pg-delta: transaction=false` directive on genuinely non-transactional files, engine-neutral grant/revoke review guidance, coverage warnings + `--strict-coverage`); documents what pg-delta captures in managed schemas (user triggers, RLS policies on `auth` tables and on `storage.objects`/`storage.buckets`/`realtime.messages`) versus what it doesn't; adds key-command rows for the declarative commands and troubleshooting entries (`db pull` non-zero exit when in sync, the `schema_paths` warning, `PGDELTA_DEBUG=1` bundles under `supabase/.temp/pgdelta/v2/debug/`). - **`declarative-database-schemas.mdx`**: swaps `db diff -f` for `db schema declarative sync -f` throughout; replaces lexicographic/`schema_paths` ordering guidance with automatic dependency ordering and the `generate` export layout (`_cluster/`, reserved `_custom/`); bootstraps from production via `db schema declarative generate --linked` (explicit target + `--overwrite` in scripts) and refreshes via `db pull --declarative`; rewrites known caveats for pg-delta (DML including storage buckets, untracked object kinds + the `_custom/` escape hatch, managed schemas, extension-managed objects, and the two gates when adopting an existing schema tree: `[experimental.webhooks]` for `pg_net` migrations and declaring the tree's extensions) keeping the `migra` workflow and issue list under a legacy section for projects that haven't enabled it. - **`managing-environments.mdx`**: frames the verbose grant sample as legacy-engine output, notes that generated migrations can include grant statements on any engine, describes `--use-migra` as a single-run fallback, and adds a `db diff --strict-coverage` CI step. - **`backup-restore.mdx`**: replaces `db diff --linked --schema auth,storage` with a plain `db diff --linked` on `pg-delta` (keeping the `--schema auth,storage` form for the legacy engine) and explains what the engine includes (user triggers on managed tables, user RLS policies on `auth`, `storage.objects`/`storage.buckets`/`realtime.messages`) and what must be recreated manually. - **New `diff-engines.mdx` page** (from #49889): the single home for how the engine is selected, a behavior matrix for `pg-delta` versus `migra`, the per-command fallback flags, a procedure for switching an existing project (the first `db pull` after enabling may write a catch-up migration), and how to go back with `enabled = false`. Registered in navigation. A shared `diff_engine_check` partial replaces the inline engine parentheticals across seven pages, and a `managed_schemas_diff_capture` partial carries the managed-schema capture rules. - **CLI reference (`cli_v1_commands.yaml`, `cli_v1_config.yaml`)**: `db pull`, `db schema declarative sync`/`generate` flags and descriptions, `experimental.pgdelta.*` and `db.migrations.schema_paths` config keys, and the `db diff` description updated to describe both engines. Note that `cli_v1_commands.yaml` is generated from the CLI repo; [supabase/cli#6557](https://github.com/supabase/cli/pull/6557) carries the matching `db pull` example and overlay text so the next publish keeps it. - **`examples/prompts/declarative-database-schema.md`**: rewritten for the `db schema declarative sync` flow, with the `[experimental.pgdelta]` prerequisite. ## Additional context The first draft was written against pg-delta 1.0.0-alpha.42. supabase/cli#6300 (engine upgrade to alpha.46) then changed two documented behaviors, both reflected here: generated SQL now defaults to uppercase pretty-printed keywords, and user RLS policies on `storage.objects`/`storage.buckets`/`realtime.messages` are included via the engine's `SUPABASE_USER_POLICY_SURFACES` allowlist. A follow-up dogfood run on `develop` `38f31b4` then falsified three more claims (pg-delta emits no grant noise, `_schema_changes`/`_after_enum_values` multi-file names, directive on every split file), all corrected in the last commit. **Update (Sep 14 to 17):** [#49889](https://github.com/supabase/supabase/pull/49889) and [#50220](https://github.com/supabase/supabase/pull/50220) were merged into this branch, so this PR now carries the full stack. #50220 corrected the `schema_paths` warning wording (the CLI warns only when the setting lists paths), added `auth` RLS policies to the managed-schema partial, and described the migra initial pull accurately (the `pg_dump` skips managed schemas and the migra diff pass that follows appends the trigger and policy changes). It also reframed `pg-delta` as the default for every project ahead of supabase/cli#6391. That plan changed: no breaking default flip before Select, so [#50332](https://github.com/supabase/supabase/pull/50332) restores the opt-in framing (`pg-delta` requires `[experimental.pgdelta] enabled = true`, which `supabase init` writes for new projects) and also resolves the four CodeRabbit findings from the latest review round. Two claims are pending confirmation from the owning teams: that branching runs every migration in a transaction and ignores the `-- pg-delta: transaction=false` directive, and the `--db-url` pooler-versus-direct connection advice, which currently disagrees with the CLI's own `db pull` docs. Stale spots found in the CLI repo's own docs while verifying (out of scope here, worth follow-ups): four `SIDE_EFFECTS.md` files still claim lowercase output, `docs/supabase/db/diff.md` still lists `migra`-era "known failure cases" that alpha.46 fully models, the `supabase init` template's commented `format_options` example shows `maxWidth: 80` against an actual default of 180, and the CLI upgrade recipe appends `--experimental` even when the config already enables pg-delta. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01SUuaVmXLRbV6tZjzhka3cp <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified `pg-delta` and legacy `migra` behavior, configuration, and switching guidance. * Expanded declarative schema workflows, including synchronization, migration generation, baselines, deployment, and legacy-engine support. * Documented managed schemas, permissions, extensions, transaction handling, dependency ordering, and troubleshooting. * Added guidance for strict coverage checks, output directories, non-interactive workflows, and declarative pull modes. * Added a dedicated diff engines guide and updated CLI navigation, backup and restore, branching, deployment, and CI documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Wen Bo Xie <wenbox323@gmail.com> |
||
|
Riccardo Busetti
|
ced974e073 | docs(pipelines): Align and streamline replication guides (#49252) | ||
|
Miranda Limonczenko
|
36749659e6 |
docs(functions): answer the recurring secrets questions from reader feedback (#50422)
Five reports on this page, four of them the same confusion: which .env file does what. Where local values come from is a new section listing the files that feed a local environment: supabase/functions/.env, a file you name yourself, the root .env that config.toml reads through env(), and [edge_runtime.secrets]. It says a value in one is not a value in the other. That is what CLI-818 asked for in as many words, the duplication FDBKIN-11884 complains about, and the config route FDBKIN-12716 raises. It sits with the other reference section rather than inside the local procedure, because it answers what the parts are rather than how to do something. Accessing environment variables splits into an Edge Function and a Deno script you run yourself, where neither env file applies. Deno.env.get needs --allow-env, so both commands pass it; without the flag the script prompts, and fails outright when nothing is there to answer. FDBKIN-7937. Production secrets now states who can set one, and the reserved prefix. Also calls Deno.env.get a method rather than a handler, which is what it is. The wording came in with the style pass at the bottom of the stack; fixing it here avoids restacking four branches for one word. Two claims from the source reports are deliberately not here. FDBKIN-34962 reports that adding a secret requires OWNER. The access control matrix in guides/platform/access-control.mdx says Owner or Administrator can create and delete, and Developer can view. The reporter found their version by external searching, so the page states what our own matrix says. supabase/agent-skills#452 reports that a secret value cannot be recovered after saving. SecretResponse_Output in the Management API spec returns value as a required field, and the Dashboard renders it, so that does not hold up from what I can check here. Left out rather than guessed at; the issue stays open. The reserved prefix is not a third-party host restriction as supabase/agent-skills#553 frames it. CreateSecretBody carries pattern ^(?!SUPABASE_).*, AddNewSecretForm.tsx:42 rejects the same, and the CLI filters SUPABASE_-prefixed names out of the local function environment. It is ours, and the page says so. |
||
|
Miranda Limonczenko
|
06aafbae4b |
docs(functions): give local secrets a procedure that produces a working key (#50420)
The Managing secrets guide is the only place that tells you where a local secret has to sit for the Edge Function runtime to load it. Neither the supabase agent skill nor Supacademy covers it. The page named supabase/functions/.env once, in prose, and never had the reader create it. The eval in supabase/evals#285 reproduces what that produces: across three runs on codex-gpt-5.6-luna-no-skills, every run built a function reading its key from the environment, started the stack, and answered missing_api_key. Two of the three wrote supabase/functions/.env.example and stopped, which is a template with the variable name in it rather than the file the runtime reads. Local secrets is now a five-step procedure that creates the file with a working value, ignores it, creates the function that reads the key, starts the stack, and calls the function to confirm. That last step is the one that tells the reader whether it worked. The function is created before the stack starts, so a reader following the steps literally from a fresh project has something to call. The gitignore instruction moved out of its admonition and into step 2, carrying its consequence with it. It's an instruction the reader has to follow, so it belongs in the procedure rather than beside it. Recovery for a variable the function can't see gets its own section rather than trailing the procedure. "I set it and the function cannot read it" is the most repeated shape in the feedback on this page, and as loose sentences mid-section it had no entry in the table of contents. |
||
|
Miranda Limonczenko
|
7012ba4a55 |
docs(functions): regroup the secrets guide by information type (#50419)
Moves and heading levels only. No claims changed. Studio renders a Docs button at apps/studio/pages/project/[ref]/functions/secrets.tsx:43 pointing at #using-the-cli, but "Using the CLI" was bold text rather than a heading, so the anchor had no target and the button dropped the reader at the top of the page. It and "Using the Dashboard" are now real headings, which repairs it. Local secrets and Production secrets were h3 under "Accessing environment variables", but neither is about accessing one. Both are now h2 siblings, and the reference list moved to the end, so the page runs procedures first and facts last. Sections are ordered by what the reader is doing, not by subject: set a secret locally, read it in code, then set it in production. "Accessing environment variables" sat after production, which put the reading step after the shipping step. Local secrets held a two-item list of the loading mechanisms, which is a fact sitting inside a procedure. It is now the section's opening sentence, where a one-line fact can qualify the procedure without interrupting it. Every existing heading text is unchanged, so #default-secrets, #local-secrets, #production-secrets and #accessing-environment-variables all still resolve. Added a value statement opener, and an outcome after the production procedure. No intro outline: the page is short and its headings already scan. The frontmatter title was title case. Renaming it to sentence case moves a navigation label and a search entry, so the nav entry and the three pages that used the old title as link text change with it. The slug is untouched. |
||
|
Miranda Limonczenko
|
82e9f6fb0e |
docs(functions): tighten the voice in the secrets guide (#50418)
Style only. No heading moves and no claim changes. The page carried the same caution admonition twice, word for word, and explained the local .env loading rules twice more: once as a list of the two mechanisms, then again as a pair of serve commands with the same prose around them. Both copies are gone, along with the trailing line about managing different environments that restated the --env-file bullet. The rest is voice. First person became second, future tense became present, and "allows you to" became a sentence with the reader as its subject. SB_REGION and SB_EXECUTION_ID had lost words. The two NEVER shouts became bold, per the emphasis rule. The alt text named the topic the heading already names. It now describes the Key and Value fields, the reveal and remove controls, and the Add another and Save buttons, which is what a reader who can't see the screenshot needs. Dropped the item count ahead of the local loading list, and made that list unordered, because the two mechanisms are alternatives rather than steps. |
||
|
Tina Ha
|
f69195f9df |
docs: fix numbered list rendering in secrets-limit troubleshooting doc (#50479)
## Summary - #50366 added a numbered "How to fix" list, but the fenced code blocks and follow-up paragraphs between items 1/2/3 weren't indented under their list markers, so each numbered item parses as its own single-item list per CommonMark's list-continuation rules — the rendered doc shows "1, 1, 1" instead of "1, 2, 3". - Indents the code fences and paragraphs so they attach to their list item, keeping the whole "How to fix" section as one ordered list. No content changes — purely a list-structure/indentation fix so the doc renders correctly. ## Test plan - [ ] Preview the docs page and confirm "How to fix" renders as 1, 2, 3 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the troubleshooting guide with clearer Markdown and TypeScript code formatting for secret configuration and retrieval examples. - Clarified how to set grouped credentials, handle missing secret values, and access parsed keys individually. - Documented behavior remains unchanged: grouped credentials count as one secret, and missing `API_KEYS` values produce an error. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Victor Farazdagi
|
a536a8fdd0 |
docs(pipelines): add Snowflake materialization examples (#50571)
## 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? Documentation update. ## What is the current behavior? The Snowflake destination guide describes its append-only change history, but does not include SQL examples for querying current state or maintaining a materialized result. ## What is the new behavior? Add a "Query and materialize current state" section with: - A query and reusable view that select the latest event per identity before filtering deletes. - An incremental dynamic-table example with a configurable freshness target. - Guidance on stable keys, permissions, change tracking, refresh costs, and recovery after table resets or schema changes. - Links to official Snowflake documentation, including the streams-and-tasks alternative. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded Snowflake replication guidance for deriving current state from append-only change history. * Added examples for identity selection, `QUALIFY`-based filtering, reusable views, dynamic tables, streams, and tasks. * Documented considerations for mutable identity columns, delete handling, change tracking permissions, refresh settings, target lag, and DDL effects. * Clarified that change tracking must be enabled before altering managed objects. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
51b6908236 |
tsguide(realtime): add guide to isolate client vs server issues (#49933)
## 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? Troubleshooting docs addition. ## What is the current behavior? This is troubleshooting documentation on how to diagnose missing real-time messages and isolate whether it is a client-side or server-side issue. ## What is the new behavior? Adds a step-by-step troubleshooting guide for Realtime. This helps check isolate connection and message delivery issues using:? Realtime Inspector: to confirm server-side dispatch. Browser DevTools: to confirm client-side receipt via WebSockets. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a Supabase Realtime troubleshooting guide for isolating server-side, client-side, and network-related subscription issues. * Covers Realtime Inspector checks for subscriptions, broadcasts, and presence; authorization and RLS validation; client configuration; WebSocket traffic in browser developer tools; network connection verification; and preparing diagnostic details for Support. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ali Waseem <waseema393@gmail.com> Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: krishnasaivandavasi <241076000+krishnasaivandavasi@users.noreply.github.com> |
||
|
ŁUKASZ KORBASIEWICZ
|
804e7cda5c |
docs: add pg_net schema troubleshooting (#50390)
## 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? It adds a new troubleshooting section to the `pg_net` extension documentation. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added troubleshooting guidance for resolving a Security Advisor warning when `pg_net` is installed in the `public` schema. - Documented that `pg_net` must be dropped and recreated in the `extensions` schema. - Added a warning that this process deletes queued requests and stored responses, including requests that have not yet been sent. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Maksym Ionutsaandcoderabbitai[bot]
|
b5f174a6f9 |
docs: warn against installing PostGIS in the public schema (#50509)
## 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? docs update ## What is the current behavior? Gap in the docs that agents misinterpret ## What is the new behavior? <img width="1566" height="718" alt="CleanShot 2026-09-17 at 12 13 59@2x" src="https://github.com/user-attachments/assets/d50b4228-b0ec-4cca-94d3-ec083720a04a" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added guidance to install PostGIS in a dedicated schema rather than `public`. - Clarified that installing PostGIS in `public` exposes the `spatial_ref_sys` table through the Data API. - Explained that related security advisor warnings are expected and do not indicate user data exposure. - Added steps for moving PostGIS to another schema, including backup precautions and an option to contact Support. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> |
||
|
Maksym Ionutsa
|
fe0afd66b8 |
docs(cron): document how to clean up cron.job_run_details (#50211)
cron.job_run_details grows unbounded and is never pruned automatically, even after a job is unscheduled. Add an example that schedules a daily cleanup job, and link it from the existing disk-usage caution. ## 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? docs update ## What is the current behavior? No mention of the _necessary_ regular cleanups ## What is the new behavior? This is now explicitly called out with a weekly clean-up example <img width="1620" height="654" alt="CleanShot 2026-09-10 at 11 41 25@2x" src="https://github.com/user-attachments/assets/2f78a051-5994-4f8a-95c2-c96c64679bed" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the cron quickstart guide with guidance on cleaning up job run history. - Added an example showing how to schedule a daily cleanup job that removes records older than seven days. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Lukas BernertandClaude Fable 5
|
459436e87f |
docs: update compute size descriptions (CPU column, pg_restore guidance) (#49996)
## What kind of change does this PR introduce? Docs update: aligns compute descriptions with the current compute options. Fixes PROD-655 ## What is the new behavior? - compute-and-disk: CPU column now shows "Shared" (Nano–Medium) and "Dedicated · N vCPUs" (Large and above), matching the pricing page - migrating-to-supabase/postgres: pg_restore -j guidance keyed to the vCPU count per compute size - which-version-of-postgres: uses show server_version;, which gives simpler, architecture-agnostic output - High-CPU troubleshooting guide: recommends upgrading compute size instead of naming specific instance types billing-on-supabase: "64 cores" → "64 vCPUs" - Section anchors unchanged (deep-linked from other pages) ## Self-review Content-only MDX change: - pnpm lint:mdx: no findings in the changed files (all reported errors/warnings are pre-existing in unrelated files) - pnpm build:guides-markdown: builds clean; generated .md exports for the changed pages verified - All pages verified rendering in the local dev app on current master - Swept apps/docs for remaining core-count / instance-type mentions in compute descriptions <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated PostgreSQL version-checking instructions to use `show server_version;` with simplified output. * Clarified compute sizing terminology using shared and dedicated CPU allocations and vCPU-based descriptions. * Updated billing guidance to describe scaling up to 64 vCPUs. * Revised database restore guidance with current compute tiers and recommended parallelization settings. * Simplified high-CPU troubleshooting guidance to recommend temporarily scaling CPU capacity. * Added writing guidance to consistently use “vCPU” and “vCPUs” for Supabase compute resources. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> |
||
|
Lukas Bernert
|
055cc7b956 |
docs: state disk limits as per-size minimums, align burst copy (#50016)
## What kind of change does this PR introduce? Docs update: states disk limits as per-size minimums and aligns burst copy across pages. Follow-up to #49996 (compute descriptions). Fixes PROD-658 ## What is the current behavior? - The disk limits table and surrounding prose describe a narrower set of configurations than a compute size can run on - Burst thresholds are inconsistent across pages (three different variants), and one section contradicts itself - Burst is described as CPU behavior, when the burst users observe is disk IO ## What is the new behavior? - `shared-data/compute-disk-limits.ts`: Medium baseline throughput adjusted to 39 MB/s: the lowest value across configurations - `compute-and-disk`: disk limits presented as minimums ("at least"); burst described as disk IO drawing on a disk IO budget; consistent thresholds: burst available up to 2XL, baseline equals maximum from 8XL - Troubleshooting guides (`exhaust-disk-io`, `failed-to-retrieve-tables`, `interpreting-supabase-grafana-io-charts`) aligned to the same threshold; `failed-to-retrieve-tables` keeps the ~30-minutes-per-day burst window with the corrected size range - Section anchors unchanged ## Self-review - Values verified against the AWS EBS-optimized performance data (`describe-instance-types`) for every configuration per size; content cross-checked with the internal runbooks (linked in PROD-658) - `supa-mdx-lint`: no findings in changed files - `pnpm build:guides-markdown` clean; generated `.md` exports show the new values and prose - All changed pages verified rendering in the local dev app - `pnpm typecheck` passes (shared-data + docs) - Note: `compute-disk-limits.ts` also feeds Studio (disk validation, IO budget tooltips). The only value change (Medium 43 → 39 MB/s) surfaces there as one chart tooltip label; conservative direction. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified the differences between shared and dedicated CPU resources. - Updated disk I/O guidance to explain baseline and burst limits as minimums. - Documented disk I/O bursting for compute sizes up to 2XL, including expected duration and limitations. - Clarified that 8XL and larger compute sizes have consistent performance without burst capacity. - Updated the documented baseline throughput for medium compute resources. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Wen Bo Xie
|
20d09b4a72 |
docs(auth): clarify OAuth 2.1 server pricing is included in Auth MAUs (#49753)
OAuth 2.1 server had a single pricing statement anywhere, and it said the feature is free during beta. This states the actual model everywhere the feature is documented or sold: there is no separate charge, and users who sign in through the OAuth server count toward Auth MAUs. - docs getting started: replace the "free during beta" sentence with the MAU-based pricing statement - docs overview: add a Pricing section linking to the MAU usage guide and the pricing page - docs MCP authentication: note that agents authenticate as existing users, and MAUs count per distinct user, so multiple agents for one user count once - www pricing comparison table: add an "OAuth 2.1 Server" row (included on all plans) with a tooltip, and extend the MAU tooltip to cover OAuth server sign-ins <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that OAuth 2.1 Server is available on all plans without a separate charge. * Explained that OAuth sign-ins count toward Monthly Active Users (MAUs), with multiple agents for one user counted once. * Added links to MAU and pricing guidance. * **Pricing** * Added OAuth 2.1 Server as a plan feature and updated billing descriptions for greater clarity. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Saxon FletcherandClaude Opus 5
|
91e23a0f2d |
docs: define detection checks and specialist monitoring prompts (#50075)
## 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? Documentation update. ## What is the current behavior? Specialist monitoring prompts leave some comparison windows, baselines, thresholds, and missing-data behavior undefined. This can produce reports or forecasts without sufficient evidence. ## What is the new behavior? Detection checks define inputs, comparison windows, thresholds, units, missing-data behavior, and next investigation steps. Query regressions require comparable snapshots and reset history; capacity forecasts require saved measurements and a matching confirmed limit. Health, Security, Performance, and Capacity prompts fetch and follow the shared detection checks automatically. They record finding, clear, or unable to assess, preserve alert state, and suppress unchanged repeats. Missing history or failed access cannot become a healthy result. Specialist pages retain their diagrams and the sections What it watches, When it watches, What it will output, and Set up the agent. Setup explains the necessary documentation access and saved state; optional links explain report triggers. Prompt and provider setup tabs remain available in HTML and Markdown. The Hire an agent overview and Generalist page and prompt remain unchanged. Prompt Markdown exports use the Markdown serializer to safely contain nested code fences, preserving the full Generalist prompt and its SQL examples. Both prompt exporters have parser-based round-trip coverage. ## Additional context Full docs suite: 215 passed, 2 skipped against a freshly reset disposable Supabase stack. Typecheck, targeted ESLint, formatting, and guides Markdown generation also pass after the export fix. Earlier validation: production docs build, docs typecheck, targeted ESLint, formatting, and guides Markdown generation pass. All four specialist exports contain their diagrams, setup sections, enhanced prompts, and provider instructions. The Health page diagram and setup tab were checked in the browser. Changed pages have no MDX lint violations; existing repository-wide violations remain. The unchanged detection SQL was previously smoke-tested in a disposable sandbox. Hosted MCP runs, scheduler persistence, notifications, and agent evals are outside this validation. Evals remain outside this change. Stage 3 of 3; depends on stage 2. Stack: #50073 → #50074 → #50075. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Reworked observability guidance around hourly, read-only monitoring checks. - Updated health, security, performance, and usage monitors to identify new findings, data gaps, regressions, and resource growth. - Added clearer setup instructions for linked documentation, saved measurements, and alert state. - Replaced the issue-detection guide with standardized outcomes: finding, clear, or unable to assess. - Added explicit thresholds, evidence details, investigation links, and verification steps for turning detections into diagnoses. - **Improvements** - Standardized monitoring prompts and presentation across supported agent types. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Miranda Limonczenko
|
e8547352c5 |
docs(auth): answer the four most repeated SSR auth questions (#50289)
Closes DOCS-1313 Closes FDBKIN-4573 Closes FDBKIN-15214 Closes FDBKIN-10628 ## Problem Four asks come up repeatedly in feedback intake. The Eval is green and this feedback cannot be included in the Eval. Using the Evals work as an excuse to action on the feedback. 😄 Readers can't tell which auth call verifies a token and which only reads stored state. They don't know that the response the cookies were written to is the response they have to return, because that only ever existed as a code comment. Nobody is warned that refreshing in two places burns a single-use refresh token, which surfaces as users being signed out at random. And nothing in `apps/docs` says `proxy.ts` is Next.js 16 and later, so a reader on 15 writes a file the framework never calls. ## Solution - Add the fact that `getClaims()` refreshes a session close to expiring before it verifies. It was only in the typedoc remarks, and it is what makes the double refresh warning make sense. - Say that `setAll` rebuilds `supabaseResponse` on every write, so a response built earlier is stale, and show how to copy the cookies onto a different one. - Warn that a second refresh outside the reuse window revokes the session, linking refresh token reuse detection. - Note that `proxy.ts` is Next.js 16 and later, and that the file is `middleware.ts` before that. - Name the file in the proxy fence in `examples/prompts/nextjs-supabase-auth.md`, which gave agents the export name and no path. The auth methods partial is shared by five other pages, so that first change surfaces there too. ## Manual testing 1. Open the [SSR client guide](https://docs-git-docs-ssr-client-feedback-supabase.vercel.app/docs/guides/auth/server-side/creating-a-client) on the deploy preview. The Next.js panel carries the version note, the refresh warning, and the response guidance. 2. Select the refresh token reuse detection link. It resolves to the sessions guide. 3. Open the [Next.js Auth prompt](https://docs-git-docs-ssr-client-feedback-supabase.vercel.app/docs/guides/ai-tools/ai-prompts/nextjs-supabase-auth). The proxy section names the file and says it is `proxy.ts` on Next.js 16 and later. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation - Clarified that `getClaims` refreshes sessions when access tokens are near expiration, helping server-rendered sessions remain active. - Expanded Next.js SSR guidance for session-refresh setup, including file placement and version-specific naming. - Added warnings about refresh-token reuse and session revocation after repeated refreshes outside the reuse window. - Added guidance for preserving authentication cookies and cache-related headers when returning updated responses. - Clarified that refreshed tokens should be passed to Server Components to keep sessions active. - Clarified the required session-refresh handler export and example filename. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |