docs(functions): tighten the voice in the secrets guide (#50418)

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.
This commit is contained in:
Miranda Limonczenko authored and GitHub committed 2026-09-18 13:45:30 -07:00
1 parent f69195f9df
commit 82e9f6fb0e
1 file changed
+27 -43
+27 -43
View File
@@ -10,27 +10,27 @@ subtitle: 'Manage sensitive data securely across environments.'
Edge Functions have access to these secrets by default:
- `SUPABASE_URL`: The API gateway for your Supabase project
- `SUPABASE_DB_URL`: The URL for your Postgres database. You can use this to connect directly to your database
- `SUPABASE_DB_URL`: The URL for your Postgres database. Use it to connect directly to your database
- `SUPABASE_PUBLISHABLE_KEYS`: The `publishable` keys JSON dictionary for your Supabase API. This is safe to use in a browser when you have Row Level Security enabled
- `SUPABASE_SECRET_KEYS`: The `secret` keys JSON dictionary for your Supabase API. This is safe to use in Edge Functions, but it should NEVER be used in a browser. This key will bypass Row Level Security
- `SUPABASE_SECRET_KEYS`: The `secret` keys JSON dictionary for your Supabase API. This is safe to use in Edge Functions, but **never** use it in a browser. These keys bypass Row Level Security
- `SUPABASE_JWKS`: The JSON Web Key Set used to verify user JWTs. Same value served at `https://<project-ref>.supabase.co/auth/v1/.well-known/jwks.json`
Legacy keys:
- `SUPABASE_ANON_KEY`: The `anon` key for your Supabase API. This is safe to use in a browser when you have Row Level Security enabled
- `SUPABASE_SERVICE_ROLE_KEY`: The `service_role` key for your Supabase API. This is safe to use in Edge Functions, but it should NEVER be used in a browser. This key will bypass Row Level Security
- `SUPABASE_SERVICE_ROLE_KEY`: The `service_role` key for your Supabase API. This is safe to use in Edge Functions, but **never** use it in a browser. This key bypasses Row Level Security
In a hosted environment, functions have access to the following environment variables:
- `SB_REGION`: The region function was invoked
- `SB_EXECUTION_ID`: A UUID of function instance ([isolate](/docs/guides/functions/architecture#4-execution-mechanics-fast-and-isolated))
- `DENO_DEPLOYMENT_ID`: Version of the function code (`{project_ref}_{function_id}_{version}`)
- `SB_REGION`: The region the function was invoked in
- `SB_EXECUTION_ID`: A UUID for the function instance, or [isolate](/docs/guides/functions/architecture#4-execution-mechanics-fast-and-isolated)
- `DENO_DEPLOYMENT_ID`: The version of the function code, formatted as `{project_ref}_{function_id}_{version}`
---
## Accessing environment variables
You can access environment variables using Deno's built-in handler, and passing it the name of the environment variable you’d like to access.
Access an environment variable with Deno's built-in handler, passing the name of the variable you want.
```js
Deno.env.get('NAME_OF_SECRET')
@@ -46,7 +46,7 @@ const SUPABASE_PUBLISHABLE_KEYS = JSON.parse(Deno.env.get('SUPABASE_PUBLISHABLE_
// For user-facing operations (respects RLS)
const supabase = createClient(
Deno.env.get('SUPABASE_URL')!,
// If you want to use a different api key, change 'default' to your preferred key name
// To use a different API key, change 'default' to your preferred key name
SUPABASE_PUBLISHABLE_KEYS['default']
)
@@ -54,7 +54,7 @@ const SUPABASE_SECRET_KEYS = JSON.parse(Deno.env.get('SUPABASE_SECRET_KEYS')!)
// For admin operations (bypasses RLS)
const supabaseAdmin = createClient(
Deno.env.get('SUPABASE_URL')!,
// If you want to use a different api key, change 'default' to your preferred key name
// To use a different API key, change 'default' to your preferred key name
SUPABASE_SECRET_KEYS['default']
)
```
@@ -63,10 +63,10 @@ const supabaseAdmin = createClient(
### Local secrets
In development, you can load environment variables in two ways:
In development, load environment variables from a file:
1. Through an `.env` file placed at `supabase/functions/.env`, which is automatically loaded on `supabase start`
2. Through the `--env-file` option for `supabase functions serve`. This allows you to use custom file names like `.env.local` to distinguish between different environments.
- An `.env` file at `supabase/functions/.env`, which is automatically loaded on `supabase start`
- A file you name yourself, such as `.env.local`, passed to `supabase functions serve` with the `--env-file` option
```bash
supabase functions serve --env-file .env.local
@@ -74,82 +74,67 @@ supabase functions serve --env-file .env.local
<Admonition type="caution">
Never check your `.env` files into Git! Instead, add the path to this file to your `.gitignore`.
A `.env` file committed to Git exposes every secret in it to anyone who can read the repository. Add the file to your `.gitignore` before you commit.
</Admonition>
We can automatically access the secrets in our Edge Functions through Deno’s handler
Your function reads the secret through Deno's handler:
```tsx
const secretKey = Deno.env.get('STRIPE_SECRET_KEY')
```
Now we can invoke our function locally. If you're using the default `.env` file at `supabase/functions/.env`, it's automatically loaded:
Serve the function locally:
```bash
supabase functions serve hello-world
```
Or you can specify a custom `.env` file with the `--env-file` flag:
```bash
supabase functions serve hello-world --env-file .env.local
```
This is useful for managing different environments (development, staging, etc.).
---
### Production secrets
You will also need to set secrets for your production Edge Functions. You can do this via the Dashboard or using the CLI.
Set secrets for your production Edge Functions in the Dashboard or with the CLI.
**Using the Dashboard**:
1. Visit [Edge Function Secrets Management](/dashboard/project/_/functions/secrets) page in your Dashboard.
2. Add the Key and Value for your secret and press Save
1. Open [Edge Function Secrets](/dashboard/project/_/functions/secrets) in the Dashboard.
2. Enter the **Key** and **Value** for your secret, then click **Save**.
<Image
alt="Edge Functions Secrets Management"
alt="The Edge Function Secrets page in the Supabase Dashboard. An Add new secrets card holds a Key field hinting e.g. CLIENT_KEY and a Value field with a reveal toggle and a remove button, above an Add another button and a Save button."
src={{
light: '/docs/img/edge-functions-secrets--light.jpg',
dark: '/docs/img/edge-functions-secrets.jpg',
}}
width={3757}
height={1525}
width={3757}
height={1525}
/>
Note that you can paste multiple secrets at a time.
You can paste multiple secrets at once.
**Using the CLI**
You can create a `.env` file to help deploy your secrets to production
Create a `.env` file with the secrets you want to deploy. Add it to your `.gitignore` before you commit.
```bash
# .env
STRIPE_SECRET_KEY=sk_live_...
```
<Admonition type="caution">
Never check your `.env` files into Git! Instead, add the path to this file to your `.gitignore`.
</Admonition>
You can push all the secrets from the `.env` file to your remote project using `supabase secrets set`. This makes the environment visible in the dashboard as well.
Push every secret in the file to your remote project with `supabase secrets set`, which also makes them visible in the Dashboard.
```bash
supabase secrets set --env-file .env
```
Alternatively, this command also allows you to set production secrets individually rather than storing them in a `.env` file.
This command also sets production secrets individually, without a `.env` file.
```bash
supabase secrets set STRIPE_SECRET_KEY=sk_live_...
```
To see all the secrets which you have set remotely, you can use `supabase secrets list`
To see the secrets you have set remotely, use `supabase secrets list`.
```bash
supabase secrets list
@@ -157,7 +142,6 @@ supabase secrets list
<Admonition type="note">
You don't need to re-deploy after setting your secrets. They're available immediately in your
functions.
Secrets are available in your functions immediately. You don't need to redeploy after setting them.
</Admonition>