What is difference between use env('APP_ENV'), config('app.env') or App::environment() to get app environment?

Question

What is difference between use env('APP_ENV'), config('app.env') or App::environment() to get app environment?

I know that the env('APP_ENV') will to $_ENV, config('app.env') reads the configuration and App::environment() is an abstraction of all. And in my opinion the advantage is even this. Abstraction.

I do not know if there are other differences, such as the level of performance or security

Answer 1

In Short & up-to-date 2022:

• 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:

  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'

---

Explanation & History:

I just felt over it. When you cache your config file, env() will (sometimes?) not work right. So what I found out:

1. 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.
2. 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.

From this article on Laracast:

UPDATE:
env() calls work as long as you don't use php artisan config:cache. So it's very dangerous because it will often work while development but will fail on production. See upgrade guide

Caching And Env

If you are using the config:cache command during deployment, you must make sure that you are only calling the env function from within your configuration files, and not from anywhere else in your application.

If you are calling env from within your application, it is strongly recommended you add proper configuration values to your configuration files and call env from that location instead, allowing you to convert your env calls to config calls.

UPDATE Laravel 5.6:
Laravel now recommends in its documentation to use

$environment = App::environment();

// or check on an array of environments:
if (App::environment(['local', 'staging'])) {
    // The environment is either local OR staging...
}

and describes that env() is just to retrieve values from .env in config files, like config('app.env') or config('app.debug').

Answer 2

You have two equally good options

if (\App::environment('production')) {...}

or

if (app()->environment('production')) {...}

app()->environment() is actually used by Bugsnag, look in documentation here it says

By default, we’ll automatically detect the app environment by calling the environment() function on Laravel’s application instance.

Now, differences:

1) env(...) function returns null after caching config. It happens on production a lot.

2) you can change config parameters inside unit tests, it gives you flexibility while testing.

Answer 3

One thing to consider is perhaps the convenience factor of passing string to app()->environment() in order validate your current environment.

// or App:: whichever you prefer.
if (app()->environment('local', 'staging')) {
    logger("We are not live yet!");
    Seeder::seedThemAll();
} else {
    logger("We are LIVE!");
}

Answer 4

If you are using the config:cache command during deployment, you must make sure that you are only calling the env function from within your configuration files, and not from anywhere else in your application.

If you are calling env from within your application, it is strongly recommended you add proper configuration values to your configuration files and call env from that location instead, allowing you to convert your env calls to config calls.

Add an env configuration option to your app.php configuration file that looks like the following:

'env' => env('APP_ENV', 'production'),

More: https://laravel.com/docs/5.2/upgrade#upgrade-5.2.0

Answer 5

In 12factor methodology application contains two types of configuration values:

• internal which not vary between deploys and are stored in laravel ./config/ folder. In this type we usually store some technical optimal/good values used in application which should not be changed by users over time e.g. optimal image compression level, connection timeout, session expiration time etc.
• external which vary between deploys and are stored in .env file (but should not be stored in git repo, however .env.example with example values with detail info can be stored in repo). In this type we store usually some important/protected values which depends on local environment e.g. passwords, debug mode, db address etc.

Laravel proposes handy approach for this

• in regular code we use only config(...) helper (so on this level programmer do not need to know which configuration value is internal and which is external)
• in configuration code external config values should be set using env(...) helper e.g. in config/app.php 'debug' => env('APP_DEBUG', false)