[ldng]

Files are written to disk. In a cloud setup that mean possibly leaking credentials when your disk is re-assigned to another tenant.

Yes, cloud provider are supposed to properly erase hard drive before reassigning. Can you be 100% sure they do though ?

With environment variable in RAM the problem is moot. Committing and/or generating .env in production system is completely missing the point.

[vegardx]

If you're worried about that you should be worried about what gets written to memory too. You have little control over where virtual memory ends up actually storing your bits and bytes. Unless you run without swap, but that's just a bad idea overall.

[ldng]

Lots of distributions precisely clean swap on boot or shutdown for security reasons. Also, clean a swap that is relatively small is faster than zeroing a full disk.

Your argument does not validate the use of easily recoverable .env file. Recovering a .env file is easier than recovering virtual memory.

[palotasb]

"Files are written to disk" is not strictly true. In the use case where the config contains (hopefully short-lived) credentials, one would pass them in a temporary file that usually only lives in RAM (unless /tmp doesn't use tmpfs or the temporary config file is put somewhere else) and of course doesn't get committed to the repo. (I'm not sure if you meant git commit or filesystem commit.)

I sometimes find secrets to be safer inside config files since so many times the environment variables get dumped into logs – hence all the popular CI/CD products have features to try to scrub such secrets from their logs.

I agree about not using .env files in production, I'd not use it at all.

[alexisread]

This is an advantage with sqlite as a config store as well - initial db config file augmented in-memory with secrets, accessible from all major languages, without relying on the vagarities of the filesystem (windows vs Linux tmp mount points) and easy to have multiple switchable configurations depending on environment, test mode (integration tests after deployment etc.) or customer.