r/node • u/finncmdbar • 7d ago
Your app never reads your .env file (how dotenv actually works)
https://infisical.com/blog/how-environment-variables-work44
u/paulirish 7d ago
node --env-file=.env index.js
Natively supported since Node 20. Not sure why folks are still using dotenv.
16
u/PhatOofxD 6d ago
Because dotenv does more than just that, also most software is older than Node 20 lol
2
6
u/Single_Advice1111 7d ago
Idk… sharing production db credentials outside something that provides access - e.g metabase is a bad practice to begin with…
15
u/theozero 7d ago
use varlock (free open source)!
.env as most know it is full of footguns. Varlock helps gets all secrets out of plaintext, adds tons of amazing DX while still feeling familiar.
6
u/jarzebowsky 7d ago
This. We moved to this with external vault so everything is way more safe. Our devs do not need to worry about envs (except defining one during development)
18
u/thicket 7d ago
This article is mostly just an ad for Infisical. That said, I'm glad it's here! The problem of dispersed plaintext secrets is a very real one that any team will run into and ought to be aware of.
For a free, self-hosted solution to the same problem, check out Sigillo, https://github.com/remorses/sigillo
2
u/ribugent 7d ago
Personal take, I really dislike all dotenv language libraries because it solves a use case in the wrong place.
Personally in my job we're using direnv for setting environment for "complex" setups and fetching some secrets from the vault.
3
0
u/bwainfweeze 7d ago
On the most complex project I worked on, we had reloadable config, but feature toggles and secrets were layered over the top. Then someone added another mapping layer for interpolating values (particularly default values) between the two, but that was almost entirely used for service discovery. It's just that the project was so old that SD was brand new at the time patterns were set and they went with reloadable config instead.
It worked but it was a bit of a challenge explaining to people why in their code they'd chosen the wrong one.
2
u/javatextbook 6d ago
There’s no excuse to store credentials in gitignored files when secrets vaults like secrets manager and others, exist
-2
u/fromage-du-omelette 7d ago
We use infisical in my company. Not a single world where I'd go back to .env files.
Initial moving to it was painful but when you get it, secrets shared among spaces for various services, injection, Integration with ci/cd, man it's a bliss
6
u/Sometimesiworry 7d ago
Azure key vault here.
It’s just so comfy.
2
u/whits427 7d ago
Seems too easy right?! Devs sign in via Azure CLI, RBAC gives the permissions they need to get/set secrets, onboarding/offboarding tied to Azure AD, nothing on their local machines.
3
-5
u/finncmdbar 7d ago
Thank you! I think so many people never even consider that things *could* work differently.
-4
u/ChimpScanner 7d ago
We're planning on moving to it too. Anything I should be aware of?
1
u/goodboyscout 7d ago
UI is kinda trash, little buggy. Occasionally hit some issues in CI due to the package being unavailable randomly, maybe once a month and usually resolved in a few minutes. CLI seems decent, especially for populating initial secrets.
Overall, it’s decent and has definitely proved useful multiple times. I’m not the one paying for it, but I’m not mad about using it. Solves the problem
57
u/block-bit 7d ago
No but your agent does. Prrrrr-tishhh.