## Problem
As part of my investigation of this
[issue](https://linear.app/supabase/issue/AI-1263/test-byo-mcp-with-custom-domains)
I realized that, in order for byo-mcp to work with custom domains,
there's a tweak needed, and I'm documenting it here.
The long term use to fix it lives
[here](https://linear.app/supabase/issue/FDBKIN-20212/use-custom-domain-in-oidc-and-oauth-well-known-discovery-endpoints).
With that one in place, we could remove the clarification and the
experience would be much much simpler.
Fixes AI-1263
## Solution
I'm documenting for now, and will follow up if something else needs a
change.
## Review instructions
Provide a clear numbered procedure that the PR reviewer can walk
through.
1. Visit `docs/guides/ai-tools/byo-mcp` and read the added text.
2. See if it all makes sense.
3. Ask @raulb if something's not clear or confusing.
## Checklist
Check all before review:
- [x] I have read
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
- [x] If I wrote a new docs topic or edited an existing topic, I used
the `/write-the-docs` or `/edit-the-docs` skill, which applies the docs
[style
guide](https://github.com/supabase/supabase/tree/master/apps/docs/style-guide)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added guidance for configuring MCP authorization metadata with a
custom domain, including setting the authorization server to the
Supabase Auth project issuer and checking it against the advertised
metadata.
* Clarified that the resource URL continues to use the domain requested
by the client, and that leaving the issuer setting unset locally retains
the default.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
## 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?
Fixes AI-1009
Updates the BYO-MCP guide so it includes information about the new
middleware that will let users authenticate much more easily when
building their own MCP server. This one includes a couple of
clarifications which are important to document (use of environment
variables, etc.)
## What is the new behavior?
- Updated the existing guide (and example) for deploying an MCP server
to use `@modelcontextprotocol/server` v2 with `createMcpHandler`.
- Added new bits related to the new middleware which helps with
authentication specifying the required versions of supabase/server and
supabase/middleware, and also the auth prerequisites
- Includes a table of where each MCP client takes the URL.
- Added a new example to
`examples/edge-functions/supabase/functions/mcp/` to illustrate the
authentication example `authenticated-mcp-server`.
## Publish order
> [!IMPORTANT]
> There will be a companion PR to include the library components so this
PR is blocked until https://github.com/supabase/supabase/pull/49579
ships.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added comprehensive guidance for deploying authenticated MCP servers
with OAuth 2.1, Supabase Auth, and user-scoped data access.
* Added an authenticated MCP server example with `list_todos` and
`create_todo` tools, protected by row-level security.
* Added setup instructions for OAuth configuration, consent screens,
local testing, and deployment.
* **Documentation**
* Updated authentication guidance and MCP security warnings across
related guides.
* Added links to MCP server and OAuth consent resources.
* **Refactor**
* Simplified the unauthenticated MCP server example and updated its
tooling configuration.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Feature (self-hosted Edge Functions)
## What is the current behavior?
The self-hosted Edge Functions router
(`docker/volumes/functions/main/index.ts`) doesn't tell a function which
slug a request resolved to. As a result, `@supabase/server`'s
`withOAuthProtectedResource` can't derive its canonical resource URL and
falls back to reconstructing it from the request path against the
internal `api-gw` origin, so the advertised OAuth Protected Resource is
/wrong for self-hosted deployments.
## What is the new behavior?
`main/index.ts` now injects `SUPABASE_FUNCTION_SLUG: service_name` per
request (after the `Deno.env.toObject()` snapshot, so nothing in the
container env can shadow it).
Combined with the operator's `SUPABASE_PUBLIC_URL`, the advertised
resource is the correct external
`{SUPABASE_PUBLIC_URL}/functions/v1/{slug}`, not the internal
`http://api-gw:8000`.
Verified on the docker stack: the slug is injected per-function, the
resource origin resolves to `SUPABASE_PUBLIC_URL`, and the `401`
`www-authenticate` carries the right `resource_metadata`.
## Additional context
Fixes AI-1128
Companion to `@supabase/server` [PR
#117](https://github.com/supabase/server/pull/117) and the [CLI slug
injection](https://github.com/supabase/cli/pull/6345)
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Edge workers now receive the correct function slug in their runtime
environment, improving per-function request handling.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Adds regression tests for something we noticed today. AI skills weren't
being loaded on https://supabase.com/docs/guides/ai-tools/ai-skills, so
while we fixed it, we wanted to make sure we could identify this faster.
## What is the current behavior?
Less tests. AI skills loading and not
## What is the new behavior?
Two tests, no new workflows — both ride existing CI:
- **Unit test** (`AiSkills.utils.test.ts`) mocks GitHub, checks the
parsing/shaping logic (dir filtering, frontmatter, install command,
sorting, empty→fallback). Runs on every PR.
- **Smoke test** (`AiSkillsIndex.smoke.test.ts`) hits the live page and
asserts the skills table actually rendered. Runs in the daily docs smoke
job, and can be pointed at any environment via `DOCS_SMOKE_URL`.
Small supporting change: `getAiSkillsImpl` is now exported so the unit
test can call it directly.
## Additional Context
- Fixes
https://linear.app/supabase/issue/AI-915/skills-docs-page-fails-to-load-available-skills
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Tests**
* Added coverage for AI Skills loading, including directory filtering,
metadata parsing, install command generation, fallback descriptions, and
error handling.
* Added a smoke test confirming the AI Skills documentation page loads
successfully and displays install commands.
* **Refactor**
* Made AI Skills loading functionality accessible for direct testing
while preserving existing behavior.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Refactor based on https://github.com/supabase/platform/pull/31325
## What is the current behavior?
We presented a page to Stripe users to let them either pick an existing
org or create one.
## What is the new behavior?
We're forcing them to create a new one (or show that there was one
already linked).
- It also adds the option to sign out when there's a conflict. Fixes
https://linear.app/supabase/issue/API-963/add-a-button-to-logout-from-the-page-you-must-be-logged-in-as-x-to
- And adds the link to root from the logo.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added organization preview creation endpoint for billing workflows.
* **Bug Fixes**
* Removed organization-picking flow from Stripe Projects login; users
now proceed directly with confirmation.
* Added a "Sign out" button on error pages.
* **Refactor**
* Removed a legacy billing partner option.
* Made the Supabase logo clickable for quick navigation.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Ivan Vasilov <vasilov.ivan@gmail.com>
* refactor: infra queries to use `attributes`
This PR refactors the infrastructure monitoring query code reducing duplication and unifying the API request to always be `attributes`:
• Removed the separate useInfraMonitoringQuery hook and getInfraMonitoring function that handled a single monitoring query
• Consolidated all infrastructure monitoring queries into a unified useInfraMonitoringAttributesQuery hook that handles multi-attribute requests
• Moved interval selection logic from the query layer to the consumer (InfrastructureActivity.tsx), where it can be computed dynamically based on user-selected date ranges
• Simplified query types by removing intermediate InfraMonitoringData and InfraMonitoringVariables types
• Interval is now computed in the component (defaults to 1d, switches to 1h for date ranges ≤48 hours) rather than hardcoded in the query layer
• All queries now use the unified multi-attribute endpoint with explicit parameter passing
* fix: handle single-attribute response format
