IMO env files are a bit of an anti-pattern, env vars should be set outside the context of your app so that your app doesn't need to care where they come from, it just uses standard env var APIs to read them. This means developers can choose how they load them and what tools they use to do so.
With that said, the problem still exists just one layer higher. If they are secrets, I use Infisical (https://infisical.com/) which is free and self-hostable, and let's you inject secrets at runtime via their CLI. Very handy for small teams.
On top of that, I use direnv (https://direnv.net/) with a hook to infisical's export command. This means when I 'cd' into a project, infisical runs and injects the secrets for my developer environment.
Everything that isn't secret just lives in .envrc and gets loaded by direnv, and you can just send those files however you want because they aren't sensitive.
Check out varlock - it’s a free and open source toolkit to help with this. It has built in validation, extra protection for your secrets, and uses plugins to pull sensitive data from most common sources. Also has built in local encryption with biometric unlock.
`sops` and `age` are about as barebones as you can get if you want to have something to check into a repo, I suppose. Most CI/CD runners have secret storage you can use to make this a nonissue as well.
I tend to use env variables instead of env files (12 Factor Apps - https://12factor.net/). Safer, not safest. As @late_night_fix mentioned, there has to be a balance.
I've seen teams spend more time managing secret access than building features.There's definitely a balance between security and keeping developer workflow fast.
Why does it needs to be shared? You either have a local copy of the infrastructure and set your own values. Or parts of the infrastructure is shared by the team so anyone can just get their own values. If it's something that's critical, then the usual security practices take place.
IMO env files are a bit of an anti-pattern, env vars should be set outside the context of your app so that your app doesn't need to care where they come from, it just uses standard env var APIs to read them. This means developers can choose how they load them and what tools they use to do so.
With that said, the problem still exists just one layer higher. If they are secrets, I use Infisical (https://infisical.com/) which is free and self-hostable, and let's you inject secrets at runtime via their CLI. Very handy for small teams.
On top of that, I use direnv (https://direnv.net/) with a hook to infisical's export command. This means when I 'cd' into a project, infisical runs and injects the secrets for my developer environment.
Everything that isn't secret just lives in .envrc and gets loaded by direnv, and you can just send those files however you want because they aren't sensitive.
Check out varlock - it’s a free and open source toolkit to help with this. It has built in validation, extra protection for your secrets, and uses plugins to pull sensitive data from most common sources. Also has built in local encryption with biometric unlock.
`sops` and `age` are about as barebones as you can get if you want to have something to check into a repo, I suppose. Most CI/CD runners have secret storage you can use to make this a nonissue as well.
I tend to use env variables instead of env files (12 Factor Apps - https://12factor.net/). Safer, not safest. As @late_night_fix mentioned, there has to be a balance.
I've seen teams spend more time managing secret access than building features.There's definitely a balance between security and keeping developer workflow fast.
I started to use the croc tool to sent the .env files.
Why does it needs to be shared? You either have a local copy of the infrastructure and set your own values. Or parts of the infrastructure is shared by the team so anyone can just get their own values. If it's something that's critical, then the usual security practices take place.