use --env-file on localhost supabase start / stop / reset

[jdgamble555]

Describe the bug I'm not sure if this is a bug or a needed feature, but I would like to be able to load a different .env file name besides just .env. Apparently this is possible for local edge functions per Managing Secrets and Environment Variables, but not possible for the whole supabase? This doesn't make sense to me why it would only be available for local function testing and not the whole config.toml, so perhaps I am missing something?

To Reproduce Steps to reproduce the behavior: Run localhost with supabase start --env-file ./.env.development

Expected behavior It would load the .env.development (or whatever name), instead of throwing an error:

unknown flag: --env-file

Desktop (please complete the following information):

• OS: Windows 11
• Version of CLI 1.99.5
• Version of Node.js 18

Thanks,

J

[bombillazo]

That I know of, supabase start does not use a --env.file flag, but you can source the env file you want to use locally in your terminal and supabase start will see those variables when you run start.

[jdgamble555]

source is specific to unix and still a work around. I am using Windows (statistically most programmers do), and I don't want to declare all my projects env variables globally.

This needs to be implemented as a --env-file flag so that it can work for Windows users as well.

J

[jdgamble555]

I should add that this works:

supabase functions serve --env-file ./path/to/.env-file

But we need this to work:

supabase start --env-file ./path/to/.env-file
supabase stop --env-file ./path/to/.env-file
supabase reset --env-file ./path/to/.env-file
...

So not just supabase start.

J

[msawangwan]

this would be much appreciated.

[Matsuuu]

I've also come to want this. Mainly because I want to be creating a dev setup, where I could have a simple setup steps for our dev team on varying machines (unix, windows, etc.) without having to have separate instructions on each machine.

Running supabase from npx or a local installation is already quite cross-platform but if the project has any env variables, it becomes a burdain to make cross platform.

After reading through Function.run codes and Start.run codebases, I don't think it's impossible to just Boop some env variables on board.

Actually implementing it to all of the cli api's though? That might require some monkey patching which I don't know is the best approach.

Could there be an approach where we create a loader for --env-file files and use it anywhere in the system? That would allow us to add this functionality to all of the cli endpoints, without having to trickle down the variable through all of the function calls.

Something along the lines of (writing js as go isn't my strong suit)

class LocalEnvManager {
  #instance;
  static getInstance() {
    if (!this.#instance) {
      this.#instance = new LocalEnvManager();
    }
    return this.#instance;
  }

  readSuppliedEnv(envFilePath) {
        // envFilePath is supplied by user via `--env-file`
	const userEnv = parseEnvFile(envFilePath, fsys) // This function is already in https://github.com/supabase/cli/blob/main/internal/functions/serve/serve.go#L180
  }
}

And then we could just call the singleton instance throughout our cli pathways to trickle them around the different utils.DockerStart calls.

---

Would this singleton-ish approach make any sense? It would allow us to utilize the same flag across the cli API without having to completely butcher the function calls by adding more and more params to them and trickling the data down all of the pipes.

I'd be happy to take a stab at this if there's interest. Ping @sweatybridge or someone who's actively maintaining this project.

[goggle555]

Personally, I would be happy if .env.local is automatically used in the local development environment. .env.local is often included in .gitignore and can safely handle environmental counts.

[sweatybridge]

Personally, I would be happy if .env.local is automatically used in the local development environment.

I like this suggestion as well. We can probably follow the convention documented by godotenv. While it's not as explicit as --env-file flag, it does save quite a lot of keystrokes when starting and stopping.

If anyone would like to contribute a PR, this would be the code to update: https://github.com/supabase/cli/blob/4f83327b92768dc691a849ff0b5c75570a218ff7/internal/utils/config.go#L485

[sweatybridge]

CLI now supports the following precedence order when loading .env files

Priority	Environment			.gitignoreit?	Notes
	development	test	production
highest	.env.development.local	.env.test.local	.env.production.local	Yes	Environment-specific local overrides
2nd	.env.local	N/A	.env.local	Yes	Local overrides
3rd	.env.development	.env.test	.env.production	No	Shared environment-specific variables
last	.env	.env	.env	Maybe	Shared for all environments

Ref: https://github.com/bkeepers/dotenv?tab=readme-ov-file#customizing-rails