Declare CUSTOM_ACCESS_TOKEN_SECRET environment variable twice

[agestaun]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

When running Supabase locally, environment variables used in the config.toml file (for example, inside auth.hook.custom_access_token.secret) are not loaded from the same .env file used by Edge Functions.

Currently, Edge Functions correctly load variables from supabase/functions/.env, but config.toml only reads variables from the project root .env.
As a result, the same variable (e.g. CUSTOM_ACCESS_TOKEN_SECRET) must be duplicated in both places for the setup to work — which is error-prone and confusing.

Ideally, both environments (Supabase services and Edge Functions) should share the same .env context, or config.toml should also look for environment variables inside supabase/functions/.env when running locally.

To Reproduce

Steps to reproduce the behavior, please provide code snippets or a repository:

1. Define the variable only in supabase/functions/.env:

   CUSTOM_ACCESS_TOKEN_SECRET=super_secret_value

2. Reference it in supabase/config.toml:

   [auth.hook.custom_access_token]
   secret = "env(CUSTOM_ACCESS_TOKEN_SECRET)"

3. Run:

   supabase start

4. Observe that Supabase fails to validate the JWT hook with:

   Invalid hook config: auth.hook.custom_access_token.secrets must be formatted as "v1,whsec_<base64_encoded_secret>"
   

5. Duplicating the variable in the root .env file fixes the issue.

Expected behavior

config.toml should also read environment variables from the same .env file used by Edge Functions (supabase/functions/.env) to avoid duplication and inconsistencies.

Screenshots

If applicable, add screenshots to help explain your problem.

System information

• OS: MacOS
• Version of supabase-js: 2.80.0
• Version of Node.js: 22.17.0

Additional context

This issue becomes noticeable when using custom JWT hooks or other configurations that rely on secrets defined for local development.

Allowing config.toml to access variables from supabase/functions/.env, or providing a clear hierarchy for env loading (root → functions), would greatly improve DX and reduce confusion.

[kallebysantos]

Hi @agestaun 💚
Thank you for your report!

I did check and seems there's no way to specific a custom .env file from config.toml, reference code.
You can also do specify your secrets directly from config.toml while using the "env(SECRET_NAME)" placeholder,
or just serve your functions with a custom .env by using the --env-file flag:

supabase functions serve --env-file <string>

Please check the cli docs

[agestaun]

yeah, I knew that but I hoped there was a simpler way to do this without passing them nor declaring them twice. Thanks @kallebysantos

[kallebysantos]

Sure!
I'll note your suggestion ☺️
Is a great feature that maybe cli should have

[Vansh5632]

@kallebysantos i am going through this issue and we can do like a hierarchy merging of the env ensuring that there is no need for declaring multiple places

we can do something like a loading project env before viper read it
would love to hear your thoughts about this ?

[kallebysantos]

Hi @Vansh5632 💚
Thanks for sharing it! I was thinking the same idea, about merging envs from all places.

Just didn't find time yet to propose this change to the internal team 😅

[Hallidayo]

Transferred from the supabase/supabase repo.

[Vansh5632]

should i raise a PR with my solution
@kallebysantos