Show HN: From dotenv to dotenvx – better config management
1–10 of 223 posts
Re: Show HN: From dotenv to dotenvx – better config management
#2Seems odd to announce new features without calling out to the fact that libraries with the same name in other languages have had those same features for years. (for example, the dotenv gem in Ruby)
Re: Show HN: From dotenv to dotenvx – better config management
#3I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.
Re: Show HN: From dotenv to dotenvx – better config management
#4Would be nice to be able to configure which .env file to read as an environment variable. Why? Imagine a package.json with this line:
`start: dotenvx run -f .env.local -f .env -- node index.js`
Instead of the -f flag, which now cannot be overriden, one could invoke it with
`DOTENV=.env.staging npm run start`
Re: Show HN: From dotenv to dotenvx – better config management
#5Seems odd to announce new features without calling out to the fact that libraries with the same name in other languages have had those same features for years. (for example, the dotenv gem in Ruby)
Node.js already has built in support for .env
https://nodejs.org/en/blog/release/v20.6.0#built-in-env-file...
Re: Show HN: From dotenv to dotenvx – better config management
#6Seems odd to announce new features without calling out to the fact that libraries with the same name in other languages have had those same features for years. (for example, the dotenv gem in Ruby)
[flagged]
Re: Show HN: From dotenv to dotenvx – better config management
#7[flagged]
Re: Show HN: From dotenv to dotenvx – better config management
#8I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.
Just set those env vars in your IDE. Let your IDE or docker-compose or whatever read an .env file if you must. But don't do it directly from your application code, indeed you're one lazy dev away from putting an .env file on prod servers.
Using dotenv-like constructions is, in my eyes, an antipattern.
Re: Show HN: From dotenv to dotenvx – better config management
#9I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.
You can commit your secrets as an encrypted vault with this. Then decrypt it with a key where needed: locally, on CI, on prod, etc.
This is basically a simplified version of Hashicorp's Vault, GCP key vault etc. with some less granularity on user authentication.
It solves the issues around .env.example and is perfect for gitops. You have all your secrets for all your envs ready, while you only need to set a single env var (the private encrpytion key) on your specific hosting environment.
You could even use separate keys per env, eg.: to give access to a developer to staging only.
Mozilla's https://github.com/getsops/sops is another contender but with a more complicated (and perhaps more flexible) key management.
Re: Show HN: From dotenv to dotenvx – better config management
#10I don't get it. Dotenv is only good for local dev. Otherwise you should put your secrets in environment variables (the "env" in ".env"). That people put .env files in prod is a mistake itself, and the proposed fixes here seem to not really do much about that.
Dotenv is an okay hack, but the root problem is that the operating systems we run these applications in don't have a fully conceived environment variable system.
I think you have a fair point that dotenvx doesn't get the implementation right, but it does at least seem to recognize where the problem lies and is trying to fix it from that angle. You have to start somewhere. Almost never do we get solutions right the first time. It takes iteration and experimentation and perhaps this (and others like it) can pave the way towards a better solution.