mirror of
https://github.com/supabase/supabase.git
synced 2026-10-05 09:25:06 +03:00
claude[bot]andClaude
89a5d03817
<!-- ccr-slack-attribution --> _Requested by **Kalleby Santos** · [Slack thread](https://supabase.slack.com/archives/C02KMRX22NR/p1785871243937099?thread_ts=1785871243.937099&cid=C02KMRX22NR)_ ## 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 — one-line content fix. ## What is the current behavior? The [Regional Invocations](https://supabase.com/docs/guides/functions/regional-invocation) page's "Available regions" section lists every Edge Functions region **except `eu-central-2`** (AWS Europe, Zurich). The region has been live in production for a while, but it was never added to the docs. A user reading this page to pick a region for `x-region` / `FunctionRegion` had no way to know Zurich was an option — the page reads as an exhaustive list, so the omission actively implies the region doesn't exist. Reported by Kalleby Santos (Edge Functions team). Linear: [FUNC-761 — Add eu-central-2 to regional invocation docs page](https://linear.app/supabase/issue/FUNC-761/add-eu-central-2-to-regional-invocation-docs-page) ## What is the new behavior? **Before:** the Europe group listed `eu-central-1`, `eu-west-1`, `eu-west-2`, `eu-west-3`. **After:** `eu-central-2` (Zurich) is listed alongside the others, so the page reflects the regions Edge Functions actually serves. ### How One line added to `apps/docs/content/guides/functions/regional-invocation.mdx`, in the **Europe** group directly after `eu-central-1`, following the list's existing sort-by-region-code order and the surrounding `` `code` (Short location) `` label style: ```diff **Europe:** - `eu-central-1` (Frankfurt) +- `eu-central-2` (Zurich) - `eu-west-1` (Ireland) - `eu-west-2` (London) - `eu-west-3` (Paris) ``` No other files changed. This page's region list is hand-maintained in the MDX and is deliberately narrower than the project-creation region list in `packages/shared-data/regions.ts` (which also includes `us-east-2` and `eu-north-1`), so no shared constant needed updating and no other product's region list was touched. ## Additional context **Verification that `eu-central-2` is a real Edge Functions invocation region** — confirmed in three independent places: 1. `supabase/platform` → `pulumi/edge-runtime/Pulumi.prod.yaml:533` — `region: eu-central-2`, with `enabled: true` at `:531`. A fully provisioned prod region (360–540 always-on tasks), not a placeholder. Branch `develop`, HEAD `1f44167768f951c0c794313006bc2c9f9758c344`. 2. `supabase/platform` → `pulumi/edge-runtime-next/stack-config/Pulumi.prod.aws.euc2.yaml:6` — `aws:region: eu-central-2` under the `Edge-Functions/K8s-Prod` environment, tagged `product: functions`. 3. `supabase/api-gateway` → `customer-router/wrangler.toml` — `eu-central-2` is present in the `EDGE_FUNCTIONS_REGIONAL_ORIGINS` map (`eu-central-2 = "https://eu-central-2.edge-runtime.supabase.green"`). This is the table that resolves the `x-region` header, so regional invocation into Zurich is genuinely routable — not just deployed. **For a reviewer to confirm separately (intentionally not in this diff):** production infra has 16 enabled Edge Functions regions, so `us-east-2` (Ohio, `pulumi/edge-runtime/Pulumi.prod.yaml:507`, `enabled: true`) is *also* missing from this page. It's excluded here because we don't yet know whether that omission is deliberate; it's being confirmed with the team and can be a follow-up. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_017UJhSvVpPfYNaHZ8Y1x3sy --- _Generated by [Claude Code](https://claude.ai/code/session_017UJhSvVpPfYNaHZ8Y1x3sy)_ Co-authored-by: Claude <noreply@anthropic.com>
Reference Docs
Supabase Reference Docs
Maintainers
If you are a maintainer of any tools in the Supabase ecosystem, you can use this site to provide documentation for the tools & libraries that you maintain.
DocSpec
We use documentation specifications which can be used to generate human-readable docs.
- OpenAPI: for documenting API endpoints.
- SDKSpec (custom to Supabase): for SDKs and client libraries.
- ConfigSpec (custom to Supabase): for configuration options.
- CLISpec (custom to Supabase): for CLI commands and usage.
The benefit of using custom specifications is that we can generate many other types from a strict schema (eg, HTML and manpages). It also means that we can switch to any documentation system we want. On this site we use Next.js, but on Supabase's official website, we use a custom React site and expose only a subset of the available API for each tool.
Contributing
To contribute to docs, see the developers' guide and contributing guide.