What's the correct way to set ENV variables in Laravel 5?

Question

In laravel 4 we had:

$env = $app->detectEnvironment(array(
    'local' => array('homestead')
));

by default.

But in laravel 5 it's changed to:

$env = $app->detectEnvironment(function()
{
    return getenv('APP_ENV') ?: 'production';
});

Also, they have excluded .env.* line in .gitignore, now it has:

.env

And added file .env.example:

APP_ENV=local
APP_KEY=SomeRandomString
DB_USERNAME=homestead
DB_PASSWORD=homestead

So, if i have more than 2 environments, do i have to set all of them in a single .env file now? E.g.:

APP_ENV=local
DB_PASSWORD=123

APP_ENV=alpha
DB_PASSWORD=456

If i would have no .env file, how laravel will know what environment i am using?

Answer 1

You can do it exactly the same as in Laravel 4:

$env = $app->detectEnvironment(array(
    'local' => array('homestead')
));

*.env file are just used to put sensitive data that shouldn't be put into VCS. The same is in Laravel 4

but is seems that in last days default detectEnvironment was changed to:

$env = $app->detectEnvironment(function()
{
    return getenv('APP_ENV') ?: 'production';
});

so you can use either setting variable from PC name or from ENV file.

If you use ENV based environment detection in main env file (by default .env file you need to add:

APP_ENV=local

Of course local here is local environment, you can change it into production or dev

At the moment the most important issue I see is that you need to remember when going on production to change this .env file content from APP_ENV=local to APP_ENV=production so in my opinion much better method is the old default method based on PC names.

Now ENV files. If you use ENV based environment detection, you should put into your ENV file only:

APP_ENV=local

Now you can create separate ENV files for your different environments for example:

.local.env :

 MY_DB=testdb

.production.env :

MY_DB=productiondb

and now in bootstrap.environment.php file you can modfiy:

if (file_exists(__DIR__.'/../.env'))
{
    Dotenv::load(__DIR__.'/../');
}

into:

if (file_exists(__DIR__.'/../.env'))
{
    Dotenv::load(__DIR__.'/../');

    if (getenv('APP_ENV') && file_exists(__DIR__.'/../.' .getenv('APP_ENV') .'.env')) {
        Dotenv::load(__DIR__ . '/../', '.' . getenv('APP_ENV') . '.env');
    }   
}

to load extra env file based on APP_ENV from main env file.

Now you will be able to use it in your other configuration file as always: $_ENV['MY_DB']

Answer 2

The fact that you can't have more than one .env file by default and that it's excluded in .gitignore is intentional and is the intended way to manage environments. The .env file should not be in version control and should be configured per environment. .env sets your environment and all environment variables.

So, if i have more than 2 environments, do i have to set all of them in a single .env file now?

No. You would have a .env file in each place that you have your application installed. The difference is in what is inside that file.

Additionally, because the .env file is simply a key-value store, any subsequent declarations would overwrite previous ones. In your example, Laravel would never see your "local" settings.

It seems odd at first, but this new default system is actually generally easier and less prone to the issues the "4.2 way" had/has, as there's no place for logic errors.

If i would have no .env file, how laravel will know what environment i am using?

It wouldn't run at all. In the .env file is also an APP_KEY declaration, which Laravel will not run without. Without a .env file, you would get a 500 server error.

Answer 3

I just wanted to contribute my solution for Laravel 5.1, which is slightly simpler IMHO. In bootstrap/app.php, I have (just after where the Application is instantiated):

$app->beforeBootstrapping(\Illuminate\Foundation\Bootstrap\DetectEnvironment::class, function() use ($app) {
    $suffix = (env('APP_ENV')) 
        ? '.'.env('APP_ENV') 
        : '';
    $app->loadEnvironmentFrom('.env'.$suffix);
});

There's no need for any checking or error handling. Laravel will default to "production" if the file is not found.

That is all.

Answer 4

For Laravel version 10 and above:

You can actually use this package syamsoul/laravel-set-env

1. Just install via composer

composer require syamsoul/laravel-set-env

2. Run this command:

php artisan souldoit:set-env

• And you will be prompted to insert the variable name and the value.
• Or can straightaway insert the variable name and the value into the argument, for example:

php artisan souldoit:set-env "MY_APP_NAME=My Application"

Answer 5

For those who just upgraded to 5.2:

You cannot longer use the static Dotenv::load() method. Use the following instead:

$dotenv = new Dotenv\Dotenv(__DIR__ . '/../', '.' . getenv('APP_ENV') . '.env'); // Laravel 5.2
$dotenv->load();

in bootstrap/app.php.

//edit Soo.. after digging into this for the past hour I might as well add some additional info here:

• Laravel uses .env files for configuration
• By default, the file ".env" in the root directory of the application is loaded
• You can access the values within those .env files via the env() helper function or directly via PHP's native getenv() function. Although you should only do so to fill your config files (see /config/*.php), because those can be cached.
• the .env files are loaded in the DetectEnvironment class. I found this helpful while debugging to set breakpoints. Please take note of the line (new Dotenv($app->environmentPath(), $app->environmentFile()))->load();: Since it uses load() any environment value that has already been set will not be overwritten! (You would have to use overload() to do so - this drove me nuts because homestead sets the APP_ENV variable to local in the php-fpm config /etc/php/7.0/fpm/php-fpm.conf and you cannot change it via .env file)
• when writing unit tests, you usually inherit from TestCase, which sets the APP_ENV variable to testing (via refreshApplication() -- using putenv() to override the default local value)