mirror of
https://github.com/supabase/supabase.git
synced 2026-09-08 10:59:38 +08:00
cli/ref-doc
2146 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
73e36ec516 |
docs(troubleshooting): add postgres_changes not delivering guide (#48997)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES/NO ## What kind of change does this PR introduce? Docs update. ## What is the current behavior? ## What is the new behavior? Realtime postgres changes troubleshooting. ## Additional context Just a guide for customer to check why they wont see events with postgres changes. Couple of steps to check etc. Would appreciate Realtime team's feedback. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a comprehensive troubleshooting guide for Realtime Postgres change events. * Covers publication settings, row-level security, replica identity, subscription status, timing gaps, project and table configuration, logs, delivery guarantees, and network issues. * Includes practical SQL, JavaScript, and React examples, diagnostic steps, fixes, and links to related documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
500dddc20c |
docs(integrations): add Stripe Projects provisioning guide (#49354)
## 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? This PR adds some missing Stripe Projects documentation: a short peer entry on the Integrations overview (next to the existing Vercel Marketplace entry) plus a focused guide page. Closes DOCS-1337. ## What is the current behavior? - Linear item: `DOCS-1337`: Document programmatic project provisioning, with Stripe Projects as a partner example - No page under `apps/docs/content/**` mentions Stripe Projects. The only existing prose is a blog post and a `/go/` marketing page, neither indexed as docs nor surfaced in `llms.txt` (which is generated purely from `content/guides/**` directory names/titles). - The Studio-side confirmation flow (`apps/studio/pages/partners/stripe/projects/login.tsx`) already exists and works; the gap is entirely on the docs side. ## What is the new behavior? - `apps/docs/content/guides/integrations.mdx`: added a "Stripe Projects" section, same weight as the existing "Vercel Marketplace" section (short description + link), so Stripe is presented as one of several provisioning paths rather than singled out. - `apps/docs/content/guides/integrations/stripe-projects.mdx` (new): Overview, Quickstart (CLI commands from the Stripe Projects blog post), Authorizing the request (the actual Supabase-side confirmation screen behavior), and Limitations. - `apps/docs/components/Navigation/NavigationMenu/NavigationMenu.constants.ts`: added the new page to the Integrations sidebar nav, alongside Vercel Marketplace. ## Additional context - Worktree: `~/GitHub/supabase/supabase/.claude/worktrees/docs-1337-stripe-projects` - Paired eval issue: `DOCS-1338`: a regression eval to be added/run separately, before and after this PR, to confirm agent discoverability actually improves. - Out of scope: the agent-skills piece (separate `supabase/agent-skills` repo, federated into docs at `content/guides/ai-tools/ai-skills.mdx`) is being picked up separately. - The org-linking limitation is confirmed against `AccountRequestDetailsDto` and `AccountRequestsController_confirmAccountRequest` in `packages/api-types/types/platform.d.ts`: the schema exposes a single optional `linked_organization`, not a list, and the confirm endpoint takes no request body, so there's no way for the client to select a different organization. - The first Vercel deploy on this branch failed on an invalid `<!-- -->` HTML comment (not valid MDX); fixed in a follow-up commit to use `{/* */}`. - Heading case (`Stripe Projects`) and the word `proxied` needed allowlist entries in `supa-mdx-lint/Rule001HeadingCase.toml` and `supa-mdx-lint/Rule003Spelling.toml`, matching the existing `Vercel Marketplace` precedent. - Added a Limitations bullet (per reviewer suggestion from gregorvand) on accessing the dashboard for a newly provisioned organization via `stripe projects open supabase` or the reset-password flow. ### Integrations page update ([PR preview](https://docs-git-nikrichers-docs-1337-document-programm-7b3426-supabase.vercel.app/docs/guides/integrations))  ### Stripe Projects page addition ([PR preview](https://docs-git-nikrichers-docs-1337-document-programm-7b3426-supabase.vercel.app/docs/guides/integrations/stripe-projects))  ### Test plan - [x] Confirm the "Stripe Projects" section renders on [the Integrations overview page (preview)](https://docs-git-nikrichers-docs-1337-document-programm-7b3426-supabase.vercel.app/docs/guides/integrations) - [x] Confirm [the new Stripe Projects page (preview)](https://docs-git-nikrichers-docs-1337-document-programm-7b3426-supabase.vercel.app/docs/guides/integrations/stripe-projects) renders and appears in the sidebar under Integrations - [ ] Confirm the new page surfaces in `llms.txt` (directory/title based) - [x] Org-linking limitation confirmed via the `AccountRequestDetailsDto`/confirm-endpoint schema (see Additional context) rather than a Stripe Projects team conversation - [x] Re-ran `supa-mdx-lint` allowlist additions locally; heading-case and spelling findings addressed <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit - **New Features** - Added Stripe Projects to the integrations navigation. - Added guidance for provisioning Supabase projects through the Stripe CLI, synchronizing environments, accessing dashboards, rotating credentials, and understanding authorization and organization-linking limitations. - **Documentation** - Linked the Stripe Projects guide from the integrations overview. - Updated documentation validation to support Stripe Projects terminology and capitalization. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Nik Richers <nik@validmind.ai> Co-authored-by: Gregor <1828888+gregorvand@users.noreply.github.com> |
||
|
|
21265b2e59 |
docs(database): make writing and running the tests part of the procedure (#49276)
Ref DOCS-1274 Follow-up to #49017, now merged. This is the go-to-green piece: everything aimed at the three failing eval checks, and nothing else. Technical corrections follow in the PR stacked on this one. ## Problem `build-docs-002-rls-guide` points an agent at this guide with a vibe-coder prompt that never says RLS, policy, role, or test. Grants, policies, access probes, indexes, and security-definer placement all pass. Three checks fail, and have failed on every recorded run: | Check | What it measures | Why it failed | | --- | --- | --- | | `pgTAP test file(s) written under supabase/tests/` | Any `.sql` file exists | The agent never wrote one. | | `supabase test db runs at least 8 assertions and all pass` | Suite runs, ≥8 assertions, none failing | Nothing to run. The only example was `plan(4)`, under the floor even if copied perfectly. | | `tests assert allow and deny per operation … for anon and authenticated` | LLM judge on coverage | Never reached the judge: "no test files to review". | The guide already had a `Test your policies` section, so this isn't a strength problem. Agents don't read the page. They fetch it through an LLM extraction guided by their own query, and that query asked for enabling RLS, policy syntax, `auth.uid()`, indexes, and security definer functions. It never mentioned tests. A section about testing never enters the extract, so more testing prose cannot reach the agent. There was also a plain documentation bug underneath it: `Secure a table with RLS` said a table isn't secured until the suite passes, but the procedure beneath it ran 1–3 and ended on `grant`. A reader following the numbered steps finished without ever being told to write a test. ## Solution Put the tests where the procedure and the examples already are. - **`Secure a table with RLS`** opens with the four steps that finish a table, ending on `supabase test db`. Until the suite passes, you don't know whether the policies do what you intended. - **`Enable RLS and set the grants` gains step 4** — `supabase test new <table>_rls.test`, then `supabase test db`. The procedure ends on a passing suite instead of a grant. - **The public-read example** gains its policy and `announcements_rls.test.sql`, so a test file rides along in the enable-RLS extract. - **The four policy examples** are followed immediately by `profiles_rls.test.sql`, so one rides along in the `create policy` extract too. - **`Run the test suite` shrinks** to creating and running the files. It no longer carries content that has to survive extraction. - Each file leads with its own path as a comment, so it survives if the fence metadata is dropped. ### How that maps to the three checks | Check | Addressed by | | --- | --- | | Test files written | A complete test file now sits inside both extracts an agent's own query pulls, and step 4 of the procedure names the command that creates one. | | ≥8 assertions, all passing | `announcements_rls.test.sql` is `plan(10)`, `profiles_rls.test.sql` is `plan(14)`. Either alone clears the floor; together, 24. | | Coverage judge | `profiles` asserts allow **and** deny for all four operations. Allowed writes use `returning` + `results_eq`, proving state changed rather than that nothing raised. `using`-filtered denials use `is_empty`, asserting the row is unchanged rather than that an error was raised — the case the rubric explicitly fails suites for getting wrong. Both files switch role with `set local role` and identity with `set local request.jwt.claim.sub`, and cover `anon` as well as `authenticated`. | ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-tests-in-procedure-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. `Secure a table with RLS` opens with a four-step definition of done ending on `supabase test db`. 2. Read `Enable RLS and set the grants`. The procedure runs 1–4 and ends on writing and running the test, not on the grant. 3. Scroll to `DELETE policies`. The four policies are followed immediately by `profiles_rls.test.sql`, not a pointer to a later section. 4. Open the [markdown version](https://docs-git-docs-rls-tests-in-procedure-supabase.vercel.app/docs/guides/database/postgres/row-level-security.md), which is what agents fetch. Both test files are present, each leading with its path. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation - Updated database security guidance for enabling row-level security and configuring grants. - Added per-table pgTAP testing requirements and revised `supabase test db` examples. - Expanded examples for permitted and denied access across public and authenticated roles. - Added dedicated guidance for profile testing and security-definer member/non-member cases. - Documented recursive-policy `42P17` failures and the security-definer workaround. - Clarified indexing, denial diagnosis, returned-row verification, and table-hardening links. - Streamlined the general policy-testing guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
166cab8dee |
docs: fix api link path in pg_net.mdx (#49478)
## 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? fix: Updates the Data API link in current permission section ## What is the current behavior? The link currently points to the wrong path, resulting in a 404 error. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the Data API permissions documentation link to point to the current API guide. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
665f043ecb |
fix(docs)link-ch-sql-syntax (#49473)
semi related to this PR: https://github.com/supabase/changelog/pull/234 Trying to ensure the information architecture links someone reading the debugging docs to the correct info on SQL syntax required by CH. This is a simple QOL change vs doing a larger IA fix ## 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? Does not direct users to CH sql syntax doc ## What is the new behavior? Directs users to CH sql syntax doc ## Additional context https://supabase.com/changelog/48235-migration-of-supabase-management-api-logs-all-analytics-endpoint-to-logs-endpoint <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the MCP server description to link to Logs Explorer documentation for the supported ClickHouse SQL syntax used when querying logs. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
e478aabb80 |
Clarify pg_net net schema grants (#49472)
## 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 — adds a new "Permissions" section to the pg_net guide. ## What is the current behavior? The pg_net docs don't explain the default permission model for the net schema. Customers running security reviews flag that net schema objects (net.http_request_queue, net._http_response) are readable by anon/authenticated via inherited PUBLIC grants, and some have run their own REVOKE scripts to lock this down. This breaks the pg_net background worker, since postgres (the role the worker runs as) inherits its own access through that same PUBLIC grant. ## What is the new behavior? Adds a "Permissions" section clarifying that the default grants are safe as-is, net isn't exposed through the Data API, and anon/authenticated are NOLOGIN roles with no direct database connection. ## Additional context For background and reviewer discussion on the accuracy of this, see the https://supabase.slack.com/archives/C02FHG9QQAF/p1787299415288589. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added permissions guidance for the `net` schema. * Clarified access available to `anon` and `authenticated` roles. * Explained why these permissions do not expose request data through the Data API or direct database connections. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com> |
||
|
|
3bc52101ee |
(docs/pipelines): early access destinations (#49304)
## What kind of change does this PR introduce? Docs update ## Summary - Add Early Access setup and reference guides for ClickHouse, DuckLake, and Snowflake. - Update Pipelines navigation and shared documentation with destination-specific data models, source requirements, schema-change support, and recovery behavior. - Keep all three destinations organization-gated. DuckLake is documented only as a Pipelines replication destination i.e. query compute remains external and this is not a Warehouse launch. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added ClickHouse, DuckLake, and Snowflake as Early Access Pipelines destinations. * Added BigQuery as a managed destination. * Added destination navigation and setup guides covering configuration, replication behavior, schema changes, type mappings, troubleshooting, and monitoring. * **Documentation** * Clarified destination availability, regional guidance, requirements, limitations, and processing behavior. * Documented destination-specific schema-change support, table identity requirements, reset behavior, and CDC replication modes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
34454037d3 |
clean up docs admonition structure (#48669)
## What kind of change does this PR introduce? Docs update. Resolves DEPR-634. Stacked on #48664. The linter package and CI revision pins will be updated after [supa-mdx-lint#121](https://github.com/supabase-community/supa-mdx-lint/pull/121) merges and is released. ## What is the current behavior? Admonition body content can contain structural headings, which inherit prose spacing and produce awkward callout layouts. Standalone Docs actions are also rendered as ordinary body content in two places. | Before | | --- | | <img width="1264" height="840" alt="70168" src="https://github.com/user-attachments/assets/00aa7620-a6b4-452c-971f-b3ce2eda0e8c" /> | | _Recent violation with Markdown header in `children`. Notice the big gap up top._ | ## What is the new behavior? - Documents that admonition titles belong in the `title` prop, standalone calls to action belong in `actions`, and document sections belong outside admonitions. - Configures heading-inside-admonition violations as errors for the forthcoming linter release. - Moves the UI-library and wrapper dashboard buttons into the existing `actions` slot without changing the shared component. Validated with the forthcoming linter across all 810 Docs sources, Docs type-checking, targeted ESLint and Prettier checks, and desktop/mobile rendering. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified admonition guidelines for optional titles, headings, rich content, and standalone calls to action. * Improved guidance on when contextual links and interactive examples belong in admonition content. * **Style** * Updated documentation call-to-action buttons to use the designated actions area. * **Quality Improvements** * Added validation to prevent headings inside admonitions and maintain consistent formatting. * Updated documentation linting to apply the latest validation rules. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
22e2370b35 | docs(self-hosted): add poolers how-to guide (#49303) | ||
|
|
29e47821f5 |
fix(realtime): add pg changes pool to realtime settings (#49256)
## 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? Feature — adds a new Realtime setting to configure the Postgres Changes connection pool size. ## What is the current behavior? The Realtime settings page only exposes the connection pool used for Realtime Authorization (`connection_pool`). The pool that Realtime uses for Postgres Changes is not surfaced anywhere in the dashboard, so projects that need to tune it have no self-serve way to do so — the only option is to contact support. ## What is the new behavior? The Realtime settings page now includes a **Postgres Changes connection pool size** field: - Reads `postgres_changes_pool` from the project's Realtime config, falling back to a default of `2` when no override is stored. - Validates input from `1` through `20` (`MAX_POSTGRES_CHANGES_POOL`), and submits the value as a number in the config `PATCH` payload. - Docs (`apps/docs/content/guides/realtime/settings.mdx`) are expanded with sizing guidance for both connection pools, plus limits, resource-usage notes, and the operational error codes to look for. <img width="1160" height="166" alt="Screenshot 2026-08-19 at 13 59 04" src="https://github.com/user-attachments/assets/fd3ee29e-e9bf-438b-970f-8008ec57020f" /> ## Additional context The named `RealtimeConfigResponse` / `UpdateRealtimeConfigBody` schemas in the generated `api-types` package do not carry `postgres_changes_pool` yet, so both the query and mutation types extend the generated schema locally — the same pattern already used elsewhere in `apps/studio/data/`. Once the platform OpenAPI spec ships the field and `api-types` is regenerated, those two local intersections can be dropped. Covered by component tests in `RealtimeSettings.test.tsx` for both the fetch and save paths. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a Realtime setting to configure the Postgres Changes connection pool size. * Connection pools support 1–20 connections, with a default of 2. * Saving the setting now applies the configured value correctly. * **Documentation** * Expanded Realtime Settings guidance with configuration limits, resource usage, channel access, payload and presence limits, plan ceilings, spend-cap restrictions, and operational error codes. * Added guidance for sizing authorization and Postgres Changes connection pools. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com> |
||
|
|
bb086a84b8 |
feat(studio): remove read replicas from Replication (#49046)
## What kind of change does this PR introduce? Feature. Stack 4 of 5 for [PIPE-1007](https://linear.app/supabase/issue/PIPE-1007/move-read-replicas-out-of-replication-into-infrastructure). Contributes to PIPE-1008. ## What is the current behavior? Database / Replication lists, creates, and diagrams read replicas alongside pipelines. ## What is the new behavior? Replication is pipelines-only. No replica rows, type, or diagram nodes. `?destinationType=Read+Replica` redirects to Infrastructure. A short callout points create-mode users at the new home. ## Additional context Please review, but do not merge until [#48921](https://github.com/supabase/supabase/pull/48921) is ready to follow immediately. The flag is already on, so this PR is the user-facing cutover off Replication. ## To test `infrastructure:read_replicas` is an enabled-feature, on by default. There is no Feature Preview or ConfigCat switch. You should already see the Infrastructure Read replicas section. If you do not, your profile lists `infrastructure:read_replicas` in `disabled_features`. Open [Database / Replication](https://studio-staging-git-danny-pipe-1007-04-cut-from-77ef95-supabase.vercel.app/dashboard/project/_/database/replication?destinationType=Read+Replica). You should land on Infrastructure with the add-replica sheet, not a replica destination type. The Replication page itself should be pipelines-only. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added guidance directing users to Infrastructure to create read replicas. * Added automatic redirection for legacy read-replica links. * **Updates** * Replication destinations now focus exclusively on external analytics and pipeline destinations. * Updated destination selection, empty states, descriptions, and diagrams to reflect the streamlined experience. * Removed read replicas from the replication destination list and related creation flow. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com> |
||
|
|
2e65e82ef4 |
docs(platforms): query logs via the ClickHouse endpoint (#49299)
The `logs.all` Management API endpoint runs BigQuery SQL and is being
retired next month. The Platforms guide was the only hand-written doc
still pointing at it.
Repoints the debugging example at `GET
/v1/projects/{ref}/analytics/endpoints/logs`, which serves the same data
as a single `logs` table keyed by `source`, with structured fields in
the `log_attributes` map, and converts the query to the ClickHouse
dialect.
Verified by running the example's exact SQL and curl shape against a
real project on the OTEL logs endpoint: 100 rows, with `status_code` and
`path` populated.
The generated API specs still list `logs.all`; those regenerate from the
platform side.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated the Supabase for Platforms integration guide’s
debugging-projects example.
- Revised the example to use the analytics logs endpoint and unified
logs table.
- Added ClickHouse SQL filtering for edge logs, structured log
attributes, and HTTP errors.
- Improved the example’s alignment with current log query and analytics
capabilities.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
|
01d12e83c1 |
docs: migrate logs queries to ClickHouse and link to the SQL Editor (#49273)
The 47 BigQuery-era logs queries across these 20 pages error on the
ClickHouse-backed logs engine ("Backend error! Retry your query."). This
converts them per the rules in `apps/studio/lib/ai/clickhouse-logs.ts`
and repoints every Logs Explorer link at the SQL Editor with the query
source set to **Logs**, since the Logs Explorer is being retired. Also
fixes two stale PostgreSQL 12 links in the tables guide.
Each of the 14 prefilled links was verified to decode back to exactly
the SQL shown on its page. One caveat for review:
`response.headers.proxy_status` in `postgrest-error-codes.mdx` is
unverified — it isn't in the published field reference, and the test
project had no `edge_logs` traffic to confirm against.
Fixes DOCS-1331
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Documentation**
- Updated database, storage, API, and Edge Function logging guides to
use the SQL Editor and current Logs interface.
- Replaced legacy Log Explorer and BigQuery examples with current query
syntax and structured log fields.
- Refreshed troubleshooting queries for error diagnosis, filtering,
aggregation, and performance analysis.
- Improved examples with clearer source filters, status handling,
request details, joins, and result limits.
- Updated PostgreSQL documentation links and clarified how API error
codes appear in responses.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Jordi Enric <jordi.err@gmail.com>
|
||
|
|
e5f12b4252 |
fix(docs): fix step code block spacing and Prisma guide tabs (#49263)
Two fixes for the [Prisma guide](https://supabase.com/docs/guides/database/prisma): - `StepHikeCompact.Code` marked its whole subtree `not-prose`, so the labels and admonitions that steps interleave with their code samples rendered at 16px with zero margins, flush against the samples and tab bars. Dropping `not-prose` restores body typography and spacing; back-to-back samples now get a gap too, since they have no prose between them. - The guide's three outer tab groups omitted `type`, so they fell back to pill styling — the only pills among 395 `<Tabs>` in the content tree. Fixes DOCS-1327 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Improved spacing and prose behavior for code samples in the documentation. * Preserved existing code margin customizations. * Updated Prisma guide tabs with a consistent compact, underlined appearance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
6368f00ca0 |
docs(database): restructure the RLS guide by information type (#49017)
## Problem The guide alternated between context, procedure, and reference on almost every heading. A reader who wanted to write a policy passed through four context or reference sections to reach one. A reader who wanted the model had to skip three procedures. ## Solution - Group into three sections by information type: `Understand Row Level Security`, `Secure a table with RLS`, and `RLS reference`, with a navigation intro. - Merge the four policy sections. They repeated the same setup block, burying the clause that differed. One setup block now precedes four short policy examples. - Move the auto-enable recipe into `event-triggers.mdx`, whose stub section's entire body was a link back here. - Relocate the stranded `auth.uid()` caution into the `auth.uid()` reference. - Lift the revoke-and-grant procedure out of the danger admonition and merge it with the two other places that taught `enable row level security`. - Point the Grafana IO chart entry at the performance guide. Its `#rls-performance-recommendations` anchor went away when tuning split out in #49016. 765 lines to 582. 30 headings to 25. Headings are demoted rather than renamed wherever anything links to them. Every inbound anchor in the repo still resolves; the only one removed, `#auto-enable-rls-for-new-tables`, was referenced solely by the `event-triggers.mdx` stub this PR replaces. ## Note on the history Rebuilt from `master` after #49011, #49015, and #49016 merged. The branch previously carried those 10 commits plus rebase churn against them. Rebasing naively would have reverted review feedback from #49016 (`70fa812`), which removed the benchmarks table and the "This guide" opener from the performance guide. Those are deliberately not restored here. The only changes to that file are two missing `await`s and a join predicate that was a tautology while unqualified. The three PRs stacked on this one (#49268, #49269, #49270) have been rebased onto the new base. ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. Three top-level sections appear in the table of contents. 2. Select each link in the intro. All three jump to their section. 3. Open [Event triggers](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/event-triggers). The auto-enable section holds the full recipe instead of a link. 4. Open the [performance guide](https://docs-git-docs-rls-restructure-supabase.vercel.app/docs/guides/database/postgres/row-level-security-performance). No benchmarks table, and the three bullets at the top link into the RLS guide. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Reworked the Row Level Security guide with clearer guidance on grants, policies, permissions, performance, testing, views, and secure functions. * Added a complete example for automatically enabling RLS on newly created public tables. * Improved SQL examples and clarified table references in RLS performance guidance. * Corrected grammar in the Grafana chart troubleshooting documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
edf50668aa |
docs(database): split RLS tuning into its own guide (#49016)
Stacked on #49015, which is stacked on #49011. Review those first. ## Problem The Row Level Security guide spent 225 lines and 5 benchmark tables on performance, 29% of the page. The `RLS Performance and Best Practices` troubleshooting entry already covers the same six tips with the same numbers, from the same source. Neither page tells you how to check whether RLS is your bottleneck in the first place. Four of the six tips are not tuning advice. Indexes, `select`-wrapping, role scoping, and `security definer` safety change whether a policy is correct and safe, not just fast. ## Solution - Add `guides/database/postgres/row-level-security-performance`. It carries the client-filter rule, the join-rewrite rule, all 5 benchmark tables merged into one, and a new `Diagnose whether RLS is the bottleneck` section: toggle RLS off to confirm it's the cost, then read the plan under an impersonated role. That diagnostic exists in the troubleshooting entry and has never been in the guide. - Keep every rule that affects correctness on the RLS guide, grouped under `Write policies that scale`. These are also the four the `build-docs-002-rls-guide` eval grades, and an agent reads the guide top-down. - Repoint the Grafana IO troubleshooting entry at the new page. - Rewrite `More resources` as `Related content`. Every link now says what it is and when to use it. Adds `Advanced pgTAP testing`, the deepest RLS testing content in the docs, which nothing here linked. Drops discussion 14576: locked, mislabeled here as "RLS Guide and Best Practices" when it is "RLS **Performance** and Best Practices", and superseded by the troubleshooting entry and this new page. **Ownership rule** so the two pages don't drift: the RLS guide owns the rule and the correct form. The performance page owns the measurement and the optimizer explanation. If a sentence on the performance page tells you what to write, it belongs on the guide. Scoped out of this PR: `More resources` was assigned to the restructure PR in the plan, but the 14576 link is what this PR supersedes, so leaving it would ship a stale pointer. ## Manual testing 1. Open the [RLS performance guide](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/database/postgres/row-level-security-performance) on the preview. It appears in the left nav under Database, Access and security, directly below Row Level Security. 2. Select the three rule links in its intro. Each lands on the matching section of the RLS guide. 3. Open the [Row Level Security guide](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/database/postgres/row-level-security) and go to `Write policies that scale`. It holds indexes, `select`-wrapping, and role scoping, with one link out to the performance page. 4. Open the [Grafana IO troubleshooting entry](https://docs-git-docs-rls-performance-split-supabase.vercel.app/docs/guides/troubleshooting/interpreting-supabase-grafana-io-charts-MUynDR) and select the RLS performance guide link. It lands on the new page. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added a dedicated guide for diagnosing and improving PostgreSQL Row Level Security performance. * Expanded guidance on indexing, query filters, role targeting, function usage, and avoiding costly policy joins. * Updated the Row Level Security guide with streamlined, scalable policy recommendations and links to related resources. * Added the new performance guide to the Database documentation navigation. * Updated troubleshooting guidance to reference the dedicated performance guide. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
7107a22a67 |
docs(functions): update Pro and Team function limits (#49173)
Pro plan increased from 500 to 1000 functions per project, Team from 1000 to 2000. ## 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 for function limits ## What is the current behavior? The function limits for Pro and Team plans are 500 and 1000 respectively in the docs. ## What is the new behavior? The function limits are updated to 1000 and 2000 for Pro and Team plans in the docs to match the updated limits in the backend. ## Additional context <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated platform limits for Pro plans to support up to 1,000 functions per project. * Updated platform limits for Team plans to support up to 2,000 functions per project. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
2440b06cb7 |
fix(docs/oauth-server): add plain for code_challenge_method (#49180)
## 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 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that OAuth authorization requests support both `S256` and `plain` code challenge methods. * Recommends `S256` for improved security. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com> |
||
|
|
45bb7c30ce |
docs(database): fix RLS guide copy and two SQL examples (#49015)
Stacked on #49011. Base is `docs/rls-revision`, so review that one first. ## Problem An audit of the Row Level Security guide against `apps/docs/CONTRIBUTING.md` and `WORD_LIST.md` turned up 4 lint warnings and 3 things that are wrong rather than just untidy. - Two SQL examples contradict the guide's own advice. The own-profile `SELECT` policy has no `TO` clause. The `security definer` example has no `set search_path`. - `## Bypassing Row Level Security` says Service Keys bypass RLS, then a note says Supabase adheres to the signed-in user's policy anyway. The condition that separates the two is never stated. - `#using-functions` is linked twice from the RBAC guide and has never existed on the RLS page. ## Solution Copy and correctness only. No section moves, no heading renames. - Replace the italic emphasis on `never` with bold. CONTRIBUTING permits **bold** for a term the reader must not miss, not italics for general emphasis. The matching fix for `must` lives in #49011, which rewrites that line anyway. - Drop marketing language from the opener, the Supabase intro, and the policies and performance leads. Removes the idiom "get the hang of them" and the filler `just`. - Replace `we` with second person in two places. - Scope the own-profile `SELECT` example with `to authenticated`. - Pin `search_path = ''` on the `security definer` example, schema-qualify its body to match, and state the requirement in prose. - State when a Service Key actually bypasses RLS. - Repoint the two RBAC links to `#use-security-definer-functions` and `#helper-functions`. `supa-mdx-lint` on the RLS guide goes from 4 warnings to 0. ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-copy-fixes-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. The own-profile SELECT example shows `to authenticated`, and the security definer example shows `set search_path = ''`. 2. Open the [RBAC guide](https://docs-git-docs-rls-copy-fixes-supabase.vercel.app/docs/guides/api/custom-claims-and-role-based-access-control-rbac) and select the "RLS helper functions" link near the end. It lands on the Helper functions section instead of the top of the page. 3. From `apps/docs`, run `pnpm lint:mdx`. The RLS guide reports no warnings. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated access-control guidance with clearer links for security-definer functions and RLS helper functions. - Clarified that exposed tables require Row Level Security (RLS), while table grants and row policies provide separate controls. - Added least-privilege and grant-revocation examples, plus explanations for authorization errors. - Expanded testing guidance for CRUD policies, identity switching, and denied operations. - Improved recommendations for service keys, policy performance, indexing, and secure function configuration. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com> |
||
|
|
d2ccbe5d46 |
docs(database): close the RLS guide gaps the eval flagged (#49011)
Closes DOCS-1274 ## Problem The `build-docs-002-rls-guide` eval points an agent at the Row Level Security guide with a vibe-coder prompt that never says RLS, policy, role, or test. It failed 6 of 35 checks. Each failure traces to something the guide doesn't say. - **Grants.** `anon` kept insert, update, and delete on all four to-do tables. Both client roles kept writes on the weather feed. 24 privileges untouched. - **Indexes.** Missing on `list_members.user_id`. The agent indexed the other three, so it missed the composite-primary-key case specifically. - **Tests.** No pgTAP files. `Result: NOTESTS`, so the coverage judge never ran. ## Solution - **Add a `Grants and policies` section.** - **Rewrite the opening danger admonition around revoke-then-grant.** It previously showed `grant` only, which reads as though privileges start from nothing. - **Drop the `(or primary keys)` carve-out from `Add indexes`.** A column counts as indexed only when it leads a `btree` index, shown with a composite-primary-key example. - **Add a `Test your policies` section.** Covers file location under `supabase/tests/`, `supabase test db`, role and identity switching, which assertion matches which denial, and an 11-assertion example spanning allow and deny for all four operations across `anon` and `authenticated`. Used the supacademy RLS course as a second reference. Its framing of grants running before RLS shaped the new section. ## Manual testing 1. Open the [Row Level Security guide](https://docs-git-docs-rls-revision-supabase.vercel.app/docs/guides/database/postgres/row-level-security) on the preview. `Grants and policies` and `Test your policies` appear in the table of contents. 2. Select the `Grants and policies` link at the end of the first admonition. It jumps to the new section. 3. Open the [markdown version](https://docs-git-docs-rls-revision-supabase.vercel.app/docs/guides/database/postgres/row-level-security.md), which is what agents fetch. Both new sections and the revised `Add indexes` text are present. 4. From `apps/docs`, run `pnpm lint:mdx`. The 4 warnings on this file match `master`, with no new ones. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Documentation * Clarified that exposed tables must enable row-level security. * Explained the distinction between database grants and row-level security policies. * Added least-privilege examples for client roles, including read-only access. * Added pgTAP testing guidance with a complete `profiles` example. * Clarified that composite indexes support policy filters only on their leading columns. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
ff6c8d4b30 |
fix(log-drains): add UK1 and US2-FED Datadog regions (#49156)
## Summary - Add `UK1` and `US2-FED` to the Datadog region dropdown in the log drains studio UI - Add the same two regions to the Datadog region list in the log-drains docs page The Logflare backend added support for these two Datadog regions in [Logflare/logflare#3790](https://github.com/Logflare/logflare/pull/3790) (shipped in v1.50.1), but the studio dropdown and docs were never updated, so customers on UK1 or US2-FED couldn't actually select their region when setting up a Datadog log drain. ## Test plan - [ ] Open Project Settings → Log Drains → add a Datadog destination and confirm UK1 and US2-FED appear in the Region dropdown - [ ] Confirm a log drain configured with `UK1`/`US2-FED` saves and sends events successfully <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added support for configuring Datadog log drains in the UK1 and US2-FED regions. * **Documentation** * Updated the monitoring and debugging guide with the UK1 Datadog region. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
04ddc6bef8 |
chore: update cors for pg routes (#49136)
## 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? Bug fix - config hardening ## What is the current behavior? CORS is applied at the global level in a permissive mode ## What is the new behavior? Self-hosted envoy config should apply CORS to the `/pg` routes. These should only be called from the studio dashboard (when called via a browser). uses `SUPABASE_PUBLIC_URL`, which should mean this isn't a breaking change. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Security & Access** * Added stricter CORS controls for the `/pg/` route. * Requests are limited to the configured public URL and localhost origins. * Standard HTTP methods and headers are supported, with preflight responses cached for one hour. * **Documentation** * Updated self-hosting guidance to describe the `/pg/` route’s CORS policy. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
7c46793a3f |
docs: mention MCP debugging tools and Supabase agent skill in debugging docs (#48978)
## What - Adds a **Debug with AI tools** section to the debugging guide, covering the MCP debugging tools (`get_logs`, `query_logs`, `get_advisors`, `execute_sql`), the Supabase agent skill, and the combined plugin install, with a pointer to the MCP security best practices. - Adds a one-line pointer to it from the Monitoring and Debugging overview. - Adds the missing `query_logs` entry to the MCP server's Debugging tool group. Note: `pnpm lint:mdx` couldn't run locally (Node version), Prettier passes. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added guidance for debugging with AI tools, including MCP tools and the Supabase agent skill for reading logs and advisors. * Documented plugin installation and security considerations when connecting AI agents through MCP. * Added links from monitoring and debugging guidance to the new AI tools documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> |
||
|
|
4433d9ddaf |
feat(studio): mark PrivateLink waiting as a warning (#49086)
## What kind of change does this PR introduce? UI ## What is the current behavior? Waiting (still labelled Ready in #49085) is green. Creating is orange. Deleting is red. ## What is the new behavior? Waiting is orange. Creating is grey. Deleting is orange. Connected stays the only green state. | Before | After | | --- | --- | | <img width="1448" height="492" alt="CleanShot 2026-08-14 at 12 43 59@2x" src="https://github.com/user-attachments/assets/c0d95b51-7841-4714-a01b-47e5587c3efb" /> | <img width="1434" height="470" alt="CleanShot 2026-08-14 at 12 44 59@2x" src="https://github.com/user-attachments/assets/3ba10dc5-5fdd-464a-a748-5085d2d65df3" /> | | <img width="842" height="440" alt="CleanShot 2026-08-14 at 12 44 21@2x" src="https://github.com/user-attachments/assets/757db647-4b7c-4f77-8dcf-1eb289c40cc1" /> | <img width="842" height="432" alt="CleanShot 2026-08-14 at 12 44 49@2x" src="https://github.com/user-attachments/assets/1311a6d2-4712-4cb9-a6f2-f39387f0a953" /> | ## Additional context Stacked on #49085. See #49030 for the end state, as it may already include fixes you might propose. ## To test - **Project Settings → Integrations → AWS PrivateLink.** A connection that AWS has not accepted yet should show an orange **Waiting** badge, not green Ready. - Creating should be grey. Deleting orange. Expired and Failed stay red. - **Docs preview → Platform → PrivateLink.** Should say Waiting, not Ready. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Updated AWS PrivateLink connection statuses to accurately show “Waiting” while the AWS Resource Share is pending acceptance. * Refined status badge styling for creating, waiting, and deleting connections. * Clarified that Resource Shares must be accepted within 12 hours. * **Documentation** * Updated PrivateLink setup instructions to reflect the revised connection status flow. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
0c1da8fd09 |
feat(studio): tighten PrivateLink sheet fields (#49085)
## What kind of change does this PR introduce? Feature ## What is the current behavior? Add connection field order and nickname handling are harder to scan. Empty description can still show up as a blank name. ## What is the new behavior? Add connection is AWS account ID, then database, then optional description. An empty description is omitted from the list title. | Before | After | | --- | --- | | <img width="846" height="874" alt="CleanShot 2026-08-14 at 12 42 33@2x" src="https://github.com/user-attachments/assets/abfc4f37-a401-4bba-9408-c2530b0ac09b" /> | <img width="844" height="794" alt="CleanShot 2026-08-14 at 12 43 01@2x" src="https://github.com/user-attachments/assets/0cadeaea-583d-4c2b-9336-3d0fe6a1415b" /> | ## Additional context Stacked on #49084. See #49030 for the end state, as it may already include fixes you might propose. ## To test - **Project Settings → Integrations → AWS PrivateLink → Add connection.** Confirm field order: account ID, database, description. - Save once with a description and once without. Without one, the row title should fall back to the account ID. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added AWS account ID and database target fields to the PrivateLink setup form. - Added validation and improved preservation of entered values while editing. - Made the connection description optional. - Updated connection status labels and badges for clearer status visibility. - **Documentation** - Updated PrivateLink setup instructions to reflect the revised field order and optional description. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
3d966e3709 |
feat(studio): show PrivateLink resource IDs and use connection copy (#48967)
## What kind of change does this PR introduce? Feature and docs ## What is the current behavior? PrivateLink is labelled as an AWS account, and there is no way to tell which resource configuration belongs to the primary vs a read replica. Put simply: you’re not adding an AWS account. You’re adding a connection. One AWS account can have multiple PrivateLink connections, just to different databases, with more fields also coming soon. Part of PRODSEC-238 and fixes SEC-939. ## What is the new behavior? Each connection shows resource configuration IDs so primary and replica are distinguishable. Customer-facing copy says **connection**. API paths and AWS console labels still say association. | Before | After | | --- | --- | | <img width="1452" height="496" alt="CleanShot 2026-08-14 at 12 33 49@2x" src="https://github.com/user-attachments/assets/3b295136-0325-4587-9291-b5f01fc07806" /> | <img width="1440" height="434" alt="CleanShot 2026-08-14 at 12 34 30@2x" src="https://github.com/user-attachments/assets/dd6ba064-18e4-4969-9c76-e3b79ac9d288" /> | | <img width="846" height="912" alt="CleanShot 2026-08-14 at 12 33 28@2x" src="https://github.com/user-attachments/assets/c4c6caca-a2f6-4516-99c7-ad7cf865f8ac" /> | <img width="844" height="880" alt="CleanShot 2026-08-14 at 12 34 39@2x" src="https://github.com/user-attachments/assets/f3874c6b-abdc-4ef8-84fa-141cd9150871" /> | | <img width="1448" height="560" alt="CleanShot 2026-08-14 at 12 33 10@2x" src="https://github.com/user-attachments/assets/8ae734cb-ec1f-4e4e-acf7-f4de459296d1" /> | <img width="1460" height="496" alt="CleanShot 2026-08-14 at 12 32 15@2x" src="https://github.com/user-attachments/assets/883050d5-a6f1-44bd-8ebd-1513a2c41e9f" /> | ## Additional context First PR in a stacked PrivateLink series (#49084 onwards). See https://github.com/supabase/supabase/pull/49030 for the end state, as it may already include fixes you might propose. ## To test - **Project Settings → Integrations → AWS PrivateLink.** Open **Add connection**, or **View** an existing one. Confirm the UI says connection, and that resource config IDs are copyable. - **Docs preview → Platform → PrivateLink.** Procedure steps should say Add connection / View connection. --------- Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com> |
||
|
|
ee1eb5dbca |
docs: standardize quickstart guides (#48950)
## 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 new behavior? - All 19 guides follow one step order: create project → set up database → create app → AI tooling → add keys → create client → query data → run it → go to production. Added _template.mdx with structure requirements; it is not enforced with a lint check for now - this will be a separate PR before adding new guides. - 4 new partials replace copy-pasted blocks (AI tooling, connection strings, mobile env vars, going to production). - Error handling: return a message instead of a blank page when a query fails. - All guides verified and tested separately - all work as described. What was fixed: wrong env var names in the Hono sample, a Next.js page that redirected to login, missing database permissions in Refine and Hono, and stale file paths and APIs in SvelteKit, Refine, and TanStack. - Astro, Expo, Python, Laravel, and Rails were live but missing from the quickstart grid or listing page. Added, with two new icons. ## Quick links for review Base preview: https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs **Quickstart discovery**: new Astro/Expo/Python/Laravel/Rails entries and icons - [Docs homepage grid](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs) <img width="1998" height="882" alt="CleanShot 2026-08-12 at 12 06 31@2x" src="https://github.com/user-attachments/assets/942eb7e2-1e85-4b20-a6a7-c2b127d31b2b" /> - [Getting started overview](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started) <img width="856" height="878" alt="CleanShot 2026-08-12 at 12 13 30@2x" src="https://github.com/user-attachments/assets/d48091a9-7daf-4796-a521-14116b7479c9" /> ### New shared files: **[apps/docs/content/guides/getting-started/quickstarts/_template.mdx]( |
||
|
|
a5afb3dd22 |
feat(docs): add enterprise managed MCP auth (#47691)
## 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? Added docs for enterprise managed MCP auth <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added guidance for Enterprise-Managed Authentication for MCP. * Documented setup requirements, authorization flow, configuration steps, and security considerations. * Expanded the SSO guide and navigation with links to the new MCP authentication documentation. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Chris Chinchilla <chris.ward@supabase.io> |
||
|
|
773b388f25 |
chore(docs): correct api for temporary access (#48741)
## 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 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated temporary access guidance to require SSL-enforced incoming connections. * Updated Management API examples to use the `/jit-access` endpoint for checking, enabling, and disabling temporary access. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
9ef9f1b8c1 |
feat(self-host): use @supabase/server in functions template and docs (#48996)
Updates the self-host Edge Functions template to use `@supabase/server`, matching the CLI's `supabase functions new` templates (part of SDK-1150, follows up on #45635 which exposed `SUPABASE_JWKS` to the functions container). The `hello` example function now wraps its handler in `withSupabase({ auth: 'none' })` and resolves the package through a per-function `deno.json` import map, which the runtime auto-discovers, so no dispatcher changes are needed. The self-hosted functions guide is updated to match: the create-a-function snippet, a `ctx.supabaseAdmin` example replacing the manual esm.sh `createClient` wiring, and a note that `auth: 'user'` requires `SUPABASE_JWKS`. Verified on `supabase/edge-runtime:v1.74.0` with the compose environment variables: `curl /functions/v1/hello` returns the same response body as before, so existing docs and troubleshooting pages stay accurate. The `docker/.gitignore` change: `volumes/functions/**` ignores self-hosters' own functions, but it also hid the new `deno.json`, which must ship with the repo for the `hello` import to resolve. The allowlist entries follow the existing `main/index.ts` pattern. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Edge Functions now support authenticated invocation with publishable or secret API keys. * Function handlers can access authenticated and administrative Supabase clients through the request context. * Added automatic environment configuration and JWT verification support. * **Documentation** * Updated the self-hosting guide with the new function setup and authentication workflow. * Improved local function examples for supported access patterns and privileged operations. * **Tests** * Updated self-hosted smoke tests to validate publishable-key function access. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Kalleby Santos <kalleby_santos@hotmail.com> Co-authored-by: Kalleby Santos <105971119+kallebysantos@users.noreply.github.com> |
||
|
|
7bfc45cc7b |
Update pg_net schema (#48694)
## 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? The create extension snippet defaults to public which trips the Security Advisor check "0014_extension_in_public". The extension either way creates its own "net" schema. ## What is the new behavior? Register pg_net in the extensions schema. This is also the default when installing the extension from the dashboard. <img width="425" height="224" alt="image" src="https://github.com/user-attachments/assets/160309c0-9d35-4de7-b583-32f5db310a96" /> ## Additional context When no schema is specified, defaults to public which trips the Security Advisor check: <img width="1084" height="250" alt="image" src="https://github.com/user-attachments/assets/ac5f2859-17bf-4763-9880-453b0f414b4f" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the pg_net installation example to place the extension in the `extensions` schema. * Clarified that this configuration keeps pg_net out of `public` and satisfies the Security Advisor check. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
5627d01183 |
docs: Update tab reference in project setup documentation (#48451)
Tab naming has changed ## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. * YES/NO ## What kind of change does this PR introduce? * docs update ## What is the current behavior? * Tab section referred do NOT exist anymore ## What is the new behavior? <img width="1823" height="823" alt="image" src="https://github.com/user-attachments/assets/7f2253ba-a251-434d-a005-10a598ae83b9" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the User Management Starter quickstart navigation instructions to use **Reference > Examples** in the Dashboard. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com> |
||
|
|
514f53a944 |
docs: point explain and rpc reference links at their current pages (#48655)
## 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 fix (broken links). ## What is the current behavior? Three links in two troubleshooting entries point at `/docs/reference/javascript/explain`, which returns 404. That slug is not in the docs sitemap any more. Two of the three are not explain links at all. In `fixing-520-errors-in-the-database-rest-api-Ur5-B2.mdx` the link text is "RPCs" and "RPC" and the query string asks for `example=call-a-postgres-function-with-arguments`, so both were meant to point at the `rpc` reference. The third, in `understanding-postgresql-explain-output-Un9dqX.mdx`, really is about explain: the text is "EXPLAIN" and it asks for `example=get-execution-plan-with-analyze-and-verbose`. ## What is the new behavior? - the two "RPC" links now point at `/docs/reference/javascript/rpc` - the "EXPLAIN" link now points at `/docs/reference/javascript/using-modifiers-explain` Both destinations return 200. The `queryGroups` and `example` query strings are carried over unchanged, I only changed the slug. ## Additional context Files: - `apps/docs/content/troubleshooting/fixing-520-errors-in-the-database-rest-api-Ur5-B2.mdx` (2 links, to `rpc`) - `apps/docs/content/troubleshooting/understanding-postgresql-explain-output-Un9dqX.mdx` (1 link, to `using-modifiers-explain`) What I verified: `/docs/reference/javascript/explain` returns 404, and both `/docs/reference/javascript/rpc` and `/docs/reference/javascript/using-modifiers-explain` return 200 and appear in the sitemap. After the change there are no `javascript/explain?` references left in `apps/docs/content`. What I could not verify, so I am flagging it rather than claiming it: I could not confirm server side that the `example=` ids still exist on the destination pages, because the reference pages appear to build their example selectors client side and the ids are not in the fetched HTML. I kept each existing `example=` value as it was, on the basis that an unmatched example parameter just leaves the default selection rather than breaking the page, which is still better than the current 404. If you know those example ids have been renamed too, tell me and I will update them in the same PR. This was the one case I deliberately left out of #48568, where I said the intended target looked ambiguous. Looking at it again, the link text and the example parameter agree with each other in all three cases, so the mapping is clearer than I first thought. Gates run locally: `test:prettier` passes repo wide and the docs vitest suite passes (22 files, 169 tests, 1 file and 2 tests skipped). I did not run a build: `pnpm build` needs `DOCS_GITHUB_APP_PRIVATE_KEY` for the docs `build:federated-content` step, which I do not have, and it fails before Next compiles. Freshman contributor here, working through these with Claude Code's help and checking each URL myself. Happy to change any of the targets if you would rather they went elsewhere. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated database REST API troubleshooting links for RPC guidance. * Corrected the Supabase JavaScript EXPLAIN documentation link. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com> |
||
|
|
ececf6c003 |
docs: Update Devin Desktop Supabase plugin guides (#49048)
## 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? - Windsurf has been renamed to Devin Desktop. This PR updates public-facing mentions of Windsurf to Devin Desktop - Update MCP installation instruction to match the current behavior. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated supported environment guidance to reference Devin Desktop instead of Windsurf. * Updated the MCP configuration path for Devin Desktop. * Removed outdated Windsurf-specific setup instructions and transport limitations. * Refreshed related MCP client labeling and setup guidance for clarity and consistency across the documentation and configuration experience. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com> |
||
|
|
4d492db5eb |
docs: update settings links after upgrade UI move to General (#49053)
## 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 - Upgrade project button and Postgres/PostgREST version checks moved from Infrastructure to General settings - Updated links across 13 docs pages to match <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated dashboard links throughout the documentation to direct users to **General Settings** instead of **Infrastructure Settings**. - Corrected guidance for Postgres, pgvector, pg_net, and PostgREST upgrades, configuration, and version checks. - Updated monitoring, Grafana, and Log Drains links to current documentation paths. - Fixed troubleshooting links, CLI project path examples, pg_cron terminology, and Markdown formatting. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
0c2b8d77b2 |
fix: Update supabase test docs to use _test.sql (#48993)
## 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? The database testing docs currently show test files using the `.test.sql` suffix, but `supabase test new` generates `_test.sql` files. Both formats work, but the generator behavior matches the previous Go CLI implementation and existing test fixtures. Update the docs for consistency with the actual generated file naming. Relevant context: [database testing docs](<https://supabase.com/docs/guides/database/testing>) and [CLI-1318](<https://linear.app/supabase/issue/CLI-1318/port-supabase-test-db-supabase-test-new>). We might want to add `supabase test new` to the docs, but that's a separate change. ## What is the current behavior? It reports `.test.sql` ## What is the new behavior? it reports `_test.sql` inline with the generator ## Additional context [slack thread](https://supabase.slack.com/archives/C07E5GFAHTM/p1786373594478619) - we can also add the test generator to the docs but I think that's a separate issue. |
||
|
|
25e77c4720 |
(fix): clarify re-enabling data api section of no exposed schemas troubleshooting guide (#48998)
## 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? ## Additional context Add any other context or screenshots. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded troubleshooting guidance for re-enabling the Data API after applying the schema exposure workaround. * Clarified the steps and context for reversing the workaround. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
ba5f0f57fd |
docs: add update step to agent skills docs page (#48982)
The agent skills docs page covered installing skills but not upgrading them, and skill fixes/features (like the debugging skill, only available from v0.1.8) can go unnoticed if users never re-run the CLI. Adds an **Upgrading skills** section with the `npx skills update` command and a link to the [`skills update` docs](https://github.com/vercel-labs/skills#skills-update). ### Preview <img width="813" height="611" alt="image" src="https://github.com/user-attachments/assets/c4b96316-f2d1-4b8a-b7bd-a868156447d5" /> [source](https://docs-git-docs-add-update-agent-skills-step-to-docs-supabase.vercel.app/docs/guides/ai-tools/ai-skills) Closes [AI-1066](https://linear.app/supabase/issue/AI-1066/add-agent-skills-upgrade-step-to-docs-page). <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Added an “Upgrading skills” guide explaining how to update all or selected installed skills. * Included links to additional documentation for more details. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
0c27456c86 |
docs: Update documentation from JS, Dart, and Swift SDK changes (#48723)
## Summary Updates docs based on recent SDK changes across three of the six tracked SDKs. `supabase-py`, `supabase-kt`, and `supabase-csharp` were also analyzed this cycle but had no doc-worthy changes (internal bug fixes / dependency bumps only, or no new commits). ## Changes analyzed | SDK | Repo | Commits | Latest tag | |---|---|---|---| | js | https://github.com/supabase/supabase-js | `485695ff7...21e410f56` | v3.0.0-next.29 | | dart | https://github.com/supabase/supabase-flutter | `6979093...5447063` | yet_another_json_isolate-v2.1.1 | | py | https://github.com/supabase/supabase-py | `3c98900...0490201` | v3.0.0a1 | | swift | https://github.com/supabase/supabase-swift | `c24795d...51a083a` | v2.54.1 | | kt | https://github.com/supabase-community/supabase-kt | (no new commits) | 3.7.0 | | csharp | https://github.com/supabase-community/supabase-csharp | `572624e...ac057a2` | v1.5.0 | ## Documentation updates - **`apps/docs/content/guides/auth/sessions/pkce-flow.mdx`** — new "Overlapping flows" section documenting the experimental `appendPkceFlowIdToRedirects` option and `flowId`-aware `exchangeCodeForSession()`, added in supabase-js #2569, which fixes concurrent PKCE flows (e.g. multiple tabs) clobbering each other's stored code verifier. - **`apps/docs/spec/supabase_dart_v2.yml`** — `stream()` entry: documented the new filter methods (`like`, `ilike`, `match`, `imatch`, `isFilter`, `isDistinct`) and multi-filter chaining added in supabase-flutter #1610, plus two behavioral caveats (filter re-evaluation on UPDATE, primary-key-only DELETE payloads) and a new example. - **`apps/docs/spec/supabase_swift_v2.yml`**: - `invoke()` entry: documented the new `timeoutInterval` override on `FunctionInvokeOptions` (supabase-swift #1144), with a new example. - Added missing `generate-link` and `signOut()` (admin) spec entries — supabase-swift #1152 added these methods but Swift had no reference entries for them, even though the shared nav ids already existed in `common-client-libs-sections.json` for other SDKs. ## Test plan - [x] `python3 -c "import yaml; yaml.safe_load(...)"` on both edited YAML spec files — parses cleanly - [x] `npx prettier --check` on all three changed files — passes - [ ] Visual check of rendered reference pages for the new Swift `generate-link` / `signOut` / timeout examples and the Dart `stream()` multi-filter example (docs dev server) --- 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Added guidance for experimental overlapping PKCE authentication flows, including separating concurrent flows and exchanging their flow IDs. - Expanded Dart streaming documentation with filter operators, multiple-filter behavior, update semantics, delete payloads, and chained-filter examples. - Added Swift documentation for admin link generation, user sign-out, and configurable Edge Function timeouts. - Documented the default 150-second Edge Function idle timeout and per-invocation timeout overrides. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
|
1440cb81ab |
docs: update database inspect page title DOCS-1300 (#48972)
## Problem The database debugging and monitoring guide had the generic title "Debugging and monitoring", which lacked product context and made it unclear in search results or breadcrumbs which area it covered. ## Fix Changed the page title to "Database debugging and monitoring". The sidebar entry keeps its shorter "Debugging and monitoring" label since it already has database section context. ## How to test - Navigate to the database debugging and monitoring guide in the docs - Confirm the page H1 reads "Database debugging and monitoring" - Confirm the sidebar entry still reads "Debugging and monitoring" <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the guide title to “Database debugging and monitoring” for clearer navigation and context. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
47595f8ac7 |
feat(self-hosted): implement queryLogs for the MCP debugging tools (#48900)
> [!IMPORTANT] > > Only merge this when (https://github.com/supabase/platform/pull/36804) is merged, as the AI assistant will not have access to the `query_logs` tool for the remote MCP server ## 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? Feature (self-hosted / CLI Studio MCP server). ## What is the current behavior? Self-hosted `getDebuggingOperations` (`apps/studio/lib/api/self-hosted/mcp.ts`) implements only `getLogs`, so the MCP `debugging` group exposes `get_logs` — a fixed per-service log dump built by `getLogQuery`. Logs are served by Logflare, which speaks BigQuery SQL. ## What is the new behavior? Bumps `@supabase/mcp-server-supabase` to `^0.10.0` (adds `query_logs` + `logsDialect`, and hides `get_logs` wherever a platform declares `queryLogs`) and moves logs over to it. - **Self-hosted `query_logs`:** declares `logsDialect: 'bigquery'` and implements `queryLogs`, passing the model's SQL straight through to the same Logflare `logs.all` endpoint (arbitrary `sql` param) — no new endpoint, no dialect translation. - **Drops `get_logs` from self-hosted:** `getLogs` throws (the server hides it once `queryLogs` exists) and the per-service `getLogQuery` builder is deleted; the model now writes its own BigQuery SQL, guided by the dialect schema hint. - **Honors no-logs mode:** `query_logs` throws when `logs:all` is disabled — the self-hosted default, enabled via the `docker-compose.logs.yml` override. - **Assistant:** switches the dashboard assistant from `get_logs` to `query_logs` (allowlist, drift guard, prompt, mocks, evals). Refs AI-1046 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * AI debugging can query recent project logs using read-only SQL. * Log queries support optional time-range filters, filtering, aggregation, and joins. * Self-hosted debugging checks whether logging is enabled before running queries. * **Bug Fixes** * Updated debugging workflows and validation to consistently use the new log-query capability. * Removed reliance on legacy service-specific log filtering and query behavior. * **Documentation** * Updated MCP debugging tool guidance to describe SQL-based log queries. * **Tests** * Expanded coverage for enabled, disabled, and unsupported logging scenarios. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
|
34c29f0b98 |
docs(python): add python docs for otel instrumention (#48898)
## 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? Adds a new tab section for the `client-side-tracing.mdx` document file, explaining how to setup OTel context propagation in the `supabase-py` library. ## What is the current behavior? No documentation. ## What is the new behavior? Documentation. ## Additional context Add any other context or screenshots. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the client-side tracing guide to document W3C trace-context propagation support in the Python SDK. * Added Python setup instructions for OpenTelemetry HTTPX instrumentation, tracer configuration, and tracing Supabase queries. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Katerina Skroumpelou <sk.katherine@gmail.com> |
||
|
|
433175e79a |
Clarify behavior of preview branches in documentation (#48744)
Update the description of preview branches to clarify that they are automatically deleted when a PR is merged or closed. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Clarified that preview branches are temporary and automatically deleted when a pull request is merged or closed. - Removed outdated guidance stating that preview branches pause after inactivity. - Clarified that persistent branches remain available long-term and are not automatically paused or deleted due to inactivity or pull request closure. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
fc5db9bb03 |
docs: update client-side tracing and Edge Function CORS guides (#48924)
Updates the client-side tracing and Edge Function CORS docs for changes shipping in `@supabase/supabase-js` v2.112.3 (supabase/supabase-js#2603, supabase/supabase-js#2604). The tracing guide gains a vendor compatibility table (plain OpenTelemetry works as is, Sentry needs `propagateTraceparent: true`, Datadog RUM needs `allowedTracingUrls`), the new `respectSamplingDecision` semantics (non-sampled requests now carry `traceparent` only, so logs stay correlatable), a troubleshooting entry for the SDK's new propagator warning, and a note that browser calls to Edge Functions need the trace headers in the function's CORS allow-list. The CORS guide now states explicitly that trace headers are sent only when trace propagation is opted in (never by default), adds a table of when each SDK header is actually sent, and the hardcoded `corsHeaders` examples are updated to the full header list. Should merge after the v2.112.3 release is published, since it documents that version's behavior. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded CORS guidance with trace-propagation requirements and SDK version considerations. * Added browser and Edge Function setup guidance for client-side tracing. * Documented updated sampling behavior, advanced configuration, vendor setup examples, and troubleshooting. * **Bug Fixes** * Updated CORS configurations to allow retry and tracing headers required for supported requests. * Improved compatibility for browser requests that transmit distributed tracing context. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> |
||
|
|
5b301e1ffa |
Add docs for diagnosing stuck and blocked queries (#48920)
## Context Related to the dashboard work for [Database Connections](https://github.com/orgs/supabase/discussions/48639) - updates the "Connection Management" docs page to include a section about "Diagnosing stuck and blocked queries". Content is intentionally agnostic to the UI, but more focused on Postgres. Preview: https://docs-cdukolvgy-supabase.vercel.app/docs/guides/database/connection-management Covers the following sub-topics: - Reading a session's state - Finding out what's blocking a query - How to stop the session responsible - Small footer to link to the dashboard's Database Connections page Also adding a cross-reference in 2 areas - Troubleshooting: How to check if my queries are being blocked by other queries - Monitoring and Debugging MDX -> Related to observability skills <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Expanded connection-management guidance with clearer explanations of session states. * Added instructions for diagnosing stuck or blocked queries, identifying blocking sessions and chains, and choosing when to cancel or terminate them. * Documented required permissions and available dashboard tools for managing sessions. * Added cross-references and telemetry updates to make troubleshooting guidance easier to discover. * Clarified how to use PostgreSQL activity information when investigating blocked queries. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
5a8eecf509 | feat(self-hosted): envoy is the default api gateway (#48153) | ||
|
|
9596b5f3ed | docs(self-hosted): add a separate architecture diagram (#48763) | ||
|
|
cb35e1f98e |
chore(library): update routes, redirects, and naming (#48668)
Our UI Library registry is expanding to include blocks that go beyond UI and in some cases focus purely on back-end. This PR is a precursor to adding more back-end related blocks. This PR includes the `ui-library -> library` rename plus redirects and small UI copy updates. Since this is a rename we'll need to update Vercel configuration. ## Vercel rollout Keep the Library project Root Directory as `apps/ui-library` 1. In the **Library** Vercel project, set: `NEXT_PUBLIC_BASE_PATH=/library` Apply it to Preview and Production, then redeploy the Library project. 2. In the **www** Vercel project, add: `NEXT_PUBLIC_LIBRARY_URL=<current value of NEXT_PUBLIC_UI_LIBRARY_URL>` Apply it to Preview and Production. Keep `NEXT_PUBLIC_UI_LIBRARY_URL` during the migration, then redeploy the www project. 3. Deploy in this order: 1. Library project 2. www project 4. Validate: - `/library` - `/library/docs/nextjs/password-based-auth` - `/ui` redirects to `/library` - `/ui/docs/nextjs/password-based-auth` redirects to `/library/docs/nextjs/password-based-auth` - `/ui/docs/ai-editors-rules/*` still uses its existing Docs redirects No Vercel dashboard redirect rules are needed. Environment-variable changes require a new deployment. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Supabase UI Library has been renamed to **Supabase Library** across navigation, pages, documentation, and resource links. * The Library is now available at `/library`, with updated descriptions covering components, blocks, and developer tools. * **Bug Fixes** * Added permanent redirects from legacy `/ui` URLs to corresponding `/library` paths. * Updated links throughout the site and documentation to prevent broken navigation and references. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
ae9042ceb4 |
feat(docs): scoped pat update (#48802)
## 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? Updates docs around scoped PAT's. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that temporary database access uses a Personal Access Token as the Postgres role password. * Updated API documentation to explain that Personal Access Tokens support custom expiration rather than being described as long-lived. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
18c26bf933 |
docs(auth): clarify audit logs storage options and configuration (#48852)
## Summary - Clarify that external log storage is the default - Explain that Postgres database storage is optional - Fix grammar and typos - Improve admonition messaging to be more actionable - Simplify toggle step wording for clarity Slack thread with team-auth: https://supabase.slack.com/archives/C022071RB2L/p1785945149999009 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Clarified that audit logs are stored in external log storage by default. * Documented optional database storage in `auth.audit_log_entries`. * Added instructions for enabling or disabling database storage with the “Write audit logs to the database” toggle. * Noted that enabling database storage incurs additional database storage costs. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |