Doing much better than your .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. <a href="https://medium.com/@tony.infisical/the-death-of-the-env-file-6d65bfc6ac5e">Read More</a>