A place for developers to talk about building on Farcaster.

/dev

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

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

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.

Software developer, open source enthusiast, privacy advocate.

Clear Wallet Open-source privacy focused wallet: https://clear-wallet.flashsoft.eu/


Encrypted env files is an interesting feature tho. Especially when you have very sensitive info like private keys

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.

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.

you should check out the .env.vault file because that is what it does - without dependence on a 3rd party surface. runtime injection.