mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
2013ebf417f01930f2b954fb3aa4ee8c463f88d1
2260
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
bdfd69e955 |
docs(api): note db.schema generic requirement for TS (#49967)
Adds a note to the "Using Custom Schemas" guide:
`createClient<Database>(...)` needs the schema passed as the second
generic (`createClient<Database, 'myschema'>(...)`) to type-check
`db.schema` against anything but `public`.
`supabase.schema('myschema').from(...)` is the per-call alternative that
needs no second generic.
Related to supabase/supabase-js#969 — the existing JS example has no
type parameters so it never surfaces this, and TypeScript users
extending it with `<Database>` hit a confusing compile error with no
pointer to the fix.
supabase-js companion: supabase/supabase-js#2662
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added guidance to the custom schemas guide explaining TypeScript
typing behavior when using non-public schemas.
* Clarified how to specify a schema explicitly and when schema types are
inferred automatically.
* Noted that custom schemas must be included in the generated `Database`
type.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
|
90b7b34d7f |
docs(self-hosted): add passkeys guide (#48954)
] |
||
|
|
479486433e | docs(self-hosted): add auth hooks guide (#43372) | ||
|
|
37a95fd912 | docs: update edge functions limits and examples across guides (#49899) | ||
|
|
6e83f71a56 |
docs: wire middleware sdk docs (#49854)
Wire middleware sdk docs (`@supabase/middleware`) https://github.com/supabase/middleware Preview ref here: https://docs-git-docs-supabase-middleware-sdk-supabase.vercel.app/docs/reference/middleware/introduction <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a Middleware SDK reference section to the documentation. * Added installation guidance for npm, Yarn, pnpm, Deno, and Bun. * Documented framework-agnostic middleware composition, typed shared context, ordering, trust, and environment access across supported runtimes. * Added Middleware documentation to navigation and search. * Identified the Middleware SDK as an alpha release. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
4d2bd0eacf |
docs: add the missing API key decision information (#49799)
Closes DOCS-1311 Closes FDBKIN-2926 Closes DOCS-694 ## 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. Corrections and new content. This is the PR that is to bring the Eval to green. ## What is the current behavior? Two statements are wrong, and the gaps behind most logged confusion about this page are unfilled. - The Availability column marks publishable and secret keys Platform-only. `supabase start` prints both. - The page says Edge Functions only verify the legacy keys and to use `--no-verify-jwt`. #49700 updated `guides/functions/auth-headers` to document that `verify_jwt` accepts the new keys on either header, but left this page and the migration guide stating the old behavior. - The page has no code samples, so it never shows how a key reaches code. An agent reading it falls back on `SUPABASE_SERVICE_ROLE_KEY`, the legacy key this same page deprecates. - Nothing maps `anon` and `service_role` to their replacements, or says the replacements aren't `eyJ`-prefixed JWTs. - The Postgres role table covers only publishable keys. ## What is the new behavior? Corrections: - Mark all four key types available on Platform and CLI, and note that the local secret key takes the place of the local `service_role` key. - Point the Edge Functions guidance at the `@supabase/server` SDK instead of `--no-verify-jwt`. Fix the same bullet in the migration guide. Additions: - "Coming from `anon` and `service_role`" gives the legacy-to-new mapping and says the replacements aren't JWTs. - Extend the Postgres role table to cover secret keys, and note that grants are evaluated before Row Level Security, so a missing grant fails even for `service_role`. - State who does what. Copying a key needs a signed-in Dashboard session, so it is a person's step, while code only refers to the variable name. Add a `.env` sample naming the variables. - Add the two `createClient` samples the page lacked, plus an "Inside an Edge Function" subsection using `withSupabase`, which reads no key from the environment. - Cross-reference from the key decision to retrieving a value, wiring it into code, or migrating an application that ships legacy keys. ## Additional context PR 4 of 4. Base is #49797. ## Manual testing 1. Open the API keys guide on the deploy preview. 2. Check the Key types table. All four rows read "Platform, CLI". 3. Check Known limitations. It no longer mentions `--no-verify-jwt`. 4. Open the migration guide and check Known limitations. The Edge Functions bullet matches. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated API key guidance with clearer instructions for finding, selecting, and using publishable and secret keys. * Added examples for environment variables, client applications, backend code, and Edge Functions. * Clarified key formats, CLI availability, local development output, Postgres role mappings, and authorization behavior. * Expanded guidance on `apikey` headers, RLS errors, and Edge Function API key authorization. * Refined migration guidance for API key authentication in Edge Functions. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
5bd0b90cf0 |
docs: add all ways to get an API key (not just Studio) (#49797)
## 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? "Find your keys" offers only the Dashboard. Readers working from a script, a preview branch, or a local stack have no path, which accounts for several logged reports of people unable to locate a key. ## What is the new behavior? Replace the procedure with a tabbed selector so a reader picks the path that matches where they work: - Dashboard, through the Connect dialog or Settings > API Keys. - Supabase CLI, `supabase projects api-keys --project-ref`, including the note that a preview branch has its own keys and needs its own ref. - Management API, `GET /v1/projects/{ref}/api-keys?reveal=true`, for deploy scripts and provisioning tooling. - Local stack, from `supabase start` output or `supabase status`. `queryGroup="retrieval-method"` makes each tab deep-linkable, so a reader can be sent straight to one path. ## Additional context PR 3 of 4. Base is #49796. ## Manual testing 1. Open the API keys guide on the deploy preview and find "Find your keys". 2. Select each tab. One panel shows at a time, and the URL gains `?retrieval-method=<tab>`. 3. Open that URL in a new tab. It restores the same selection. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated the API key deprecation guidance to link to the “Find your keys” guide. - Expanded the guide with instructions for retrieving keys through the Dashboard, CLI, Management API, and local stack. - Added guidance to create keys in the Dashboard when none are available. - Reworded the table of contents entry for improved clarity. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
d7f1a44e53 |
docs: restructure the API keys guide by information type (#49796)
## 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. Restructure, mostly moved lines, plus a tense fix in a shared partial. ## What is the current behavior? Context, procedure, and reference material are interleaved, so background reading interrupts the action path. - The page never states which key to use as an answer. You infer it from a five-column reference table. - Finding a key is a fragment inside an admonition, placed above the page's own definition of an API key. - Rotating a leaked key, the only procedure on the page, is the last H3. - The "Changes to API keys" notice narrates a past change in future tense, and "They will be deprecated" has no antecedent in its paragraph. ## What is the new behavior? Group the guide into context, procedure, and reference sections, per CONTRIBUTING § Guides on mixed information types. - Lead with "Which key do you use?", a decision table keyed on where the code runs. Section navigation sits directly below the intro. - Collect the conceptual sections under "How API keys work" and give publishable and secret keys parallel headings. - Promote both procedures into "Find and use your keys". Rotation is now an ordered procedure. - Move the enumerated secret key rules into "Security reference", grouped under bold labels by the kind of mistake each prevents, and leave a short danger admonition where secret keys are introduced. - Promote the five-sentence coexistence admonition to its own section. Admonitions are for short warnings. - Rewrite the shared deprecation partial for timeless documentation: present tense, no dangling "They", no "now". The partial renders on five pages. - Pin a stable anchor on the rotation heading and update the one inbound link, in the rotating-anon-service-and-jwt-secrets troubleshooting entry. - Align link text across docs for this guide. Twenty-one links pointed at it under fourteen labels, including two that named the wrong destination. Rule: when a link means the guide, the text is "API keys"; when it means a specific key or section, the specific text stays. Twelve now share "API keys", up from three. Review with `git diff --color-moved=zebra`. ## Additional context PR 2 of 4. Base is #49795. Includes the link-text alignment previously opened as #49866. ## Manual testing 1. Open the API keys guide on the deploy preview. 2. Check the table of contents. It shows three groups: How API keys work, Find and use your keys, Security reference. 3. Open the rotating-anon-service-and-jwt-secrets troubleshooting entry and follow "Rotate a leaked or compromised key" under Further readings. It lands on the renamed heading. 4. Open the Realtime Broadcast guide and check the "Changes to API keys" notice. It reads in present tense there too. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Documentation** - Updated API key guidance to explain the transition from legacy `anon` and `service_role` keys to publishable and secret keys by the end of 2026. - Reorganized the API keys guide with clearer key-selection guidance, security recommendations, usage examples, and rotation steps. - Updated troubleshooting references to point to the revised leaked-key rotation guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
2f31010a18 |
docs: style edit for the API keys guide (#49795)
## 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. Style only. ## What is the current behavior? The API keys guide has drifted from `WORD_LIST.md` and `CONTRIBUTING.md`. It also carries two defects: - The rotation steps tell you to replace the new key with the compromised one, rather than the reverse. - The secret key caution list opens with "Do not:" but several items read "Never use" and "Do not pass", which inverts them into the opposite instruction. ## What is the new behavior? Word-level edit. No section is added, moved, or reordered, so the restructure in the next PR of this stack lands as a readable set of moved lines. - Fix the reversed rotation instruction. - Rewrite the caution list so every item completes its "Don't:" stem. - Replace the Silicon Valley character names and trailing ellipses in the responsibility table. - Drop italics used for plain emphasis, parenthetical asides, `etc.`, `&`, the lint-flagged "easy", and existential sentence openers. - Replace "since" and "as" used for cause, and future tense used for current product behavior. ## Additional context PR 1 of 4. Base is `master`. ## Manual testing 1. Open [Understanding API keys](https://docs-git-docs-api-keys-style-edit-supabase.vercel.app/docs/guides/getting-started/api-keys) on the deploy preview. 2. Read the secret key caution list. Every item completes the "Don't:" stem. 3. Read "What to do if a secret key or `service_role` has been leaked or compromised". The order is: create the new key, then replace the compromised key with it. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Rewritten the API keys guide with clearer wording and improved structure. * Clarified how to access API keys through the Connect dialog and distinguished API keys from Supabase Auth. * Updated explanations of publishable and secret keys, including cautions, security best practices, and steps for responding to leaked keys. * Refined guidance on known limitations and compatibility differences. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
55385adad5 |
fix(docs): fix tab bar overlapping code blocks (#49775)
## What kind of change does this PR introduce? bug fix: removes `<$CodeTabs>` from [declarative-database-schemas.mdx](https://github.com/supabase/supabase/blob/master/apps/docs/content/guides/local-development/declarative-database-schemas.mdx) following up with #49263 ## What is the current behavior? on [/declarative-database-schemas](https://supabase.com/docs/guides/local-development/declarative-database-schemas#declaring-your-schema) the tab bar above each step code block overlaps the code below it every step wraps code in `<$CodeTabs>` but carries a `-mb-6` expecting the code default margin to absorb it, while `StepHikeCompact` zeroes™ it note: it's the only page nesting `<$CodeTabs>` inside a step ## What is the new behavior? | state | preview | | -------|------| | before | <img width="795" height="417" alt="image" src="https://github.com/user-attachments/assets/d3d65f57-d621-4d5a-a3f9-229f5908cdf7" /> | | after | <img width="795" height="417" alt="image" src="https://github.com/user-attachments/assets/f3dc9f2d-fd4b-4ebd-95b4-63de587604fb" /> | ## Additional context could go the other way and add `<$CodeTabs>` to those two guides for consistency but that would need StepHikeCompact to take another ! utility to restore it, but not against it if feels better. |
||
|
|
2681a21f5c |
docs: add Personal Access Tokens guide with generated permission tables (#49732)
Add a guide that compares classic and scoped personal access tokens, explains how account roles constrain token permissions, and walks through creating and testing a project-scoped token. Include generated tables mapping permissions to Management API endpoints and MCP tools, and link the guide from docs navigation and Studio token sheets. Move the scoped-token permission catalog from Studio into shared-data. Studio and docs generation now share permission names, categories, descriptions, risk metadata, modes, scopes, and display order. Generate the tables from the shared catalog, OpenAPI x-fga-permissions, and the downloaded MCP permission map. Exclude Workers permissions until the feature is live. Run regeneration through the docs Makefile, verify checked-in output in CI, and refresh it in the weekly Management API workflow. Add Dashboard and Docs ownership plus contributor guidance so permission changes stay synchronized. |
||
|
|
fda58a4b38 | docs: clarify that new API keys are accepted in the Authorization header (#49700) | ||
|
|
59c8ea3ddc |
docs(BRA-282): clarify that branches are created as clones of the base project (#49594)
## What kind of change does this PR introduce? Docs update. ## What is the new behavior? The branching docs now state consistently that every branch, preview or persistent, is created as a clone of the base project, starting with that project's schema, Edge Functions, and configuration. Data and storage objects are not cloned by default. ## Additional context This documents new branch-creation behavior. Two automated reviewers flagged the clone wording and argued for a migration-replay description; that reflects the previous implementation, so their findings don't apply here and the clone framing stands. --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Jeremias Menichelli <jmenichelli@gmail.com> |
||
|
|
aeb9511967 |
docs: retarget upgrade caveats to 15.19/17.11 + add btree_gist reindex note (#49621)
## 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 — Postgres upgrade guide for the 15.19 / 17.11 minor release. ## What is the current behavior? The upgrade guide's caveats are tagged for 15.18 / 17.10. ## What is the new behavior? - Retarget the ltree-reindex and custom-operator caveats: `15.18 or 17.10` → `15.19 or 17.11`. - Replace the ltree detection query with an operator-class-based one that also catches expression indexes and excludes `INCLUDE`d columns. - Add a `btree_gist` caveat: `float4`/`float8` gist indexes that may contain `NaN` need a `REINDEX` (upstream fixed NaN handling in 15.19/17.11). - Note the separate ltree >~14,653-label overflow case (encoding-independent). - Use schema-qualified names in `REINDEX INDEX CONCURRENTLY` and note it cannot run inside a transaction block. Detection queries validated on real 15.19 and 17.11. ## Additional context Refs: PSQL-1245. A pgcrypto (CVE-2026-14663) caveat is intentionally not included here. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated upgrade guidance for PostgreSQL 15.19 and 17.11. * Documented schema-qualified ltree index names and transaction-block restrictions for reindexing. * Improved the ltree overflow query to account for partial-index predicates when identifying values exceeding approximately 14,653 labels. * Added guidance for identifying and concurrently rebuilding affected `btree_gist` floating-point indexes containing `NaN` values. * Updated supported-version guidance for custom operator selectivity estimators. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
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](https://github.com/supabase/supabase/blob/e311542913cf8da07f322a7586339d6f5de30c61/apps/docs/content/guides/getting-started/quickstarts/_template.mdx?plain=1)** A reference contract the other 19 quickstart guides are checked against. Documents the required frontmatter, the canonical 10-step section order, every guide's deviation from that order (and why), the direct-Postgres exception (Laravel/Rails/RedwoodJS/Spring Boot), and the discovery-surface/icon requirements for adding a new guide. No lint rule enforces it yet; that's a follow-up PR. **[apps/docs/content/_partials/quickstart_ai_tooling.mdx](https://github.com/supabase/supabase/blob/e311542913cf8da07f322a7586339d6f5de30c61/apps/docs/content/_partials/quickstart_ai_tooling.mdx?plain=1)** Example: [Next.js](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/nextjs#4-set-up-ai-tooling-optional) → "Set up AI tooling" section Shared by all 19 guides: astrojs, expo-react-native, flask, flutter, hono, ios-swiftui, kotlin, laravel, nextjs, nuxtjs, reactjs, redwoodjs, refine, ruby-on-rails, solidjs, spring-boot, sveltekit, tanstack, vue **[apps/docs/content/_partials/quickstart_going_to_production.mdx](https://github.com/supabase/supabase/blob/e311542913cf8da07f322a7586339d6f5de30c61/apps/docs/content/_partials/quickstart_going_to_production.mdx?plain=1)** Example: [Next.js](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/nextjs#going-to-production) → "Going to production" section Shared by all 19 guides: same full list as above **[apps/docs/content/_partials/quickstart_connection_string.mdx](https://github.com/supabase/supabase/blob/e311542913cf8da07f322a7586339d6f5de30c61/apps/docs/content/_partials/quickstart_connection_string.mdx?plain=1)** Example: [Laravel](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/laravel#5-set-up-the-postgres-connection-details) → connection string setup step Shared by 3 guides: laravel, ruby-on-rails, spring-boot – the ORM/backend frameworks that connect directly to Postgres rather than through the Data API **[apps/docs/content/_partials/quickstart_mobile_env_note.mdx](https://github.com/supabase/supabase/blob/e311542913cf8da07f322a7586339d6f5de30c61/apps/docs/content/_partials/quickstart_mobile_env_note.mdx?plain=1)** Example: [iOS SwiftUI](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/ios-swiftui#get-api-details:~:text=This%20guide%20substitutes%20your%20project%20URL%20and%20key%20directly) → environment variables step Shared by 3 guides: ios-swiftui, flutter, kotlin – note Expo React Native is mobile too but doesn't use this partial, since it has its own `EXPO_PUBLIC_` prefix convention inline instead. ## Per guide changes **[Astro](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/astrojs#9-query-supabase-data-from-astro)** Typed query error in the server client sample. **[Expo React Native](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/expo-react-native#8-query-data-from-the-app)** Added an `error` state alongside instruments. Also removed the broken [`--web` verification path](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/expo-react-native#9-start-the-app): expo-sqlite needs Metro wasm + COEP/COOP config the guide never had (CodeRabbit finding). **[Flask](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/flask#7-create-the-supabase-client)** Split "Create the Supabase client" and ["Query data"](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/flask#8-query-data-from-the-app) into their own steps. **[Flutter](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/flutter#9-setup-deep-links-optional)** Reworded the deep-links section; keeps the framework-specific [Android `INTERNET` permission subsection](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/flutter#android) under "Going to production." **[Hono](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/hono#6-declare-supabase-environment-variables)** Split into "Install dependencies," "Declare environment variables," "Set up anonymous sign-ins," and "Query data" as separate steps. Fixes wrong env var names from the previous sample. **[iOS SwiftUI](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/ios-swiftui#8-query-data-from-the-app)** Added an `isLoading` state so the loading overlay doesn't hang forever on a successful empty result (CodeRabbit fix). **[Kotlin](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/kotlin#5-install-dependencies)** Fixed the Compose compiler plugin declaration: `apply false` was missing from the app module (CodeRabbit finding). **[Laravel](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/laravel#5-set-up-the-postgres-connection-details)** Now uses the shared `quickstart_connection_string.mdx` partial for the session-pooler/SSL guidance instead of inline copy. **[Next.js](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/nextjs#6-allow-public-access-to-the-instruments-page)** New step fixing the page that previously redirected to login. Its middleware path check is also now segment-aware so it doesn't over-match paths like `/instruments-private` (CodeRabbit finding). **[Nuxt](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/nuxtjs#7-create-the-supabase-client)** "Create the Supabase client" and ["Query data"](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/nuxtjs#8-query-data-from-the-app) split out as their own steps. **[React](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/reactjs#7-create-the-supabase-client)** Same client-creation/[query-data](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/reactjs#8-query-data-from-the-app) split as the other Vite-based guides. **[RedwoodJS](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/redwoodjs#2-gather-database-connection-strings)** Expanded into explicit transaction-mode/session-mode connection strings, Prisma schema, migration, seed, and scaffold steps; fixes stale file paths and APIs from the previous version. **[Refine](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/refine#8-allow-writes-to-the-instruments-table)** New step fixing the missing RLS grants that made the scaffolded create/edit pages fail. **[Ruby on Rails](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/ruby-on-rails#4-set-up-the-postgres-connection-details)** Now uses `quickstart_connection_string.mdx`; added a [reminder to save the database password](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/ruby-on-rails#1-create-a-supabase-project) before it's needed for the connection string. **[SolidJS](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/solidjs#7-create-the-supabase-client)** Same client-creation/[query-data](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/solidjs#8-query-data-from-the-app) split, adapted to Solid's `resource.error`. **[Spring Boot](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/spring-boot#4-set-up-the-postgres-connection-details)** Connection-string section now uses the shared partial instead of a duplicated inline caution. **[SvelteKit](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/sveltekit#8-query-data-from-the-app)** Updated `load` functions (both `+page.js` and `+page.server.ts` variants) with explicit query-error typing; fixes stale file paths and APIs from the previous version. **[TanStack](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/tanstack#8-query-supabase-data-from-tanstack-start)** `fetchInstruments` now returns and renders the query error instead of silently returning an empty list (CodeRabbit finding); fixes stale file paths and APIs from the previous version. **[Vue](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/vue#7-create-the-supabase-client)** Same client-creation/[query-data](https://docs-git-docs-standardize-framework-quickstarts-supabase.vercel.app/docs/guides/getting-started/quickstarts/vue#8-query-data-from-the-app) split as the other Vite-based guides. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added SolidJS, RedwoodJS, Refine, Laravel, and Ruby on Rails quickstarts. * Added framework discovery entries for Astro, Expo React Native, Python, Laravel, and Rails. * Added optional AI tooling, MCP setup, connection-string, mobile configuration, and production-readiness guidance. * Added a Hono authentication example with anonymous sign-in, user details, and instrument data. * **Documentation** * Expanded setup, environment, authentication, RLS, migration, SSL, and deployment guidance. * **Bug Fixes** * Improved sample error handling for failed data requests. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> |
||
|
|
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. |