dotenvx, almost perfect replacement for dotenv

When I first discovered dotenvx, I thought, “This is exactly what I was looking for!” Now I can safely share the .env file with the team via Git. I used to pass around the entire .env using 1Password — which worked — but now we only need to share one secret: .env.keys. No more rotating every API key when someone leaves the team. Just rotate the secret key. Fantastic! Except the last part is not true. Team members can decrypt env vars and save them elsewhere. So yes, you still need to rotate API keys periodically. That’s when it hit me — dotenvx solves .env distribution, but it doesn’t inherently improve security. So I started thinking: why not stick with our battle-tested workflow and just bolt on encrypted .env distribution? Keep .env in .gitignore as always Add .env.encrypted to the repo Let contributors decrypt with a command and update the full .env as needed This allows for a transparent migration. No need to change your dev server launch commands or update package.json to use dotenvx run all over the place. Just run a simple decrypt command when someone commits a new .env.encrypted. Keep the same mental model around .env. This will also prevent the false sense of security that I felt — makes it clear you still need to rotate your API keys, because nothing is inherently changed. You just improved the process of distribution of .env, not security. I think this aspect is very important to maintain the efficacy of security in practice. I hope dotenvx will embrace this thought process for the spirit of progressive enhancement.

Mar 30, 2025 - 06:00

dotenvx, almost perfect replacement for dotenv

When I first discovered dotenvx, I thought, “This is exactly what I was looking for!”

Now I can safely share the .env file with the team via Git. I used to pass around the entire .env using 1Password — which worked — but now we only need to share one secret: .env.keys.

No more rotating every API key when someone leaves the team. Just rotate the secret key. Fantastic!

Except the last part is not true. Team members can decrypt env vars and save them elsewhere. So yes, you still need to rotate API keys periodically.

That’s when it hit me — dotenvx solves .env distribution, but it doesn’t inherently improve security.

So I started thinking: why not stick with our battle-tested workflow and just bolt on encrypted .env distribution?

Keep .env in .gitignore as always
Add .env.encrypted to the repo
Let contributors decrypt with a command and update the full .env as needed

This allows for a transparent migration.

No need to change your dev server launch commands or update package.json to use dotenvx run all over the place. Just run a simple decrypt command when someone commits a new .env.encrypted. Keep the same mental model around .env.

This will also prevent the false sense of security that I felt — makes it clear you still need to rotate your API keys, because nothing is inherently changed. You just improved the process of distribution of .env, not security.

I think this aspect is very important to maintain the efficacy of security in practice.

I hope dotenvx will embrace this thought process for the spirit of progressive enhancement.