Nice article, it does a good job of conveying just how simple it is to use the OS primitives for secure-ish* delivery of secrets.
I think it falls short in meeting people where they are when they use env files. I appreciate the section at the end that says "if you must use dotenv files", but surely there's gotta be a middle ground where you can still leverage the OS and not lose out on convenience.
I think it could even look like an npm package that helps you set up the service correctly for local development, accounting for the reality that there is likely several projects on a developer's machine and some of these projects are there temporarily.
* of course, there's still all that stuff about environment variables being visible to other processes, so we still need decent runtime infrastructure for envvars like `DATABASE_URL_FILE`, a temporary file where the application can read the secret at runtime. I'd love to see that in Node instead of the `env-file`
That is the same impression I got reading this. I would enthusiastically use any OS-first method if it means one less brittle dependency, but the current usage of environment variable is rather different than what is described in the post.
Where .env files shine is that:
- they act as a declaration of expected environment variables,
- they are project-scoped, which is one big issue with using "/etc" for example
I personally like to set a .env.example for my collaborators to know what's expected, and I use a .envrc with direnv. And to make it more secure, I always have .envrc in my global gitignore so I can't just forget it.
The drawback is that for any non-interactive run (debugger) I have to manually add each variable each time.
Nice article, it does a good job of conveying just how simple it is to use the OS primitives for secure-ish* delivery of secrets.
I think it falls short in meeting people where they are when they use env files. I appreciate the section at the end that says "if you must use dotenv files", but surely there's gotta be a middle ground where you can still leverage the OS and not lose out on convenience.
I think it could even look like an npm package that helps you set up the service correctly for local development, accounting for the reality that there is likely several projects on a developer's machine and some of these projects are there temporarily.
* of course, there's still all that stuff about environment variables being visible to other processes, so we still need decent runtime infrastructure for envvars like `DATABASE_URL_FILE`, a temporary file where the application can read the secret at runtime. I'd love to see that in Node instead of the `env-file`
That is the same impression I got reading this. I would enthusiastically use any OS-first method if it means one less brittle dependency, but the current usage of environment variable is rather different than what is described in the post.
Where .env files shine is that: - they act as a declaration of expected environment variables, - they are project-scoped, which is one big issue with using "/etc" for example
I personally like to set a .env.example for my collaborators to know what's expected, and I use a .envrc with direnv. And to make it more secure, I always have .envrc in my global gitignore so I can't just forget it.
The drawback is that for any non-interactive run (debugger) I have to manually add each variable each time.
Check out https://varlock.dev - it makes .env files useful and safer!
"The file has no permissions model. No encryption. No audit trail. It is a sticky note on a monitor, formatted as UTF-8."
I dont think form is function.