mirror of
https://github.com/supabase/supabase.git
synced 2026-10-06 01:45:10 +03:00
master
563
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Pamela Chia
|
a9078612f2 |
fix(www): stop cross-zone link prefetch (#51066)
About 95% of the 404s served on supabase.com are App Router RSC prefetches (`?_rsc=`) that www `<Link>`s fire at paths another zone serves: `/docs`, `/dashboard`, `/library`, and the footer's `humans.txt`, `lawyers.txt` and `security.txt`. Next.js can't prefetch or client-navigate across multi-zone boundaries, so each prefetch 404s even though the link itself works. I turned every www link into another zone into a plain `<a>` and added a lint rule so new ones stay that way. **Changed:** - **Cross-zone links are plain anchors**: links that always leave www (literal `/docs`, `/dashboard` and `.txt` hrefs, absolute `https://supabase.com/dashboard` URLs, the `getDashboardCtaHref` CTAs) render `<a>`. Renderers whose href comes from data (nav, footer, plan and add-on CTAs, product cards) branch on `isCrossZoneHref`, which reads the zone list from `lib/rewrites.js`. In-zone links stay `<Link>` and keep prefetching. - **New literal links can't regress**: `www/no-cross-zone-link` errors on a `next/link` `<Link>` whose literal or template href points at another zone. It evaluates `lib/rewrites.js` as production, so `/docs` counts in every environment. - **Click tracking survives the full navigation**: `sign_in_button_clicked`, `start_project_button_clicked` and `www_pricing_plan_cta_clicked` now send with `keepalive`, like `sign_in_submitted` already did, so an immediate page load can't cancel them. The mobile nav Sign in and Start your project buttons used `legacyBehavior`, which never called their `onClick`: PostHog has no `Mobile Nav` location for either event in the last 30 days. Those clicks report from this PR on. - **Typecheck no longer crashes**: the functions page's default export inferred a type through `RealtimeLogs`'s unexported `Props`, which makes the native TypeScript compiler panic during `tsc --noEmit`. I exported `Props`. **Note:** the lint rule only sees literal hrefs. A new renderer whose href comes from data needs its own `isCrossZoneHref` branch, and review is the only check on that. ## To test `/docs` is only rewritten on production and absolute `https://supabase.com/...` links are cross-origin on a preview, so the preview proves the relative non-docs cases (`/dashboard*`, `/library`, the footer .txt files). `/docs/...` prefetches still appear on the preview because it has no docs rewrite. Tested on Vercel preview: - [x] Open `/` with the network tab filtered to `_rsc` and scroll to the footer: no requests for `/dashboard*`, `/library`, `/design-system`, `/kb`, `/evals`, `/humans.txt`, `/lawyers.txt` or `/.well-known/security.txt`, while in-zone ones such as `/pricing`, `/features` and `/blog` still appear - [x] Same check on `/pricing`, `/auth`, `/database`, `/storage`, `/realtime`, `/edge-functions`, `/blog` and a blog post: no `_rsc` requests to `/dashboard*`, `/library` or the footer .txt files - [x] Open the Developers dropdown on desktop and the mobile menu at 390px: no new `_rsc` requests to `/dashboard*` or `/library` - [x] Click header Docs, footer Humans.txt, the hero Start your project button and the pricing Free plan button: each lands where it did before (`/docs`, `/humans.txt` text, `https://supabase.com/dashboard/sign-up`, `https://supabase.com/dashboard/new?plan=free`). Signed out, the Free plan button lands on the dashboard sign-in with `plan=free&returnTo=%2Fnew` - [x] Click the hero Start your project button: the `/platform/telemetry/event` POST with `start_project_button_clicked` completes with a 2xx after the page starts navigating. 201 with the navigation held; on the real navigation the event still reached staging PostHog - [x] At 390px, open the mobile menu and click Sign in: a `/platform/telemetry/event` POST with `sign_in_button_clicked` and `buttonLocation: "Mobile Nav"` fires. Start your project in the same menu also sends `start_project_button_clicked` with `buttonLocation: "Mobile Nav"` - [ ] Signed in, load `/`: no `/dashboard/projects?_rsc=` request (not run: the preview origin has no signed-in session) - [x] Open the desktop Product dropdown and the Product section of the 390px mobile menu: Compute shows its Private Alpha badge and the other products show none (checks the master merge into `MenuItem`) After deploy, `/` and `/pricing` on supabase.com show no `_rsc` requests to `/docs*`, `/dashboard*` or `/library`. After a full day, the share of supabase.com 404s carrying `_rsc=` should drop from about 95% to under 10%, and `sign_in_button_clicked` and `start_project_button_clicked` should start showing a `Mobile Nav` location in PostHog. ## Linear - fixes GROWTH-1294 |
||
|
Wen Bo Xie
|
f414a68e1b |
docs(cli): address final review feedback on supabase stack guides (#51217)
- Add stack = true under the existing [experimental] table instead of pasting a duplicate table, which leaves the setting off. - Note that db dump targets the linked project unless --local is passed, and that --db-url reaches a named local project through DB_URL. - Qualify offline destroy on the host data being deletable, and scope the shared Docker volume cleanup note to volume-backed projects. - Say Docker database storage is chosen when the local project is created. - Allow GitHub's release download host alongside github.com, or the S3 host alone, in allowlisted sandboxes. - www: most services stop when idle (not Functions), and state the [experimental] stack prerequisite in the native runtime entry. |
||
|
Riccardo Busetti
|
4ab54b9359 | ref(docs): Make ClickHouse, Snowflake and DuckLake in public alpha (#51195) | ||
|
Francesco Sansalvadore
|
4617b6f4cb |
feat: compute landing page (#50899)
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 --> |
||
|
Wen Bo Xie
|
ffd2754c7a |
docs(cli): document experimental supabase stack commands and native runtime (#50391)
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. |
||
|
samroseandArtur Zakirov
|
9946747579 |
docs(orioledb): update OrioleDB docs for public beta (#50813)
> [!IMPORTANT] > Don't merge until the OrioleDB public beta launches. Docs deploy on merge. ## What Updates the OrioleDB guide (`guides/database/orioledb`) for the public beta: - States that OrioleDB is in public beta and that OrioleDB projects have access to the same paid features as other Supabase projects. - Replaces the outdated "choose `OrioleDB Public Alpha` Postgres version" instruction and its screenshot with text steps that match the current project creation form (**Advanced Configuration** → **Postgres Type** → **Postgres with OrioleDB**). It also notes that OrioleDB can't be added to or removed from an existing project. A new screenshot will follow once the dashboard shows the beta labels. - Corrects the `orioledb.default_compress` range to `-1` to `22`. Values outside that range are rejected. - Updates the `EXPLAIN` output for the primary key lookup to match what OrioleDB returns (`Custom Scan (o_scan)`). - Replaces the benchmark chart's alt text with a description of the chart. Headings, frontmatter, and navigation are unchanged, so existing links to this page and its sections still work. ## Checked against upstream OrioleDB Checked the page's claims against the [OrioleDB docs](https://github.com/orioledb/orioledb/tree/main/doc/usage) and codebase on `main`: - The concepts section, the `orioledb.serializable` values, and the compression settings match. - The limitations link still resolves (`#current-limitations`). - Doc changes on `main` since beta17 (collations, sparse files, concurrent unique bridged indexes) don't affect claims on this page. ## Verification (`/test-the-docs`) | Snippet / step | Class | Sandbox | Result | Notes | | --- | --- | --- | --- | --- | | `create table blog_post …` | runnable-local | DinD + runner, `supabase/postgres:17.9.0.028-orioledb` | pass | Table created with the `orioledb` access method (default) | | `create index …` (2 indexes) | runnable-with-setup | same | pass | | | `insert …` + `select …` | runnable-with-setup | same | pass | Timestamp differs, as expected | | `explain` (3 statements) | runnable-with-setup | same | pass | Primary key lookup output updated in this PR to match | | `select … from pg_settings where name like 'orioledb.%'` | runnable-local | same | pass | All 10 automatically tuned settings present | | `alter database … default_compress to 1` | runnable-local | same | pass | | | Compression range `-1`–`22` | claim check | same | pass | `23` rejected: "outside the valid range (-1 .. 22)" | | User-configurable settings have `user` context | claim check | same | pass | `serializable` values match the page | | Hidden `ctid` key when no primary key is defined | claim check | same | pass | | | HNSW index via index bridging | claim check | same | fail (product bug) | Index misses rows inserted after it's created. Known upstream as orioledb/orioledb#1118, fixed after beta17. The tested image bundles an earlier OrioleDB release. Re-test on an image with beta18 before merging. | | Dashboard project creation steps | deferred | — | deferred | Needs a hosted project; labels checked against Studio source | **Tier A path:** every SQL block on the page, run in page order against the Supabase OrioleDB image. **Environment:** Docker 29.4.0 (linux/aarch64); compose sandbox from `test-the-docs`; all SQL run inside the runner container. **Build:** `pnpm build:guides-markdown` passes; the generated markdown for this page includes all changes. ## Self-review **Blockers:** none. **Before merging:** - [ ] Re-run the HNSW check on an image with OrioleDB beta18. - [ ] Re-check the page against the `beta18` tag once it's published. **Nits left for a follow-up (existing text, outside this PR's scope):** - The page spells `pg_vector`; the extension is `pgvector`. - Index support is described twice, in the top note and again under "Creating indexes". - The markdown export (`internals/markdown-schema/Admonition.ts`) drops admonition titles on every page. This PR avoids relying on a title for the beta status. Linear: DOCS-1399 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the OrioleDB guide with benchmark results for an 8xlarge instance, including a 1.8x speedup and throughput data across 32–256 connections. * Clarified that OrioleDB projects have access to the same paid features as other Supabase projects, and added guidance to review its limitations. * Updated project setup instructions, noting that OrioleDB must be selected when creating a project and cannot be added later or removed. * Revised the query plan example and documented compression levels from `0` through `22`. * **Product Updates** * Updated OrioleDB’s availability stage to public beta. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Artur Zakirov <zaartur@gmail.com> |
||
|
Pamela Chia
|
99c6e306c7 |
fix(www): repair legacy reference redirects (#51059)
I repointed legacy reference redirects and first-party links to the sections the Docs app currently serves. Old client and common-filter URLs still targeted bare slugs, while SDK landing URLs targeted `/start`. I preserved v1 auth destinations and linked the retired Dart v0 migration guide to its original source. ## To test On the www preview: - [x] Request `/docs/client/order` with a crawler user agent. Expect a redirect to `/docs/reference/javascript/using-modifiers-order`. - [x] Request `/docs/common/filters/_sl` with a crawler user agent. Expect a redirect to `/docs/reference/javascript/using-filters-rangelt`. - [x] Request `/docs/reference/kotlin` with a crawler user agent. Expect a redirect to `/docs/reference/kotlin/introduction`. - [x] Open the Storage permissions section. Expect its bucket reference link to target `/docs/reference/javascript/file-buckets-createbucket`. ## Linear - fixes GROWTH-1293 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated links across blog posts, product pages, and feature listings to point to current JavaScript, Flutter, and Dart documentation. * Updated legacy documentation redirects to current reference pages, including filter, modifier, client, and authentication guides. * Changed reference-root redirects to lead to each language’s introduction page. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Pamela Chia
|
177ef0cdd6 |
fix(www): repair broken docs links and redirect /blog/rss.xml (#51002)
## Problem Four www pages link to docs URLs that return 404: - `/storage`: the "Learn more" links for analytics and vector buckets (`storage/analytics-buckets`, `storage/vector-buckets`) - `/` (frameworks grid): the Vue quickstart (`quickstarts/vuejs`) - `/edge-functions`: the CI/CD link (`functions/cicd-workflow`; that page was merged into the deploy guide) - `/partners`: the Enterprise SSO link (`auth/sso`) Feed readers also request `/blog/rss.xml`, which renders the blog 404, while the feed lives at `/rss.xml`. Apart from prefetch requests, it is the most-requested 404 on www. ## Solution - Point each link at the live page: `storage/analytics/introduction`, `storage/vector/introduction`, `quickstarts/vue`, `functions/deploy#cicd-deployment`, `auth/enterprise-sso`. - Redirect `/docs/guides/functions/cicd-workflow` to the deploy guide. This also fixes the older blog post and changelog links to it. The redirect destination has no anchor because the `.md` redirect generator in `next.config.mjs` appends `.md` to the destination. - Redirect `/blog/rss.xml` to `/rss.xml`. ## To test On the www Vercel preview: - [x] On `/storage`, click "Learn more" under analytics buckets and vector buckets: expect the analytics and vector introduction pages. They navigate to `/docs/guides/storage/analytics/introduction` and `/docs/guides/storage/vector/introduction`. The www preview doesn't serve `/docs`, so I confirmed every new docs target returns 200 on production. - [x] On `/`, click Vue in the frameworks grid: expect the Vue quickstart. The Vue tab's "Read docs for Vue" link navigates to `/docs/guides/getting-started/quickstarts/vue`. - [x] On `/edge-functions`, click the CI/CD link: expect the deploy guide scrolled to CI/CD deployment. Opens "Deploy to Production" in a new tab with `#cicd-deployment` in view. - [x] On `/partners`, click the Enterprise SSO link: expect the enterprise SSO guide. Opens "Enterprise Single Sign-On" in a new tab. - [x] Request `/blog/rss.xml` and `/docs/guides/functions/cicd-workflow`: expect 308s to `/rss.xml` and `/docs/guides/functions/deploy`. Both return 308, and `/rss.xml` serves the feed as XML. - [x] `/docs/guides/functions/cicd-workflow.md` returns 308 to `/docs/guides/functions/deploy.md`. - [x] None of the four pages still links to an old path (`analytics-buckets`, `vector-buckets`, `quickstarts/vuejs`, `functions/cicd-workflow`, `auth/sso`). ## Linear - fixes GROWTH-1297 <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated quickstart and integration links for Vue, Edge Functions CI/CD, analytics and vector storage buckets, and Enterprise SSO. * Added permanent redirects from the old RSS feed and Functions CI/CD guide URLs to their current locations. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
51a167d910 |
feat(www): partners landing page (#47874)
<!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added a redesigned Partners page with partnership options, benefits, application steps, FAQs, integration resources, and featured partners. - Added an on-page partner application form with questions tailored to the selected partnership type. - Added a confirmation message with next steps and a link to the OAuth integration guide. - **Bug Fixes** - Updated partner application links to open the form on the Partners page. - Added support for checkbox-group fields in forms. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alan Daniel <stylesshjs@gmail.com> Co-authored-by: Alex Hall <alex.hall@supabase.io> Co-authored-by: Dion Zeneli <101271736+Dionysos288@users.noreply.github.com> |
||
|
Danny WhiteandJoshen Lim
|
05a45dd1ed |
feat(studio): rename Replication to Pipelines (#50637)
## What kind of change does this PR introduce? Feature and docs update. ## What is the current behavior? The Dashboard lists Pipelines destinations under Database > Replication. Read replicas have moved to Infrastructure, but the temporary notices remain on the destinations page and new destination sheet. Closes PIPE-1021. ## What is the new behavior? The canonical Dashboard routes are Database > Pipelines, while legacy Replication list and detail URLs permanently redirect to the equivalent Pipelines routes. Navigation, command palette, shortcuts, pipeline links, docs, and current marketing copy use Pipelines. Read-replica notices and their obsolete dismissal state are removed. | Before | After | | --- | --- | | <img width="1024" height="759" alt="Replication Database Agua Basket Supabase" src="https://github.com/user-attachments/assets/53f9f565-1ed1-43e9-a7d9-b66b2a47e948" /> | <img width="1024" height="759" alt="2540" src="https://github.com/user-attachments/assets/14ab2d61-d01c-483f-9d4f-0ac286dae159" /> | The Management API, pipeline behaviour, replication logs, and Postgres replication terminology remain unchanged. ## To test - Open `/project/<ref>/database/pipelines` and confirm the Database navigation, page header, and pipeline breadcrumb say Pipelines. - Open `/project/<ref>/database/replication?source=bookmark#destinations` and a legacy pipeline detail URL. Confirm each redirects to the matching Pipelines URL while preserving parameters and fragments. - From the Pipelines page, open Add destination. Confirm no read-replica migration notice appears. - Open the Pipelines guide and confirm its Dashboard steps lead to Database > Pipelines. ## Before merge - [ ] Get changelog entry reviewed https://github.com/supabase/changelog/pull/262 and prepare to merge simultaneously <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added dedicated **Database > Pipelines** pages for pipeline lists and details. - Added permanent redirects from legacy Replication URLs to their corresponding Pipelines pages. - Read replica management links now open **Settings > Infrastructure**. - **Documentation** - Updated Pipelines setup, monitoring, troubleshooting, and usage guidance to reference the current dashboard locations. - Updated Realtime guidance to use **Database > Publications**. - **Updates** - Renamed dashboard navigation, breadcrumbs, commands, and keyboard shortcuts from **Replication** to **Pipelines**. - Removed the “Read replicas have moved” notification. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Danny White
|
ec53175b8a |
refactor(ui): rename text-brand to text-primary (#50564)
## What kind of change does this PR introduce? Refactor. Follow-up to #49871. ## What is the current behavior? Branded (green) text still uses the `text-brand` classname while the colour comes from `--primary`. ## What is the new behavior? **Rename-only:** `text-brand` → `text-primary` across callsites and docs. Leftover `bg-brand` / `border-brand` alias to `brand-default`. No intentional colour changes in this PR. This better matches how we treat our green in other components and props, like `variant="primary"` for green buttons. ## To test On light mode: smoke-test that branded text still looks like #49871 (readable green, not the bright fill). - [Homepage](https://zone-www-dot-com-git-dnywh-depr-316-text-brand-de2380-supabase.vercel.app/): “Scale to millions” uses `text-primary` - [Docs homepage](https://docs-git-dnywh-depr-316-text-brand-to-primary-supabase.vercel.app/docs): branded links like “More on self-hosting” are still readable - [Typography docs](https://design-system-git-dnywh-depr-316-text-brand-to-primary-supabase.vercel.app/design-system/docs/typography): documents `text-primary` - [Colour usage](https://design-system-git-dnywh-depr-316-text-brand-to-primary-supabase.vercel.app/design-system/docs/color-usage): `text-primary` is visibly darker than `bg-brand-default` _on light mode_ - [Studio auth providers](https://studio-staging-git-dnywh-depr-316-text-brand-to-60fa6c-supabase.vercel.app/dashboard/project/_/auth/providers): enabled provider badge text readable; status dot stays bright green <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Style** * Updated branded text, link hover states, icons, badges, indicators, and highlighted content across the Design System, Docs, Studio, Learn, UI Library, and marketing experiences to use the primary theme color. * Updated syntax highlighting and table-of-contents styling for consistent primary-color presentation. * Refined brand color fallback behavior for bright fills and borders. * **Documentation** * Updated color-usage and typography guidance to recommend the primary text utility. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Danny WhiteandJoshen Lim
|
a31ca2bad0 |
fix(ui): make brand text readable across themes (#49871)
## What kind of change does this PR introduce? Bug fix and design-system update. Resolves DEPR-316. Follow-up rename (`text-brand` → `text-primary`) is in a dedicated PR (https://github.com/supabase/supabase/pull/50564) stacked on this one. ## What is the current behavior? `text-brand` resolves to the canonical bright brand green in places that need readable text, which fails WCAG AA on light surfaces. A separate `text-brand-display` token adds another green for large type. ## What is the new behavior? - `text-brand` maps to accessible `--primary` (light mode darkened to meet ~4.5:1 AA) - `--hue` / `--primary-hue` aligned to 157.5 - `text-brand-display` removed; former display callsites use `text-brand` - Bright fills/borders stay on `brand-default` - Design-system colour and typography docs updated | Before | After | | --- | --- | | <img width="514" height="112" alt="CleanShot 2026-09-02 at 11 13 09@2x" src="https://github.com/user-attachments/assets/4e0138a9-a32d-4e4c-a426-90736706e1e7" /> | <img width="512" height="138" alt="CleanShot 2026-09-21 at 11 42 05@2x" src="https://github.com/user-attachments/assets/164cc5b1-a0c5-4e93-95f1-80016641a114" /> | | <img width="864" height="266" alt="CleanShot 2026-09-02 at 11 13 53@2x" src="https://github.com/user-attachments/assets/3c1ca53f-bf9e-431e-bc15-816b4a275b8e" /> | <img width="882" height="248" alt="CleanShot 2026-09-21 at 11 41 37@2x" src="https://github.com/user-attachments/assets/24828e7b-ed6b-44cb-b9dc-becc3398bdfc" /> | | <img width="782" height="692" alt="CleanShot 2026-09-02 at 11 16 30@2x" src="https://github.com/user-attachments/assets/fc871977-77bc-47fb-9e0e-9284e0ecd5cc" /> | <img width="730" height="690" alt="CleanShot 2026-09-21 at 11 42 52@2x" src="https://github.com/user-attachments/assets/bf479515-d5f9-471e-b82d-f097c0f4b56c" /> | | <img width="480" height="306" alt="CleanShot 2026-09-02 at 11 18 53@2x" src="https://github.com/user-attachments/assets/03f341f4-f02e-44f8-a2b2-8c31670d0427" /> | <img width="470" height="300" alt="CleanShot 2026-09-21 at 11 43 19@2x" src="https://github.com/user-attachments/assets/9df18217-d5e6-48b8-ba0b-579d2664b94b" /> | | <img width="960" height="300" alt="CleanShot 2026-09-02 at 11 32 04@2x" src="https://github.com/user-attachments/assets/6b1d9373-7a71-4247-81ff-26441604b09d" /> | <img width="980" height="306" alt="CleanShot 2026-09-21 at 11 44 13@2x" src="https://github.com/user-attachments/assets/41ad4784-02ec-4b29-b860-32af9fa79aa8" /> | | <img width="924" height="214" alt="CleanShot 2026-09-02 at 11 34 44@2x" src="https://github.com/user-attachments/assets/1de661fe-c7b6-499b-a94f-e4737436ec79" /> | <img width="752" height="162" alt="CleanShot 2026-09-21 at 11 44 56@2x" src="https://github.com/user-attachments/assets/1811890f-0660-4445-84e9-447720954fa1" /> | ## To test Test each callsite **in light mode** (dark mode is largely unchanged). ### WWW - [Homepage](https://zone-www-dot-com-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/): “Scale to millions” uses readable brand text (display token is gone) - [Careers](https://zone-www-dot-com-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/careers): small “Careers” eyebrow readable; green dividers stay bright `brand-default` - [Contact](https://zone-www-dot-com-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/contact-us): email / policy links use readable brand text - [Regions](https://zone-www-dot-com-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/regions): “Ask about early access to BYOC” readable ### Docs - [Docs homepage](https://docs-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/docs): “DOCS” wordmark and resource links readable - [Database overview](https://docs-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/docs/guides/database/overview): nav / footer brand links readable - [JavaScript reference](https://docs-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/docs/reference/javascript/introduction): active sidebar treatment readable ### Design system - [Typography](https://design-system-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/docs/typography): documents `text-brand` only (no display) - [Colour usage](https://design-system-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/docs/color-usage): `text-brand` vs `bg-brand-default` - [Design-system homepage](https://design-system-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/): brand text examples across themes ### Studio - [Auth providers](https://studio-staging-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/dashboard/project/_/auth/providers): enabled provider badge text readable; status dot stays bright - [Database policies](https://studio-staging-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/dashboard/project/_/database/policies?new=true): template hover text more legible - [Database connections](https://studio-staging-git-dnywh-depr-316-brand-text-tokens-supabase.vercel.app/dashboard/project/_/observability/connections): “Live” status readable; animated dot stays bright green --------- Co-authored-by: Joshen Lim <joshenlimek@gmail.com> |
||
|
Prashant Sridharan
|
170cda1295 |
Changed a brand on the State of Startups page (#50583)
Replace Datapods with General Evidence and update its link to https://www.generalevidence.com in the State of Startups 2026 participant list. Keep the list in alphabetical order. ## 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? Content correction. ## What is the current behavior? The participant list displays Datapods and links to https://datapods.app. ## What is the new behavior? The participant list displays General Evidence and links to https://www.generalevidence.com. ## Additional context Validation: - All 149 tests passed across 11 test files. - Prettier and git diff checks passed. - App lint completed with zero errors and 1,173 warnings. - Local build stopped during the docs prebuild step because GitHub credentials were missing from the build environment. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Updates** * Replaced the Datapods participant with General Evidence in the State of Startups survey participant list. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Lukas Bernert
|
593e95345a |
www: update compute size descriptions (Compute column, vCPU units) (#49998)
## What kind of change does this PR introduce? www update: aligns compute descriptions on the pricing surfaces with the current compute options. Counterpart to the docs update in #49996. Fixes PROD-654 ## What is the new behavior? - Pricing compute table: the CPU and Dedicated columns are merged into a single Compute column — "Shared compute" for Micro–Medium, "Dedicated · N vCPUs" for Large and above (the `dedicated` key is removed from `PricingAddOnTable.json`) - Pricing calculator: the instance summary line uses the new Compute value directly - Pricing compute section headline: "64 cores" → "64 vCPUs" - `/pricing.md`, `/llms-full.txt`, `/llms/pricing.txt`: generated markdown mirrors the new table - `/database.md`: describes the compute range as Micro to 16XL+ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **Pricing Updates** - Compute pricing tables now label the column “Compute” and show shared compute or dedicated vCPU counts. - Removed the separate “Dedicated” column from compute add-on tables. - Dedicated-plan values now display consistently across desktop and mobile layouts. - Compute instance details no longer repeat the “CPU” label after the CPU value. - Updated scaling language to refer to “64 vCPUs.” - Simplified technical details by removing specific core-count examples while retaining configurable sizing and autoscaling information. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
supabase-supabase-autofixer[bot]andivasilov
|
127e21b926 |
Changes by create-pull-request action (#44860)
Automated changes by [create-pull-request](https://github.com/peter-evans/create-pull-request) GitHub action Co-authored-by: ivasilov <568291+ivasilov@users.noreply.github.com> |
||
|
claude[bot]andClaude
|
adca15deab |
chore(www): add Privacy Policy v4 (data controller entity, Freebuff cookie) (#50392)
<!-- ccr-slack-attribution --> _Requested by **Sofia Calado** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1789462983606899)_ ## 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? Content update — a new version (v4) of the Privacy Policy legal page, added following the existing versioned-legal-page pattern (v1-v3 already present, selectable via a version dropdown). ## What is the current behavior? Before: On `/privacy`, the latest selectable version is "Version 3 — May 13, 2026". That text names "Supabase, Inc" as the entity you're dealing with — both in the opening paragraph ("Thank you for your interest in Supabase, Inc., ...") and again as the named data controller in the EEA/UK/Switzerland disclosures section ("Supabase, Inc is the data controller..."). The Section 8 cookie table (EEA cookies) lists nine cookies/rows (Stripe x3, Cloudflare x2, Youtube, hCaptcha, Posthog, Google Analytics 4, Google Ads, `_sb_first_referrer`) and does not mention Freebuff anywhere. ## What is the new behavior? After: `/privacy` gains a new "Version 4" entry in the dropdown, at the top of the list (selected by default). Reading Version 4, the same two passages instead name "Supabase Pte. Ltd." as the entity/data controller. The Section 8 cookie table gains one additional row for "Freebuff" (Type: Advertising; dropped when you visit the Site after interacting with a Freebuff ad; 30-day duration; purpose: measuring ad campaign performance and attributing conversions to ad clicks upon consent; linking to the Freebuff Privacy Policy), formatted identically to the existing rows. Versions 1-3 are unchanged and remain selectable. ## Additional context Two changes, scoped exactly as requested: 1. **Data controller entity**: every "Supabase, Inc" / "Supabase Inc." reference that names the data controller is replaced with "Supabase Pte. Ltd." — at the top of the policy and in the EEA disclosures section. No other "Supabase" references (e.g. plain brand mentions) were touched. 2. **Freebuff cookie row**: added to the Section 8 (EEA cookies) table, matching the existing table's markdown formatting exactly. **Open question — effective date needs Sofia/Nicole's input before merge.** No effective date was given for v4. The version-selector component (`LegalDocVersions`) requires a non-empty `effectiveDate` string per version to render (used both in the dropdown label and, for a single-version page, an on-page line) — there's no way to add the version without wiring some string. Following the pattern's convention of never inventing a plausible-looking date, `effectiveDate` is set to the literal placeholder `'TBD'` for v4 in `apps/www/pages/privacy.tsx`. **This must be replaced with a real effective date before this PR merges** — flagging for Sofia Calado / Nicole Kramer to confirm. **Validation**: `pnpm --filter=www build` fails in this sandbox due to an unrelated prebuild step (`docs` app's `build:federated-content` script needs live GitHub API credentials to fetch tags — 401 Bad credentials — not related to this change). `tsc --noEmit` on `apps/www` ran clean of any error touching `privacy.tsx` or the privacy `.mdx` files (all reported errors are pre-existing, about unrelated missing generated assets/images). As a direct substitute, all four `apps/www/data/legal/privacy/*.mdx` files (v1-v4) were compiled through the app's actual MDX pipeline (`@mdx-js/mdx` with the same `remark-code-hike` + `remark-gfm` + `rehype-slug` config as `next.config.mjs`) and all compiled successfully, confirming the new table syntax and content are valid MDX/GFM. Files touched: - `apps/www/data/legal/privacy/v4.mdx` (new) - `apps/www/pages/privacy.tsx` (added v4 to the `versions` array) 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01BzHiVEUzjvrwxgnxCrrER1 --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Danny White
|
476d4a5851 |
refactor(ui): drop redundant Button variant="default" props (#50161)
## What kind of change does this PR introduce? Mechanical cleanup on top of the Button default-variant change (#50160). ## What is the current behavior? Many callsites still pass `variant="default"` even though that is now the component default. ## What is the new behavior? Removes redundant static `variant="default"` from legacy `Button` and `ButtonTooltip` callsites. Keeps explicit defaults where they document the API: - `button-default.tsx` and `button-sizes.tsx` demos - `DocsButton`, which pins neutral styling at the wrapper boundary ## To test Studio: - [Auth → Rate Limits](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/auth/rate-limits): dirty the form so Cancel appears; Cancel stays neutral, Save stays green - [Project Settings → API Keys](https://studio-staging-2s957kwc4-supabase.vercel.app/dashboard/project/_/settings/api-keys): `DocsButton` in the header actions stays neutral Design system: - [Design system → Button](https://design-system-git-dnywh-dc924ac1-supabase.vercel.app/design-system/docs/components/button): `button-default` / `button-sizes` still show explicit default styling; Primary (green) is restricted to the Primary section (and `asChild`) WWW: - [www → Brand assets](https://zone-www-dot-com-git-dnywh-dc924ac1-supabase.vercel.app/brand-assets): Download logo kit / Download button kit stay neutral |
||
|
Gildas GarciaandAlaister Young
|
737b8595f2 |
Update API types (#50234)
## Problem platform, v1 and v2 have been already completely migrated and introduced some changes. Some types have been renamed, some outputs and inputs updated. ## Solution - Update the API types - Fix the TS errors ## Update Taking this over to unblock #50134, which needs the new scoped token permission ids from the regenerated types. - Merged `master`. - Regenerated `api-v2.d.ts` from the production spec. The previous files came from a local API that exposed a webhook events endpoint production doesn't have yet. Production has since added standardized 400 error responses on the v2 organization endpoints. `api-v1.d.ts` and `platform.d.ts` already matched production. - Fixed `verify-production-types`. It formatted the regenerated files in a temp directory outside the repository, so Prettier fell back to its defaults and the comparison could never match the committed files. It now passes the repository config explicitly. `pnpm api:verify-types` passes on this branch. - Verified locally: `pnpm typecheck`, `pnpm api:verify-types`, Studio unit tests. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Preserved descriptions when saving, sharing, moving, or unsharing notebooks, reports, SQL snippets, and saved queries. * Improved handling of empty or null values across notebook descriptions, billing usage, pooler settings, and infrastructure fields. * Improved read-replica connection handling, including read-only connection strings. * Updated storage configuration and capability handling to match current settings. * **API and Compatibility** * Updated organization, project, storage, OAuth, billing, and infrastructure data handling to match current API responses. * OAuth app creation and updates now require scopes. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com> |
||
|
Miranda Limonczenko
|
23a5bd4707 |
fix: update inbound links to the pooling guide (#50187)
## 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. Link string changes only, no content changes. ## What is the current behavior? Nine inbound links in `apps/www` and `apps/studio` point at anchors on the connecting to Postgres guide that don't exist. All nine are already broken on production today: `#connection-pooler`, `#connection-pool`, `#how-connection-pooling-works`, `#serverside-poolers`, and `#connecting-with-drizzle` are all missing from the live page. #49869 moves the pooling content to a child page, so these links need current destinations either way. ## What is the new behavior? Point each link at the page that holds the content now. - **Studio, 3 links.** The Connect sheet's Drizzle link goes to the Drizzle guide. The connection pooling and pooling modes links go to `pooling-and-limits#how-connection-pooling-works`. - **www, 6 links.** Three blog posts, the Heroku comparison page, and the Dedicated poolers feature entry go to `pooling-and-limits`. The feature entry uses `#shared-pooler`. ## Additional context Split out of #49869. These paths belong to `@supabase/marketing` and `@supabase/Dashboard` in CODEOWNERS, and pulling both teams into a docs-only restructure for nine link strings isn't a good trade. Merge after #49928. The destinations don't exist on production until the docs pages land. ## Manual testing 1. Open [Supavisor: Scaling Postgres to 1 Million Connections](https://zone-www-dot-com-git-fix-pooler-docs-links-supabase.vercel.app/blog/supavisor-1-million). The "connection pooling" link in the opening paragraph resolves to `connecting-to-postgres/pooling-and-limits#how-connection-pooling-works`. 2. Open [Dedicated poolers](https://zone-www-dot-com-git-fix-pooler-docs-links-supabase.vercel.app/features/dedicated-poolers). The docs link resolves to `pooling-and-limits#shared-pooler`. 3. Open [Supabase vs Heroku Postgres](https://zone-www-dot-com-git-fix-pooler-docs-links-supabase.vercel.app/alternatives/supabase-vs-heroku-postgres). Both connection pooling links resolve to `pooling-and-limits#how-connection-pooling-works`. 4. Open [Connection pooling and limits](https://docs-git-docs-connecting-to-postgres-technical-supabase.vercel.app/docs/guides/database/connecting-to-postgres/pooling-and-limits) on the #49928 docs preview. The `how-connection-pooling-works` and `shared-pooler` headings both render with those IDs. 5. Open the Connect dialog on any project. Under Drizzle, the docs link opens the Drizzle guide. 6. Open Database settings, then Connection pooling. The pooler link opens Connection pooling and limits. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated connection pooling links across Studio, product pages, blogs, and comparison content to point to the relevant pooling guidance. * Refined links for Drizzle ORM, dedicated poolers, direct connections, and shared poolers. * Improved navigation to specific documentation sections explaining connection pooling modes and behavior. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
e0280cb650 |
docs: restructure observability navigation and overview (#49505)
<!-- CURSOR_AGENT_PR_BODY_BEGIN --> ## Stack Draft stack extracted from `docs/monitoring`. Merge bottom-up. The troubleshooting *catalog* rewrite (`content/troubleshooting` and the Diagnosing UI) stays out of scope. 1. #49503 move inspect and advisors 2. #49501 split Studio logs from ClickHouse queries 3. #49500 treat reports as signal dashboards 4. #49502 add Observe the data hub 5. #49506 add agent setup components 6. #49504 add hire-an-agent templates 7. **#49505** restructure observability nav, overview, Detecting, and flatten Observe the data ← **this PR** ## 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. Top layer in the observability stack. ## What is the current behavior? The section is still titled Monitoring and Debugging, with a Debugging / Monitoring split that does not match the new pages. The debugging guide is still the master layer-isolation + symptom table. Observe the data is split into “what data” vs “where to observe it,” which duplicates the source pages. ## What is the new behavior? - Section title is Observability - Overview groups Observe the data, Detect and resolve, Hire an agent, and Export - **Observe the data is flattened by source.** Logs, Metrics API, Database, Advisors, and Reports each list where to read that source. There is no separate MCP/API/CLI/Studio nav group. - **Observe vs Detecting:** Observe is the catalog (what exists, how to access it). Detecting is how to *use* those sources to pick up a Health / Security / Performance / Usage signal. Named errors skip to Diagnosing. - Studio Logs sits under Logs. Reports sits beside the other sources. - Troubleshooting stays in the global menu and also appears as Diagnosing under Detect and resolve ## Additional context This is the last PR in the stack. Together the seven PRs reconstruct the `docs/monitoring` observability IA and guide content, without shipping the troubleshooting catalog overhaul. <!-- CURSOR_AGENT_PR_BODY_END --> <div><a href="https://cursor.com/agents/bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794?cursor_ref=pr_footer&cursor_cta=open_in_web"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-web-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-web-light.png"><img alt="Open in Web" width="114" height="28" src="https://cursor.com/assets/images/open-in-web-dark.png"></picture></a> <a href="https://cursor.com/background-agent?bcId=bc-a3cb5ece-925b-4046-b58a-5d69e9a9d794&cursor_ref=pr_footer&cursor_cta=open_in_cursor"><picture><source media="(prefers-color-scheme: dark)" srcset="https://cursor.com/assets/images/open-in-cursor-dark.png"><source media="(prefers-color-scheme: light)" srcset="https://cursor.com/assets/images/open-in-cursor-light.png"><img alt="Open in Cursor" width="131" height="28" src="https://cursor.com/assets/images/open-in-cursor-dark.png"></picture></a> </div> --------- Co-authored-by: Cursor Agent <cursoragent@cursor.com> Co-authored-by: Saxon Fletcher <SaxonF@users.noreply.github.com> Co-authored-by: Nik Richers <nik@validmind.ai> |
||
|
Wendie CheungandWendie Cheung
|
658a5c7fee |
Update Lingo.dev customer story slug to lingodotdev (#49623)
## What kind of change does this PR introduce? Content: slug update for an already-live customer story. ## What is the current behavior? The Lingo.dev customer story (originally added in #49595) lives at `/customers/lingo-dev`. ## What is the new behavior? - Renames `apps/www/_customers/lingo-dev.mdx` to `apps/www/_customers/lingodotdev.mdx`. - Updates the `url` in `apps/www/data/CustomerStories.ts` to `/customers/lingodotdev`. - Adds a permanent redirect from `/customers/lingo-dev` to `/customers/lingodotdev` in `apps/www/lib/redirects.js`. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a customer story highlighting Lingo.dev’s localization workflow, platform usage, security practices, results, and future plans. * **Bug Fixes** * Updated the customer story link to its new URL. * Added a permanent redirect so existing links to the previous URL continue to work. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Wendie Cheung <wendie.cheung@supabase.io> |
||
|
|
292c08b7b7 |
Added new /regions page (#49306)
## 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 ## What is the current behavior? Region and data residency information is split across docs, `/security`, and legal pages. [MARKET-1866](https://linear.app/supabase/issue/MARKET-1866/package-and-display-available-regions-better-on-website) ## What is the new behavior? Adds `/regions`: a catalog of all 17 regions generated from `regions.ts`, plus what stays in-region, the Europe vs EU caveat, and links to the DPA, GDPR guide, sub-processor list, and security page. Regions is in the footer under Security & Compliance. The security page residency card now links here. ## Test plan - [ ] Open `/regions` in light and dark mode - [ ] Confirm the region count and list match `packages/shared-data/regions.ts` - [ ] Confirm footer Regions link and `/security` residency link go to `/regions` Made with [Cursor](https://cursor.com) <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit - **New Features** - Added a Regions page showcasing available AWS regions by geography. - Added an interactive map and region list with selection, hover states, keyboard accessibility, and residency badges. - Included data residency guidance, legal resources, and a call-to-action for next steps. - Added Regions links in the site footer and security documentation. - **Documentation** - Updated agent skill resources with expanded troubleshooting and operational guidance. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Cursor <cursoragent@cursor.com> Co-authored-by: Francesco Sansalvadore <f.sansalvadore@gmail.com> |
||
|
|
8291ed1401 |
Add Lingo.dev customer case study (#49595)
## 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? Content: new customer case study for supabase.com/customers. ## What is the current behavior? Lingo.dev doesn't have a case study on supabase.com/customers yet. Source content: [Notion case study doc](https://app.notion.com/p/supabase/Lingo-dev-3c05004b775f81e5a936dd40f77e2781) (Linear: [MARKET-1468](https://linear.app/supabase/issue/MARKET-1468/case-study-lingodev)). ## What is the new behavior? - Adds `apps/www/_customers/lingo-dev.mdx`: how Lingo.dev runs retrieval augmented localization on Supabase Database, Vector, Auth, and Storage, and clears every enterprise security review (Mistral AI, Solana Foundation, Veriff) without a database question raised. - Registers the story in `apps/www/data/CustomerStories.ts` so it surfaces on the customer stories listing. - Adds logo (on-light/on-dark) and founder headshot assets for Max Prilutskiy and Veronica Prilutskaya. ## Additional context Ran through `supabase-writing` and `humanize` style passes before finalizing copy. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Content** * Added a customer story highlighting Lingo.dev’s localization platform, architecture, security practices, and operational results. * Added the story to the customer stories collection with supporting imagery, description, and call-to-action details. <!-- 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> |
||
|
Victor Farazdagi
|
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 --> |
||
|
Danny White
|
fdf33e72c4 |
fix(studio): clean up onboarding returnTo paths (#49283)
## What kind of change does this PR introduce? Bug fix. Follow-up to #41041 and DEPR-318. ## What is the current behavior? Marketing "Start your project" links go to `/dashboard`, which redirects unauthenticated users to `/org` and sets `returnTo=/org`. That value survives when they switch from sign-in to sign-up, so email verification still lands on the org list instead of org creation. ## What is the new behavior? - Sign-in's **Sign up** link rewrites `returnTo=/org` (and `/organizations`) to `/new` - Docs mobile menu, www homepage/product CTAs, and solution page CTAs link to `/dashboard/sign-up` for guests - Signed-in visitors get the dashboard URL instead, so they never hit the sign-up form - Shared `DASHBOARD_SIGN_UP_URL` / `getDashboardCtaHref` helpers for www Stacked on #41041. ## To test Stacked on #41041. The studio preview below includes both PRs. www and docs have their own previews. ### Studio: sign-in → sign-up rewrite Using the [studio-staging preview](https://studio-staging-git-dnywh-fixonboarding-return-to-supabase.vercel.app/) from Vercel checks: 1. Open the preview while logged out. It should land on `/dashboard/sign-in?returnTo=%2Forg` 2. Click **Sign up**. Expect the URL to include `returnTo=%2Fnew` ### Optional: www CTAs Using the [www preview](https://zone-www-dot-com-git-dnywh-fixonboarding-return-to-supabase.vercel.app/): 3. Logged out: homepage, product, or solutions **Start your project** should go to `/dashboard/sign-up` 4. Logged in: the same CTAs should go to `/dashboard` (not sign-up) (thought this will be hard if not impossible to test on staging) ### Optional: docs CTAs Using the [docs preview](https://docs-git-dnywh-fixonboarding-return-to-supabase.vercel.app/): 5. On mobile nav while logged out, click **Start your project**. Expect `/dashboard/sign-up` ### Compare on supabase.green Optional. Just to show what happens currently on `master`: 6. Open **supabase.green** while logged out, then click **Sign up** from `/dashboard/sign-in?returnTo=%2Forg`. `returnTo` should stay as `/org` <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Start-project and sign-up links now direct visitors to registration while signed-in users continue to reach the dashboard. * Homepage, product, solution, and mobile navigation CTAs now provide consistent authentication-aware destinations. * Sign-up links preserve return destinations and existing navigation parameters. * **Bug Fixes** * Corrected mobile navigation and marketing CTA links that previously sent visitors to the dashboard root instead of the appropriate sign-up flow. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
AnaandSteven Eubank
|
0a677ac9ee |
feat(www): add client-side trace propagation to Logs & Analytics (#49161)
## 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 page content update (`apps/www/data/features.tsx`) - Docs link fix ## What is the current behavior? The Logs & Analytics feature page entry covers Supabase exporting its own telemetry outward (OpenTelemetry export, Metrics API) but does not mention client-side trace propagation. The Log Drains entry links a stale docs URL. ## What is the new behavior? - Logs & Analytics entry now also covers client-side trace propagation: supabase-js, Swift, Flutter, and Python can propagate W3C Trace Context to Supabase so a client trace and the corresponding Supabase logs share a `trace_id`, added as a new paragraph and Key benefit - Log Drains entry's `docsUrl` fixed from `/guides/telemetry/log-drains` to `/guides/monitoring-and-debugging/log-drains` ## Additional context <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added information about W3C trace-context propagation for Logs & Analytics. * Documented supported client libraries, tracer integrations, opt-in behavior, and shared `trace_id` correlation. * **Documentation** * Updated the Log Drains documentation link. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Steven Eubank <47563310+smeubank@users.noreply.github.com> |
||
|
claude[bot]
|
00952806f2 | fix(www): correct three outdated pricing page FAQ answers (#49036) | ||
|
Miranda Limonczenko
|
de39dda387 | docs: replace Pico references with Nano in Supabase for Platforms content (#48958) | ||
|
Danny White
|
2e7a8a3362 |
chore(www): rename customer logo folders to on-dark and on-light (#48962)
## What kind of change does this PR introduce?
Chore: rename customer logo folders and document the theme contract. No
intended visual change, aside from Phoenix Energy whose two marks were
in the wrong folders.
## What is the current behavior?
Customer logos live at:
- `/images/customers/logos/{slug}.png` (`logo`, light mode)
- `/images/customers/logos/light/{slug}.png` (`logo_inverse`, dark mode)
`light/` actually means “use me on a dark background”.
## What is the new behavior?
Same assets, clearer paths:
- `/images/customers/logos/on-light/{slug}.png` → dark/black mark →
`logo` → light mode
- `/images/customers/logos/on-dark/{slug}.png` → light/white mark →
`logo_inverse` → dark mode
Icon chips stay at `/images/customers/logos/{slug}-icon.svg`. Old
`/images/customers/logos/light/*` URLs redirect to `on-dark`. www README
now has the contract.
# To test
Use the [www
preview](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app).
Toggle light/dark from the site header on each page. Logos should stay
readable (no white-on-white or black-on-black).
1. [Customers
grid](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/customers)
— main `logo` / `logo_inverse` surface. Spot-check Juniver, Phoenix
Energy, and one other card.
2. [Phoenix Energy
story](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/customers/phoenix-energy)
— story header uses `logo` only (on-light, plus a dark-mode brightness
filter). We swapped this pair.
3.
[Homepage](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/)
— “How industry leaders…” section. Icon chips only (`*-icon.svg`); the
wordmark `logo` field is unused here.
4. [Solutions /
Agents](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/solutions/agents)
— Chatbase quote near the top shows both theme variants. Same pattern on
[/healthcare](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/solutions/healthcare),
[/finserv](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/solutions/finserv),
and
[/b2b-saas](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/solutions/b2b-saas).
5. [Contact
sales](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/contact/sales)
— Good Tape / Xendit / Chatbase wordmarks (`on-light`). Same logos on
the demo form at
[/solutions/enterprise](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/solutions/enterprise).
6.
[Enterprise](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/solutions/enterprise)
— Mozilla / Epsilon3 / Pebblely icons in the use-cases section
(`on-dark`).
7.
[Vector](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/modules/vector)
— customer quotes. This is the only page that builds `on-light` /
`on-dark` paths at runtime from the customer slug.
8. [Mobbin
event](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/events/migrating-from-firebase-mobbin)
— company logo uses event `logo` / `logo_light` (dark vs light).
Optional second:
[/events/scale-to-millions-goodtape-auth](https://zone-www-dot-com-git-dnywh-chorecustomer-logo-o-0d7bc1-supabase.vercel.app/events/scale-to-millions-goodtape-auth).
Quick extra: hover **Product** in the site nav. The customer story
thumbnail uses `imgUrl` (`on-light`).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Documentation
- Clarified customer logo requirements, including separate light and
dark asset locations, monochrome formats, and dark PNG assets for image
generation.
## Updates
- Standardized customer logos across stories, events, sales pages,
solution pages, testimonials, and generated images.
- Improved logo rendering across light and dark themes with dedicated
variants.
- Added permanent redirects for legacy logo URLs while preserving
filename suffixes.
## Tests
- Added coverage verifying legacy logo redirects resolve correctly,
including supported exceptions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
|
||
|
David_CandPamela Chia
|
6bda113bf0 |
fix(www): fix duplicate row level security key (#48325)
## 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 (fixes #48324) ## What is the current behavior? Detailed in #48324, there's a duplicate row-level-security section. Line 369 to 392 (right above the change) already have this row-level-security section, seems like a simple forget to change the copy pasted content mistake ## What is the new behavior? Fixed based on the title and image name <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Content Updates** * Replaced the “Row Level Security” feature card with “Full SQL access” in the Postgres platform features section. * Updated the associated image description to “SQL Editor.” <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com> |
||
|
Ayaan GazaliandPamela Chia
|
279e577fac |
fix(www): correct broken product carousel and partner logo image paths (#48822)
## 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 (broken images on the database product page and the agencies solutions page). ## What is the current behavior? Five image paths point at files that are not in the repo, so they 404 in production. Four of them are carousel slides on the database product page, which means those slides render with a broken image. | referenced | actually committed | | --- | --- | | `sql-view/manaco-editor.png` | `sql-view/monaco-editor.png` | | `table-view/spreadsheet-interface.png` | `table-view/spreadsheet.png` | | `table-view/create-table.png` | `table-view/create-tables.png` | | `table-view/export.png` | `table-view/export-csv.png` | | `logos/publicity/sj-innovation.svg` | `logos/publicity/sjinnovation.svg` | All five confirmed 404 on production, and all five replacements confirmed 200. ## What is the new behavior? Each path points at the file that is actually committed. No assets added, renamed or deleted. The mapping is not guesswork, each slide's own title and text names the image: - the `manaco-editor` slide is titled "Monaco editor" with the text "Built in Monaco editor, with rich validation and autocomplete", so that is a plain spelling slip for `monaco-editor.png` - the `create-table` slide is titled and labelled "Create tables", plural, matching `create-tables.png` - the `export` slide is "Select and Export" with the text "Pick the rows you want and export them into a CSV", matching `export-csv.png` - the `spreadsheet-interface` slide is "The simplicity of a spreadsheet", matching `spreadsheet.png` I also checked the dark and light convention before picking: every other slide in both carousels uses the plain filename rather than the `-light` variant, so I stayed consistent with that and did not switch any slide to a `-light` asset. ## Additional context Files: - `apps/www/data/products/database/sql-view-carousel.json` (1) - `apps/www/data/products/database/table-view-carousel.json` (3) - `apps/www/data/solutions/agencies.tsx` (1) How I found it: compared every `/images/...` reference across `apps/www` (2152 distinct paths) against `apps/www/public`, then for each miss looked for a near match in the same directory before deciding anything, and finally live-checked both the broken path and the proposed replacement. One in the same file I could not fix: `apps/www/data/solutions/agencies.tsx` also references `logos/publicity/imaginary-space.svg`, which 404s and has no similarly named asset anywhere in that directory. That one needs the actual logo, so it is not something I can resolve from the repo. Gates run locally: `test:prettier` passes repo wide, `typecheck` passes 16/16, and the www vitest suite passes (6 files, 73 tests). I did not run `pnpm build`, which cannot complete in my environment because the docs `build:federated-content` step needs `DOCS_GITHUB_APP_PRIVATE_KEY` and fails before Next compiles. Freshman contributor, found these with a local asset scan and verified every status code myself, with Claude Code's help along the way. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Corrected image references in the SQL view and table view carousels. * Updated illustration paths for spreadsheet editing, table creation, and CSV export content. * Fixed the SJ Innovation testimonial logo so it displays correctly. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Pamela Chia <pamelachiamayyee@gmail.com> |
||
|
Saxon Fletcher
|
cb35e1f98e |
chore(library): update routes, redirects, and naming (#48668)
Our UI Library registry is expanding to include blocks that go beyond UI and in some cases focus purely on back-end. This PR is a precursor to adding more back-end related blocks. This PR includes the `ui-library -> library` rename plus redirects and small UI copy updates. Since this is a rename we'll need to update Vercel configuration. ## Vercel rollout Keep the Library project Root Directory as `apps/ui-library` 1. In the **Library** Vercel project, set: `NEXT_PUBLIC_BASE_PATH=/library` Apply it to Preview and Production, then redeploy the Library project. 2. In the **www** Vercel project, add: `NEXT_PUBLIC_LIBRARY_URL=<current value of NEXT_PUBLIC_UI_LIBRARY_URL>` Apply it to Preview and Production. Keep `NEXT_PUBLIC_UI_LIBRARY_URL` during the migration, then redeploy the www project. 3. Deploy in this order: 1. Library project 2. www project 4. Validate: - `/library` - `/library/docs/nextjs/password-based-auth` - `/ui` redirects to `/library` - `/ui/docs/nextjs/password-based-auth` redirects to `/library/docs/nextjs/password-based-auth` - `/ui/docs/ai-editors-rules/*` still uses its existing Docs redirects No Vercel dashboard redirect rules are needed. Environment-variable changes require a new deployment. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Supabase UI Library has been renamed to **Supabase Library** across navigation, pages, documentation, and resource links. * The Library is now available at `/library`, with updated descriptions covering components, blocks, and developer tools. * **Bug Fixes** * Added permanent redirects from legacy `/ui` URLs to corresponding `/library` paths. * Updated links throughout the site and documentation to prevent broken navigation and references. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
claude[bot]andClaude
|
86854671e9 |
feat(www): add Open Authorization Integration Addendum (#48804)
<!-- ccr-slack-attribution --> _Requested by **Nicole Kramer** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1786027145751449)_ ## 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 — a new legal page on the marketing site (`apps/www`). ## What is the current behavior? **Before:** the Program Addenda page at `/legal/partner-resources/program-addenda` lists exactly one addendum, the Integration Partner Addendum. There is no published Open Authorization (OAuth) addendum anywhere on the site. ## What is the new behavior? **After:** the Program Addenda page also lists the **Open Authorization Integration Addendum**, linking to a new page at `/legal/partner-resources/program-addenda/oauth-partner-addendum`. Formatting, breadcrumbs, version selector, and listing badge all match the existing Integration Partner Addendum. **How:** three files. - `apps/www/data/legal/partner-resources/oauth-partner-addendum/20260806-v1.mdx` — the addendum text, formatted to match `integration-partner-addendum/20260615-v1.1.mdx` (escaped section-number periods, `####` run-in headings for the lettered subsections, italic `_Label_` run-in labels for the enumerated data-protection clauses, explicit `[url](url)` links). - `apps/www/pages/legal/partner-resources/program-addenda/oauth-partner-addendum.tsx` — the page, mirroring `integration-partner-addendum.tsx` with a single-version `versions` array. - `apps/www/lib/addenda.ts` — adds a small `TITLE_OVERRIDES` map. The listing derives titles by capitalizing slug words, which turns `oauth-partner-addendum` into "Oauth Partner Addendum"; the override makes the listing link read the same as the page's `h1`. No other wiring was needed: the addenda listing is generated from the directory, so there is no hub entry, redirect, rewrite, sitemap entry, or `noindex` rule to add. ## Additional context Two things for the requester to confirm: - **The effective date is an assumption.** The addendum document itself contains no date. The listing and version label derive the effective date from the `YYYYMMDD` filename prefix, so this file is dated **August 6, 2026**, taken from the source document's own filename (`2026.08.06 - Supabase-OAuthAddendum-ONLINE.docx`). To change it, rename the file — no code change required. - **The legal text is a verbatim transcription.** Source wording, capitalization, and punctuation are preserved exactly as drafted, including anything that reads like a typo. Only markup was added; the plain text was diffed against the transcription and is character-identical. Please review the wording itself rather than assuming it was copy-edited. One wording choice that was not in the source document: the page subheader, "An addendum to the Master Partner Program Agreement governing OAuth integrations." It mirrors the one-line subheader style of the existing addendum page and is easy to reword. ## Also fixed here: a literal `(c)` rendered as `©` in legal headings While formatting the new addendum we hit a rendering bug that turned out to be **already live on supabase.com**, not new to this branch. The heading font, **Manrope**, ships a default-on standard `liga` feature that maps the glyph sequence `parenleft c parenright` to the copyright glyph. So a literal `(c)` anywhere inside an `h2`–`h6` on the marketing site paints as `©`. Body copy is unaffected because it uses Inter, whose subset has no such ligature — which is why this only ever shows up in headings. This branch adds a `legal-prose` utility (`font-variant-ligatures: no-common-ligatures`) in `apps/www/styles/globals.css` and applies it to two pages: - the new **Open Authorization Integration Addendum** page (heading `#### (c) Security.`), and - the **Master Partner Program Agreement** page, where the `#### (b) Such indemnity …` heading in section 17.1 contains `… ; or (c) replace the Covered Materials …` about 600 characters into the line. That page was **already published**, and rendered "or © replace the Covered Materials" in production. The MPPA change is one word — `className="prose"` → `className="prose legal-prose"`. **No legal text was modified**: no HTML entities, no zero-width characters, no rewording, no re-hyphenation. The DOM still holds `U+0028 U+0063 U+0029`; only the font's shaping is suppressed. Verified in Chromium against the real heading text and the same two font subsets `next/font` serves: the `(c)` run measures **15.36px** before the fix (a single `©` glyph) and **22.05px** after (three literal glyphs), against a 23.30px control for the `(b)` in the same heading. All 17 `.mdx` files under `apps/www/data/legal/` were swept for `(c)` and the other Manrope `liga` input sequences (`--`, `->`, `<-`, `(>)`, `<3`) on heading lines. The only two hits are the two pages fixed above; nothing else needs the utility today. (Headings do contain `ff`/`fi`/`fl`/`tt` — those ligatures are ordinary typography and are intentionally left alone.) **For future legal pages:** because the cause is the heading font's default ligature rather than anything about these documents, any new legal page whose source has `(c)` in a heading will need `legal-prose` on its prose container too. **One side effect worth flagging:** `no-common-ligatures` is blunt, so on those two pages it also suppresses the ordinary `fi`, `ff` and `tt` ligatures — a sweep of the legal `.mdx` files counts 107 such occurrences in headings (`fi` 83, `ff` 21, `tt` 3, `fl` 0), so the note above about leaving them alone holds for the rest of the site rather than for these two pages. That is a deliberate trade-off: correctness of the legal text beats typographic polish on two addendum pages. A narrower alternative exists — `font-feature-settings: "liga" 0` scoped to just the offending ligature, or overriding only the `parenleft_c_parenright` substitution — but it is more fragile and more subset-specific, so push back here if you would rather have that instead. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01VtcJJGqw5jL1ESwhs8DGCu --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Wendie Cheung
|
6ac0316738 | Add QA.tech customer case study (#48798) | ||
|
AnaandAna
|
405d789e27 |
docs(www): add launch video to Supabase Pipelines feature page (#48654)
## 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? - Sets `heroImage` on the `supabase-pipelines` entry in `apps/www/data/features.tsx` to the "Introducing Supabase Pipelines" YouTube embed ## What is the current behavior? `/features/supabase-pipelines` has an empty `heroImage`, so the hero renders the fallback icon block instead of media. ## What is the new behavior? - The feature page hero renders the launch video, using the same `youtube-nocookie.com/embed/<id>` format as the other 22 feature entries with video heroes ## Additional context N/A <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Content Updates** * Updated the Supabase Pipelines feature presentation to display a YouTube video as its hero visual. <!-- end of auto-generated comment: release notes by coderabbit.ai --> Co-authored-by: Ana <ana1337x@users.noreply.github.com> |
||
|
Pamela Chia
|
c4c58ef3e3 |
feat: remove pandadoc dpa request flow (#48525)
Terms of Service v3 (effective August 1, 2026, #48482) incorporates the Data Processing Addendum by reference, so customers no longer sign a separate DPA. Legal confirmed the PandaDoc signing flow can go; previously signed DPAs remain binding. This removes the frontend flow only. I'll remove the platform endpoint (`POST /platform/organizations/{slug}/documents/dpa`) separately once the PandaDoc contract conversation wraps. **Changed:** - **Dashboard DPA card no longer requests PandaDoc documents**: the Request DPA button and confirm modal are replaced with a View DPA link to the canonical legal page, with evergreen copy explaining the DPA is part of the Terms. Tracked via the same `document_view_button_clicked` event the other document cards use. - **Legacy `/legal/dpa` page retired**: the page told users to request a signed DPA from the dashboard, which no longer exists. It now permanently redirects to `/legal/customer-resources/data-processing-addendum` (the follow-up already flagged in #48483), and the footer link is removed. The `dpa_pdf_opened` and `dpa_request_button_clicked` events are removed with their last call sites. The latest privacy version links the canonical page directly; archived v1/v2 keep their original `/legal/dpa` link, served by the redirect. - **Orphaned DPA PDFs removed**: the four dated `Supabase+DPA+*.pdf` files under `/downloads/docs` had zero remaining references once the signing flow is gone. No redirect: nothing links these URLs, so they 404. - **Subscription tracking**: the subprocessor updates form now fires `www_subprocessor_updates_subscribed` on successful submit, so we can measure uptake of the notification list that replaces per-customer DPA emails. ## To test Verified on the Vercel previews (Playwright): - [x] Studio: `/org/_/documents` shows the DPA card with the incorporation copy and a working View DPA link (href = canonical page); no Request DPA button, no PandaDoc mention; TIA/SOC2/ISO27001/HIPAA cards unaffected - [x] www: `/legal/dpa` permanently redirects to `/legal/customer-resources/data-processing-addendum`; footer no longer shows DPA; zero console errors - [x] www: subscribing on the subprocessor page succeeds (200 from the form route, profile created with topic_4) and fires `www_subprocessor_updates_subscribed` (201 from the telemetry endpoint); test profile unsubscribed afterwards - [x] www: `/downloads/docs/Supabase+DPA+260601.pdf` returns 404 with no redirect; DPA card copy verified without the effective date ## Linear - fixes GROWTH-1068 |
||
|
claude[bot]andClaude
|
76a9ba968c |
refactor(www): unify legal page shells and versioning (#48483)
<!-- ccr-slack-attribution --> _Requested by **Francesco Sansalvadore, Nicole Kramer** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1785399057853249?thread_ts=1785399057.853249&cid=C0161K73J1J)_ ## 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? Refactor of the marketing site's legal pages, plus two small content fixes (removal of duplicated dates, two heading corrections) and two permanent redirects. ## What is the current behavior? The documents linked from the Legal Hub are built three different ways: - `/terms` and `/enterprise-terms` render a plain inline heading with no breadcrumbs. - `/sla`, `/support-policy`, `/aup` and `/privacy` are standalone MDX pages carrying their own layout. - `/legal/dpa` has a one-off centered heading and grid of its own. On top of that, the documents that already have a version selector *also* print a "Last Modified" line inside the document body, so the same fact is stated twice on the page. On `/terms` and `/enterprise-terms` the two statements disagree: the selector says "Version 2 — May 6, 2026" while the body says "Last Modified: 1 May 2026". `/privacy` handles its history differently again — earlier versions live at their own archived URLs (`/privacy-260316` and `/privacy-250528`), strung together by "Previous Version" links at the bottom of each page. ## What is the new behavior? Every legal page now renders through one shell: `PageHeader` with a `PageBreadcrumb`, so the Legal Hub is one click away from any document. - The duplicate "Last Modified" rows are removed from the five versioned documents. The version selector is now the single place a date appears. - `/aup` and `/privacy` gain the version selector. - `/privacy`'s three historical versions are now selectable from the one page, and the two old archived URLs permanently redirect to it. - `/sla` and `/support-policy` pick up the shell and breadcrumbs but intentionally show neither a date nor a selector — neither document has ever carried one, and Legal asked that the SLA stay that way for now. Implementation-wise the canonical pattern is the one the Data Processing Addendum page was already using: `DefaultLayout` > `NextSeo` > `PageHeader` (with a `breadcrumb` slot) > `MDXProvider` > `SectionContainer className="prose"` > `LegalDocVersions`. The standalone MDX pages were moved to `apps/www/data/legal/<slug>/vN.mdx` as bare content partials, with a new TSX shell taking over the original route. No route changed except the two archived privacy pages, which redirect. Dates were carried across from the "Last Modified" lines being deleted rather than invented: `/aup` becomes Version 1 — June 1, 2026, and privacy v1/v2/v3 become May 28 2025, March 16 2026 and May 13 2026. ## Additional context **This is a stacked PR.** It is sequenced behind three PRs that touch the same files and should land first: the Terms of Service v3 bump, the Enterprise SaaS Subscription Agreement v3 bump, and #48481 (DPA effective date → August 1, 2026). #48481 edits the very "Last Modified" line this PR removes from the DPA content file, so a trivial conflict there is expected. This branch will be rebased onto master before it leaves draft. **Two contracts now contain a clause that no longer describes the page.** `apps/www/data/legal/terms/v1.mdx` and `v2.mdx` — and the same sentence in the MPPA and both integration-partner addenda — still read "The date on which the Agreement was last modified will be updated at the top of this Agreement". There is no longer a date in the document body; it sits in the version selector above it. Left untouched here because it is contract text, but Legal should re-word it. **The date mismatch is resolved in favour of the selector.** On `/terms` and `/enterprise-terms`, deleting the body line leaves May 6, 2026 as the only date on the page. Nicole Kramer confirmed in Slack that May 6 is the correct date. **Two headings change visibly**, to line up with the labels used on the Legal Hub: "Terms of service" → "Terms of Service", and "Service Level Agreements" → "Service Level Agreement". **`/legal/dpa` now looks almost identical to `/legal/customer-resources/data-processing-addendum`** — same heading, same breadcrumb, different content. The legacy page is a PDF download plus a signing flow and was deliberately left live, but the overlap is more obvious than it was. Redirecting it to the versioned page is the natural follow-up; it is not done here. **Build verification was incomplete in this environment.** `pnpm install` could not finish because `npm.jsr.io` is blocked by network policy (403), so `next build` never gave a real signal. What did run and pass: - `tsc --noEmit` on `apps/www`, with output byte-identical to clean master - ESLint on every changed file — 0 errors - Prettier using the repo's actual config - a direct MDX compile of all 14 `data/legal/**/*.mdx` files using the app's own MDX options The one thing left unverified is webpack resolving `ui-patterns/PrivacySettings` from the privacy content's new directory. CI will confirm that. Co-authored-by: Claude <noreply@anthropic.com> |
||
|
claude[bot]andClaude
|
8a607a6108 |
feat(www): add Enterprise SaaS Subscription Agreement v3 (#48484)
<!-- ccr-slack-attribution --> _Requested by **Nicole Kramer** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1785399555203219)_ ## 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? Content update — a new version of a published legal agreement. ## What is the current behavior? The version selector on `/enterprise-terms` offers two versions of the Enterprise SaaS Subscription Agreement: Version 2 (May 6, 2026) and Version 1 (April 17, 2026). Version 2 is what the page shows by default. ## What is the new behavior? **Before:** opening `/enterprise-terms` showed Version 2 — May 6, 2026. **After:** it shows **Version 3 — August 1, 2026**. Versions 2 and 1 are unchanged and still reachable from the dropdown (`?version=v2`, `?version=v1`). Two files change: - **New** `apps/www/data/legal/enterprise-terms/v3.mdx` — the Version 3 text, transcribed from the source Word document supplied in the Slack thread (`2026.07.29 - Supabase - Enterprise Terms.docx`). - `apps/www/pages/enterprise-terms.tsx` — imports the new MDX and prepends `{ id: 'v3', label: 'Version 3', effectiveDate: 'August 1, 2026', Component: V3 }` to the `versions` array. Since the array is newest-first, v3 becomes the default. ## Additional context ### Transcription fidelity The legal text was not edited, reworded, reordered, or corrected — only re-rendered in the MDX conventions already used by `v1.mdx` and `v2.mdx`. This was verified mechanically rather than by eye: markdown markup was stripped from `v3.mdx` and the result diffed paragraph-by-paragraph against text extracted directly from the source document's OOXML. - **137 paragraphs in the source, 137 in `v3.mdx`, 0 differing.** - 14 top-level sections and 48 subsections, matching the source's heading counts exactly. - All 3 distinct URLs preserved, written as bare URLs per the existing convention in this file family (remark-gfm autolinks them). - Pure ASCII apart from 5 `§` characters in the 48 C.F.R. citations, matching `v1.mdx`/`v2.mdx`. - Prettier clean; no British spellings that would trip the US-locale misspell check. Formatting decisions worth knowing: the source document contains no bold or italic runs at all, but `v1.mdx` and `v2.mdx` both bold defined terms and section numbers, so v3 follows that house style for consistent rendering across the three versions. The source also carries no date or version line of its own; the `_Last Modified: 1 August 2026_` first line is repo convention, matching how every other legal MDX in `apps/www/data/legal/` is written. ### What changed from v2, in the legal text Structure is identical — same 14 sections, same 48 subsection titles. Five substantive prose changes: 1. **Preamble** — the effective date is now "the date of last signature of an Order referencing these terms", replacing v2's unfilled `[Deal.CloseDate]` merge-field placeholder. "Signature block below" becomes "signature block in an Order". 2. **New § 1.4 "Data Processing Addendum"** — defined by reference to `https://supabase.com/legal/customer-resources/data-processing-addendum`, with a carve-out for a separately executed agreement covering the same subject matter. Former § 1.4–1.12 shift to § 1.5–1.13; nothing was removed or reordered. 3. **§ 7.2 Data Processing** replaced — v2's GDPR / UK GDPR / Swiss clause is gone, replaced by a general compliance paragraph that incorporates the Data Processing Addendum into the Agreement. 4. **§ 13.3** cross-reference corrected from Section 10.1 (Mutual) to Section 10.3 (Limited Warranty), which is the clause the refund remedy actually depends on. 5. **§ 14.4 Amendment and Modification** rewritten — v2 required a writing executed by both Parties; v3 gives Supabase a unilateral right to modify by posting a revised version at `https://supabase.com/enterprise-terms`, effective the first day of the following calendar month, or at the start of the next Renewal Subscription Period for Orders with a fixed Subscription Period of 12 months or longer, with non-renewal under § 13.1 as Customer's sole and exclusive remedy. Two things carried over verbatim from the source rather than fixed, since the text must not be edited: § 7.2 is now near-duplicative of § 7.1 (three of its four sentences repeat § 7.1 almost word for word), and "HIPAA" is used in both § 7.1 and § 7.2 without being defined. One pre-existing inconsistency, unrelated to this change: `v2.mdx`'s own first line reads `_Last Modified: 1 May 2026_` while the page lists Version 2's effective date as `May 6, 2026`. Left alone here. ### Overlap with concurrent work Two sibling changes are in flight for the same requester today — one adjusting the new Data Processing Addendum page's dates, one publishing Terms of Service v3. Neither touches these two files, but all three touch the `apps/www/data/legal/` tree, and note that § 1.4 above now links to the DPA page. [#48483](https://github.com/supabase/supabase/pull/48483) removes the `_Last Modified:` first line from every versioned legal MDX, on the principle that the version selector should be the only place a date appears. It is sequenced to land after this PR, and its file list predates `v3.mdx`. A three-way merge of the two branches is clean, but whoever rebases #48483 should add `apps/www/data/legal/enterprise-terms/v3.mdx` to that removal — otherwise v3 keeps a body date after v1 and v2 lose theirs. The `_Last Modified: 1 May 2026` / `May 6, 2026` mismatch on v2 is also handled in #48483 and is deliberately left alone here, so the same line isn't touched by two PRs. Co-authored-by: Claude <noreply@anthropic.com> |
||
|
claude[bot]andClaude
|
44bc7b5a57 |
feat(www): add Terms of Service v3 (effective August 1, 2026) (#48482)
<!-- ccr-slack-attribution --> _Requested by **Nicole Kramer** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1785399344523739)_ ## 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? Content update — adds a new version of the Terms of Service to the marketing site (`apps/www`). ## What is the current behavior? `/terms` offers two versions in the version dropdown: **Version 2 (May 6, 2026)**, shown by default, and **Version 1 (July 11, 2025)**. ## What is the new behavior? `/terms` shows **Version 3 (August 1, 2026)** by default. Version 2 and Version 1 are still selectable from the version dropdown (`/terms?version=v2`, `/terms?version=v1`) and are completely unchanged. Two files: - **New:** `apps/www/data/legal/terms/v3.mdx` — the full v3 Terms of Service. - **Changed:** `apps/www/pages/terms.tsx` — imports `V3` and prepends it to the `versions` array. Newest-first ordering is required, because `LegalDocVersions` treats `versions[0]` as the latest. ## Additional context ### The legal text is a verbatim transcription — please review it as such It comes from a Word document supplied by Legal, converted with pandoc and then verified character-exact against the source: **8055 words, 136 blocks, 0 word-level diffs**. Prettier was run over the file and changed nothing. **Known typos in the source document were deliberately preserved. Please do not correct them in review:** - §1 Definitions contains a **duplicate `d.`** — one `d.` introduces the Data Processing Addendum definition and the very next item is also lettered `d.` for the Documentation definition. The list therefore runs a, b, c, d, d, e … Re-lettering would shift internal cross-references, so it is left exactly as drafted. - §12(d) Survival contains a **doubled “and”** — *and Sections 1, 5, 6, 8, 9, 10, 11, and 13, and 14 survive*. Also preserved verbatim from the source: curly quotes on the Data Processing Addendum definition only (every other defined term uses straight quotes), and non-breaking spaces around the hyperlinks. ### Date The source document carries **no date line of its own**, even though its §14(d) states that the last-modified date *will be updated at the top of this Agreement*. August 1, 2026 was specified by the requester, and is placed in the `_Last Modified: 1 August 2026_` line at the top of the MDX, following the v1/v2 convention. As with v1 and v2, the `.mdx` uses `D Month YYYY` while `effectiveDate` in `terms.tsx` uses US long form (`August 1, 2026`). That split is pre-existing and intentional. ### New DPA link §1 of v3 links the Data Processing Addendum page at `/legal/customer-resources/data-processing-addendum`. This link is new relative to v2, and the DPA is also incorporated by reference in §7(b). ### No overlap with the concurrent DPA branch This PR touches only `apps/www/data/legal/terms/v3.mdx` and `apps/www/pages/terms.tsx` — **zero file overlap** with the branch updating the DPA page dates. ### Reviewer checklist - 14 numbered sections (1 Definitions → 14 Miscellaneous), 44 lettered subsections, 6 roman sub-subsections. - ALL-CAPS acceptance block at the top; ALL-CAPS AI disclaimer at the end of §9(b); ALL-CAPS §11 Limitations of Liability. - Three link targets intact: the DPA page, `https://supabase.com/privacy`, and `mailto:legal@supabase.io` (×3). Co-authored-by: Claude <noreply@anthropic.com> |
||
|
claude[bot]andClaude
|
4db78dfe5f |
chore(www): update DPA effective date to August 1, 2026 (#48481)
<!-- ccr-slack-attribution --> _Requested by **Nicole Kramer** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1785399057853249?thread_ts=1785399057.853249&cid=C0161K73J1J)_ ## 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? Content update — moves the Data Processing Addendum's effective date out by two months. ## What is the current behavior? The DPA page at `/legal/customer-resources/data-processing-addendum` shows "Version 1 — June 1, 2026" in the version selector, and the document body opens with "Last Modified: 1 June 2026". ## What is the new behavior? Both now read August 1, 2026: the version selector shows "Version 1 — August 1, 2026" and the document opens with "Last Modified: 1 August 2026". ## Additional context The page renders a hardcoded `versions` array through the shared `LegalDocVersions` component, so the effective date lives in the TSX file; the "Last Modified" line is simply the first line of the MDX content file. Both were updated, each keeping its file's existing date format (`M D, YYYY` in the TSX, `D Month YYYY` in the MDX). No other content changed. ### Not changed — flagging for confirmation The same June 1, 2026 date appears on a few other surfaces. I left them alone because they are either different documents or point at a dated PDF asset that would need to be re-generated and re-uploaded. Let me know if any of these should move too: - `apps/www/pages/legal/dpa.tsx` — the legacy `/legal/dpa` page, which links `Supabase+DPA+260601.pdf` - `apps/studio/components/interfaces/Organization/Documents/DPA.tsx` — Studio links that same PDF - `apps/www/pages/legal/customer-resources/subprocessor-list.tsx` — the subprocessor list (`June-1-2026.pdf` and a "June 1, 2026" label); a separate document - `apps/www/pages/aup.mdx` — the Acceptable Use Policy, "Last Modified: 1 June 2026"; a separate document Co-authored-by: Claude <noreply@anthropic.com> |
||
|
AnaandAna
|
602aa82855 |
docs(www): add column selection to Postgres Changes feature page (#48455)
## I have read the [CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md) file. YES ## What kind of change does this PR introduce? - Updates the `description` copy of the `realtime-postgres-changes` entry in `apps/www/data/features.tsx` - Documents column selection as a key feature - Clarifies that filters can be applied on one or more columns - Removes a stale closing paragraph and normalizes the `Benefits` heading ## What is the current behavior? The Realtime Postgres Changes feature page lists five key features, does not mention column selection, describes filtering without noting multi-column support, and ends with a summary paragraph that is not part of the approved feature copy. ## What is the new behavior? - Key feature 3 reads "Granular filtering: Apply filters on one or more columns to receive only relevant changes." - New key feature 6 reads "Column selection: Opt in to receive only the columns you choose in the event payload, with the primary key always included." - The `## Benefits:` heading is now `## Benefits` - The closing paragraph "Supabase's Realtime Postgres Changes feature provides a powerful tool for creating responsive, real-time applications while leveraging the full capabilities of your Postgres database." is removed ## Additional context - The Realtime team shipped AND filter composition, expanded filter operators, and column selection on 2026-07-02. Docs were updated on 2026-07-06. - This change brings the feature page in line with the Notion Features Page, which is the source of truth for feature page copy. - Filipe Cabaço (Realtime) approved the content. - `blogUrl` is intentionally not added in this PR. It will follow separately once the launch blog post is live. - Scope is limited to the `realtime-postgres-changes` entry. No other feature entries were touched and the file was not reformatted. `prettier --check` passes on the file. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Documentation** * Updated the “Realtime - Postgres changes” feature documentation with clearer wording for granular filtering and row-level security integration. * Added a new bullet explaining column selection, including primary key inclusion. * Improved formatting in the benefits section and removed outdated closing text. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Ana <ana1337x@users.noreply.github.com> |
||
|
claude[bot]andClaude
|
35b2e82852 |
feat(www): add Data Processing Addendum legal page (#48269)
<!-- ccr-slack-attribution --> _Requested by **Nicole Kramer** · [Slack thread](https://supabase.slack.com/archives/C0161K73J1J/p1784836047880599?thread_ts=1784836047.880599&cid=C0161K73J1J)_ ## What kind of change does this PR introduce? Feature — a new marketing-site legal page. ## What is the current behavior? There is no Data Processing Addendum page under Customer Legal Resources. The only DPA content is a legacy `/legal/dpa` page that links out to a static PDF. ## What is the new behavior? **Before:** no DPA page under Customer Legal Resources; DPA content lived only on the legacy `/legal/dpa` page (static PDF link). **After:** a new DPA page at `/legal/customer-resources/data-processing-addendum`, styled like the Terms of Service page — a version dropdown ready for future versions, a "Last Modified: 1 June 2026" line, and the full DPA text (14 clauses + 3 schedules). A "Data Processing Addendum" link is added to the Legal Hub under Customer Legal Resources, using the same FileText icon as Terms of Service. **How:** - New versioned MDX at `apps/www/data/legal/customer-resources/data-processing-addendum/v1.mdx`. - New page `apps/www/pages/legal/customer-resources/data-processing-addendum.tsx`, modeled on the ToS / integration-partner-addendum pattern and rendering via the shared `LegalDocVersions` component (`versions` entry: `{ id: 'v1', label: 'Version 1', effectiveDate: 'June 1, 2026' }`). - Legal Hub link added in `apps/www/pages/legal/index.tsx` with `type: 'document'`. ## Preview Please review on the Vercel preview deploy. Two URLs to check: - `/legal/customer-resources/data-processing-addendum` - `/legal` ## Notes for reviewers - Content was converted faithfully from the provided .docx (normalized word-content diff: 5678/5678 words, zero missing/extra). The source has no tables. - The legacy `/legal/dpa` page (static PDF link) is left untouched — flag if it should be redirected to the new route or retired. - Typecheck/lint could not be run in the build sandbox due to an unrelated JSR-registry 403 during `pnpm install`; Prettier was run and passes. Please confirm CI (typecheck + lint) is green. ## Additional context Version dropdown is single-version for now and is set up to accept future DPA versions. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --- _Generated by [Claude Code](https://claude.ai/code/session_01JA6SATQGc9J8kApnH2NvCz)_ --------- Co-authored-by: Claude <noreply@anthropic.com> |
||
|
Francesco Sansalvadore
|
7c20cc574c |
feat(www): new changelog sync (#47880)
## What kind of change does this PR introduce? Sync changelog from private supabase/changelog. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Changelog entries now come from the structured changelog repository. * Added filters for change type, product stage, and self-hosted impact. * Updated badge UI for affected products and change types with filter links. * Changelog detail sidebar now shows lifecycle stage, sunset dates, and self-hosted impact (when available). * **Improvements** * Product category discovery and filtering now use affected products. * Discussion links show only when legacy discussion data is present. * RSS feeds and generated changelog markdown now use the updated metadata. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
Riccardo Busetti
|
f19cb09b43 | feat(pipelines): Update product docs and UI copy (#47997) | ||
|
Danny White
|
2279c4e69e |
fix(studio,www): repair Join us on Discord buttons (#47711)
## What kind of change does this PR introduce? Bug fix ## What is the current behavior? The "Join us on Discord" buttons are broken in two places: - **Studio support sidebar** (`HelpPanel`): on light mode the button background is not white, so the intended white button with purple icon and text is broken. - **www `/support` page** (shared `secondary` button variant): the text disappears on hover, and the Discord icon is never rendered (always invisible). Both issues occur on light and dark mode. ## What is the new behavior? - **Studio support sidebar**: force a white background on all colour schemes via `bg-white hover:bg-white/90`, matching the existing pattern in `DiscordCTACard`. The purple icon and text now render correctly on light mode. - **Shared `secondary` button variant** (`packages/ui`): - The icon container used `text-border-muted`, which blended into the `bg-foreground` button, so the icon was invisible. Changed to `text-background` to match the button's text colour. - The hover state used `text-border-stronger`, which had no contrast against the background, so text disappeared on hover. Changed to `text-background/80`. - Removed the ineffective `fill="var(--background-default)"` from `IconDiscord` on the `/support` page — the SVG path uses `currentColor`, so the fill prop had no effect. These `secondary` variant fixes apply globally, so other secondary buttons benefit too. | Before | After | | --- | --- | | <img width="868" height="642" alt="CleanShot 2026-07-07 at 15 39 42@2x" src="https://github.com/user-attachments/assets/6897b6ba-311e-43c7-bb5a-7b70017a54cc" /> | <img width="906" height="610" alt="CleanShot 2026-07-07 at 16 21 31@2x" src="https://github.com/user-attachments/assets/16104cf0-8ed1-4857-8467-532c1f7fdb5f" /> | | <img width="636" height="620" alt="CleanShot 2026-07-07 at 15 24 53@2x" src="https://github.com/user-attachments/assets/75f55f6c-eaa7-45ee-94fe-eac513126eff" /> | <img width="656" height="404" alt="CleanShot 2026-07-07 at 16 24 23@2x" src="https://github.com/user-attachments/assets/35649b23-fcdd-42fd-8140-e4aaf394667e" /> | <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **Style** * Refreshed secondary button styling for a more consistent look, including updated hover and loading text/icon colors. * Improved the “Join us on Discord” button’s background and hover appearance. * Simplified the Discord card’s icon rendering to rely on the default icon styling. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
|
d23f86021a |
feat(www): Partner Catalog update (#46757)
## Info architecture change around "Partners" The www "integrations" now become more partner-driven. `/partners/integrations` -> now Partner Catalog under `/partners/catalog` (old links redirect to new paths) Moved them close together in the nav dropdown and in the footer <img width="494" height="336" alt="Screenshot 2026-07-09 at 11 06 41" src="https://github.com/user-attachments/assets/a875fef0-0ab8-47ca-8756-d658b27c4892" /> <img width="1149" height="665" alt="Screenshot 2026-07-09 at 11 09 48" src="https://github.com/user-attachments/assets/9631bb72-fe25-4fb4-b1af-9f14a37d02e7" /> ## /partners This page remains untouched in this PR, updates to layout, content and intake form are delegated to #47874 ## /partners/catalog Listed in the [catalog](https://zone-www-dot-com-git-feat-www-partners-pages-supabase.vercel.app/partners/catalog) are now partners. Some partners match with a listing. <img width="1207" height="866" alt="Screenshot 2026-07-09 at 11 14 17" src="https://github.com/user-attachments/assets/b65216be-976f-4ef5-91f8-1ad49da87b45" /> ## /partners/catalog/[partner] Each partner can have one or more "listings" which are either - simple guides - foreign data wrappers - dashboard integrations Integrations available in the dashboard now all have a prominent "Install integration" cta to open it in the dashboard [integrations page](https://supabase.com/dashboard/project/_/integrations). <img width="1269" height="776" alt="Screenshot 2026-07-09 at 11 16 51" src="https://github.com/user-attachments/assets/3c7bb715-ffce-4d0a-905f-9a660c3b1f5a" /> ## Docs Update docs → [Preview](https://docs-git-feat-www-partners-pages-supabase.vercel.app/docs/guides/integrations) - remove "Supabase marketplace" - use "Dashboard Integrations and Partner Catalog - update integrations in sidenav to link to updated /partners/catalog/** listings <img width="1520" height="696" alt="Screenshot 2026-07-15 at 12 54 47" src="https://github.com/user-attachments/assets/9f5a2794-4536-4299-97df-9732d3d75b4c" /> <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a Partner Catalog experience with search, category filters, official-partner toggle, responsive filtering (sidebar + bottom sheet), grid/list views, and featured partners. * Added Partner Catalog detail pages with tabbed listings, MDX-rendered content, image gallery with zoom overlay, and “add/install” actions. * **Improvements** * Updated “Become a Partner” layout and form support for prefilled values and checkbox-group fields (including validation). * Updated navigation/footer/docs and partner tile links to use Partner Catalog routes; expanded redirects from legacy integrations paths. * Added public agent-skills discovery manifest. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Alan Daniel <stylesshjs@gmail.com> Co-authored-by: Alex Hall <alex.hall@supabase.io> Co-authored-by: Miranda Limonczenko <miranda.limonczenko@supabase.io> |
||
|
|
949a57d285 |
content(www): update investor logo wall on company page (#47753)
## Summary - Adds 8 new investor logos: Accel, Craft, Figma, Georgian, GIC, Peak XV, Salesforce Ventures, Stripe - Reorders lead investor grid to match design mockup (3 rows of 4) - Adds per-logo `scale` field to control logo size within each cell - Adds `grayscaleOnly` field for Salesforce Ventures to preserve tonal contrast (prevents wordmark from being hidden by `contrast-0` filter) ## Test plan - [ ] Visit /company and verify all 12 investor logos render correctly across 3 rows - [ ] Check logo sizing and order matches the mockup - [ ] Verify Salesforce Ventures wordmark is visible inside the cloud shape - [ ] Check dark mode 🤖 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** * Expanded and reordered the “Our investors” lead cards with additional entries (including Stripe, Salesforce Ventures, and others). * Enhanced logo presentation options for lead cards with per-investor sizing/positioning controls. * **Bug Fixes** * Improved lead investor card image rendering by removing internal scrolling and using an overflow-hidden container with scale-based sizing. * Preserved the existing logo filter behavior (opacity-only when configured, grayscale-only when selected, otherwise the default contrast treatment). <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com> |
||
|
Francesco Sansalvadore
|
532ac3638d |
fix(www): update customer logos from svg to pngs (#47777)
Some customer pages didn't show og-images properly because satori breaks using svgs. This PR replaces all customer logos from svgs to pngs. They're all exported at least 2x to 4x so image quality shouldn't get worse anywhere. <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **Bug Fixes** * Updated several customer story pages and related listings to use PNG logo assets, improving logo rendering consistency across the site. * Refreshed the customer RSS feed metadata and removed a duplicate entry so the feed stays up to date and cleaner. <!-- end of auto-generated comment: release notes by coderabbit.ai --> |
||
|
ShaneandDanny White
|
586ed82270 |
content(www): update company page metrics, investors, and press (#47700)
## Summary - Updated community stats: 10M+ developers, 100K+ GitHub stars, 200K+ followers, 50K+ SupaTroopers - Updated funding copy from \"over \$116 million\" to \"\$1 Billion\" - Added Supabase Series F blog post to Press section - Changed press articles grid from 3-column to 4-column to match podcasts layout - Reduced community stats font size (text-4xl → text-3xl) and added right padding to prevent overlap with dividers <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit ## Summary by CodeRabbit * **Bug Fixes** * Improved spacing and borders in the community stats grid for cleaner end-of-list alignment. * **Style** * Reduced the community stat number size for better readability. * Updated the Press articles layout on large screens to show more items per row. * **Content Updates** * Refreshed community stat counts for Developers, GitHub, Twitter, and Discord. * Updated “Our investors” copy to **$1 billion**. * Added **“Supabase Series F”** as the first Press article. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Danny White <3104761+dnywh@users.noreply.github.com> |
||
|
Francesco SansalvadoreandClaude
|
31509521b6 |
feat(www): add Customer Legal Resources to legal hub and declutter footer (#47655)
## 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 / content update to the Legal Hub (`apps/www`). ## What is the current behavior? The `/legal` hub page (`apps/www/pages/legal/index.tsx`) has a single section, "Partner Legal Resources." The customer-facing legal documents (Terms of Service, Support Policy, Service Level Agreement) are only reachable from the footer "Company" column, which is cluttered. ## What is the new behavior? - Adds a new **"Customer Legal Resources"** section to the `/legal` hub, placed **above** "Partner Legal Resources," with links to: - Terms of Service → `/terms` - Support Policy → `/support-policy` - Service Level Agreement → `/sla` These use the same formatting (document icon + link) as the existing "Master Partner Program Agreement" entry. - Removes those same three links (Terms of Service, Support Policy, Service Level Agreement) from the footer **"Company"** column (`apps/www/data/Footer.ts`) to declutter it. The "Legal" hub link, Privacy Policy, Privacy Settings, and Acceptable Use Policy all remain. The `/terms`, `/support-policy`, and `/sla` URLs are unchanged and continue to operate exactly as they do today — this only changes where they're surfaced in navigation. Note: per discussion, the hidden `/enterprise-terms` page was intentionally **not** linked from the public hub; it remains `noindex/nofollow` and reachable only by direct URL. ## Additional context Visual result (Customer section above Partner section, three matching links) and footer cleanup match the requested design. No routing, redirect, or page-content changes. --- _Generated by [Claude Code](https://claude.ai/code/session_015kQyGkM9s9XEbA3HSLpeku)_ <!-- This is an auto-generated comment: release notes by coderabbit.ai --> ## Summary by CodeRabbit * **New Features** * Added a **“Customer Legal Resources”** section to the legal resources page with links to **Terms of Service**, **Support Policy**, and **Service Level Agreement**. * **UI Updates** * Updated the legal page branding from **“Legal”** to **“Legal Hub”** and adjusted the layout to a more spacious two-column presentation. * Updated the footer **Company** links by replacing **“Legal”** with **“Legal Hub”** and removing the Terms/Support/Service Level links from that set. <!-- end of auto-generated comment: release notes by coderabbit.ai --> --------- Co-authored-by: Claude <noreply@anthropic.com> |
