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

211–220 of 223 posts

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

#211

Post by anentropic »

graemep wrote: post #198
anentropic wrote: post #181

Earlier quoted context omitted.

Yes... surely the point of .env file is as a shortcut to provide env vars for local development .env file shouldn't be used in production, env vars should be injected directly

I agree that is what should happen. That is not what dotenv does though: https://www.npmjs.com/package/dotenv#-documentation

I think dotenv would be fine as long as it doesn't raise exceptions if no .env file is found, i.e. if it works just as a helper for local dev and as a no-op for production

I notice the dotenv docs are recommending dotenvx now in places: https://www.npmjs.com/package/dotenv#-manage-multiple-enviro...

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

#212

Post by theozero »

0xbadcafebee wrote: post #52

The whole idea of using environment variables for configuration information is good, but ultimately flawed, and we are way past the point where this should continue to be the status quo. Environment variables are great for configuration because: - you can inherit them from a previous application or application(s) - you can override them in each environment you run your app in - you can pass them on to other applicati…

Super early days but we're building something very similar to what you are describing over at https://dmno.dev

Granted our solution is more javascript/typescript focused - and the config schema will be defined using TypeScript and piggyback on npm for sharing plugins/extensions. But the config will be usable in any language (and generate types for multiple languages) with deeper integrations coming soon.

The pluggable nature of our architecture also means you can encrypt secrets in your repo if you want to, or sync with other backends. Shouldn't be too hard to keep everything away from env vars either if that's what some folks want.

Would love your input, and to hear what you think!

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

#213

Post by stiiv »

iamsaitam wrote: post #185
stiiv wrote: post #81

dotenv has zero npm dependencies. dotenvx has 21, including a few I have never heard of. Is this really more secure?

This is quite a common remark when it comes to Javascript. I rarely see the same being made about Rust libs, which also rely heavily on external dependencies.

Justifiably! Supply-chain attacks have occurred via npm, and have been widely reported. A lack of oversight and lack of standard libraries are often cited as the cause.

I don't know if it's a problem for Rust (or other platforms like Python, .NET, or Java afaik).

As someone who primarily writes TypeScript to run in browsers and on node.js, this kind of threat requires an extra level of vigilence, and often nudges me toward writing my own things rather than importing them.

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

#214

Post by wodenokoto »

A lot of people here are saying that a vault is preferable to this, especially for secrets.

Is there a good primer on using vaults? I know how to query and insert into Azure Key Vaults, but architecting around it is unclear to me.

Things that come up for me:

- As (azure) key vaults don't support per secret access rights, where do I store secrets between deployments?

- Should I store connection strings to cloud resources, or just ask the resource for the connection string at deployment time (for Azure, a cloud function pretty much needs a connection string for most basic things. They say they are moving away from this but ...)

- A security warning is send if a key is accessed more then x/times per hour. Does that mean I should pull in the key from vault at deployment? Cache it after first call during runtime?

- Most of our 3rd party vendors gives us 1 and only 1 key. How do I manage that key between development, production and several developers? Right now we mostly forward the e-mail from the vendor with the key ...

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

#215

Post by solatic »

Grimburger wrote: post #146
solatic wrote: post #78

Earlier quoted context omitted.

The biggest issue with storing secrets in version control with the code is that past secrets are never relevant after they have been rotated. This makes rollbacks risky. Consider: 1. Create secret v1 2. Code v1 3. Deploy 4. Secret v2 (rotation) 5. Code v2 6. Deploy 7. Oops, need to roll back to v1 (from step 2) 8. Outage, because the secrets in step 2 are not the secrets from step 4

This seems trivially solved by never mingling secret rotations with general deployments?

Inserting deployments between steps 1 and 2 and between steps 4 and 5 still results in an outage when the deploy for code v2 needs to be rolled back to the older commit, not the commit before. Arguing that rollbacks means you only ever need to rollback to commit #n-1 is like arguing you should never retain more than one backup; there's always a chance that you need to rollback even further to fix things.

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

#216

Post by pnt12 »

treflop wrote: post #98

The only reason I use .env is because it’s dead simple and very obvious as to how it works to anyone. If now someone has to read docs to figure out how to configure the app, I’d rather have them read docs for some other safer and more powerful configuration scheme.

I've dealt with problems from python-dotenv and very much prefer it as a command than as a library.

As an example, once I changed a .env fikr and unit tests started failing. Digging deeper into it, and lots of code was checking for .env to load its configurations, and would break without it. I'd prefer this not to happen, as our tests were executing based on outside, not version controlled, configurations.

After removing dotenv as a library and using it only as a command, we were able to separate configuration and logic, and not have .env files affecting our unit tests - we simply ran the application with dotenv command, and the unit tests without.

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

#217

Post by graemep »

anentropic wrote: post #211
graemep wrote: post #198

Earlier quoted context omitted.

I agree that is what should happen. That is not what dotenv does though: https://www.npmjs.com/package/dotenv#-documentation

I think dotenv would be fine as long as it doesn't raise exceptions if no .env file is found, i.e. if it works just as a helper for local dev and as a no-op for production I notice the dotenv docs are recommending dotenvx now in places: https://www.npmjs.com/package/dotenv#-manage-multiple-enviro...

I have seen many .env files in production. SOme junior devs told me it was what they had been taught to do.

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

#218

Post by jen20 »

lucasyvas wrote: post #203
jen20 wrote: post #191

Earlier quoted context omitted.

> The right time to access secret stores is just before you start the container as part of the deploy process or vm startup in cloud environments. So how do you rotate secrets without bouncing app servers..?!

You don’t - you bounce the servers because it’s simpler. If your secret is static for the lifetime of a deployment - just redeploy to get a new value. I like secret stores but only when the value of something regularly changes in a way that redeploying becomes unacceptable.

Bouncing things is often unacceptably expensive - caches, consensus and the cost of data redistribution etc are all good reasons to have hot configuration for secrets.

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

#219

Post by horse666 »

sandstrom wrote: post #79

I've started using Mise for some stuff at work. Haven't digged in a lot yet, but looks really promising. https://mise.jdx.dev/ It handles task running (wipe local test db, run linting scripts, etc), environment variables and 'virtual environments', as well as replacing stuff like asdf, nvm, pyenv and rbenv. Still somewhat early days, tasks are experimental. But looks very promising and the stuff I've tried to far (ta…

Yes, also definitely a big vote for Mise.

I’ve switched recently from asdf for managing language & tool versions and the ergonomics are much nicer (eg one command vs having to manually install plugins, etc., more logical commands) It’s also noticeably faster.

Regarding the env vars features, a couple of relevant Mise issues around people trying to integrate env var secrets using SOPS, 1Password, etc.

- https://github.com/jdx/mise/issues/1617

- https://github.com/jdx/mise/issues/1359

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

#220

Post by boxed »

pluc wrote: post #59
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.

Keys in the env file will ultimately be loaded as environmental variables, so it's just adding a convenience layer.

One that negates the entire point.
Post reply on HN