Laravel .env file, APP_KEY and config caching

Laravel reads its .env file with the phpdotenv library each time the application starts to handle a request or an Artisan command, and real environment variables set on the server or in the system take precedence over the file. Configuration files in config/ turn those variables into settings with env(), and the rest of the app reads settings with config(). In production, php artisan config:cache freezes that result into one cached file, after which Laravel doesn't read .env at all. If APP_ENV is provided from outside, Laravel loads .env.[APP_ENV] instead of .env when that file exists. This page follows the Laravel 13.x configuration documentation, checked October 30, 2026.

Which file Laravel loads

The first row surprises people who expect files to stack. .env.staging replaces .env, it doesn't override a few keys on top of it. Everything the staging app needs has to be in that one file.

Above any file sits the real environment. A variable set by the web server, the container runtime or a process manager overrides the same name in .env. That's also why a value exported by mistake on a server can shadow the file for months without anyone noticing.

What env() returns, and what it doesn't

All values in .env are strings, with a few reserved words. env() turns true and (true) into a boolean, false and (false) into false, empty into an empty string and null into PHP null. Quote values with spaces: APP_NAME="My Application".

env() has a second argument for a default, returned when the variable doesn't exist. Laravel's own config files use it everywhere, for example 'debug' => (bool) env('APP_DEBUG', false). That particular one deserves care: the documentation says APP_DEBUG must always be false in production, because true risks showing sensitive configuration values to your users.

config:cache changes the rules

Caching is recommended for every production deploy. php artisan config:cache combines all configuration files into one file that loads faster. From then on:

• .env is not loaded, neither during requests nor during Artisan commands.
• env() returns only external, system-level variables. A call to env('STRIPE_SECRET') in a controller or a job returns null in production unless the server's real environment has it.
• Settings keep the values from the moment of caching. Changing an environment variable later does nothing until you cache again or run config:clear.

The rule that follows is short: call env() only inside files in config/, and use config() everywhere else. Then caching can't break anything.

There's a quieter consequence. The cache is a file with the resolved configuration, so every secret that went through env() in a config file is now written in it in plain text. Treat that file like a .env: keep it out of images you publish, out of backups that many people can read, and out of the repository.

APP_KEY and rotation

APP_KEY drives Laravel's encrypter. The encryption documentation says to generate it with php artisan key:generate. Every cookie Laravel sets is encrypted with it, including the session cookie, so changing the key logs out every user, and data you encrypted with the old key can no longer be decrypted.

Laravel supports graceful rotation. Put the new key in APP_KEY and the previous ones in APP_PREVIOUS_KEYS, comma-separated. Laravel always encrypts with the current key and, when decrypting, tries the current key first and then each previous key. Keep old keys there until the data and cookies that used them have been re-encrypted or expired.

Laravel's own encrypted .env

php artisan env:encrypt encrypts .env into .env.encrypted, which you can commit. The key is printed once, and you keep it in a password manager or pass it as LARAVEL_ENV_ENCRYPTION_KEY to php artisan env:decrypt, which writes the plain .env back to disk. The --readable option keeps variable names visible and encrypts only values, which makes pull requests easier to review. The default cipher is AES-256-CBC.

That's a reasonable setup for a small team. Its limits are the usual ones for a shared file key: everyone with LARAVEL_ENV_ENCRYPTION_KEY can decrypt every committed version, there is one key for the whole file, and the decrypted .env ends up on disk on every machine that runs the app.

Run Laravel with values from Crunu

crunu run decrypts a Crunu environment in memory and starts your command with its variables in the process environment. Laravel treats them as external variables, which outrank .env, so no file has to exist. Each stage has its own Crunu environment and its own key, and a person with access to development never receives production values.

Why --no-reload in step 2? When a .env file exists, php artisan serve watches it and restarts its PHP server on changes. To let the restarted server read the file fresh, it starts that server with a filtered environment: every variable in $_ENV that isn't on a short passthrough list, such as APP_ENV and PATH, is removed, as the ServeCommand source shows. Depending on the variables_order setting in your php.ini, that can include the values crunu run passed in. --no-reload keeps the whole environment, and so does deleting .env once its values live in Crunu.

Step 3 is a choice with a cost. Caching under crunu run gives you the speed of a cached configuration, but the cached file then holds the production values on the server's disk, as described above. If that matters more than the speed gain, skip config:cache and let PHP read the environment on each boot. Either way, re-run the cache step after any value changes, or the app keeps the old ones.

For long-running processes such as queue workers, --restart on-change restarts the worker when a value changes, so a rotated API key reaches it without a deploy.

The web side needs more thought. Under PHP-FPM, the clear_env directive defaults to yes: FPM clears the environment of its worker processes and adds back only the variables listed with env[...] in the pool configuration. Starting FPM under crunu run therefore doesn't hand your variables to the PHP code by itself. You either list each variable in the pool with env[NAME] = $NAME, set clear_env = no for that pool, or use config:cache from step 3 so the web workers read the cached configuration instead of the environment. Laravel Octane and php artisan serve run as one long-lived command and inherit the environment of crunu run directly.

Related reading

• Rails for encrypted credentials with a master key.
• Rotate a Laravel APP_KEY and the Laravel APP_KEY generator.
• Docker Compose for Laravel in containers.
• How to share .env files with your team.