Redis Cache Backend for Drupal. Configuration, Failsafe Setup, and Why You Need Both

Configuring Redis as Drupal's cache backend is one of the highest-impact performance changes you can make to a busy Drupal site. The difference in response times is immediate and measurable. What most tutorials do not cover is what happens when Redis goes down — and if you have not configured a failsafe, the answer is: your Drupal site goes down with it.

This post covers the full setup: connecting Drupal to Redis, configuring cache bins appropriately, and adding a failsafe so a Redis failure degrades gracefully instead of causing a site outage.

Prerequisites

This assumes:

• Drupal 9, 10, or 11
• Redis installed and running (locally or on a dedicated instance)
• The redis Drupal module installed (composer require drupal/redis)
• PHP phpredis extension or predis library available

I recommend phpredis over predis for performance. You can verify it is available with php -m | grep redis.

Basic Configuration

In your settings.php (or settings.local.php for environment-specific config):

$settings['redis.connection']['interface'] = 'PhpRedis';
$settings['redis.connection']['host'] = '127.0.0.1';
$settings['redis.connection']['port'] = 6379;
$settings['redis.connection']['password'] = 'your_redis_password'; // if auth is set

$settings['cache']['default'] = 'cache.backend.redis';
$settings['cache_prefix']['default'] = 'mysite_';

The cache_prefix is important if you are running multiple Drupal sites on the same Redis instance. Without it, cache keys from different sites will collide.

Configuring Cache Bins Selectively

Not all cache bins should go to Redis. The bootstrap and config bins are read very early in the Drupal bootstrap process, and if Redis is unavailable at that point, Drupal cannot recover gracefully. I recommend keeping those on the database backend:

$settings['cache']['bins']['bootstrap'] = 'cache.backend.database';
$settings['cache']['bins']['config'] = 'cache.backend.database';
$settings['cache']['bins']['discovery'] = 'cache.backend.database';

Everything else — render, page, data, dynamic_page_cache, search — can go to Redis and benefit significantly from the in-memory speed.

The Failsafe — The Part Most Tutorials Skip

If Redis becomes unavailable and you have set the default cache backend to Redis without a failsafe, Drupal will throw connection errors and your site will go down. This is not theoretical — Redis can restart, run out of memory, or become unreachable due to a network issue.

The Redis module provides a built-in failsafe mechanism. Add this to your settings.php:

$settings['redis.connection']['interface'] = 'PhpRedis';

// Enable the failsafe.
if (class_exists('Redis', FALSE)) {
  $settings['cache']['default'] = 'cache.backend.redis';
}
else {
  // Redis PHP extension not available, fall back to database.
  $settings['cache']['default'] = 'cache.backend.database';
}

This handles the case where the PHP extension is missing, but not a live connection failure. For that, wrap the Redis connection check:

try {
  $test = new Redis();
  $test->connect('127.0.0.1', 6379, 1); // 1 second timeout
  $settings['cache']['default'] = 'cache.backend.redis';
}
catch (Exception $e) {
  $settings['cache']['default'] = 'cache.backend.database';
}

This runs on every request bootstrap, which has negligible overhead compared to the protection it provides. When Redis is down, Drupal falls back to the database automatically with no manual intervention needed.

Redis Memory Configuration

Redis by default will grow its memory usage unbounded. For a Drupal cache backend, you want to configure a memory limit and an eviction policy. In your redis.conf:

maxmemory 512mb
maxmemory-policy allkeys-lru

allkeys-lru evicts the least recently used keys when the memory limit is reached, which is exactly the right behaviour for a cache. Without this, Redis will either refuse writes (causing errors) or consume all available memory.

Verifying It Is Working

After deploying, verify Redis is actually being used:

redis-cli monitor

Then visit a page on your Drupal site. You should see a stream of SET and GET commands with your configured prefix. If you see nothing, the configuration has not taken effect.

You can also check via Drush:

drush php-eval "var_dump(\Drupal::cache()->get('test'));"

And confirm via the Drupal admin at /admin/reports/status — if the Redis module is correctly connected, it will report the Redis version and connection status.

Performance Impact

On a high-traffic Drupal site serving millions of pageviews per month with high editorial frequency, switching from database cache to Redis reduced average page generation time from ~450ms to ~90ms for cached pages. Database query count per request dropped by over 60% on content-heavy pages.

The failsafe configuration added zero observable overhead during normal operations and prevented what would have been a full site outage during a Redis restart following a server maintenance window.

If you are running a Drupal site at any meaningful traffic level and are not using Redis, this is the highest-ROI infrastructure change available to you. Just make sure the failsafe is in place before you deploy.