title: Laravel: Do multiple environments require multiple .env files?
body: <p>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.</p>
  
  <p>With Laravel 5.x it seems I have to take the following approach:</p>
  
  <ul>
  <li><p>On my local machine a .env file in the root directory with "APP_ENV=local" and other config stuff to run locally.</p></li>
  <li><p>On my server the same thing with "APP_ENV=production" and the related settings.</p></li>
  </ul>
  
  <p>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.</p>
  
  <p>Is this correct so far or am I missing something here?</p>
  
  <p>The main goal is to keep sensitive data out of version control and have everything in one place.</p>
  
  <p>Following points and questions about this approach are unclear:</p>
  
  <ul>
  <li><p>The creator of the .env package recommends to NOT use it in production mode (source: <a href="https://github.com/vlucas/phpdotenv" rel="nofollow">https://github.com/vlucas/phpdotenv</a>). 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).</p></li>
  <li><p>If the solution in the point above is used, how would you keep the sensitive data out of version control?</p></li>
  <li><p>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?</p></li>
  </ul>
  
  <p>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.</p>