Feature request: let Postgres call its own Edge Functions on every branch, with no hand-copied URLs or keys

Edge Functions

Database

Branching

CLI

Supabase's own guides for calling an Edge Function from Postgres (Scheduling Edge Functions, Automatic embeddings) all follow one pattern: pg_cron → pg_net → the project URL and a key read from Vault. Every step of that pattern assumes one hand-configured project. With Branching, it breaks down.

1. Postgres cannot learn its own API URL

An Edge Function gets SUPABASE_URL automatically. Postgres gets nothing, so every guide has you paste https://<project-ref>.supabase.co into vault.create_secret(...) by hand (discussion #12813 has asked about this for years).
A preview branch gets a new project ref at creation time, so no value in config.toml or a dotenvx file can name it ahead of time. [remotes.<branch>.db.vault] covers persistent branches only.
Locally, the URL that works from inside Postgres is http://api.supabase.internal:8000, a host the CLI hard-codes and the docs mention only in passing. It differs from the the local functions see.

How to help

Ian Copp requests a feature to allow Postgres to automatically call its own Edge Functions on every branch without manually configuring URLs or keys. The current process involves manual steps that do not scale well with branching. The user suggests improvements such as built-in API URL access, named secret keys in config.toml, and a first-party method to call Edge Functions from SQL.

Help on GitHub

SUPABASE_URL

The workarounds people use are a CI step that calls the Management API after branch creation (which must be created and maintained separately by each Supabase customer), or skipping preview branches entirely.

2. Branching cannot manage a named secret key

The new API keys allow scoped, named secret keys, and @supabase/server's withSupabase({ auth: 'secret:<name>' }) checks for one. That is the right auth for a cron-to-function call.
But config.toml cannot declare a named key, so a branch never gets one. Each key has to be created in the dashboard for each project, then copied into env files and Vault by hand. That does not scale past one or two persistent branches.

3. Getting a key into Vault means copying it in plaintext

A key reaches Vault only by pasting its value into SQL, or through [db.vault] with env() from an env file someone filled in by hand. There is no way to give Postgres a key the platform already knows.
The docs examples show the anon or service key as a literal in the cron SQL, or in a vault.create_secret('<your key>', ...) someone pastes by hand. Followed literally, they put a long-lived key into migration history or the SQL editor log.
The older standard_webhook_* pattern is gone, and nothing with the same zero-config property has replaced it.

What we did instead

A migration generates a random token into Vault, the cron job sends it in a header, and the function reads the same Vault entry back with service-role access and compares the two in constant time. That works on every branch with nothing configured, but every project that wants this pattern has to rebuild it from scratch.

Ask

A built-in way for Postgres to read its own API URL on every branch and locally, e.g. a supabase.api_url setting or function.
Named secret keys declared in config.toml, created per branch and with unique values per branch, and readable from Vault without the value ever appearing in a file.
A first-party way to call your own Edge Function from SQL, authenticated, e.g. net.invoke_function('name', body) or a Vault entry the platform maintains. Then update the guides to use it instead of pasted URLs and keys.