• 5 min read

How to Properly Use Laravel Config and Environment Variables Together

Today, we’re diving into something that might seem small but is actually incredibly important in your Laravel journey: how to properly use Laravel’s config files together with your .env variables.

Today, we’re diving into something that might seem small but is actually incredibly important in your Laravel journey: how to properly use Laravel’s config files together with your .env variables.

This is one of those topics that can really level up the way you structure and manage your application, especially if you’re building apps that need to run in different environments (development, staging, production, etc.).

The config/ directory

The config/ directory is where Laravel stores all of your application’s configuration files. Each file inside this folder (like app.php, database.php, mail.php, etc.) contains settings related to a specific part of the framework.

These config files are just plain PHP files that return associative arrays — meaning they’re super easy to read, write, and customize. Whether you want to change the default timezone, add custom values, or pull in data from your .env file, it all happens here.

Laravel uses this directory to define settings that you can easily adjust based on your environment — without ever touching your app’s core logic. This makes your code more maintainable and much easier to scale across development, staging, and production environments.

The .env and .env.example files

We’ve got two environment-related files: .env and .env.example.

The .env file is where you define all your environment-specific configuration values — things like your database credentials, app name, debug mode, and more. This file is unique to your local setup, and it should never be pushed to version control (which is why it’s listed in the .gitignore file).

Then there’s the .env.example file. This one acts as a template. It contains the same structure and keys as your .env file, but without any sensitive values. You do commit this one to version control, so your teammates — or your future self — can copy it and rename it to .env when setting up the project.

The relationship between config/ and .env

Before we talk about how Laravel’s config files and .env variables work together, let’s first understand how you access them individually.

Laravel gives you two powerful helper functions:

  • config() — used to retrieve values from the configuration files inside the config/ directory.
  • env() — used to retrieve values directly from the .env file.

Here’s the key thing to remember:

You should not use env() directly in your application logic.

That’s right. Laravel’s best practice is to define your environment-specific variables in the .env file, reference them inside your config files, and then access them throughout your application using the config() helper.

This separation keeps your application logic clean, secure, and environment-agnostic.

Accessing config values

Let’s walk through a complete example of how you can define and retrieve configuration values the Laravel way.

If you open your .env file, you’ll see lots of variables, but for this example let’s work with the variable called APP_NAME.

APP_NAME=Laravel

Now, if you check the config/app.php file, you’ll see how Laravel connects this variable to a configuration key:

<?php

return [
    'name' => env('APP_NAME', 'Laravel'),
];

The env() function fetches the value from .env (in this case APP_NAME), and Laravel is the fallback if no value is found.

To retrieve this value in your application, you don’t call env('APP_NAME') directly. Instead, you use the config() helper:

config('app.name'); // Returns "Laravel"

Now, let’s add our own value to config/app.php. Right below the name key, add:

'author' => env('APP_AUTHOR', 'Code With Dary'),

Then, define it in your .env file:

APP_AUTHOR="Code With Dary"

You can now retrieve it anywhere in your app like this:

config('app.author'); // Returns "Code With Dary"

Unlimited config files

The great thing about Laravel’s config system is that you’re not limited to just app.php. You can create unlimited configuration files in the config/ directory, and Laravel will automatically load them.

For example, you could create a file called config/blog.php:

<?php

return [
    'title' => env('BLOG_TITLE', 'The best blog ever'),
    'posts_per_page' => 10,
];

You have complete freedom to organize your settings into logical files and retrieve them cleanly with config().

Nested configuration values

You’re not limited to flat key-value pairs. Laravel lets you organize related settings into nested arrays.

A nested array is simply an array that contains one or more arrays inside it. In other words, it’s an array within an array.

<?php

return [
    'stack' => [
        'backend' => env('APP_BACKEND', 'Laravel'),
        'frontend' => env('APP_FRONTEND', 'React'),
    ],
];

You can access the values using the dot notation. Here’s the breakdown:

  • app is the name of the config file (config/app.php)
  • stack is the first key in the array
  • backend is the key inside the stack array
config('app.stack'); // Returns the full array

config('app.stack.backend'); // Returns 'Laravel'

Conclusion

Laravel’s configuration system might seem like a small detail, but it plays a huge role in making your applications flexible, clean, and environment-aware. The key takeaway is this: use the .env file to store environment-specific values, like credentials and app-level settings. Then, reference those values inside your config files using the env() helper — not directly in your application logic. Throughout your app, always use the config() helper to access those values. This separation keeps your logic clean, your settings centralized, and your app ready to scale across development, staging, and production environments.

Laravel doesn’t limit you to the default config files like app.php or database.php. You can create unlimited custom config files, organizing your settings however makes the most sense for your project. And when your config structure grows, nested arrays and dot notation make it easy to keep things organized and easy to access.

By following this approach, you’re not just following best practices — you’re setting yourself up for a more maintainable and scalable Laravel project. Thanks for reading, and stay tuned for the next post, where we’ll begin setting up the database!