Introduction to .env files

Many software projects have a .env or similar file which includes the “secret” keys to a project. In this file, keys and values are often stored in a manner like:

MY_SECRET_KEY=nowcast_rocks123

These keys are later read by your application — for example a Ruby app might look at ENV["MY_SECRET_KEY"] in order to find the API keys for 3rd-party services like a payment processor or file storage or a database password/connection string. So these value are indeed quite secret, and the .env file is where many projects store them.

The .env file (that’s the name of the file, “.env”) is often untracked by source control, which in today’s standard setup often means it is in your .gitignore file, which lists the files untracked by git.

This is important for several reasons:

a) You don’t want your file with all of your secret keys tracked by git, because then they could be read with anyone with access to the source code. Assuming your project is stored on GitHub or somewhere similar, anyone who can view your code will be able to see your secrets. You don’t want that, clearly. Because of the nature of source control, even if you delete the keys from your code an attacker could browse the commit history and find the keys.

b) You want to have separate keys per environment (hence the .env moniker). Your development database connection string is separate from a “staging” environment, which is separate from production. Each environment needs its own keys.

So a standard setup is that each application instance expects a .env file to contain any necessary keys, secrets, and configuration options which are environment-dependent and/or secret.

If you are interested in additional such web architecture talks, you should watch my NowCast at Tuesdays at 7pm PST: https://nowcast.co/@sellarafaeli/XXbYG/Advanced-Web-Architecture.