Difference between ...
Clear all

Difference between using App::environment() vs app()->environment() vs config('app.env')


Topic starter

What's the difference between using App::environment() vs app()->environment() vs config('app.env') for checking environment? I assume the first two are the exact same thing, but what about those vs using config('app.env')?

What I can see the first two returns the whole service container instance, so is that worse for performance, but more secure or something? I'm reading that people recommend only using config() for your own config variables and for any other config variable that isn't the env one. Trying to figure out the reasoning.


2 Answers
Topic starter

App::environment() and app()->environment() are the exact same thing. The App facade and the app() helper function are both just shortcuts to access your application container.

In a web context (hitting your page from a browser), the App::environment() method and the config('app.env') function will return the same value.

In a cli context (artisan command, queued job, etc), the App::environment() method and the config('app.env') function could return different values. If the command being run is executed with the --env argument (ex: --env=testing), then the App::environment() method will return the actual detected environment ("testing"), whereas the config('app.env') function will continue to return the environment defined in your config file.

Two extra things to consider:

  1. The environment() method is part of the public api. This means the only potential for breaking changes is on major releases. The app.env config value is not part of the public api. Laravel could change that at any point if they wanted to, even on a minor release. I doubt they ever would, but they've made no public promises.

  2. The environment() method takes optional parameters to add a little syntactic sugar for testing your current environment. If you pass parameters, the method will return a boolean if you're in any of the supplied environments, instead of returning a string with the name of the current environment. The parameters are also treated as regex searches:

    $isTesting = App::environment('test', 'testing', 'testarossa')
    // or
    $isTesting = App::environment('test*')

    (the "*" is replaced with ".*" before the regex is run)

Topic starter

uses a Facade to get the environment, a facade of Illuminate\Foundation\Application.

uses a helper function to return the \Illuminate\Container\Container::getInstance(). environment() in a method of this Container instance.

is an alias for app() but expects a parameter e.g. resolve('config') or resolve(Application::class).

Uses the Container to resolve the Application. This is equal to app(Application::class).

uses the Facade of \Illuminate\Config\Repository.

uses a helper function to call app() to resolve the Config. You should only use env() when you are working in a config file located in config/.

public function __construct(Config $config)
uses dependency injection to resolve the Config.


When bootstrapping the Application, the config variables are loaded in this application using the Config.

So the Container uses Config to load the variables. Both are singletons, so calling them does not really affect the performance.

Which solution you choose sometimes depends on the use-case and mostly on preference.