Lumen and PHP-FPM: where should production configuration enter?

Direct Answer

Make PHP-FPM pool environment variables the single authoritative source for production configuration. Reserve .env exclusively for local development defaults. When configuration caching is enabled, build the cache in the production environment with the FPM-provided variables present and no production .env file; after the cache is built, config() reads only the cached values and later changes to either source are inert until the cache is rebuilt.

Why PHP-FPM Pool Env Vars Win

• Explicit production channel: env[VAR]=value in the pool configuration is the deliberate, auditable injection point for the hosting layer.
• Prevents masking: Lumen 5.8 loads .env during bootstrap. If a production .env exists and the dotenv loader overwrites existing environment variables, it can silently override the FPM values. Omitting the file (or using a non-overwriting loader) guarantees FPM values take precedence.
• Secrets hygiene: Keeping secrets out of version control is easier when they are only in the FPM pool (managed by infrastructure automation) and never written to a file in the repository.

Configuration Caching Precedence

When php artisan config:cache runs, it resolves all env() calls at that moment and serializes the resulting configuration array. The cache file becomes the sole source for config() thereafter. Therefore:

1. Run the cache build as the same user and under the same environment as the FPM workers (same pool env vars, no production .env).
2. Restart or reload PHP-FPM after the cache is written so workers pick up the new cache.
3. Any subsequent change to FPM env vars or a newly introduced .env will be ignored until the next cache rebuild.

Deployment Contract Checklist

• Production .env absent or root-owned 0600 and non-authoritative (dotenv loader set to not overwrite).
• APP_DEBUG=false in FPM env.
• Call env() only inside config/*.php files; never in request paths.
• Expose a minimal health endpoint returning only non-sensitive keys (e.g., config('app.env'), config('app.debug'), config('cache.default'), or a custom deploy.config_stamp) for cross-environment verification.
• Rebuild config cache on every deploy after environment variables are set.

Verification Steps

1. In bootstrap/app.php, confirm the exact dotenv call (e.g., Dotenv::createImmutable(...)->load() vs Dotenv::createMutable(...)->load()) and the .env path.
2. In the PHP-FPM pool file, confirm clear_env setting and that required env[...] entries exist.
3. Deploy a temporary route returning config('app.env') === 'production' and getenv('DEPLOY_CONFIG_STAMP') !== false; remove after verification.
4. Build the config cache under the FPM user/env, reload FPM, and confirm cached values match the FPM-provided source.

One Missing Diagnostic Detail

Can your hosting layer set env[...] directives in the PHP-FPM pool or set clear_env = no? If the answer is no, you cannot rely on FPM pool vars as the authoritative source. In that case, fall back to a single securely provisioned .env file (root-owned, 0600, deployed via secret management) as the sole production source, and still build the config cache with that file present.