Is it possible to manage multiple .env
For example, use in one project for docker-compose containers .env-a, .env-b, .env-c, but taking into account production and stage environment
Can you elaborate further? So you are use 3 different env files that are ALL for production environment? Or does each file represent an environment?
This would useful for sharing secrets between environments.
e.g. -e .env.development -e .env.shared
@hbriese interesting. Why not just place all those secrets in development though? Why maintain a shared and require a developer to look in 2 places - more mental effort?
(dotenv-vault already auto-copies over your dev keys to your other environments)
@motdotla very valid points, and that is exactly the approach we have taken. I have seen such a feature on similar tooling and was trying to guess at the case OP was making
I see. Thanks @hbriese.
@rymbekov can you elaborate further? Why do you currently prefer to have multiple .envs for a docker compose container? Do you boot up the docker compose container in development and then separately boot it up in staging and/or prod on your servers?
(dotenv-vault already auto-copies over your dev keys to your other environments)
Does it? Using dotenv-vault, the behavior I see documented and in practice is that any value not defined in an environment becomes an empty string. So if you define say a "production" environment, then do nothing else, then do npx dotenv-vault pull production you end up with a .env.production file filled with empty strings.
How can this behavior be changed and/or how can it be made to inherit values from the development environment, which would be the sensible behavior?