Laravel env() Returns Null in Production ?

Your Laravel application works perfectly on your local machine, but after deploying it to production, env() suddenly returns null instead of the expected value. 😕
One common reason is Laravel's configuration cache. If you run php artisan config:cache, calling env() directly outside configuration files can cause unexpected results.
The fix is simple: use env() inside configuration files and config() everywhere else in your application.

---

🔍 Why Does Laravel's env() Return Null in Production?​

Laravel uses environment variables to manage settings such as the application name, database credentials, debug mode, and default locale.
During development, your application typically reads environment variables from the .env file. However, production environments often use cached configuration to improve performance.
When you run php artisan config:cache, Laravel combines its configuration files into a cached configuration file. During subsequent requests, Laravel does not load the .env file in the usual way.
As a result, calling env() directly from a controller, service, model, or another application class may return null if the variable is not available in the process environment.
For example:

$locale = env('APP_LOCALE'); // ❌ May return null
$locale = config('app.locale'); // ✅ Recommended

The first line reads an environment variable directly. The second retrieves the value from Laravel's configuration system, which is designed to work with cached configuration.

---

✅ The Correct Way to Use env() in Laravel​

Laravel's recommended approach is straightforward: keep environment variable access inside configuration files, then use the config() helper throughout the rest of your application.

Step 1: Define the Environment Variable​

Add the following variable to your .env file:

APP_LOCALE=en

This sets the application's default locale to English.

Step 2: Read It Inside a Configuration File​

Open config/app.php and make sure the locale setting uses env() with an appropriate default value.

'locale' => env('APP_LOCALE', 'en'),

The second argument, 'en', is the fallback value Laravel uses when APP_LOCALE is not defined.

Step 3: Access the Configuration Anywhere in Your Application​

Now, retrieve the locale using config() in your controllers, services, jobs, or other application classes.

$locale = config('app.locale');

This approach works with both cached and uncached configuration, provided the cached configuration reflects the intended settings.
You can use the same pattern for other application settings, such as mail configuration, service credentials, and feature flags.

---

⚙️ How to Fix the Problem After Deployment​

If your application already runs in production and env() is returning null, follow these steps.

1. Search your application code for direct calls to env(), especially inside the app/ directory.
2. Move environment variable references into the appropriate files under config/.
3. Replace direct calls to env() in application code with the corresponding config() calls.
4. Rebuild the configuration cache after updating the environment or configuration files.

Run the following command from your Laravel project's root directory:

php artisan config

This command rebuilds the configuration cache using the current environment and configuration files.
Important: If you change environment variables after caching the configuration, rebuild the cache so the application picks up the intended values. In deployments where configuration is cached during the build process, make sure the cache is generated with the correct environment settings.

---

🚨 Common Mistakes to Avoid​

Here are a few mistakes that can lead to confusing configuration problems.

Mistake	Recommended approach
Calling env() inside a controller	Use config() instead
Calling env() inside a service class	Use config() instead
Changing .env without rebuilding the configuration cache	Rebuild the cache when appropriate
Forgetting a default value for optional settings	Define a sensible fallback in the configuration file
Assuming local and production environments behave identically	Test the application with cached configuration

One additional detail matters: config() does not automatically read a changed .env file. It returns the application's currently loaded configuration. If the configuration cache contains an old value, you must refresh that cache.

---

🛠️ How to Find Incorrect env() Calls​

If you want to audit an existing Laravel project, search for direct env() calls inside your application code.
On Linux or macOS, you can use grep:

grep -RIn --include='*.php' 'env(' app/

This searches PHP files under app/ and displays matching lines with their file names and line numbers.
Keep in mind that a text search can also find comments or unrelated matches. Review each result before changing it.
You should generally expect direct environment variable access to live in configuration files under config/, rather than throughout your business logic.

---

❓ Frequently Asked Questions​

----------------------

Can I use env() in a Laravel controller?​

You should avoid doing so. Use config() to retrieve application settings in controllers, services, models, and other application code.

Why does env() work locally but return null in production?​

A common reason is that production uses php artisan config:cache, which changes how Laravel loads configuration and the .env file. The variable may not be available through PHP's process environment, so a direct env() call can return null.

Does config() work when Laravel configuration is cached?​

Yes. Laravel's config() helper reads the application's loaded configuration, including configuration loaded from the cache.

Should I run config after changing the .env file?​

Yes, when your deployment uses cached configuration and the changes affect configuration values. Rebuild the cache as part of your deployment process so the application uses the intended settings.

---

🎯 Final Takeaway​

The key rule is simple: use env() in configuration files and config() everywhere else.
Following this practice helps prevent unexpected null values, makes production deployments more predictable, and keeps your Laravel configuration consistent across development, testing, and production.
💬 Have you ever spent time debugging a Laravel production issue that turned out to be a configuration cache problem? Share your experience with other developers.