Since the beginning of the book, we have seen two possible schemes for managing Laravel configurations, using environment variables, for example:

.env

APP_ENV=local

And through the configuration files that the framework incorporates, for example:

config\app.php

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

And when we configure the cache, the email or the other, we always mention that you can modify one or the other. In this section, we will give some recommendations about when you should use one or the other.

For this, we must know its advantages that automatically bring us its shortcomings.

Environment variables are ideal for when we want to test multiple configurations in a project quickly, or when several people are developing on the same project and have different project configurations, in other words, they offer a quick and agile approach to accessing multiple configurations but this can also bring inconveniences, being able to change or delete environment variables by mistake from a single file can cause problems when changing from one mode to another without realizing it or deleting some environment variable necessary for the project; using it in production can cause problems precisely because of this freedom.

Configuration files are excellent for having the final production configurations of the project, therefore, it is where we should use the environment variables in development and the configurations in production and this is something that the framework already tells us, since if we see some configurations, we will often see a scheme like the following:

config\app.php

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

What it means is that if the APP_ENV environment variable does not exist then the configuration will take the value of production which is what we have to use in production

One of the big problems in software development is that when we are developing an application and from time to time we present modules to production it is to publish along with these changes our configurations used only in development and with the scheme presented above it can be solved just by avoiding uploading the env file to production and maintaining the production values in the corresponding configuration files

This does not mean that it is not advisable or professional to use environment variables in production if possible it should be avoided but you can use it with extreme care keeping a minimum of environment variables in production that may be essential to keep it as controlled as possible

Another good use of environment variables in production is when we make big changes to the project and upload it to production or there is an error in production that is difficult to repair by viewing the log and therefore we want to test in production if everything developed works as expected in these cases you can uncomment the environment variables in production

env

APP_ENV=local 
APP_DEBUG=true

Test the system on the server and when we see that everything is working as expected, comment again:

.env

# APP_ENV=local 
# APP_DEBUG=true

And with this, we once again avoid touching the project configurations, which are files that we must handle with extreme care.

Create our own configurations

It is possible to create custom configurations for our application, which is extremely useful to be able to customize these parameters when necessary, for example, if you want to install an electronic wallet like PayPal that requires defining access keys, it is most recommended to manage these accesses through configurations to be able to edit them more easily, they are also useful if we need to create any additional parameters for the correct operation of the application.

To do this, we must select the configuration file where we want it to be hosted. Here it is recommended that you choose the one that most closely matches the configuration to be created, for example, if you want to use passwords to access Dropbox or Google Drive, you can choose database.php or app.php if they are social login credentials, you can use auth.php for example.

Finally, we create the configuration, for example:

'app_route' => "production",

Like existing configurations, it is possible to use the env() helper function to take the value from .env if it exists there:

config\app.php

'app_route' => env('APP_ROUTE', "production"),

.env

APP_ROUTE=local

To access these settings, we use the config() helper function:

config('app')['env']

In which the name of the configuration file is specified as the first parameter and the key as the next parameter:

config('app')['env']

We could also directly reference the environment variable:

env('APP_ROUTE', "production")

But if it does not exist, exceptions and errors can occur in the project, so it is recommended that you create custom configurations instead and consume them using the config() helper function.

Create custom files

If necessary, we can create custom configuration files, we simply have to create the file within the config folder of the project in which we must have the same structure that the current ones maintain, for example:

config\custom.php

<?php
return [    'test_config' => env('TEST_CONFIG', 'VALUE'),
];

And to access the custom file, we do it in the same way with the current configuration files:

config('custom');