Easily switch between .env files #828
Replies: 11 comments 3 replies
-
|
Hey @saibotsivad ! One approach is utilising prefixes (e.g., DEV, QA, STG) to distinguish between different environments.
DEV_AWS_ACCESS_KEY = secret
QA_AWS_ACCESS_KEY = secret
STG_AWS_ACCESS_KEY = secretAnd then in your envs
In this approach, your app would use a single variable Note: While each environment may contain numerous variables, only a small subset of them actually require secrecy. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I end up doing this, but it's clunky and feels like there could be a more elegant approach. Having multiple One other solution I was thinking about is if each Bruno environment was optionally associated with an additional named So suppose you have some normal
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
This is what I just tried, thinking surely this will just work, right? Unfortunately not... yet! |
Beta Was this translation helpful? Give feedback.
-
|
Hello, any updates about this topic ? I think it is a nice improvement that will help people migrate to bruno ! |
Beta Was this translation helpful? Give feedback.
-
|
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
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 |
Beta Was this translation helpful? Give feedback.
-
|
I gave up on I don't check my environments into the repo (my 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.
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
How about just supporting a .env file per environment and a global one? So that these can be combined and overwritten? |
Beta Was this translation helpful? Give feedback.
-
|
+1 for |
Beta Was this translation helpful? Give feedback.
-
|
The way ASP.NET Core manages application settings, specifically around the They have an In this case, process the |
Beta Was this translation helpful? Give feedback.
-
|
A little sad to see this is not a feature in Bruno yet. Loading .env- depending on selected bruno env and dynamically reading the correct corresponding env file. |
Beta Was this translation helpful? Give feedback.
-
|
I feel this to be a must for convenience's sake, the value will be making it easier to sell for normal dev workflows! How can I convince my colleagues with this baffling omission |
Beta Was this translation helpful? Give feedback.
-
|
To add an update on this — there are a couple of PRs currently attempting to address this functionality: #5004 and #2578. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The Praise
The approach to managing secrets in a
.envis really great, it's been pretty cool to be able to keep an.env.examplefile 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.exampleto the.gitignoreso all.envfiles are ignored except the example one.)The Pain
When storing secrets in the
.envfile, switching between environments actually requires the following steps (for example switching from staging to production):.envfiles.envto.env.staging.env.productionto.envThat'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
.envfile? For example in a fileenvironments/Production.bruthere could be:This doesn't feel like a great solution either, because a user might desire to point to a different file than
.env.productionand then you'd have to remember to never check in theenv { file }part of theProduction.brufile.Are there other ways to manage this?
Beta Was this translation helpful? Give feedback.
All reactions