Use Settings or Environment Variables? - Opinion

▶

In Laravel, one of the most important topics when developing a robust application is understanding how to manage configuration and environment variables. Although both concepts seem similar, their purpose and time of use are distinct. In this article, I explain, from a practical standpoint, how they work, when it is best to use each one, and how to apply them correctly in real projects.

Why does Laravel separate configurations and environment variables?

Laravel organizes sensitive information and configurations at two levels: environment variables (.env) and configuration files (/config). This separation is not accidental but a key decision for code security and maintenance.

The purpose of the .env file

The .env file stores data that changes according to the execution environment: database, API keys, external services, or application mode (development or production). Laravel manages them through the Dotenv package, which loads the variables when the framework starts.

These variables should not be shared or versioned. They are specific to the server, so a change in production does not affect your local environment. For example:

APP_ENV=local APP_DEBUG=true PAYPAL_CLIENT_ID=xxxx

The point is that your client can inspect the application without jeopardizing its stability. That is, they shouldn't be able to "break it," create strange data, or delete the sample information. I think it's quite clear now: the demo mode allows viewing and interacting with the app, but without altering the established records.

How the configuration system in /config/*.php works

Configuration files, on the other hand, define the application's internal parameters: logging, cache, mail, queues, etc. Each file in /config contains a PHP array with values that can reference variables from the .env file.

For example, in config/app.php:

'name' => env('APP_NAME', 'MyApp'), 'debug' => env('APP_DEBUG', false),

Differences between env() and config() in Laravel

The most common confusion is when to use env() directly or when to rely on config(). Although both functions return configurable values, their scope and purpose are different.

When to use environment variables

Only use env() to initialize configurations. You should never call it directly within your application code (controllers, services, views). In those places, it is recommended to use config(), as variables can be cached and not update correctly.

When to create a custom configuration

When a value affects the business logic and not just the environment, it's appropriate to create your own configuration file. This allows you to define default values, maintain coherence, and avoid breaking the application if a variable is missing.

Practical example: demo mode controlled by environment variable

In my case, I implemented a demo mode for a sample application. I wanted users to be able to interact with the app without altering sensitive data. For that, I created a custom environment variable:

APP_DEMO=true

And in the code, I used it simply:

if (env('APP_DEMO')) { // Block certain actions }

Why not use a configuration instead of environment variables?

You're probably asking yourself: why on earth didn't I use a configuration?
On my YouTube channel, I have several videos discussing the use of environment variables and custom configurations.

Both are valid options, but in short, I almost always recommend using configurations, as working directly with environment variables can be risky.

For example, if a variable is not defined—imagine you delete the PayPal environment variable—you would break the entire application, because PayPal needs those keys no matter what.

How to create and read custom configurations in Laravel

Create a file in /config

You can create a config/demo.php file with content like:

return [ 'enabled' => env('APP_DEMO', false), ];

Access values from controllers or views

Then, you can access the value from anywhere in your application:

if (config('demo.enabled')) { // Execute demo mode }

This approach is safer, as it keeps the logic centralized and compatible with configuration caching.

Establish secure default values

Always define default values in env() calls. That way, if a variable is not present, the system will know what to do:

'paypal_client_id' => env('PAYPAL_CLIENT_ID', 'default'),

Common errors and how to avoid them

When we use the configuration scheme, the system is designed to return the environment variable's value by default if it exists.
That has the highest priority. But if it is not defined, it then takes a default value.

This is what we normally implement in 99.9% of cases.
That's why I say the ideal is to follow that structure. Everything comes this way by default: the variable is used if it's there, and if not, the base configuration is used.

Deleting or renaming a critical variable can break the application. That's why defining configurations with default values is good practice.

In short, we want to obtain a value either from the environment variable or from the configuration, but with the assurance that it exists.

If we do it correctly, we avoid errors. But if we do it incorrectly and call the variable directly, it is just as risky as having no configuration at all.

When to create a custom configuration

Every time you want to create a custom configuration—as we did in this course with the PayPal ones—the ideal is to define them correctly.
Here, for example, the production configurations should be, although I don't place them for obvious reasons (this is a sample project).
But in a real application, they must be established.

Conclusion

The difference between configurations and environment variables in Laravel is fundamental for developing secure, predictable, and scalable applications. Environment variables serve to define the environment and sensitive data; configurations, to establish the application's internal behavior.

In my experience, I prefer to keep things simple. If I just need to know if something is active, I use an environment variable. But if the value affects the system's logic or might be missing, I opt for a configuration with a default value. That balance between simplicity and robustness is the key to clean and stable code.

Frequently asked questions about configurations and variables in Laravel

• What is the difference between config() and env()?
  env() reads environment variables, while config() gets values defined in the /config files.
• Where are configurations stored in Laravel?
  In the /config folder, where each file defines a set of application parameters.
• Is it safe to use environment variables directly?
  No. In production, they should be accessed via config(), not env() directly.
• What happens if a variable is missing in the .env file?
  If a default value is not defined, Laravel may throw errors or behave unexpectedly.