Five reports on this page, four of them the same confusion: which .env file
does what.
Where local values come from is a new section listing the files that feed a
local environment: supabase/functions/.env, a file you name yourself, the root
.env that config.toml reads through env(), and [edge_runtime.secrets]. It says
a value in one is not a value in the other. That is what CLI-818 asked for in
as many words, the duplication FDBKIN-11884 complains about, and the config
route FDBKIN-12716 raises. It sits with the other reference section rather than
inside the local procedure, because it answers what the parts are rather than
how to do something.
Accessing environment variables splits into an Edge Function and a Deno script
you run yourself, where neither env file applies. Deno.env.get needs
--allow-env, so both commands pass it; without the flag the script prompts, and
fails outright when nothing is there to answer. FDBKIN-7937.
Production secrets now states who can set one, and the reserved prefix.
Also calls Deno.env.get a method rather than a handler, which is what it is.
The wording came in with the style pass at the bottom of the stack; fixing it
here avoids restacking four branches for one word.
Two claims from the source reports are deliberately not here.
FDBKIN-34962 reports that adding a secret requires OWNER. The access control
matrix in guides/platform/access-control.mdx says Owner or Administrator can
create and delete, and Developer can view. The reporter found their version by
external searching, so the page states what our own matrix says.
supabase/agent-skills#452 reports that a secret value cannot be recovered after
saving. SecretResponse_Output in the Management API spec returns value as a
required field, and the Dashboard renders it, so that does not hold up from
what I can check here. Left out rather than guessed at; the issue stays open.
The reserved prefix is not a third-party host restriction as
supabase/agent-skills#553 frames it. CreateSecretBody carries
pattern ^(?!SUPABASE_).*, AddNewSecretForm.tsx:42 rejects the same, and the CLI
filters SUPABASE_-prefixed names out of the local function environment. It is
ours, and the page says so.
The Managing secrets guide is the only place that tells you where a local
secret has to sit for the Edge Function runtime to load it. Neither the
supabase agent skill nor Supacademy covers it.
The page named supabase/functions/.env once, in prose, and never had the reader
create it. The eval in supabase/evals#285 reproduces what that produces: across
three runs on codex-gpt-5.6-luna-no-skills, every run built a function reading
its key from the environment, started the stack, and answered missing_api_key.
Two of the three wrote supabase/functions/.env.example and stopped, which is a
template with the variable name in it rather than the file the runtime reads.
Local secrets is now a five-step procedure that creates the file with a working
value, ignores it, creates the function that reads the key, starts the stack,
and calls the function to confirm. That last step is the one that tells the
reader whether it worked. The function is created before the stack starts, so a
reader following the steps literally from a fresh project has something to call.
The gitignore instruction moved out of its admonition and into step 2, carrying
its consequence with it. It's an instruction the reader has to follow, so it
belongs in the procedure rather than beside it.
Recovery for a variable the function can't see gets its own section rather than
trailing the procedure. "I set it and the function cannot read it" is the most
repeated shape in the feedback on this page, and as loose sentences mid-section
it had no entry in the table of contents.
Moves and heading levels only. No claims changed.
Studio renders a Docs button at
apps/studio/pages/project/[ref]/functions/secrets.tsx:43 pointing at
#using-the-cli, but "Using the CLI" was bold text rather than a heading, so the
anchor had no target and the button dropped the reader at the top of the page.
It and "Using the Dashboard" are now real headings, which repairs it.
Local secrets and Production secrets were h3 under "Accessing environment
variables", but neither is about accessing one. Both are now h2 siblings, and
the reference list moved to the end, so the page runs procedures first and facts
last.
Sections are ordered by what the reader is doing, not by subject: set a secret
locally, read it in code, then set it in production. "Accessing environment
variables" sat after production, which put the reading step after the shipping
step.
Local secrets held a two-item list of the loading mechanisms, which is a fact
sitting inside a procedure. It is now the section's opening sentence, where a
one-line fact can qualify the procedure without interrupting it.
Every existing heading text is unchanged, so #default-secrets, #local-secrets,
#production-secrets and #accessing-environment-variables all still resolve.
Added a value statement opener, and an outcome after the production procedure.
No intro outline: the page is short and its headings already scan.
The frontmatter title was title case. Renaming it to sentence case moves a
navigation label and a search entry, so the nav entry and the three pages that
used the old title as link text change with it. The slug is untouched.
Style only. No heading moves and no claim changes.
The page carried the same caution admonition twice, word for word, and
explained the local .env loading rules twice more: once as a list of the two
mechanisms, then again as a pair of serve commands with the same prose around
them. Both copies are gone, along with the trailing line about managing
different environments that restated the --env-file bullet.
The rest is voice. First person became second, future tense became present,
and "allows you to" became a sentence with the reader as its subject. SB_REGION
and SB_EXECUTION_ID had lost words. The two NEVER shouts became bold, per the
emphasis rule.
The alt text named the topic the heading already names. It now describes the
Key and Value fields, the reveal and remove controls, and the Add another and
Save buttons, which is what a reader who can't see the screenshot needs.
Dropped the item count ahead of the local loading list, and made that list
unordered, because the two mechanisms are alternatives rather than steps.
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Replaced legacy "Anon"/"Service Role" key terminology with
"Publishable Keys" and "Secret Keys" across Edge Functions guides
* Updated authentication examples and request headers (client-side vs
server-side) to reflect publishable/secret key usage
* Standardized environment-variable examples to use parsed secret-key
maps with a selectable default
* Removed guidance for bypassing JWT verification via the deprecated CLI
flag
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Kalleby Santos <kalleby_santos@hotmail.com>
## Summary
- Add `SUPABASE_JWKS` to the default secrets list, noting it matches the
public JWKS endpoint
- Update the example in "Accessing environment variables" to use
`SUPABASE_PUBLISHABLE_KEYS` / `SUPABASE_SECRET_KEYS` (matches the
pattern in `functions/auth.mdx`)
- Add an inline note that `'default'` can be swapped for another key
name
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
* **Documentation**
* Updated Edge Functions secrets guide with improved code examples.
* Introduced `SUPABASE_JWKS` environment variable for JWT verification.
* Enhanced examples demonstrating environment variable configuration and
Supabase client initialization.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
docs update
## What is the current behavior?
Functions default secrets page doesn't mention new api keys secrets
## What is the new behavior?
Adding the new api keys secrets
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Documentation
* Updated Edge Functions secrets guide with newly documented environment
variables including `SUPABASE_DB_URL`, `SUPABASE_PUBLISHABLE_KEYS`, and
`SUPABASE_SECRET_KEYS` with usage guidance.
* Reorganized secrets documentation for improved clarity.
<!-- 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?
New Go landing page for the upcoming Bolt webinar. This is where we will
direct customers who want to learn more to go to request a meeting.
---------
Co-authored-by: Alan Daniel <stylesshjs@gmail.com>
* fix: rewrite relative URLs when syncing to GitHub discussion
Relative URLs back to supabse.com won't work in GitHub discussions, so
rewrite them back to absolute URLs starting with https://supabase.com
* fix: replace all supabase urls with relative urls
* chore: add linting for relative urls
* chore: bump linter version
* Prettier
---------
Co-authored-by: Chris Chinchilla <chris.ward@supabase.io>
Miranda Limonczenko