In a Laravel gym-membership app, why does env('PAYMENT_API_KEY') in a controller return null in production while it works locally?

## The symptom A gym-membership app charges monthly fees through a payment provider. A developer reads the provider's key straight from the environment inside a controller: ```php $key = env('PAYMENT_API_KEY'); ``` On a laptop the checkout works. After the production deploy, every charge fails because `$key` is `null`. The `.env` file on the server is present and correct, which makes the bug look impossible. ## How Laravel reads `.env` at boot Two things feed configuration in a Laravel app: - **`.env`** holds per-machine values as plain `KEY=value` lines. Laravel parses it with the **phpdotenv** library and places the values in the process environment. - **`config/*.php`** files return arrays. Their entries call the global `env()` helper, for example `'env' => env('APP_ENV', 'production')` in `config/app.php`, and the resulting values land in the **config repository** that `config()` reads. During boot the HTTP and console kernels run a list of bootstrappers. The order matters here: 1. `LoadEnvironmentVariables` loads `.env` into the environment, **unless** `$app->configurationIsCached()` returns true, in which case it returns immediately. 2. `LoadConfiguration` either `require`s the cached file in `bootstrap/cache/config.php` or, when there is no cache, executes every file in `config/` (where the `env()` calls run). Most production deploys cache the configuration, so step 1 is skipped and step 2 reads the cache. The `env()` calls inside `config/*.php` already ran when the cache was built, and their results are frozen in that file. An `env()` call anywhere else runs at request time, when `.env` was never loaded. ## What `env()` actually returns `env($key, $default = null)` delegates to `Illuminate\Support\Env::get()`, which asks phpdotenv's repository for the variable and falls back to the default when it is missing. So with a cached config: | Where the value lives | `env('PAYMENT_API_KEY')` in a controller | `config('services.payment.key')` | |---|---|---| | Only in `.env` | `null` (or the default you passed) | the value frozen in the cache | | A real server environment variable | the value | the value frozen in the cache | | Nowhere | `null` | `null` | Note the middle row: a variable set by the host or container is still in the process environment, so `env()` returns it. That is why the bug is described as "env() returns null for values that exist only in .env", and why it can appear on one server and not another. ## The fix Declare the variable once, in a config file, and read the config key everywhere else: ```php // config/services.php 'payment' => [ 'key' => env('PAYMENT_API_KEY'), ], // app/Http/Controllers/MembershipController.php $key = config('services.payment.key'); ``` `config/services.php` is the skeleton's conventional home for third-party credentials; a dedicated `config/payments.php` works the same way. ## Rules of thumb interviewers look for - **`env()` only inside `config/*.php`.** Every default Laravel config file follows this rule; application code, providers, jobs and views read `config()`. - **The default argument does not fix it.** `env('PAYMENT_API_KEY', '')` returns an empty string instead of `null`, which still breaks the charge, just less loudly. - **Fail loudly when a value is required.** `Config::string('services.payment.key')` throws `InvalidArgumentException` if the value is `null` or not a string, so a missing key stops the request with a clear message instead of reaching the provider. - **Nothing here depends on the `.env` file being missing.** It exists on the server; it is simply not read once config is cached. - **Tests will not catch it by default**, because the test suite runs without a config cache and loads the environment normally. ## Diagnosing it on a live server When a value is `null` in production and fine elsewhere, a short checklist settles it: 1. Check whether configuration is cached: the file `bootstrap/cache/config.php` exists on the server. 2. Run `php artisan config:show services.payment` to see the value the app resolved. If it is correct there, the config file is right and the bug is in code that bypasses `config()`. 3. Search the codebase for `env(` outside `config/`. Every hit is a candidate for the same failure. 4. Check whether the variable exists in the real process environment. If it does on one server and not on another, that explains why only some servers fail. A useful habit is a test or static-analysis rule that fails the build when `env(` appears outside `config/`, so the mistake never reaches a deploy. ## Why interviewers ask it It is the classic mid-level Laravel trap: the code works in every local and CI run and fails only in production. A good answer names the cause (config caching skips `.env`), the rule (`env()` in config files only) and the replacement (`config()` with a dot-notation key).