Another issue asking about multiple env files about dotenv HOT 6 CLOSED

Is it because of practical concerns, with theory having a hard time manifesting praxis? Or is this a concession with the status quo? Or just a change of mind/understanding? All legitimate ofc.

A little of all of that.

1. Practical - it is simpler to maintain a .env and .env.production file. The symmetry makes it easier to make sure you haven't misconfigured your production environment. Too many times I and others have missed an environment file in prod because the UI/config tool is different than the elegant .env file.
2. Concession - very popular frameworks like Next.js have popularized multiple env files particularly around the .env.local mechanism. There is a good use case for this especially as 3rd party cloud services became ubiquitous (which was not the case when .env was first created)
3. Change of mind - the introduction of the .env.vault file makes it much more elegant to manage all your environment variables in .env.environment files and then encrypt them to a single file and single decryption key on your server. This greatly helps minimize the security risk mentioned in number 1

We learned a lot over the last 10 years as a community. I think acknowledging these needs and introducing the .env.vault file will give the dotenv pattern at least another decade of heavy usage. It is more important than ever because the other patterns around secret and config management out there are largely proprietary or require keeping a service to be running. I don't like that future so dotenv will continue to carve out the more elegant and accessible solution.

P.S. closing the issue while I'm writing a response, rude 😠

haha. touché

from dotenv.

Great thoughts and strong exhaustive points @datner.

You're not the only one that has pointed that out about .env.vault.

Have you seen or tried dotenvx?

https://github.com/dotenvx/dotenvx

It has a mechanism that allows you to manage multiple .env files by doing something like this:

dotenvx run --env-file=.env.local --env-file=.env -- node index.js

docs

Would that solve your problem?

(dotenvx is taking all the learnings from dotenv and dotenv-vault and trying to wrap them up in a solution that runs everywere and works everywhere. You can use it with .env.vault or without. Your choice. It's a more flexible tool so that you can mold around your own development flows. It certainly does still recommend using .env.vault for production but you don't have to if your team lead is against that now. Admittedly, it is a modern approach that will take time for the community to adopt.)

from dotenv.

see the npm example in the dotenvx README [0] for a drop-in replacement to dotenv. (it still uses dotenv under the hood for parsing of your .env files so no behavior change/risk. [1])

[1] https://github.com/dotenvx/dotenvx/blob/main/src/lib/main.js#L5

from dotenv.

Thank you for addressing my issue @motdotla !
dotenvx, and all the other aforementioned tools, setups, scripts, and hacks, would all work just fine. dotenvx would just be the undisputed best option ofc 😉 . Yes supporting multiple env files was never an issue, even with its quirks. The question was more about the bridging between the theory and praxis.

In a way, the answer can be read as a combined

use .env.vault

and

for this example its fine to use multiple env files

For the former I would try to give it another go, I do believe in this tool.
The latter I want to go a bit more in-depth into

dotenvx being the next iteration and supporting multiple env files (representing multiple envs) ootb is a foundational shift of ethos from Twelve Factors, going from this to this. I of course could not care less, this is not my project nor do I get money from people abstractly following principles from Twelve Factors. But I'm curious why? Is it because of practical concerns, with theory having a hard time manifesting praxis? Or is this a concession with the status quo? Or just a change of mind/understanding? All legitimate ofc.

Regardless, I'll be migrating to dotenvx while waiting your answer

P.S closing the issue while I'm writing a response, rude 😠

from dotenv.

These are very astute observations, except one:

give the dotenv pattern at least another decade of heavy usage

I think it's very pessimistic to assume that technology will change in such a fundamental way that env vars would cease to be relevant in the next 10y, and the dotenv pattern long surpassed methodology and 'ascended' to foundational concept.
I'm sure you've heard such sentiments before, but a perfect companion to dotenv (conceptually) is direnv. There is already a lot of overlap, especially for development environments where env vars need to exists statically. for example rusts env! macro.

If dotenv is exploring new horizons with dotenvx and env.vault, maybe a deeper integration with it could be a worthwhile examination?

from dotenv.

well a lot can change in 10 years but I do agree with you. I was being conservative rather than pessimistic.

If dotenv is exploring new horizons with dotenvx and env.vault, maybe a deeper integration with it could be a worthwhile examination?

exactly. i think we will get there. i think it is our job mainly now to build good tooling around the .env.vault file. it's a very elegant solution to a hard problem. as tooling and education on it gets better I think tools like direnv could also adopt it. but in the spirit of open source i think it best we focus on our task and allow other tools to play things out as they wish (or as devs request it from other tools). i think it's best for the community and the industry when it happens that way.

from dotenv.