How to load different mail_driver config setting based on app_env setting in Laravel 5.3 App>

Question

In my PHP Laravel 5.3 app I have my config settings in my .env file with the APP_ENV=local which can be changed to APP_ENV=production when my app is in production/live mode.

In that .env file I also have a MAIL_DRIVER=preview setting which gets pulled into my config/mail.php config file with env('MAIL_DRIVER', 'smtp') like this:

return [
    'driver' => env('MAIL_DRIVER', 'smtp'),
]

So now my question is, when I change my .env setting APP_ENV=local into APP_ENV=production

How can I make it load a different env('MAIL_DRIVER') setting based on that env('APP_ENV') setting?

is there a way to load different .env files for each environment or different config files or how do you handle this in Laravel 5.3.

I remember in older versions of Laravel you simply created a new folder in the config folder for each environment but the whole config system is different from those older versions.

Answer 1

With Laravel 5, you have a different copy of your .env file in each environment.

This file is NOT committed into your repository. Rather, your .env.example file is, and that is what you make a copy of and name as .env in the environment.

In previous versions of Laravel (i.e. <= 4) you could have separate environment files in the same checked out copy of the project and switch between environments, but that doesn't actually make much sense.

Keep your .env.example file up to date with all the options you will need in your app, and initialize them to empty values. When you deploy to a new environment, you copy it as a new file, which keeps you from accidentally committing credentials to your repo and keeps things simple:

cp .env.example .env

Then edit the file and set the values to be appropriate in that specific environment. For example, instead of using test API keys, you may use the production keys for some service. Editing, for example:

sudo vim .env # If you like VIM

or

sudo nano .env # If you like NANO

An exception to what I just said above is with testing. Per the documentation:

You may also create a .env.testing file. This file will override values from the .env file when running PHPUnit tests or executing Artisan commands with the --env=testing option.

In that case though, having your .env.testing file in your repo is most likely acceptable assuming it doesn't contain any sensitive production values, which it probably shouldn't anyway.