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.

`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.