Skip to content

Knowledgebase

Refreshing Laravel configuration after environment changes

development

A changed environment file does not always change a running Laravel application immediately. Cached configuration and long-running workers can continue using the previous values until the deployment refreshes them.

What you need before you begin

Confirm the correct release directory, PHP executable and production environment. Save the previous setting without exposing its secret value and decide how you will verify the change.

01 Refresh Laravel configuration after environment changes

  1. Change the value in the authorised production environment or secret store. Keep calls to env() within configuration files and let application code read the configuration values.

  2. Use the Laravel command for rebuilding the configuration cache in the intended release. Running the command from another directory can update a different application.

  3. Check other caches only when the changed feature depends on them. Avoid clearing a shared cache store indiscriminately because it may hold locks, sessions or data used by other applications.

  4. Restart or reload the affected queue workers and other persistent processes through the configured supervisor. Confirm replacement processes actually start.

  5. Record the change, its time and the expected behavior. Remove any temporary diagnostic route that was used to inspect configuration.

02 Example: rebuild only Laravel configuration for a reviewed change

After changing an approved environment value, use the correct Laravel release directory and PHP executable. The first command rebuilds this application’s configuration cache; the second displays a limited environment summary for checking the selected runtime.

Command example
php artisan config:cache
php artisan about --only=environment

Run the write command only in the intended release as part of the change you are applying. Application code should read config() values rather than calling env() throughout request handlers. Replace affected persistent workers through their supported process manager so they do not retain old settings. Do not clear an unrelated shared cache store.

Expected result: A controlled test of the affected feature uses the new setting from both web and worker paths. The review does not expose a complete database or mail configuration dump, and the previous setting remains recoverable if verification fails.

Confirm the expected result

Test the feature that uses the setting, such as a new mail delivery or a database connection. Use a safe status result rather than printing a complete environment or configuration array into a browser.

Troubleshoot unexpected results

If the old value persists, compare the active release path, process environment and cache file ownership. A separately managed worker may load a different environment from PHP web requests.

A common question

Why does env() return an unexpected value after deployment?

Once configuration is cached, Laravel does not load the environment file in the same way for arbitrary application calls. Put environment reads in configuration files and consume the resulting configuration throughout the application.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support