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

101–110 of 223 posts

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

#101

Post by hu3 »

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.

I've seen so many .env files in production that I don't even wince anymore. I just formalize the finding by email and carry on.

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

#102

Post by [deleted] »

cyberax wrote: post #74

I _detest_ this kind of encryption. It's literally worse than useless. It makes life much harder during debugging, and it eventually leads to developers just storing the decryption keys locally. For this kind of encryption to work, you need to supply the decryption key from some outside system (e.g. via env vars, AWS SSM, etc.). And if it can supply the key, then why not just use it for other important secrets direct…

[deleted]

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

#104

Post by pmccarren »

mplanchard wrote: post #38

Seems pretty similar to sops[0], but without the encrypted-by-default feature that makes sops feel significantly safer for secret management. Sops also integrates easily with AWS and other existing key management solutions, so that you can use your existing IAM controls on keys. I mentioned in another comment, but I've been using it over five years at two jobs and have found it to be great. [0]: https://github.com/ge…

I too have been using sops for years, and agree -- dotenvx encryption seems very similar to sops.

I'd prefer an integration between dotevnx and sops where dotevnx handles the UX of public env and injection, while leveraging sops for secret management and retrieval. Additionally, being able to have multiple keys for different actors is important.

Having a single `.env.keys` file feels risky and error prone. dotenvx encourages adding your various env files, such as `.env.production`, to vcs, and you're one simple mistake away from committing your keyfile and having a bad day.

If sops is not to be integrated, dotenvx could take some inspiration where the main key is encrypted in the secrets file itself, and you can define multiple age key recipients, each of which can then decrypt the main key.

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

#105

Post by tracker1 »

Since node v20.06, has built in support for --env-file=.env on load... as for local(ish) encryption and pushing them into source control, I don't like this at all. I'm fine using a vault or secret distribution from either the environment host (k8s) or ci/cd deployment.

I do like to keep a .env.example that you can rename to .env and adjust as desired. I tend to have defaults for running a compose stack locally that close to "just works" as possible.

I doubt I'd ever want to use this in practice.

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

#106

Post by itslennysfault »

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

Yeah, this is a really weird post for me. Before dotenv existed I used Foreman. It worked basically exactly how "dotenvx cross-platform" works (as a global command line). I switched to node-foreman because I largely switched to working on node projects and didn't want devs to need to have ruby installed. Then, at some point I switched to dotenv, and I don't even remember why.

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

#108

Post by nunez »

dotenvx encryption goes a long way towards solving THE BIGGEST problem with dotenv; using multiple tools to ensure that secrets are protected.

I wonder if dotenvx ensures that .env is in .gitignore and yells loudly if it is not.

I encrypt my dotenvs with gpg, but that's hella esoteric and everyone shouldn't be forced to do that.

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

#109

Post by gkfasdfasdf »

wodenokoto wrote: post #45

On my phone so can’t double test, but can’t you get this by adding “export” in front of every line in your env file and then source before running command? I suppose if you don’t want it to stay after execution i believe you can: > $(source .env; my command) I’m sure there is a fairly straightforward way to encrypt and decrypt a local file

If in bash, you can use the 'allexport' option and source the .env without having to add 'export' in front of every line:

    #!/bin/bash
    
    set -o allexport
    . .env
    set +o allexport
    cmd

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

#110

Post by nunez »

hamasho wrote: post #91

I want an option to manage all env in a single file using a TOML like format like this. [local] API_KEY=local-key API_SECRET=local-secret DB=postgresql://username:password@localhost:5432/database_name [production] API_KEY=prod-key API_SECRET=prod-secret DB=postgresql://username:password@prod-db:5432/database_name [staging] API_KEY=stg-key API_SECRET=stg-secret DB=$(production.DB) It makes it easier to update all env…

You can do that today with sops if you'd like!
Post reply on HN