deployer: Laravel recipe shouldn't have shared file .env

In the laravel recipe the .env file is defined as shared file on any environment and therefor is always there while it shouldn’t! Dotenv loads the environment variables from .env into $_ENV, $_SERVER but i guess the most of the time the .env is just a empty file and hopefully not used on production environments

// Laravel 5 shared file
set('shared_files', ['.env']);

Also from the documentation Usage notes of dotenv
https://github.com/vlucas/phpdotenv#usage-notes

phpdotenv is made for development environments, and generally should not be used in production. In production, the actual environment variables should be set so that there is no overhead of loading the .env file on each request. This can be achieved via an automated deployment process with tools like Vagrant, chef, or Puppet, or can be set manually with cloud hosts like Pagodabox and Heroku.

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Comments: 16 (4 by maintainers)

Most upvoted comments

A bit late reply, but you should cache your configuration. Imho you should still share the .env file, because it’s very convenient. Caching the config will load the .env contents and write it to a cache file. This doesn’t use environment vars anymore. (At least in 5.2+)

What do you suggest in the case where there are multiple Laravel applications running on the same server?

For web requests, I could set them in each application’s SetEnv directive so that’s no problem, but what would I do for artisan commands?

Let’s say that both application require ten different environment variables to be set (DB_NAME, DB_PASS etc). How do I run php artisan migrate for one client? This is possible when using the .env file for each application in production. But without the .env file… the only way I can think of is execute artisan commands like export DB_NAME=db_name && export DB_PASS=mysecretpass && ... && php artisan migrate which clearly this isn’t a good solution.

Any ideas?