Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: From dotenv to dotenvx – better config management

dotenvx.com

Post reply on HN
Print view View original

21–30 of 223 posts

Re: Show HN: From dotenv to dotenvx – better config management

#21

Post by nevir »

Etheryte wrote: post #16
jitl wrote: post #13

Secrets in env vars in production is not too secure either, ideally you’ll move to your app pulling secrets in-process from your infrastructure at boot-up or upon use. This also gives a nice advantage of not needing to rebuild the app or container or whatever to rotate a secret.

This just moves the problem to a different step. How are you going to manage access to said secrets, especially when your application lives off premises?

Many hosting environments give you this.

For example AWS gives you multiple ways of injecting secrets as env vars into your containers when they boot up (ECS + secrets manager, EKS, etc)

Re: Show HN: From dotenv to dotenvx – better config management

#22

Post by Tainnor »

isoprophlex wrote: post #8
boxed wrote: post #3

I 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.

Please don't configure important things in the IDE. IDE configs are notoriously fickle and checking them into the repo usually just leads to a lot of problems in my experience, plus it will mean duplicated effort every time you need to do something from the CLI.

Re: Show HN: From dotenv to dotenvx – better config management

#23

Post by rhplus »

boxed wrote: post #3

I 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.

Secrets don’t belong in environment variables either. Place them in a vault and grant specific processes/identities permission to read and decrypt them.

Env vars are prone to leaking and best practice moves the goal post further. Devs love to dump envs to log files, child processes inherit them, admins can very easily sniff them.

Re: Show HN: From dotenv to dotenvx – better config management

#25

Post by pictur »

I think for some reason people don't like such simple tools. I think it seems more reasonable to deploy a vault service running on kubernetes with jenkins. In some comments, they didn't even understand what the tool was for. Dear dude, you can travel between dimensions with this tool.

Re: Show HN: From dotenv to dotenvx – better config management

#26

Post by brigadier132 »

Encrypting secrets and committing them seems very convenient but I'm paranoid about these sorts of things. Can anyone tell me why this would be a bad idea?

One reason I can think of is that normally with secrets I actually don't keep any copies of them. I just set them in whatever secret manager my cloud environment uses and never touch them again unless I need to rotate them. Meaning there is no way to accidentally expose them other than by the secret vault being hacked or my environment being hacked.

With this approach if someone gets access to the encryption key all secrets are exposed.

Re: Show HN: From dotenv to dotenvx – better config management

#27

Post by edward28 »

VWWHFSfQ wrote: post #24

I always used foreman [0] which I found to be superior to dotenv in every way. Even superior to this new dotenvx [0] https://github.com/ddollar/foreman

Not to be confused with the larger foreman[0] also written in ruby.

[0] https://theforeman.org

Re: Show HN: From dotenv to dotenvx – better config management

#28

Post by fiddlerwoaroof »

daralthus wrote: post #4

Would 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`

Or just have the environment variable used after the flags are processed

Re: Show HN: From dotenv to dotenvx – better config management

#29

Post by dymk »

throwaway240403 wrote: post #11

"Config Management" means something else to systems folks. Suggest adding "for node projects" or something akin to the title to clarify.

It's not node specific like dotenv, it's a generic tool for launching processes with (optionally encrypted) environment variables.
Post reply on HN