Laravel APP_ENV=local APP_ENV=production difference

How to switch from Laravel local env to production

4 min readJan 12, 2021

You have one .env file, but the contents can differ on each machine you run the application.

Do not forget to run the command php artisan config:clear after you have made the changes to the .env file. Do this php artisan env, which will return the correct version and assures you about what it is actually set!

The role of the .env file is to allow you to have different settings depending on which machine you are running your application. So on your production server, the .env file settings would be different from your local development environment.

production and local are just environment names that you can use to turn certain testing features on or off in different places.

In development (coding) environment use this settings:

APP_ENV=local  
APP_DEBUG=true

In the production (server) use this settings:

APP_ENV=production 
APP_DEBUG=false

When you are making your application you want to see all errors, but in production you don’t have to show the errors to the users, instead of users can see error 500, and after you can fix it on localhost.

You should always set APP_DEBUG=false when deploying to a live server. Setting debug on might expose database passwords or display your code to users.

Before you continue with the rest of this tutorial, I would like to introduce two packages for Laravel that I have recently developed: Laravel Pay Pocket, a modern multi-wallet package, and Laravel Failed Jobs, a UI for the Laravel Failed Jobs Table. I hope they may be of help to you.

https://github.com/HPWebdeveloper/laravel-pay-pocket
https://github.com/HPWebdeveloper/laravel-failed-jobs

The APP_DEBUG flag is the difference between showing the application errors (full stack trace) and show a generic "user-friendly" error page.

The APP_ENV flag is not a boolean, this is because you can have many environments in your project, for example, production, development, staging, testing, etc. You can "change" the behavior of the app while you are in a specific environment. For example if you are working with PayPal, you don't want to charge real money while you are building the application, then you can use the flag in order to switch between your sandbox and production credentials:

Or another use case as an example is when we are going to run Laravel Dusk only on local and testing environment. In this case, we set the DuskServiceProvider in the boot() method of AppServiceProvider under a certain condition:

In Laravel Blade files you can also put your logics in a @production directive:

@production     // code here@endproduction

Reference

@env('staging')
    // The application is running in "staging"...
@endenv

@env(['staging', 'production'])
    // The application is running in "staging" or "production"...
@endenv

Some more advices:

use env() only in config files
use App::environment() for checking the environment (APP_ENV in .env).
use config(‘app.var’) for all other env variables, ex. config(‘app.debug’)
create own config files for your own ENV variables. Example:
In your .env put this:

MY_VALUE=foo

example config app/myconfig.php

return [
    'myvalue' => env('MY_VALUE', 'bar'), 
    // 'bar' is default if MY_VALUE is missing in .env
];

Access in your code:

config('myconfig.myvalue') // will result in 'foo'

If you execute the config:cache command during your deployment process, you should be sure that you are only calling the env function from within your configuration files. Once the configuration has been cached, the .env file will not be loaded and all calls to the env function will return null.

Laravel recommends only to use env() within the config files. Use the config() helper in your code instead of env(). For example you can call config(‘app.env’) in your code.

Every env() call from inside the Laravel application will read the cached config file (that is inside bootstrap/cache/config.php file) and not .env file.

So env() calls read from env file as long as you don’t use php artisan config:cache.

When you use php artisan config:cache all the configuration strings are cached by the framework and any changes you make to your .env file will not be active until you run the php artisan config:cache command again.

These are equal:

\App::environment('production')app()->environment('production')

.env should not be committed on your repository, like github or bitbucket.

Official document

Example in the core of Laravel: fine HandleExceptions:

Why we have an access in config files to the env file. The reason is that we can see the order of loading of these two files in Kernel.php file in this way:

First Environment variables then those variable are ready to use in Configuration.