Managing Environment Variables

Managing secrets and environment variables.

It's common that you will need to use sensitive information or environment-specific variables inside your Edge Functions. You can access these using Deno's built-in handler

Default secrets#

Edge Functions have access to these secrets by default:

• SUPABASE_URL: The API gateway for your Supabase project.
• 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_DB_URL: The URL for your PostgreSQL database. You can use this to connect directly to your database.

Local secrets#

You can load environment variables in two ways:

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, for example: supabase functions serve --env-file ./path/to/.env-file

Let's create a local file for storing our secrets, and inside it we can store a secret MY_NAME:

This creates a new file ./supabase/.env.local for storing your local development secrets.

Now let's access this environment variable MY_NAME inside our Function. Anywhere in your function, add this line:

Now we can invoke our function locally, by serving it with our new .env.local file:

When the function starts you should see the name “Yoda” output to the terminal.

Production secrets#

Let's create a .env for production. In this case we'll just use the same as our local secrets:

This creates a new file ./supabase/.env for storing your production secrets.

Let's push all the secrets from the .env file to our remote project using supabase secrets set:

You don't need to re-deploy after setting your secrets.

To see all the secrets which you have set remotely, use supabase secrets list: