diff --git a/apps/docs/content/guides/functions/secrets.mdx b/apps/docs/content/guides/functions/secrets.mdx index fc6afbae61d..ad4fb4e7437 100644 --- a/apps/docs/content/guides/functions/secrets.mdx +++ b/apps/docs/content/guides/functions/secrets.mdx @@ -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://.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 -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. -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**. Edge Functions Secrets Management -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_... ``` - - -Never check your `.env` files into Git! Instead, add the path to this file to your `.gitignore`. - - - -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 -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.