Easily switch between .env files

[saibotsivad]

The Praise

The approach to managing secrets in a .env is really great, it's been pretty cool to be able to keep an .env.example file in the git repo.

Also, from within Bruno, the ability to switch between environments is great. You just pick one from the dropdown selector!

(I also suggest adding .env* and then !.env.example to the .gitignore so all .env files are ignored except the example one.)

The Pain

When storing secrets in the .env file, switching between environments actually requires the following steps (for example switching from staging to production):

• From within Bruno, pick "Production" from the dropdown selector
• Go to the folder with the .env files
• Rename .env to .env.staging
• Rename .env.production to .env

That's a lot of work, and annoying!

Proposal?

There could be a way from in Bruno to pick which .env* file to use? That adds another dropdown selector, which isn't a great UX but could be okay.

Or perhaps a way to associate a Bruno environment with a specific .env file? For example in a file environments/Production.bru there could be:

env {
  file: .env.production
}
vars {
  apiKey: {{process.env.API_KEY}}
}

This doesn't feel like a great solution either, because a user might desire to point to a different file than .env.production and then you'd have to remember to never check in the env { file } part of the Production.bru file.

Are there other ways to manage this?

[helloanoop]

Hey @saibotsivad !

One approach is utilising prefixes (e.g., DEV, QA, STG) to distinguish between different environments.

.env

DEV_AWS_ACCESS_KEY = secret
QA_AWS_ACCESS_KEY = secret
STG_AWS_ACCESS_KEY = secret

And then in your envs
environments/dev.bru

vars {
  AWS_ACCESS_KEY: {{process.env.DEV_AWS_ACCESS_KEY}}
}

environments/qa.bru

vars {
  AWS_ACCESS_KEY: {{process.env.AWS_ACCESS_KEY}}
}

In this approach, your app would use a single variable AWS_ACCESS_KEY, but these would be resolved to different values depending on the environment selected in the dropdown.

Note: While each environment may contain numerous variables, only a small subset of them actually require secrecy.
So, you could save the regular variables inside the usual environment configuration, and only the secret ones in the .env file.

[saibotsivad]

Yeah, I end up doing this, but it's clunky and feels like there could be a more elegant approach.

Having multiple .env files is a common problem, so this in itself isn't specific to Bruno, but I think the pain unique to Bruno is that changing environments becomes a multi-step process. Most projects I work in that use .env files make use of env-cmd, which lets you simply pass in a flag to point to a different .env file, so switching environments is a single flag.

One other solution I was thinking about is if each Bruno environment was optionally associated with an additional named .env but that association would not be a setting stored in the folder.

So suppose you have some normal environment/PROD.bru and environment/STAGE.bru files, and then you'd have some a selector inside the Environment modal, like this:

[xalvarez]

I feel the same pain and like the ideas exposed here by @saibotsivad, I just wanted to add one more, which would be to optionally read an .env file found in an environment folder. This could take precedence over an .env file created at the collection root.

[hellodave76]

This is what I just tried, thinking surely this will just work, right? Unfortunately not... yet!
+1 for some kind of native support for handling multiple .env files 🙏

[yluom]

Hello, any updates about this topic ? I think it is a nice improvement that will help people migrate to bruno !

[leaumar]

My team and I only recently started using bruno and only today found out about these handlebars-style env vars. But our first and immediate grievances were indeed

• why can't we make .env.acc, .env.prod etc instead of a single .env that complicates variable naming by having to prefix the env in every value
• and why can't bruno just autodiscover the envs from our .env.* files and let us select them, and fill the values in the requests directly from the file without the additional mapping layer of jwt.secret=process.env.JWT_SECRET

On a sidenote, using a .env file doesn't even work for us right now. We're following the docs and our experience with .env files, and bruno even resolves the secrets when we hover over the handlebar names in requests, but the actual request is fired without replacing the {{foo}} by their values. Is there some requirement to using this feature that we're missing?

[mj-h]

I gave up on .env files and just use environments, because I have to switch between environments a lot.

I don't check my environments into the repo (my .gitignore line is **/environments/*.bru), but I do maintain a environments/sample-env.bru.sample file so that my colleagues know what environment variables they have to define. For complex scenarios, I had Claude/ChatGPT write bash helper scripts for me that autogenerate environments for me.

Other colleagues of mine commit their environments to the repo, but they use the "is secret" checkbox, so that the actual value is not saved in the environment. It's a super convenient feature, but it does not work for me, because I need those values in the cli runner as well, and currently, the cli runner has no way to read the secrets from the UI-secrets-store.

[medQ-Tommy]

Add me to the list of those who thinks the .env is a great idea that isn't well implemented yet. There really needs to be support for multiple .env files, not creating one giant env with a ton of different versions of the the variables in it.

[matthiasblomme]

How about just supporting a .env file per environment and a global one? So that these can be combined and overwritten?

[filoscoder]

+1 for .env.* support 👍🏼

[chadbirch]

The way ASP.NET Core manages application settings, specifically around the appsettings files, would be a nice approach here.

They have an appsettings.json that gets processed first. then they have an appsettings.{ENVIRONMENT_NAME}.json that gets processed next. It overrides values defined in the appsettings.json and adds the remaining values as new values.

In this case, process the .env file. Then, if you're environment is set to QA_US, load the .env.QA_US if it exists. You'll need to define some logic for spaces and special characters since Environment Names may contain characters not allowed in a filename for the OS, but I believe this approach would be solve the issue that the OP brought up.