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).
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.
