What are the advantages of storing info on .env files as opposed to .php files?

Question

Considering storing settings information on a .env file, outside the document root folder, as the best practices suggest... What would be the advantages of using .env files as opposed to .php files?

.env files would be parsed by a library and stored on ENV variables. .php files don't need parsing and will store info on ENV variables.

Thanks!

Answer 1

When developing you will have a set of keys that you configure on your local environment or whichever other enviroment you are developing. These keys (password to databases, email services, etc) you do not wish to share with other developers that work along side you. Neither if you are sharing the code with the world.

.env files where created in order for you to have a working environment without having to share those keys with the world or the rest of your team. They are supposed to be singular to the environment the project is settled.

When you create keys that are going to be used across the project, besides of adding them to your .env file you also should add them to the .env.example which is pushed to the repository. Leave the keys present in there while keeping the values empty for the .env.example so other developers understand what are the required keys for the project to work and what they should add in there while not giving a hint of what your local passwords are.

Also when you are working on local environments you normally use local passwords. A problem arises when you are deploying to a production server where real passwords that contain sensitive information will exist. So you do not want these to exist on your repository and definitely you do not desire these to be permanently stored in your repository (this comes with profession responsibility, specially when you are tagged just as a developer and not a sys admin, in the case where the sysadmin will add the keys once the project is deployed on the production environment).

It is a elegant way to bypass these problems above

In response to your second question in the comments

To be honest you can do it both ways if you end up following what I explained above. The main goal is to keep your variables protected. But you can just refuse to push the php file to repo.

In my opinion on why you should use .env instead of .php goes as follow:
1. with .env you immediately know it is a environment variable holder. .php regardless of how you name it is not as direct in understanding;
2. .env will be an ocult file when listing a directory;
3. It is easier, when working whit other developers in the same repo, to quickly identify and understand something should not be pushed on that commit (think even on the case of adding extra layer of security on a hook to make sure .env is not pushed on the commit. It is harder and you have to hardcode this for .php files);

I guess in your argument level these will be a few of the Go Tos when deciding between files. I would leave the .php files to be precisely that, php programming files instead of configs;

Now if you ask me between .env or .yml etc, I would say go with the one you are familiar/feel comfortable. At the end you avoided the .php the same :)

PS: Also, if you think on how you will reference them within the code whenever you need one of the environment variables it jumps way quicker to the eye when you see something like:

getenv('YOUR_VARIABLE_HERE');