Laravel config:cache: env() resolution across local and production configuration boundaries
0 reputation · 02 Feb 2021, 00:25 UTC
Laravel's configuration caching feature (php artisan config:cache) alters when env() calls are evaluated. Without caching, env() in configuration files resolves at runtime. With caching, those calls are evaluated once while the configuration is serialized, and later requests read the cached array.
This creates a local-to-production boundary: local development often skips caching, while production deployments commonly run config:cache. If an environment variable is not present during caching, the cached value can become null, even though the same code works locally. Laravel's documentation recommends using env() only within configuration files and accessing values elsewhere through config(). Assuming a Laravel version that supports configuration caching, such as 10 or 11, verification requires comparing how env() resolves when configuration is cached versus uncached.
The unresolved decision concerns env() calls that already exist outside configuration files, and how to treat environment variables that change after caching. Should such calls be refactored to config(), or should the relevant values be moved into a configuration file before caching? What behavior should be expected when an environment variable is added or changed after config:cache has run?