Reputation: 91
In Laravel 4.x it was possible to have a development and production environment with one configuration file. The framework would detect automatically what should be used according to the host.
With Laravel 5.x it seems I have to take the following approach:
On my local machine a .env file in the root directory with "APP_ENV=local" and other config stuff to run locally.
On my server the same thing with "APP_ENV=production" and the related settings.
So if I deploy my site, I have to watch that I don't overwrite the .env file on the server with my local version.
Is this correct so far or am I missing something here?
The main goal is to keep sensitive data out of version control and have everything in one place.
Following points and questions about this approach are unclear:
The creator of the .env package recommends to NOT use it in production mode (source: https://github.com/vlucas/phpdotenv). The solution in Laravel for this issue would be to hard code every setting across the framework and to make sure that the .env file is not deployed to the server (could be a huge security hole).
If the solution in the point above is used, how would you keep the sensitive data out of version control?
Let's say two different .env files are used (for development and one for the server in production mode), wouldn't that be a performance issue in production since each setting is being called over and over again from the .env file?
This seems like a step back from the 4.x approach where I could have everything configured and done in one place, no need to have two different files with the same name and watch that I don't mix them up or something. And loading one array in .php is also a lot faster than calling one file multiple times.
Upvotes: 0
Views: 3556
Reputation: 1545
Yes you are right. For 5.x you have to create totally different .env files on any single environment like development, staging, production etc This is included in .gitignore so the git system doesn't care about it. Every manipulation should be made by hand once again when you change environment.
The typical process is to ssh into a remote machine, git clone your project, composer install all dependencies and then create a brand new .env file where you should put all dedicated settings regarding this environment. Your guide is .env.example.
Upvotes: 2
Reputation: 189
If you want to hide a file in UNIX-systems you simply do that by adding a dot to the beginning of the filename. I don't know how it works on Windows systems but the file should be hidden i OS X and Unix systems to prevent people from accidentally copying into another project.
You can only have one .env-file per environment, so you'll have to login to the server and add new .env file manually once.
If you're using GIT and want to prevent it from beeing included just add it into your .gitignore-file
// filename: .gitignore
.env
Upvotes: 0