## 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?
Bug fix - config hardening
## What is the current behavior?
CORS is applied at the global level in a permissive mode
## What is the new behavior?
Self-hosted envoy config should apply CORS to the `/pg` routes. These
should only be called from the studio dashboard (when called via a
browser).
uses `SUPABASE_PUBLIC_URL`, which should mean this isn't a breaking
change.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Security & Access**
* Added stricter CORS controls for the `/pg/` route.
* Requests are limited to the configured public URL and localhost
origins.
* Standard HTTP methods and headers are supported, with preflight
responses cached for one hour.
* **Documentation**
* Updated self-hosting guidance to describe the `/pg/` route’s CORS
policy.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Updates the self-host Edge Functions template to use `@supabase/server`,
matching the CLI's `supabase functions new` templates (part of SDK-1150,
follows up on #45635 which exposed `SUPABASE_JWKS` to the functions
container). The `hello` example function now wraps its handler in
`withSupabase({ auth: 'none' })` and resolves the package through a
per-function `deno.json` import map, which the runtime auto-discovers,
so no dispatcher changes are needed. The self-hosted functions guide is
updated to match: the create-a-function snippet, a `ctx.supabaseAdmin`
example replacing the manual esm.sh `createClient` wiring, and a note
that `auth: 'user'` requires `SUPABASE_JWKS`. Verified on
`supabase/edge-runtime:v1.74.0` with the compose environment variables:
`curl /functions/v1/hello` returns the same response body as before, so
existing docs and troubleshooting pages stay accurate.
The `docker/.gitignore` change: `volumes/functions/**` ignores
self-hosters' own functions, but it also hid the new `deno.json`, which
must ship with the repo for the `hello` import to resolve. The allowlist
entries follow the existing `main/index.ts` pattern.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Edge Functions now support authenticated invocation with publishable
or secret API keys.
* Function handlers can access authenticated and administrative Supabase
clients through the request context.
* Added automatic environment configuration and JWT verification
support.
* **Documentation**
* Updated the self-hosting guide with the new function setup and
authentication workflow.
* Improved local function examples for supported access patterns and
privileged operations.
* **Tests**
* Updated self-hosted smoke tests to validate publishable-key function
access.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Kalleby Santos <kalleby_santos@hotmail.com>
Co-authored-by: Kalleby Santos <105971119+kallebysantos@users.noreply.github.com>
The Supabase MCP repo transferred from `supabase-community/supabase-mcp`
-> `supabase/mcp`. This updates links on docs and www to point to the
new location: https://github.com/supabase/mcp
The main one needing this change is the MCP docs page at `mcp.mdx`:
https://supabase.com/mcp
I also updated links in the changelog / blog for good measure, though I
can remove those changes if desired since the old URL redirects to the
new location.
Related: https://github.com/supabase/mcp/pull/295
Ref: AI-792
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Updated Supabase MCP server repository references across all
documentation guides, blog articles, changelog entries, and supporting
materials to direct users to the current official location.
* Refreshed documentation links including feature groups, setup
instructions, abilities documentation, and GitHub issue tracking URLs
for consistency.
* Updated MCP server release links in changelog.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Vaibhav