A complete guide to caching in Laravel

1. What the Laravel cache is for
2. Cache drivers
3. Basic usage
4. Cache tags for grouped invalidation
5. Application caching vs data caching
6. Clearing the cache
7. Choosing a driver
8. Conclusion

Caching is the cheapest performance win you have after indexing. The Laravel cache wraps file, database, Redis, and memcached behind a single Cache facade, so you write the same code regardless of where the data lives. This guide covers the drivers, the day-to-day API, cache tags, and how application caching differs from data caching.

#What the Laravel cache is for

Laravel caching stores the result of expensive work, a slow query, an API call, a rendered fragment, so you compute it once and serve it from fast storage afterwards. Everything goes through the unified Illuminate\Support\Facades\Cache facade, which talks to whichever store you've configured. Swap the store from file to redis and not a line of your application code changes.

#Cache drivers

Laravel ships with several drivers, configured in config/cache.php and selected per environment in .env:

• file — serializes values to storage/framework/cache. Zero setup, fine for a single small server. Slow and not shared across machines.
• database — stores cache rows in a table. Survives deploys, works across servers, but adds load to the DB you're usually trying to protect.
• redis — in-memory, fast, supports tags and atomic locks. The default choice for production.
• memcached — also in-memory and fast; supports tags but lacks Redis's richer data types and persistence.
• array — keeps values in PHP memory for the current request only. Used in tests.

Select the store in .env. Newer Laravel (11+) uses CACHE_STORE; older releases use CACHE_DRIVER:

# Laravel 11 and newer
CACHE_STORE=redis

# Laravel 10 and older
CACHE_DRIVER=redis

REDIS_HOST=127.0.0.1
REDIS_PORT=6379

For production, use Redis. It's fast, shared across web nodes and queue workers, and unlocks tags and locks. If your app can't reach the server, see Redis connection refused in Laravel. The database driver was the default in older skeletons; it works but doesn't scale as well under read pressure.

#Basic usage

The facade exposes a small, predictable API.

use Illuminate\Support\Facades\Cache;

Cache::put('key', 'value', now()->addMinutes(10)); // store with TTL
Cache::get('key', 'default');                       // read, with fallback
Cache::has('key');                                  // existence check
Cache::forever('key', 'value');                     // no expiry
Cache::forget('key');                               // delete one key

The method you'll reach for most is remember(). It returns the cached value if present, otherwise runs the closure, stores the result, and returns it, so the slow path runs only on a miss:

$users = Cache::remember('users.active', now()->addHour(), function () {
    return User::where('active', true)
        ->withCount('orders')
        ->get();
});

That single call replaces the read/compute/write dance and is the canonical way to wrap a slow query. Use rememberForever() for values that never expire on a clock and are invalidated explicitly instead.

#Cache tags for grouped invalidation

When several keys belong together, tags let you invalidate them as a group instead of tracking every key by hand. Tags are only supported on the redis and memcached drivers, not file or database.

Cache::tags(['users', 'billing'])->put('user.42.invoices', $invoices, 3600);

// Later, blow away everything tagged "users"
Cache::tags(['users'])->flush();

This is ideal for per-model caches: tag every entry for a user with user.{id}, then flush that one tag when the user changes, leaving the rest of the cache untouched.

#Application caching vs data caching

There's a second kind of caching in Laravel that has nothing to do with the Cache facade: application/config caching. These Artisan commands compile framework files into a single fast-loading file and matter most in production.

php artisan config:cache   # merge all config into one cached file
php artisan route:cache    # compile route definitions
php artisan view:cache     # precompile Blade templates

Run these on deploy. The catch with config:cache is that env() calls outside of config files return null once config is cached, so read environment values through config() only. These caches are about boot speed; the Cache facade is about your data. They are independent systems with independent clear commands.

For the bigger picture on tuning a production app, see the Laravel performance guide, and pair the config caches with OPcache enabled in PHP for the largest boot-time gains.

#Clearing the cache

Data cache and application caches clear separately:

php artisan cache:clear         # flush the data cache (Cache facade)
php artisan config:clear        # drop cached config
php artisan route:clear         # drop cached routes
php artisan view:clear          # drop compiled views
php artisan optimize:clear      # all of the above at once

For the full rundown of when and why to run each, see clearing the cache in Laravel. If you're on Redis specifically and need to flush at the store level, see clearing the Redis cache.

#Choosing a driver

A quick decision guide:

• Local / tiny single server: file — no dependencies, good enough.
• Tests: array — isolated per request, nothing to clean up.
• Multi-server, no Redis yet: database — shared and persistent, at some DB cost.
• Production: redis — fast, shared, supports tags and locks. The recommended default.

If you need cache tags, you must be on redis or memcached; file and database silently don't support them.

#Conclusion

The Laravel cache gives you one API over many backends: configure the store in .env, wrap slow work in Cache::remember(), group related keys with tags for clean invalidation, and keep application/config caching separate in your deploy step. Use Redis in production, and when something looks stale, reach for cache:clear or optimize:clear before you start debugging.