Laravel Environment Variables 5.3 setup

Question

By default, Laravel git ignores the .env file that contains environment settings and configuration.

I would like to have a local .env, and a production .env that CAN be committed to my server so that I don't need to manually create production settings or touch the .env file at all and can use push to deploy techniques.

Anyone got any good solution for this? It seems a strange design decision to make developers always manually create the production settings in a single file, and not make it easy to switch between production and local settings. I was considering using git hooks to rename .production to .env but this seems like overkill, and I want to check that this functionality isn't available out of the box and I've missed it.

Bonus points for explaining why having three files .local.env, .production.env and .env (which switches between the two) files is a bad idea, and one the original team avoided.

I'm using the latest version of Laravel (5.3).

Answer 1

The reasons behind this design are mainly:

• Security concerns
• Different environments might need different settings

Laravel makes use of the DotEnv PHP library by Vance Lucas to provide the .env functionality, so you can read more about it there as well as in the officiall Laravel docs:

Your .env file should not be committed to your application's source control, since each developer / server using your application could require a different environment configuration.

If you are developing with a team, you may wish to continue including a .env.example file with your application. By putting place-holder values in the example configuration file, other developers on your team can clearly see which environment variables are needed to run your application.

And from DotEnv:

The .env file is generally kept out of version control since it can contain sensitive API keys and passwords. A separate .env.example file is created with all the required environment variables defined except for the sensitive ones, which are either user-supplied for their own development environments or are communicated elsewhere to project collaborators. The project collaborators then independently copy the .env.example file to a local .env and ensure all the settings are correct for their local environment, filling in the secret keys or providing their own values when necessary. In this usage, the .env file should be added to the project's .gitignore file so that it will never be committed by collaborators. This usage ensures that no sensitive passwords or API keys will ever be in the version control history so there is less risk of a security breach, and production values will never have to be shared with all project collaborators.

In summary, if you're certain that you will deploy to only one system and settings will always be the same, and there is no sensitive data inside the .env (or you're OK with everyone involved seeing it), then you could probably go ahead with your solution.

As a side node: Since you were asking for design decisions specifically, DotEnv was apparently inspired by The Twelve-Factor App, which advocates strict separation of config from code among other factors.