I added the agent-discovery surfaces the www app was missing: a resource
catalog at `/.well-known/ard.json` plus completed structured data on the
homepage. I scoped this from the agent-readiness gaps that are
truthfully closable on the www side; the catalog lists only resources
that already exist and serve 200 (MCP OAuth metadata, Management API
OpenAPI spec, llms.txt, agent-skills index).
**Changed:**
- **Agents can discover our machine-readable resources from one
document**: new static catalog at `/.well-known/ard.json` (Agentic
Resource Discovery format); the legacy `/.well-known/ai-catalog.json`
path serves the same file via rewrite, keeping a single source artifact.
- **Organization JSON-LD carries verifiable company details**: adds
`legalName`, a support `contactPoint`, and the registered address
already public on our Terms of Service.
- **Homepage declares the product as an application entity**: emits
`SoftwareApplication` JSON-LD via the existing
`softwareApplicationSchema` builder, same pattern as the vector module
page.
## To test
Tested on Vercel preview:
- [ ] `curl <preview-url>/.well-known/ard.json`: expect 200 with a JSON
catalog of 5 entries
- [ ] `curl <preview-url>/.well-known/ai-catalog.json`: expect the same
document with status 200 (rewrite, not a redirect)
- [ ] View homepage page source: expect three `application/ld+json`
scripts: Organization now includes `address` and `contactPoint`, and a
`SoftwareApplication` block is present
## Linear
- fixes GROWTH-1164
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Added an Agent Resource Description catalog listing Supabase’s MCP,
API, documentation, and agent skill resources.
- Added support for the legacy AI Catalog URL through a canonical
redirect.
- Enhanced website structured data with software application details,
legal information, support contact details, and business address.
- **Tests**
- Added validation ensuring discoverable `.well-known` resources are
cataloged and resolve correctly.
- **Chores**
- Updated marketing site test coverage for `.well-known` resource
changes.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Agent-readiness scanners and agent fetchers look for an OpenAPI spec at
conventional same-origin paths, but the Management API spec is only
served on api.supabase.com and linked from the /.well-known/api-catalog
linkset, which scanners do not read. I added a rewrite so
supabase.com/openapi.json proxies the spec from its source of truth at
api.supabase.com/api/v1-json, using the same fall-through proxy
mechanism as /humans.txt and /evals.
**Note:** no cache or CORS headers on purpose: no consumer needs them
today, and the upstream response's set-cookie header defeats edge
caching regardless. I rejected a checked-in copy of the spec in favor of
proxying live (staleness). The /.well-known/api-catalog linkset already
points at the spec (PR #44880) and is untouched here; this PR only adds
the conventional same-origin path.
**Merge order:** merge only after supabase/platform#37571 deploys. The
spec currently ships `servers: []`, so OpenAPI consumers resolve
relative paths against the fetch origin; without the platform fix this
proxy would point spec-compliant clients at supabase.com/v1/*.
## To test
Tested on Vercel preview:
- [x] `curl -s https://<preview-url>/openapi.json | head -c 40` returns
`{"openapi":"3.0.0"`
- [x] `curl -sI https://<preview-url>/openapi.json` returns 200 with
`content-type: application/json`
- [x] `curl -sI https://<preview-url>/humans.txt` returns 200 (control:
rewrite fall-through chain intact)
## Linear
- fixes GROWTH-1138
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added access to the OpenAPI specification at `/openapi.json`.
* Requests are automatically routed to the API specification endpoint.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Aleksi Immonen <aleksi@supabase.io>
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 -->
## Changes
Proxies `supabase.com/evals` to the
[evals](https://github.com/supabase/evals) frontend, following a similar
rewrite pattern as `/ui` and `/design-system`. The evals app already
serves under an `/evals` base path per supabase/evals#125.
The destination is hardcoded rather than an env var because the evals
app lives in a separate repo, and there’s not much benefit to a fully
local dev flow here, so the target URL is kept the same in every
environment.
## Before merge
- Disable deployment protection on the evals Vercel project, otherwise
`supabase.com/evals` will show a Vercel login page
- Wait until closer to Evals announcement target (July 30th)
Closes AI-826
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added routing for the `/evals` section and its subpages.
* Evals pages now load from the designated hosted destination while
preserving URL paths.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
The docs build had a fragile implicit dependency on www's filesystem
(`../../../apps/www/public/llms`), flagged by the docs team in #44670.
Rather than formalising that dependency with a shared package, this PR
eliminates it entirely by making www the sole owner of llms content
assembly.
**How it works now:**
`/llms/[slug]` handles all `/llms/*.txt` requests via a 3-step cascade:
1. Dynamic content — `pricing.txt` generated at request time from
`shared-data` imports
2. Local file — product overviews read from `data/llms/`
3. Docs proxy — reference docs (guides, js, dart, etc.) fetched from the
docs app
No hardcoded slug lists, so adding new content just works.
**What changed:**
- `apps/docs/scripts/llms.ts` trimmed to only generate per-source
reference files — www now owns `llms.txt`, `llms-full.txt`, and product
overviews
- Removed `generateLlmsPricing.mjs` build script — pricing generated
dynamically from `shared-data`
- Removed llms rewrites from `rewrites.js` — routes handle everything
with consistent `Cache-Control: public, s-maxage=3600,
stale-while-revalidate=86400`
- Product overview `.txt` files moved from `public/llms/` → `data/llms/`
so all requests go through routes for consistent caching
**Docs team concerns from GROWTH-773:**
| Concern | Resolution |
|---------|-----------|
| Docs build depends on www files at a fragile relative path | Path
removed — docs no longer reads from www |
| www restructuring breaks docs with no obvious connection | Eliminated
— no cross-app filesystem dependency |
| No build order enforcement between www and docs | Not needed — docs
doesn't depend on www's build output |
## To test
- `curl <preview>/llms.txt` — markdown index with doc + product overview
links
- `curl <preview>/llms-full.txt` — combined product overviews + docs
content
- `curl <preview>/llms/pricing.txt` — dynamically generated pricing
tables
- `curl <preview>/llms/auth.txt` — product overview from local file
- `curl <preview>/llms/guides.txt` — proxied from docs app
- `curl <preview>/llms/nonexistent.txt` — 404
- Verify `Cache-Control` header on all responses
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
Preview sites are being crawled because the rewrite causes the docs production
content (which naturally has `index, follow`) to be served under the www
preview domain. We shouldn’t be rewriting in any environment except production.
* feat: llms.txt
* feat: split llms.txt into multiple files
We have too many docs, so the concatenated text file uses an unreasonable amount of tokens. Chunk it up a little so it's more usable.
Jeremias Menichelli