Laravel APP_ENV=local APP_ENV=production difference

How to switch from Laravel local env to production

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!

Image for post

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.

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:

Image for post

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:

Image for post

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

@production     // code here@endproduction

Reference

or

@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'

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.

env() calls work 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

Config more here

Written by

Web geek, Self-taught full-stack web developer, Learning Python, Laravel, Vuejs, UX/UI design, Nuclear Physicist PhD

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store