## Context
Just a couple of UI polishes for the recovery codes UI under Account
settings -> Security - all visual, no functional changes
## Changes involved
- Shift position of Recovery codes section below MFA
- Better hierarchy since recovery codes only matter after adding an MFA
app
- Prevents layout shift with the feature flag as well
| Before | After |
|------|------|
| <img width="400" alt="image"
src="https://github.com/user-attachments/assets/3f24e30b-14b1-49cc-8942-0bd139af031b"
/> | <img width="400" alt="image"
src="https://github.com/user-attachments/assets/9a020b9b-4644-4e39-ba75-082e7f3a08db"
/> |
- Update how recovery codes are displayed
| Before | After |
|------|------|
| <img width="400" alt="image"
src="https://github.com/user-attachments/assets/9ce00013-9b7f-4ab9-9a10-0eec536022f5"
/> | <img width="400" alt="image"
src="https://github.com/user-attachments/assets/6bdc8c18-cfd2-46ea-a851-5a9fe03a5211"
/> |
- Update recovery codes modal, aligns "confirmation" UX to be more
consistent with scoped PAT
- Footer CTA is just "Done" that's disabled until either Copy or
Download is clicked
- Copy CTA shifted below codes for contextual grouping
- Also added download CTA, which just downloads codes in TXT
| Before | After |
|------|------|
| <img width="534" height="389" alt="image"
src="https://github.com/user-attachments/assets/55cdbe9f-f37c-4284-b2ac-46834fd14437"
/> | <img width="533" height="548" alt="image"
src="https://github.com/user-attachments/assets/ab091822-e5fc-464c-94e6-f1d6b6792c59"
/> |
- Show success toast after codes are successfully deleted
- Use warning variant for regenerate confirmation dialog
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Recovery codes are displayed as a numbered list, with separate options
to copy or download them.
* You must confirm that you’ve saved the codes before closing the
success dialog.
* **Improvements**
* Generation buttons show when codes are being created.
* Recovery-code actions have updated layouts, icons, and confirmation
styling. Available codes are identified as single-use, and loading
errors are displayed in an alert.
* Removing codes displays a success message before the confirmation
dialog closes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Gildas Garcia <1122076+djhi@users.noreply.github.com>
## Problem
The Sign in **Last used** badge overrode `Badge variant="success"` with
`bg-brand-400`, which reads as lime in light mode instead of the normal
success green.
## Solution
Remove the colour override so Last used uses the standard soft success
badge. No new Badge variant; no other callsite churn.
| Before | After |
| --- | --- |
| <img width="908" height="1292" alt="CleanShot 2026-10-05 at 14 19
27@2x"
src="https://github.com/user-attachments/assets/6890bf3d-90ce-423e-832a-0bbb0ecdf7cf"
/> | <img width="902" height="1280" alt="CleanShot 2026-10-05 at 14 31
15@2x"
src="https://github.com/user-attachments/assets/18b193a5-8015-4303-ac9a-a8d5981dd471"
/> |
## Review instructions
1. Open the Studio preview
[/sign-in](https://studio-staging-git-dnywh-1ce8f481-supabase.vercel.app/dashboard/sign-in)
(or the Vercel bot URL if it differs).
2. In DevTools: `localStorage.setItem('supabase-last-sign-in-method',
'email')`, then refresh.
3. Spot-check light and dark.
## Context
Just cleans up the experiment that was introduced
[here](https://github.com/supabase/supabase/issues/50851) - can clean up
feature flag in ConfigCat thereafter too
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Project Creation**
* Removed the “Best available” region option. Choose a specific region
or smart group when creating a project; the selected region name appears
in the selector.
* Recommended badges remain visible on recommended regions.
* **Telemetry**
* Project creation events no longer include details about the removed
region option or the initial region recommendation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
For staging and local only, if you opened the a table in the table
editor, then navigate out, and back into the table editor - the browser
freezes
- The TableEditor itself has a `useEffect` that reads that and redirects
to the last visited table when landing on `/editor`
- `router` is in the dependency array which for the TanStack build is
not a stable singleton, resulting in a redirect loop - so the main fix
was to remove `router` from the dependency array
- (Unrelated) Also cleaned up some logic in the redirect regarding
reading the tab ID
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Improved table editor redirects so they select the matching open table
tab from history or fall back to the first open table tab when
available.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
Two leftover App Router issues on www, unrelated to other in-flight
work:
1. `/partners` throws a React key warning because benefit items are JSX
fragments and cannot be used as keys.
2. App Router providers enable PostHog feature-flag fetches when
`IS_PLATFORM` is true. Local www does not run the platform API, so the
console fills with `Failed to fetch PH flags: API is not available`.
Pages `_app.tsx` already disables PH flags.
## Solution
- Key partner benefit list items by index (same pattern as the FAQ list
in the same file).
- Align App Router `FeatureFlagProvider` with pages: ConfigCat on,
PostHog flags off.
## Review instructions
1. Open preview `/partners` and confirm the benefits list renders with
no React key warning in the console.
2. On a local www App Router page (e.g. `/partners`), confirm the
PostHog `Failed to fetch PH flags` console error is gone.
3. Confirm ConfigCat-backed www behaviour is unchanged (pages router
already used this flags config).
## Checklist
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [ ] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs
[style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
## Problem
The Presence avatar stack on `/realtime` has had coloured rings since
the product page shipped. On production they often do not show: the gap
colour used `hsl(var(--background-surface-75))`, which is invalid after
semantic tokens moved to `oklch`, so the browser drops the whole
`box-shadow` and you get plain overlapping circles.
Separate from that token bug (fixed in
https://github.com/supabase/supabase/pull/51161), the stack still looked
wrong once the rings came back: fills used translucent `surface-200`
(`--muted`), initials clipped when discs overlapped too tightly, and the
card edge clipped the outer ring.
## Solution
- Restore rings with `var(--background-surface-75)` so the gap colour
resolves again
- Opaque `bg-surface-100` fills so stacked avatars do not show through
each other
- Draw the coloured ring first, then a card-coloured band outside it, so
neighbours read as separate discs instead of one muddy blob
- Tune size (`h-6.5`), overlap (`-space-x-[3px]`), and inset/padding so
rings and initials fit inside the card
- Smoother “You” hover: layout width and fade/scale decoupled, faster
exit
| Before | After |
| --- | --- |
| <img width="734" height="892" alt="CleanShot 2026-10-02 at 16 07
49@2x"
src="https://github.com/user-attachments/assets/a0cd1e62-8d4c-4ee8-9bed-19c085cf198e"
/> | <img width="736" height="896" alt="CleanShot 2026-10-02 at 16 07
02@2x"
src="https://github.com/user-attachments/assets/4b15867b-a95f-4482-85ce-07c51d1c20a8"
/> |
## Review instructions
WWW preview:
[zone-www](https://zone-www-dot-com-git-dnywh-fixrealtime-presence-0a88a4-supabase.vercel.app)
1. [Live /realtime](https://supabase.com/realtime) · [Preview
/realtime](https://zone-www-dot-com-git-dnywh-fixrealtime-presence-0a88a4-supabase.vercel.app/realtime)
2. Presence card, top-right: on live, plain circles with no coloured
rings; on preview, opaque discs with green/blue/red/orange rings and a
light gap between them.
3. Hover the card: “You” joins the stack with the same ring treatment
and a quick fade out when you leave.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Style**
* Updated the presence avatar stack with smaller, overlapping avatars,
colored rings, and adjusted spacing.
* Added hover animations to the “You” avatar.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
I struggled to find the private alpha form link in the Build Anything
article. I personally expected the link to be at the bottom of the
compute section.
## Solution
Added a link at the bottom of the compute section.
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs
[style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
Resolves FUNC-941
## What
When a project isn't enrolled in Compute, show a short notice with a
link to the waitlist (https://supabase.com/compute) instead of a generic
error.
## Why
The compute API returns its 404 as `{ "error": { "code", "message" } }`.
`handleError` only reads a top-level `message`, so it dropped the status
code, `isComputeUnavailable` never matched, and users saw "API error
happened while trying to communicate with the server." The query now
checks `response.status === 404` directly.
## Testing
- [ ] Project not enrolled in Compute: the waitlist notice shows
- [ ] Enrolled project: the instance list loads as before
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
- Adds the Supabase Select 2026 recap blog post at
`/blog/supabase-select-2026-recap`
## What is the current behavior?
N/A
## What is the new behavior?
- New post in `apps/www/_blog/2026-10-02-supabase-select-2026-recap.mdx`
summarizing the Build, Operate, and Scale announcements, with links to
the three theme posts, docs, and access pages
- Authors: Wen Bo Xie, Steven Eubank, Joe Sciarrino
## Additional context
- OG and thumbnail images are not added yet; the post uses the default
blog placeholder until they are
- Links to the three theme posts, `/compute`, and
`/go/multigres-early-access` resolve only once those pages are live
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a recap of Supabase Select 2026, covering code-first project
setup, local development, MCP tools, and agent-assisted operations.
* The article reviews monitoring, authentication, tokens, pipelines, and
scaling options, including Multigres, OrioleDB, and database benchmarks.
It notes availability, defaults, plan requirements, and rollout status,
including native-process local development in alpha and off by default,
and Compute in private alpha.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ana <ana1337x@users.noreply.github.com>
Co-authored-by: Saxon Fletcher <saxonafletcher@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Francesco Sansalvadore <f.sansalvadore@gmail.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Published an article introducing Multigres, OrioleDB, and dbarena,
outlining their approaches to Postgres scaling and availability.
* Noted that Multigres is in private alpha and not intended for
production workloads, OrioleDB is in public beta, and dbarena is
publicly available.
* Added contributor profiles for Aditya Maruvada, Daniel Mitterdorfer,
and Alexander Korotkov.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Saxon Fletcher <saxonafletcher@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Ana <ana1337x@users.noreply.github.com>
Add docs with bare min information abotut he addition of the 4 new
health advisors
## Problem
no docs on health advisors
## Solution
added docs covering health advisors
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added health advisors for persistently high error rates in the Data
API, Auth, Storage, and Edge Functions.
* Findings include links to relevant troubleshooting guidance and
instructions for reviewing recent errors or failed invocations in Studio
Logs, MCP, or the Management API.
* **Documentation**
* Updated the advisors guide to describe health, security, and
performance checks, with examples and links to access advisors in Studio
and the Management API.
* Clarified that findings may be intentional and can take time to clear
after a fix.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Saxon Fletcher <saxonafletcher@gmail.com>
Co-authored-by: Nik Richers <nrichers@gmail.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Published an article on Supabase Select updates, including SQL access
to project logs, health checks for key services, database connection
monitoring and controls, and notebooks combining queries with notes.
* The article also covers updated agent skills, code-based testing
environments, MCP authentication and safety confirmations, scoped
personal access tokens, and Supabase Pipelines, including replication
workflows, availability, supported destinations, and setup guides.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Saxon Fletcher <saxonafletcher@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Ana <ana1337x@users.noreply.github.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Published a blog post about agent-ready local development, declarative
database schemas and configuration, Supabase Compute, and customizable
MCP servers.
* The post explains how to opt in to the native local stack alpha,
generate migrations, deploy and access Compute services, and use an
authenticated MCP server with tools subject to row-level security.
* Includes setup instructions, documentation links, and information
about the Compute waitlist.
* Added an author profile for Rand Arete.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Saxon Fletcher <saxonafletcher@gmail.com>
Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
Co-authored-by: Ana <ana1337x@users.noreply.github.com>
## Problem
As part of my investigation of this
[issue](https://linear.app/supabase/issue/AI-1263/test-byo-mcp-with-custom-domains)
I realized that, in order for byo-mcp to work with custom domains,
there's a tweak needed, and I'm documenting it here.
The long term use to fix it lives
[here](https://linear.app/supabase/issue/FDBKIN-20212/use-custom-domain-in-oidc-and-oauth-well-known-discovery-endpoints).
With that one in place, we could remove the clarification and the
experience would be much much simpler.
Fixes AI-1263
## Solution
I'm documenting for now, and will follow up if something else needs a
change.
## Review instructions
Provide a clear numbered procedure that the PR reviewer can walk
through.
1. Visit `docs/guides/ai-tools/byo-mcp` and read the added text.
2. See if it all makes sense.
3. Ask @raulb if something's not clear or confusing.
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs
[style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added guidance for configuring MCP authorization metadata with a
custom domain, including setting the authorization server to the
Supabase Auth project issuer and checking it against the advertised
metadata.
* Clarified that the resource URL continues to use the domain requested
by the client, and that leaving the issuer setting unset locally retains
the default.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
## Problem
ratchet lints were failing after merging the compute landing page on a
previous PR.
## Solution
This PR cleans up the ratchet lint run.
## Review instructions
- Check that no ratchet lint fails on this PR
## I have read the CONTRIBUTING.md file.
YES
## What kind of change does this PR introduce?
Re-add. Reapplies the Multigres Private Alpha docs section removed in
#50662, ready to merge once Sugu gives the go-ahead. Do not merge until
then.
Linear: MUL-1621 (follow-up to MUL-452).
## What is the current behavior?
Multigres docs section is down (per #50662): no overview/compatibility
pages, no sidebar entry, no features-table row, no "What you get" cards.
## What is the new behavior?
Exact reapply of #49020 (with Multigres marked Private Alpha): overview
guide at `/docs/guides/database/multigres`, compatibility stub, Database
sidebar entry, features-table row, "What you get" cards, and the
`ContentListings` optional-`href` support they rely on.
Base branch is the revert PR (#50662) so the diff here is legible now;
retarget to `master` once #50662 merges.
## Additional context
- `pnpm --filter docs exec vitest run lib/content-listings.test.ts` — 22
passed
- Blocked on Sugu's go-ahead — `do-not-merge` label applied
---------
Co-authored-by: Nik Richers <nik@validmind.ai>
## Problem
The `/go/ask-supabase-select` hero only linked to docs; it didn't point
attendees to Discord.
## Solution
Adds a third hero CTA, "Join our Discord", linking to
`https://discord.supabase.com/`, alongside the existing primary and docs
CTAs.
## Review instructions
1. Run `pnpm --filter www dev` and visit
`http://localhost:3000/go/ask-supabase-select`.
2. Confirm the hero now shows three CTAs and the Discord link works.
## Checklist
- [x] I have read CONTRIBUTING.md
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a “Join our Discord” call to action to the hero section.
* **Updates**
* Updated the three announcement call-to-action links to point to their
respective Supabase Select 2026 blog posts.
* Updated the hero’s “Read the Recap” link to point to the Build
Anything blog post.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Wendie Cheung <wendie.cheung@supabase.io>
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* No user-facing changes are included in this update.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Overview
New blog post
## Preview links
https://zone-www-dot-com-git-blog-turso-supabase.vercel.app/blog/supabase-is-acquiring-turso
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs
[style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added a blog post announcing that Turso is joining Supabase to develop
database infrastructure for agentic AI. The post describes Supabase’s
continued focus on Postgres and Turso’s work on SQLite, including
on-demand SQLite databases for smaller workloads. It also covers Turso’s
cloud architecture and the teams’ shared commitment to open source.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Matt Linkous <matthew.linkous@gmail.com>
Compute landing page.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a Compute product page introducing ephemeral sandboxes and
always-on HTTP services, with information on workloads, security,
deployment, and common questions.
* Added a private-alpha waitlist form with submission confirmation and
error feedback.
* Added Compute links and a “Private Alpha” badge in product navigation
and the footer.
* Added an animated diagram illustrating Compute workloads and their
lifecycle.
* **Documentation**
* Added a Compute overview covering runtimes, scaling, security,
deployment, and availability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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?
- New go page at `/go/multigres-early-access` to request access to the
Multigres private alpha
- New thank-you page at `/go/multigres-early-access/thank-you`
- Both pages registered in `apps/www/_go/index.tsx`
## What is the current behavior?
There is no page to request access to the Multigres private alpha.
## What is the new behavior?
- Lead-gen page with a request form (work email and Supabase
organization slug)
- Form submissions write to a Notion waitlist database through
`crm.notion`
- Successful submissions redirect to the thank-you page
- Both pages are `noIndex`
## Additional context
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added a Multigres private-alpha access page with details about the
alpha, links to its announcement and Supabase, and a form to submit an
email address and Supabase organization slug.
* Added a confirmation page shown after a successful access request,
with a link back to Supabase.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ana <ana1337x@users.noreply.github.com>
Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com>
## Problem
- Older orioledb projects show "Public Beta" instead of "Public Alpha"
in UI.
- List of backups in the "Scheduled backups" tab hangs.
## Solution
- show in the UI "Public Alpha" for projects older than
17.11.0.001-orioledb
- show in the UI "Public Beta" for new projects
- enable scheduled-backup query for "Public Beta"
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Backup availability messages now reflect OrioleDB’s current release
stage rather than always describing it as public beta.
* AWS backup queries are no longer disabled for every OrioleDB project;
they remain disabled during the alpha stage.
* **New Features**
* Added an informational notice and documentation link for scheduled
backups on AWS OrioleDB projects in alpha.
* Added release-stage details to the PITR availability notice.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Charis <26616127+charislam@users.noreply.github.com>
## Problem
Within the KB, we'll be adding a specific type of content primarily
aimed at LLM crawlers (similar in scope to https://vercel.com/i /
https://www.runpod.io/articles / https://www.braintrust.dev/articles).
These topics don't need as much visibility for human end users of the
site, especially within a) the site navigation and b) the KB homepage.
## Solution
To allow some topics to be less emphasized, this PR adds in a new
`visible` field to elements of the `TOPICS` array and then uses that
field to filter out entries from the homepage (pinned topics, all
topics) and the navigation (Nav.tsx).
This is a more minimal approach than #51099, which was attempting to
create a different folder / schema / layout for these entries.
## Preview links
https://kb-git-kb-comparsion-topic-supabase.vercel.app/kb, which
excludes `Comparison` from the top nav and the `All topics` section.
https://kb-git-kb-comparsion-topic-supabase.vercel.app/kb/topics/comparison,
which still renders pages tagged with `Comparison`.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Updates**
* The Comparison topic no longer appears in the main navigation or
homepage topic sections, including pinned topics. Its listing page
remains available.
* Other topics continue to appear in navigation and homepage sections,
with their labels and links unchanged.
* Homepage pinned topics are selected from the topics shown in the
homepage sections.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
shadcn lint rules has been soft landed in #50676 and are now on as
warnings in every app, but nothing stops a PR from adding new violations
linear: FE-4473
## Solution
- moved the ratchet script and its tests from `apps/studio/scripts` to
`packages/eslint-config-supabase` so every app runs one copy
- added a shared rule list,
`packages/eslint-config-supabase/ratchet-rules.json` with the shadcn
rules
- www, docs, design-system, ui-library and learn get `lint-ratchet.yml`
with one job per changed app (triggered by the app, `packages/**` or the
lockfile) + a weekly `lint-ratchet-decrease.yml` (as for studio ratchet)
- package tests run in `eslint-config-supabase-tests.yml`
<!--
## Preview links
If relevant, include links to changed pages for easy review access.
Copy the preview base URL from the Vercel bot comment on this PR. Use
the following table as an example template.
| Site | Live | Preview | Search for |
| -------------- |
-------------------------------------------------------------------------
|
------------------------------------------------------------------------------------------------------------
| ----------------------------- |
| WWW | [/blog/your-post](https://supabase.com/blog/your-post) |
[/blog/your-post](https://zone-www-dot-com-git-branch-name-supabase.vercel.app/blog/your-post)
| unique phrase from the change |
| Docs |
[/docs/guides/your-page](https://supabase.com/docs/guides/your-page) |
[/docs/guides/your-page](https://docs-git-branch-name-supabase.vercel.app/docs/guides/your-page)
| unique phrase from the change |
| Studio | [/dashboard](https://supabase.com/dashboard) |
[/dashboard](https://studio-git-branch-name-supabase.vercel.app/dashboard)
| unique phrase from the change |
| Design system | [/design-system](https://supabase.com/design-system) |
[/design-system](https://design-system-git-branch-name-supabase.vercel.app/design-system)
| unique phrase from the change |
| UI library | [/library](https://supabase.com/library) |
[/library](https://ui-library-git-branch-name-supabase.vercel.app/library)
| unique phrase from the change |
| Knowledge base |
[/kb/guides/your-page](https://supabase.com/kb/guides/your-page) |
[/kb/guides/your-page](https://kb-git-branch-name-supabase.vercel.app/kb/guides/your-page)
| unique phrase from the change |
-->
<!-- ## Additional context
Optionally add any other context or screenshots.
-->
## Review instructions
1. run `pnpm --filter ./apps/www run lint:ratchet`
2. add `p-[13px]` to a `className` in any www component and run it
again. it fails with `shadcn/no-arbitrary-values` and the file name with
`(+1)`
3. revert change
4. run `pnpm --filter eslint-config-supabase test` and see 6 tests pass
5. in ci, check `Ratchet studio lint checks` and the `ratchet (<app>)`
jobs for the apps this pr touches
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs
[style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Developer Improvements**
* Expanded automated lint checks to cover additional apps and shared
package changes.
* Added checks for arbitrary Tailwind values, unknown classes, and raw
colors across supported apps.
* Added automated baseline updates that can open or update a pull
request when lint counts change.
* Added tests for the lint configuration and support for combining
multiple rule files.
* Updated Studio lint notifications to exclude Shadcn rules with
zero-baseline counts.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
[The built-in retry
guide](https://supabase.com/docs/guides/api/automatic-retries-in-supabase-js)
describes retry behaviour that `supabase-js` doesn't have. Three claims
in the "Built-in retries for PostgREST queries" section don't match the
code:
| The page says | The code does |
| --- | --- |
| "POST requests (used by PostgREST) are retried" | POST is **never**
retried |
| Retries cover "408, 409, 503 and 504" | Only `503` and `520` |
| "exponential backoff with jitter" | No jitter — the delay is
deterministic |
**The POST claim is the serious one.** It tells a reader that their
writes are retried when they aren't, which invites exactly the wrong
conclusion about how to handle a failed insert. Someone reading this
page would reasonably skip their own retry or idempotency handling on
writes, on the strength of a guarantee the library doesn't make.
The source of truth, from
`packages/core/postgrest-js/src/types/common/common.ts` on `supabase-js`
master:
```ts
export const RETRYABLE_STATUS_CODES = [520, 503] as const
export const RETRYABLE_METHODS = ['GET', 'HEAD', 'OPTIONS'] as const
export const DEFAULT_MAX_RETRIES = 3
export const getRetryDelay = (attemptIndex: number): number =>
Math.min(1000 * 2 ** attemptIndex, 30000)
```
`shouldRetry` in `packages/core/postgrest-js/src/fetchWithRetry.ts`
gates on both constants, so a request is retried only when the method is
in `RETRYABLE_METHODS` *and* the status is in `RETRYABLE_STATUS_CODES`.
`getRetryDelay` is a pure function of the attempt index, with no random
component — hence no jitter.
There's a fourth, subtler consequence. The intro says built-in retries
apply to `.from()` and `.rpc()`, but `.rpc()` sends POST unless you pass
`{ get: true }` or `{ head: true }`, so RPC calls aren't retried by
default. A reader who takes the intro at face value would expect retries
on exactly the calls that don't get them.
## Solution
Corrected the three claims in place. No restructuring, no new sections,
no change to the `fetch-retry` half of the page.
- **Methods.** Replaced the sentence claiming POST is retried with the
actual rule, and stated the consequence plainly — a write is never sent
twice.
- **Status codes.** `503 Service Unavailable` and `520 Unknown Error` in
place of 408, 409, 503 and 504.
- **Jitter.** Dropped the word, since the backoff has none.
- **`.rpc()`.** Added one sentence noting that RPC sends POST by
default, so it isn't retried unless called with `{ get: true }`.
The diff is 3 changed lines and 2 added, all in one paragraph group.
This is a technical correction only — I deliberately left the page's
style and structure alone, so the diff stays readable as a single change
of one kind.
### Note on an incoming change
supabase/supabase-js#2699 proposes adding `521`, `522`, `523` and `524`
to `RETRYABLE_STATUS_CODES`. It is open, not merged. This PR documents
what `master` does today, and if that one lands the status sentence here
needs `520-524` rather than `520`. Happy to follow up with that change
once it merges, or to fold it in if you'd rather wait and land both
together.
## Review instructions
1. Open `packages/core/postgrest-js/src/types/common/common.ts` in
`supabase/supabase-js` on `master` and read `RETRYABLE_STATUS_CODES` and
`RETRYABLE_METHODS`.
2. Compare them against the live page's second paragraph. The status
list and the method list both differ.
3. Read `shouldRetry` in
`packages/core/postgrest-js/src/fetchWithRetry.ts` and confirm it
returns `false` for any method outside `RETRYABLE_METHODS`, POST
included.
4. Read `getRetryDelay` in the same `common.ts` and confirm there is no
random component, so "with jitter" doesn't hold.
5. Check `rpc()` in `packages/core/postgrest-js/src/PostgrestClient.ts`
and confirm the method is POST unless `get` or `head` is passed.
6. Read the preview page and confirm the corrected paragraphs say the
same thing the code does.
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which references
[WORD_LIST](https://github.com/supabase/supabase/blob/master/apps/docs/WORD_LIST.md)
and the docs
[CONTRIBUTING](https://github.com/supabase/supabase/blob/master/apps/docs/CONTRIBUTING.md)
guide
## Additional context
One suggestion, which I've deliberately left out of the diff because
it's an addition rather than a correction — your call whether it belongs
on this page.
The guide sets no request timeout anywhere, in either the built-in
section or the `fetch-retry` examples. That matters because a retry only
fires once a request has failed. A request that is merely hanging never
fails, so it never triggers a retry, and the caller waits for whatever
the platform's own timeout turns out to be.
This isn't hypothetical. During a Cloudflare edge incident on 22
September 2026, PostgREST calls from Edge Functions stalled for 20 to 60
seconds and returned `522`. Supabase Support confirmed the elevated 522s
were platform-wide at the time rather than specific to one project. The
built-in retry fired on none of them — partly because `522` isn't in the
list, but also because a stalled request never reaches the retry check
at all.
A sentence pointing readers at `AbortSignal.timeout` alongside the retry
would close that gap:
```javascript
const { data, error } = await supabase
.from('your_table')
.select('*')
.abortSignal(AbortSignal.timeout(10_000))
```
Happy to write that up as a short subsection if you want it — tell me
where you'd like it to sit and I'll open a separate PR so this
correction stays reviewable on its own.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Clarified that automatic retries apply only to idempotent GET, HEAD,
and OPTIONS requests that encounter HTTP 503 or 520 responses, or
network failures.
* Documented that RPC calls use POST by default and are not retried, and
that `{ get: true }` or `{ head: true }` can use retryable methods.
* Added guidance for using `AbortSignal.timeout(10_000)` to limit
requests that hang before retry handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Katerina Skroumpelou <sk.katherine@gmail.com>
The rss didn't order items based on specified date and time but it
trimmed each item to start of day, making the sorting fall back to
alphabetical and not triggering the "latest" rss atom in case of
same-day items but ordered based on time.
## Before
The "Supabase Series F" blog post is not ordered as latest in the rss
even though it was published with a later timestamp, not triggering rss
feeds.
<img width="1217" height="455" alt="Screenshot 2026-06-10 at 12 40 24"
src="https://github.com/user-attachments/assets/7ac77d8c-26b8-4073-9474-ee03fd318240"
/>
Blog is ordered correctly:
<img width="1309" height="680" alt="Screenshot 2026-06-10 at 12 42 10"
src="https://github.com/user-attachments/assets/58f1d683-1254-468e-a2da-0eeebf1bc862"
/>
## After
The pr doesn't show the result because the rss feed is .gitignored and
generated only on prod build.
But this is the rss generated locally for reference:
<img width="713" height="497" alt="Screenshot 2026-06-10 at 12 35 52"
src="https://github.com/user-attachments/assets/4dade2f9-a8cb-4b03-a234-1d89fdbf29c5"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Blog posts published on the same day are now sorted by their
publication time.
* RSS feed publication dates now retain the exact publication time
instead of being rounded down to the start of the day.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude <noreply@anthropic.com>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated the app’s underlying framework to version 16.3.6. No
end-user-facing changes were specified.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## 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 the MCP cost confirmation launch
([AI-1161](https://linear.app/supabase/issue/AI-1161/write-the-docs)).
## What is the current behavior?
The MCP server guide lists `get_cost` / `confirm_cost` but doesn't
describe the elicitation-based cost confirmation flow that
`@supabase/mcp-server-supabase` 0.12.0 introduces for `create_project`
and `create_branch` on form-capable clients.
## What is the new behavior?
- New **Cost confirmation** section in the MCP server guide: how the
elicitation flow works (accept / decline / expiry / rate-change
outcomes, all side-effect-free except accept), the zero-cost skip,
client support, and how to tell which cost flow a connection uses.
- New troubleshooting entry: "Cost confirmations do not appear in your
MCP client".
- Three `supa-mdx-lint` dictionary additions the new prose needs
(`elicitation(s)`, `dialogs`, `pauses`).
## Additional context
**Draft — hold until launch.** Merge gates before publishing:
1. The feature is enabled for hosted connections.
2. The client support table is re-verified against launch verification
results (there's a matching `{/* ... */}` reviewer note above the
table). Client support moves quickly; the table reflects verification as
of 2026-09-04.
Needs review:
- **Rate-change behavior follows the shipped code, not the spec docs**:
on any change to the computed cost between confirmation and creation
(including a decrease), the server reissues a fresh confirmation rather
than proceeding (`account-tools.ts` redemption path in supabase/mcp).
Flagging in case the intent was lower-or-equal proceeds.
- No exact confirmation expiry is stated because the TTL is
deployment-configured (`ttlSeconds`).
- Wording deliberately says "client-mediated" style confirmation and
avoids claiming a person approved each action, since clients can answer
elicitations via hooks.
Test plan: `supa-mdx-lint` clean on both files; Prettier (repo config)
clean. No runnable snippets, so no sandbox verification needed. Vercel
preview link will appear below.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added advanced options to hosted MCP connections for skipping selected
cost or destructive-SQL confirmations when supported. Available options
depend on connection scope, enabled features, and read-only settings.
* The configuration panel explains when skip selections are unavailable
or ignored by certain client configurations.
* **Documentation**
* Added guidance on cost and SQL confirmation prompts, Edge Function
secret entry, and troubleshooting missing prompts or unavailable secret
collection. This includes client requirements, fallback behavior, and
relevant security considerations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Barry Roodt <barry.roodt@supabase.io>
Add two guides under Local Development for the experimental `supabase
stack` commands, wire them into the docs nav, the CLI reference, the
marketing features list, and the pages that readers reach with a port
conflict.
New pages:
- guides/local-development/parallel-projects: run one local project per
app, git worktree, branch, or named environment on a single machine.
Covers identity, automatic port assignment, removing fixed ports from
config.toml, named projects, finding endpoints, stop and destroy, the
`[experimental] stack` setting, and current limitations.
- guides/local-development/runtimes: the Docker and native runtimes, how
the CLI picks one, native platform requirements, artifact download and
cache locations, and runtime limitations.
Cross-links and context:
- Local development index, CLI getting started, CLI workflows, managing
environments, AI tools, MCP, and the edge functions port troubleshooting
entry now point readers to the new guides where a second `supabase
start` fails on a port conflict.
- CLI reference: `supabase stack`, `stack start`, `stack stop`, `stack
destroy`, the `experimental.stack` config key, and a note on `supabase
start` and `[experimental] stack`.
- www: two feature entries and copy tweaks on the hosted Postgres and
innovation teams solution pages.
- supa-mdx-lint: allow worktree, glibc, musl, and checksum.
## Problem
The DuckLake setup form makes it hard to choose between Supabase
projects and external connection details. Bucket creation, catalog
settings, and the guide do not clearly follow the setup flow.
## Solution
- Show **Configuration method** as two clear choices: **Select Supabase
projects** and **Enter connection details**.
- Group catalog and storage fields, move **Pool size** to **Advanced
settings**, and add **New bucket** to the bucket selector.
- Clarify the custom Postgres and S3 fields, including the metadata
schema, connection URL, and storage options.
- Update the [DuckLake destination
guide](https://docs-git-dnywh-ducklake-pipelines-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake)
to follow the form and explain resource preparation and validation.
| Before | After |
| --- | --- |
| <img width="1280" height="1323" alt="50587"
src="https://github.com/user-attachments/assets/bf5997cf-9fc4-48a8-ad4f-13fa991d56f9"
/> | <img width="1280" height="1323" alt="61914"
src="https://github.com/user-attachments/assets/2c1dd7ef-797f-4302-9e2e-93a5f1e6e515"
/> |
## Review instructions
1. Open **Database > Pipelines > Add pipeline** and select **DuckLake**.
2. Select **Select Supabase projects**. Check the catalog and storage
fields, create a bucket from the bucket selector, and find **Pool size**
under **Advanced settings**.
3. Select **Enter connection details**. Check the Catalog URL, S3 URL
style, and Use SSL guidance.
4. Compare both routes with the [DuckLake destination
guide](https://docs-git-dnywh-ducklake-pipelines-setup-supabase.vercel.app/docs/guides/database/replication/pipelines/ducklake).
## Checklist
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] I used the `/edit-the-docs` skill and the docs [style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* DuckLake destinations support Supabase-managed projects or an existing
Postgres catalog with S3-compatible storage.
* Select a storage bucket using search, configure a metadata schema, and
access clearer guidance for catalog and storage settings.
* Advanced settings provide a connection pool size from 1 to 6, with a
default of 4. Credential fields include show and hide controls.
* **Documentation**
* Updated setup steps, configuration guidance, query credential details,
and troubleshooting instructions for both configuration modes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The "Hire an agent" and "monitor" wording oversold the feature: it is
just a prompt you give an agent to check health, security, performance,
or resources, optionally on a schedule. Rename the group to "Agent
prompts", drop "monitor" from the four child pages (Health, Security,
Performance, Resources), and use plainer framing across the landing page
and observability hub. URL slugs are unchanged.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Renamed the Observability section to “Agent prompts” and updated its
page titles and descriptions to describe project checks.
* Clarified that prompts read project data without changing it, and that
findings can be sent through existing harness connections.
* Updated setup guidance to refer to running prompts and using “checks”
in task names.
* Renamed the Health, Security, Performance, and Resources entries. The
related links, schedules, and reporting details remain unchanged.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
## Problem
When I bumped the pnpm-lock file in an unrelated KB fix (#51132), I
believe that refreshed the build cache (either that, or Vercel started
flagging this issue very recently).
At any rate, builds are now failing b/c of a [vulnerable
Tanstack/react-start
package](https://github.com/TanStack/router/security/advisories/GHSA-qx66-fv34-fjm8),
which this PR attempts to fix.
```
The build blocks vulnerable @tanstack/react-start@1.168.18 due to an XSS security check.
```
<img width="1355" height="397" alt="image"
src="https://github.com/user-attachments/assets/7d0d90fb-009c-4a0b-aadc-b526e0fcce0a"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Updated project maintenance settings and supporting TanStack package
versions.
* Improved error reporting so standard errors include their stack trace,
while other error values are logged directly.
* No app features were added or removed.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
## What
Adds a warning in Project Settings > API when the `authenticator` role's
`pgrst.db_schemas` setting overrides the Dashboard's "Exposed schemas"
configuration, plus an inline "Reset override" button to fix it in one
click.
## Why
`ALTER ROLE authenticator SET pgrst.db_schemas = ...` silently overrides
what PostgREST actually exposes, regardless of what's selected in the
Dashboard. Users hit a confusing PGRST106 error with no indication that
a role-level override is the cause.
## How
- New query (`authenticatorRoleConfigQueryOptions`) reads
`pg_roles.rolconfig`
for the `authenticator` role and parses out any `pgrst.db_schemas`
value.
Configured to always refetch on mount and window focus, since the fix is
often applied outside the Dashboard (SQL editor, another client) with no
cache-invalidation event for the app to react to.
- `PostgrestConfig.tsx` compares that value against the currently
selected
schemas and shows an `Admonition` warning naming the actual overriding
schemas, with a link to the PGRST106 troubleshooting guide, when they
differ.
- The warning includes a "Reset override" button that runs
`alter role authenticator reset pgrst.db_schemas` after a confirmation
step (showing the exact SQL that will run, with a copy button), then
refetches so the warning clears immediately without a page reload.
## Testing
1. In the SQL Editor of a test project, run:
```sql
alter role authenticator set pgrst.db_schemas = 'public';
```
2. Go to Project Settings > API, and select a schema other than (or in
addition to) `public` in "Exposed schemas" (e.g. add `api`).
3. The new warning should appear, naming `public` as the schema actually
in effect, with a link to the PGRST106 troubleshooting guide.
4. Click "Reset override" in the warning, confirm in the modal, and
check
that the warning clears immediately without a page reload.
5. Alternatively, clear the override manually from the SQL editor:
```sql
alter role authenticator reset pgrst.db_schemas;
```
then navigate away from the API settings page and back (or refocus the
browser tab) — the warning should clear without a hard refresh.
Fixes
[FE-4472](https://linear.app/supabase/issue/FE-4472/warn-when-authenticator-role-overrides-exposed-schemas)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* The API settings page now warns when the authenticator role’s exposed
schemas differ from the saved Dashboard configuration.
* You can reset the override to restore the saved schema configuration.
The reset requires permission and provides success or error feedback.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Document `supabase init --use-orioledb` in the CLI reference. Add
`db.orioledb_version` to the CLI config reference, and mark
`experimental.orioledb_version` as deprecated.
This complements the general OrioleDB beta guide update in #50813.
Companion CLI PR: https://github.com/supabase/cli/pull/6828, released in
[v2.119.0](https://github.com/supabase/cli/releases/tag/v2.119.0).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Documented the `supabase init --use-orioledb` option, which sets the
OrioleDB image version in `supabase/config.toml`.
* Added configuration guidance for `db.orioledb_version`, including its
PostgreSQL version requirements.
* Marked `experimental.orioledb_version` as deprecated and directed
users to `db.orioledb_version`. The CLI continues to read the
experimental setting and warns when it is set.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
## Problem
The Snowflake destination still uses a neutral text monogram even though
its Studio asset is available. Supporting that monogram also leaves a
separate rendering path used by no other destination.
## Solution
Restore Snowflake through the shared brand-icon registry introduced by
#51073. Simplify `DestinationLogo` back to a map of destination marks,
removing the monogram type, configuration, and rendering branch.
| After |
| --- |
| <img width="924" height="730" alt="CleanShot 2026-09-30 at 15 14
59@2x"
src="https://github.com/user-attachments/assets/7409d483-3371-45ec-bf54-0ddc6ad22857"
/> |
## Review instructions
1. Open `/project/<ref>/database/replication` with a Snowflake pipeline.
2. Confirm the Snowflake mark appears in the pipeline list and diagram.
3. Open the pipeline child route and confirm the same mark appears in
its header.
4. Confirm the other destination marks remain unchanged in light and
dark themes.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Visual Updates**
* Snowflake replication destinations now display a themed brand icon
instead of the “SF” monogram. Other destinations retain their existing
icons.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Context
As per PR title - this was the behaviour for the SQL Editor and figured
it makes sense to also have this behaviour in the Explorer QueryEditor +
Logs Explorer where the main UX is writing queries, and lets the user
bring the active section of the code closer to the middle of the
viewport (rather than right at the bottom)
<img width="790" height="305" alt="image"
src="https://github.com/user-attachments/assets/07eb63fa-1bb9-4abe-859e-2968a73e7ca5"
/>
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Editor Improvements**
* Query editors now allow scrolling beyond the final line, providing
more room to position the last lines on screen.
* The SQL editor no longer forces the decoration area to zero width; it
now uses Monaco’s default width behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
Some destination marks need different assets to maintain contrast across
light and dark surfaces. Their paths are also duplicated between
Pipelines and Wrappers.
## Solution
Add a shared brand-icon registry that supports either one asset or light
and dark variants. Pipeline destination logos resolve against the active
theme, while Wrappers continue using the light variant for their white
logo tiles.
This keeps single-asset destinations unchanged and preserves the
existing monogram treatment where applicable.
| Light | Dark |
| --- | --- |
| <img width="926" height="742" alt="CleanShot 2026-09-30 at 15 03
31@2x"
src="https://github.com/user-attachments/assets/d76e5995-1bb8-4cb7-b991-c5dc1a5d8cb0"
/> | <img width="926" height="732" alt="CleanShot 2026-09-30 at 15 03
03@2x"
src="https://github.com/user-attachments/assets/83d45f30-3bf6-4ddc-8607-e27628cb4966"
/> |
## Review instructions
1. Open `/project/<ref>/database/replication` with pipelines using the
themed destination marks.
2. Switch between light and dark themes from the account menu.
3. Confirm each themed mark swaps assets and remains legible in the
pipeline list, diagram, and child-route header.
4. Open Database Integrations and confirm the corresponding Wrapper
tiles continue using their light-surface assets.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Style**
* Updated the BigQuery, ClickHouse, DuckLake, and Snowflake icons in
integration and replication views to use branded marks. Icons now use
theme-appropriate variants where available, helping them display
consistently across light and dark themes. ClickHouse’s previous “CH”
monogram is replaced with its branded mark.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The Docs sitemap lists a `/reference/<sdk>/undefined` URL for every
reference category header, on both latest and versioned paths (for
example `/reference/kotlin/v1/undefined`). `generateReferencePages`
turns every flattened section into a link, and category headers never
carry a slug. Search engines get a 404 for the `api/undefined` entries
and a soft 404 for the SDK ones.
I filtered the sections with the same predicate the reference static
params already use (`type !== 'category' && !!slug` in
`Reference.utils.ts`). I ran the generator locally before and after the
change: the only entries it removes are the `/undefined` ones (about 4%
of the sitemap), and it adds none.
**Note:** `getFlattenedSections` stays unchanged because the crawler
route and the reference pages share it.
## To test
Tested on Vercel preview:
- [x] Fetch `/docs/sitemap.xml` on the Docs preview and search for
`/undefined</loc>`: expect no matches
- [x] In the same file, search for `/docs/reference/javascript/select`
and `/docs/reference/kotlin/v1/select`: expect both still listed
## Linear
- fixes GROWTH-1310
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Reference pages no longer generate links for category sections or
sections without a slug. Existing link paths and priorities remain
unchanged.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
I made the crawler renderer resolve legacy JavaScript and Dart reference
slugs to their current sections, and updated authored guide and SDK spec
links to use them. Exact slugs still win, ambiguous bare slugs still
return 404, and `file-buckets-listv2` remains a section slug in
canonical links. I kept the www redirect work in a separate draft PR
because the apps deploy independently.
## To test
- [x] On the Docs preview, request `reference/javascript/order` and
`reference/dart/get-user` with a bot user agent. Expect the intended
heading and canonical URL.
- [x] Request `reference/javascript/file-buckets-listv2` with bot and
browser user agents. Expect it to open the list v2 section.
- [x] Request `reference/swift/get-user` and the Kotlin reference root
with a bot user agent. Expect the intended heading.
- [x] Open the Storage quickstart guide and follow its upload reference
link. Expect the current JavaScript upload section.
## Linear
refs GROWTH-1293
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Reference pages now resolve legacy aliases and ambiguous slugs more
accurately, with canonical links that preserve explicit SDK versions.
* SDK version paths are recognized only when the full path segment
matches the version format, improving reference-page routing.
* **Documentation**
* Updated API reference links across authentication, storage, security,
and SDK guides to point to current pages.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Problem
`pnpm dev:www` ran `content:build`, whose final `fetchAgentSkills` step
rewrote the committed skills index.
## Change
Local development now runs the existing `content:build:core` generators
and serves the committed index. Every WWW build still runs
`content:build`, which runs the core generators followed by
`fetchAgentSkills`.
```mermaid
flowchart LR
L[Local dev] --> C[content:build:core]
C --> N[Next dev]
I[Committed index] --> N
B[Preview / production build] --> F[content:build]
F --> C
F --> A[fetchAgentSkills]
R[Latest GitHub release] --> A
A --> D[Next build]
```
Preview builds fall back to the committed index if fetching fails.
Production builds fail rather than publish a stale index. The committed
fallback is updated to v0.1.9.
## Test plan
- `pnpm dev:www` leaves the index unchanged and serves it byte-for-byte
- stale v0.1.8 fixture refreshes to v0.1.9 through the real fetch script
- `pnpm --filter www test turbo-build.test.ts`
- `pnpm --filter www typecheck`
- `pnpm exec prettier --check apps/www/package.json
apps/www/public/.well-known/agent-skills/index.json`
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
Closes
[AI-1275](https://linear.app/supabase/issue/AI-1275/running-pnpm-devwww-modifies-the-generated-agent-skills-index)
Co-authored-by: OpenAI Codex <noreply@openai.com>
Production secrets sat after two non-procedure sections, so the reader
setting up a key crossed reference material to get from the local steps
to the production ones. Move it up to follow Local secrets, which runs
all four procedure sections unbroken before the reference sections.
Group "Where local values come from" and "Default secrets" under a
Reference heading. Both answer "what are its parts?", so both are
Structure under the style guide's information types, and Reference is
the group the worked outline ends with. They demote from H2 to H3,
which keeps them in the page TOC, since it is built from h2 and h3.
No heading is renamed, so the anchors Studio deep-links into
(#default-secrets, #using-the-cli) and the one the secrets-limit
troubleshooting page uses (#accessing-environment-variables) are
intact. Changing a heading's level preserves its slug.
Glue the new shape needs: an outline of the three section groups at the
top, a transition out of the troubleshooting section, and an opening
line under Reference.
Inline rewording only. Nothing moves and no claim changes.
Addresses reader-facing "we", UI labels in quotes rather than bold, "allows
you to", "e.g.", future tense, and title-case common nouns in body prose.
Apply the docs style guide to Securing Edge Functions. Inline changes only.
- Open the page with a value statement
- Split the sentences that ran past the 26-word aim, and keep one
relationship per sentence
- Replace dash-bounded asides with separate sentences
- Lift `(the default)` out of parentheses so it reads as a claim
- Name the section instead of "above" and "the sections below"
- Introduce the mode table in the sentence before it
- Raise the `auth: 'none'` admonition to `danger`, and state it in the
positive form
- Stop restating that admonition in the Public functions section
- Spell out Row Level Security, and name `@supabase/server` rather than
"the SDK"
- Use Supabase Dashboard and Supabase Platform consistently
- Use "function" rather than "endpoint", and spell out "db"
- Link `@supabase/server` once, and name it as a GitHub destination
- Rewrite the Secret keys alt text to describe both rows, the column
headers, and the masked key format
