The death of the .env file

Six months ago, I advocated for everyone to stop using .env files in favor of approaches using secret management platforms. Since then, I’ve learned and experienced much more about how to manage environment variables effectively. In this article, I argue again for why we should reduce the practice of storing all environment variables in a <code>.env</code> file and move to a more sophisticated approach for managing them in local development. Before you roast me, I want to make clear that my position is not that you have to ditch the .env file entirely. I’m asserting that your application’s environment variables should not be stored directly in a .env file. This doesn’t mean, however, that you can’t store a token in it that pulls in the rest of your environment variables at runtime. I also, by the way, want to make clear that this article is intended for software development teams and not security and devops teams that already have this figured out; this article is also not intended for solo developers who can feel free to use <code>.env</code> files. <h1>Don’t fix what’s not broken</h1> In the beginning, developers hardcoded environment variables into their codebase. After realizing that hardcoding them into source control was suboptimal, we introduced <code>.env</code> files for separation of concerns that is to split sensitive data from the rest of code. In practice, we’d create a <code>.env</code> file, add environment variables to it, and <code>.gitignore</code> the file. We’d start up our applications and read the environment variables into them in local development. Unfortunately, we still teach developers this as a staple of software development and proponents tend to say “don’t fix what’s not broken.” If you’re one of these stubborn proponents, then stop reading; if you’re open to improvement and breaking tradition, go on. <a href="https://medium.com/@tony.infisical/the-death-of-the-env-file-6d65bfc6ac5e">Website</a>