You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Make a clearer distinction about .env-files for config.toml and Edge Functions. #4361
Describe the problem In those 2 pages there is a mention about .env-file, but there is no indication that they are meant for different usecases and even examples show 2 different locations:
/.env (for toml.config).
supabase/functions/.env (for Edge Functions).
It's easy to think that there's supposed to be only 1 .env from which the config.toml and Edge Functions load their variables.
Personally I struggled with this for a while, thinking that Supabase docs are wrong and that the .env is supposed to be either in root OR under /supabase/functions and that there are some missing docs about how to load them from the same location.
Describe the improvement Either add specific notifications that if the .env is in root, it is used for toml.config and if it's under /supabase/functions, it's used only for the Edge Functions.
Or a more preferable solution: Change the .env-file loading so that there is only 1 .env loaded (from the root) and it's variables are used for both toml.config and Edge Functions.
Additionally, if possible, the default location for the .env could be /supabase/.env and in the config.toml we could toggle (boolean-setting) if the .env should be loaded from the root instead.
I am also very confused that if we still have to setup environment variables via Dashboard after deploying the Edge Function using supabase review CI/CD. Since the only things we can commit safely are .env.preview and .env.production, I think we should have a clean way for supabase Edge Function to read them.
We're closing this because it has not had any activity for 45 days, and we try to keep the Supabase CLI issue tracker focused on reports that are still current.
If this still reproduces on the latest Supabase CLI, please comment with /reopen on its own line and include your CLI version, updated reproduction steps, and any recent error output. We appreciate the signal and are happy to take another look.
In this way, you can have a single .env file (which must be placed at the root of your project).
But sadly, supabase config push will not push your edge function secrets to your remote production project (you have to do it manually in the dashboard or by running supabase secrets set).
Activity
utopianf commentedon Nov 4, 2025
I am also very confused that if we still have to setup environment variables via Dashboard after deploying the Edge Function using supabase review CI/CD. Since the only things we can commit safely are
.env.previewand.env.production, I think we should have a clean way for supabase Edge Function to read them.github-actions commentedon Jun 26, 2026
Hi! Thanks for opening this issue.
We're closing this because it has not had any activity for 45 days, and we try to keep the Supabase CLI issue tracker focused on reports that are still current.
If this still reproduces on the latest Supabase CLI, please comment with
/reopenon its own line and include your CLI version, updated reproduction steps, and any recent error output. We appreciate the signal and are happy to take another look.curiosissimoz commentedon Oct 5, 2026
As described here https://supabase.com/docs/guides/functions/secrets#where-local-values-come-from:
In this way, you can have a single
.envfile (which must be placed at the root of your project).But sadly,
supabase config pushwill not push your edge function secrets to your remote production project (you have to do it manually in the dashboard or by runningsupabase secrets set).curiosissimoz commentedon Oct 5, 2026
/reopen