Content
@
https://opensea.io/collection/dev-21
0 reply
0 recast
2 reactions
mot
@mot
i'm the creator of dotenv. if you use dotenv with your crypto projects, you've got to check out what we are working on now - a better dotenv. * run anywhere * multi-environment * encrypted envs https://github.com/dotenvx/dotenvx
20 replies
9 recasts
62 reactions
Andrei O.
@andrei0x309
Most newer JS runtimes already load ENV files natively. - Node 20+ is capable of loading .env file by argument(--env-file) - In deno has become part of std from 0.127.0 - Bun supported env files from the get-go I guess useful for convenience. In other languages, ppl write a few lines to read and dump in env.
1 reply
0 recast
0 reaction
Forkh
@forkh.eth
Encrypted env files is an interesting feature tho. Especially when you have very sensitive info like private keys
2 replies
0 recast
1 reaction
Andrei O.
@andrei0x309
At the point of execution, you need those secrets. That's why I have seen the recommendation of pulling them from a vault at execution by an authentification mechanism. In most cases, I wouldn't store env files in a container, plain or encrypted. However, I recognize that every project has its own requirements.
1 reply
0 recast
1 reaction
mot
@mot
you should check out the .env.vault file because that is what it does - without dependence on a 3rd party surface. runtime injection.
2 replies
0 recast
0 reaction
Andrei O.
@andrei0x309
I don't see 3rd party dep as an issue. Because if that 3rd party provider is also running my container it can provide me the secret ONLY if the container is hosted by them. BTW assuming .env is only for secrets is a controversial matter. Products SvelteKit, etc have separated env by their usage category.
0 reply
0 recast
0 reaction
