Magento 2 & Redis: Boosting Cache and Managing Sessions the Right Way

Redis: a fast, in-memory ally

Redis is a lightweight key-value store running in memory, widely used for caching, sessions, queues, and real-time data handling.

Magento 2 doesn’t require Redis, but it definitely benefits from it — especially when you’re working with multiple front servers or scaling infrastructure.

📌 Redis is still the officially recommended solution by Magento.
Check out the latest compatibility notes here:
👉 Adobe Commerce System Requirements

Redis use cases in Magento 2

1. Application cache (backend cache)

Magento can store many of its internal caches in Redis instead of writing them to the file system.

Here’s a typical list of caches from the env.php file:

'config', 'layout', 'block_html', 'collections', 'reflection',
'db_ddl', 'compiled_config', 'eav', 'customer_notification',
'config_integration', 'config_integration_api',
'graphql_query_resolver_result', 'config_webservice', 'translate'

🔍 A quick word about the config cache:

It’s slow to rebuild.
Magento automatically flushes it during setup:upgrade.
No need to flush it again manually unless really necessary.

In local dev, clear it only when you:

update Composer packages,
touch a non-layout XML file,
or encounter some weird, cache-related behavior.

2. Session storage

Storing sessions in Redis ensures they are centralized and accessible to all front servers.
If you store sessions in files, each server handles its own, leading to session loss when switching from one front to another.

👉 With Redis, user sessions are consistent across all your front servers.

💡 One Redis instance per Magento project is enough — don’t assign one Redis per front.

3. Full Page Cache (FPC)

Yes, Magento supports using Redis for FPC too.
But in most real-world scenarios, Varnish remains the recommended choice, thanks to better performance and native Magento integration.

Redis locally with Docker

If you’re not using Warden and want to spin up Redis locally:

You can run the official Redis image as-is — no customization needed.
Don’t map any volumes: Redis is a cache; it’s fine to reset it every time you restart your local stack.

A simple Docker Compose entry is enough to get going.

Local dev: caches on or off?

By default, working with most caches disabled makes development smoother.
But there are exceptions:

✅ Disable caches when:

building new features,
debugging core behavior,
working on logic that shouldn’t be masked by caching.

⚠️ Enable them when:

optimizing performance (e.g. block caching),
trying to reproduce bugs that only happen in production.

👉 Adapt your caching setup depending on what you’re working on.

Summary

Redis is highly recommended in Magento 2 for:
- Application cache
- Session storage
- (Optionally) FPC — though Varnish is usually better
Be careful with the config cache: it gets flushed during setup:upgrade and shouldn’t be cleared lightly
In local dev: disable most caches by default, but re-enable them if the task requires it
Redis works great in Docker — lightweight, no volume needed, zero config

Update for Magento 2.4.8

Starting with Magento 2.4.8, Redis is no longer recommended because it is no longer fully open source (it now uses the restrictive RSAL license)
Magento recommends switching to Valkey, a community-driven fork that is 100% open source (Apache 2.0 license) and fully compatible with Redis: same functionality, same ports, and no code changes required.
You just need to replace the Docker image with valkey/valkey:8.0, and everything will continue to work as before.