Clearing Application Cache in Laravel

"Clear the cache" in Laravel isn't one command — the framework caches several distinct things independently, and a change that isn't showing up usually means the wrong cache was cleared, not that caching should be avoided altogether.

The five caches

php artisan config:clear    # config/*.php values combined into bootstrap/cache/config.php
php artisan route:clear     # compiled route table
php artisan view:clear      # compiled Blade templates in storage/framework/views
php artisan event:clear     # cached event-to-listener mappings
php artisan cache:clear     # the actual application cache store (Cache::get/put)

Or clear everything at once during local development:

php artisan optimize:clear

Why a config change might not apply

If php artisan config:cache has been run (typically as part of a production deploy), Laravel stops reading config/*.php and .env entirely and reads only the pre-built bootstrap/cache/config.php file instead. Editing .env after that point has no effect until config:clear or a fresh config:cache is run — a very common source of "I changed the .env file but nothing happened" confusion.

Why a Blade change might not apply

Compiled views in storage/framework/views are normally regenerated automatically whenever the source .blade.php file's modification time is newer than the compiled version — so view:clear is rarely needed locally. It becomes necessary after a deploy where file timestamps get reset (a fresh git checkout, some CI/CD pipelines), because Laravel then can't tell the compiled view is stale by timestamp alone.

The application cache specifically

cache:clear only affects the store configured in CACHE_STORE (file, database, Redis, etc.) and only the default store — if the app also uses a named store via Cache::store('redis')->put(...), that store isn't touched by a plain cache:clear call. Clearing a specific store:

php artisan cache:clear --store=redis

Clearing one cache key instead of everything

Wiping the entire cache store is a blunt instrument in production — anything else cached (rate limiter state, other unrelated cached queries) gets evicted along with the key that actually needed refreshing. Prefer removing just the specific key when possible:

Cache::forget('homepage-featured-products');

Production deploy checklist

A typical zero-downtime deploy re-caches everything after pulling new code, rather than leaving the caches cleared:

php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache

Running the app with uncached config/routes in production works, but re-parses config files and rebuilds the route table on every request — cheap for a small app, measurable overhead for a large one.