Drupal Redis or Valkey cache backend setup

When a Drupal site should move cache storage out of the database

A Drupal site should consider moving cache storage out of the database once the database is spending a meaningful share of its capacity on cache reads, writes and locks instead of content queries. On a busy site, every anonymous and authenticated page build can write cache entries, and the cache, lock, flood and queue tables are written to constantly. When those writes queue behind content editing, search indexing or cron jobs, the symptoms usually show up as slow page builds, lock waits and database connections piling up during traffic peaks. Before deciding, check where the time goes: review database slow query logs and table write activity for the cache and lock tables, and compare page response times with the cache backend under load. If cache tables dominate, a Redis or Valkey backend is a reasonable next step.

Teams with modest traffic, a single web server, or content that changes rarely often run well on the database for cache storage. Drupal supports MariaDB, MySQL, PostgreSQL and SQLite, and the database is the default store, so the simplest option is to tune it first, reduce unnecessary cache writes by reviewing contributed modules and custom code, and confirm the caching defaults in your environment. Moving cache to Redis or Valkey is not a free change. It adds a separate service the team must run, patch, back up or accept the loss of, monitor for memory pressure and eviction, and secure on the network. That operating cost recurs for the life of the site, so the decision should be made with the operations team, not only the developers who see the slow pages.

Confirm three things before scoping the work: how many web servers share the site and whether they can reach one cache service, how much of the site's peak load is authenticated traffic that bypasses page caching, and who will own the Redis or Valkey service after launch. If the answers point to a shared, high-write cache across several servers, the move is justified and should be planned as its own piece of work. Your hosting team should also confirm the supported Redis or Valkey versions for your Drupal release with the Drupal.org system requirements page, since the cache backend must match what your platform supports.

What moves from the database to Redis or Valkey, and what stays

Drupal keeps several kinds of transient and operational data outside of content, and a Redis or Valkey backend can take over only some of them. The main candidates are cache bins, the render, data and dynamic page caches that core writes to the cache_* tables, along with locks (the lock system that prevents two processes running the same task), flood control (the counters that throttle failed logins and similar events) and queues (the items waiting for workers). Each category is handled by its own service in core, and the contributed Redis module (the Redis module on Drupal.org) replaces the storage behind some of these services through settings in settings.php. Which services it covers, and whether flood control or queues are included, depends on the module version and the Drupal core version in use, so confirm the supported list for your exact combination before writing a plan.

Content, configuration and user records stay in the relational database. Nodes, entities, revisions, menu and block configuration, file metadata, users, roles and permissions are persistent data that Drupal must read and write transactionally, and a cache backend does not replace them. Putting cache in Redis or Valkey therefore shrinks the database load from cache churn but does not change the database backup, restore or sizing work. Treat the database as the system of record in your recovery plan, and treat the cache backend as rebuildable. Confirm this split with the database layout your site actually uses, because contributed modules can store their own data in tables that a cache backend will never touch.

The practical decisions are which bins move, which services stay on the database, and what a cache loss means for each. A cold cache is usually tolerable for render caches but can be risky for locks held during long operations, and a flushed flood table can reopen a login window. Ask the team to list every contributed module that writes to cache, lock or queue storage, and check each against the Redis module's documented behavior for your versions. Record the result as a short table in the design document so that operations staff know which failures are cosmetic and which need intervention.

Redis or Valkey configuration options and when each fits

This table compares the main ways to run the Redis or Valkey service behind a Drupal cache backend, along with persistence and eviction settings. Read each row for the situation it suits, the trade-off it carries, and the questions to settle with your vendor or hosting provider before you commit.

Option	When it fits	Main trade-off	Confirm before you commit
Standalone instance	Single-site Drupal on one web tier where cache loss only means a slower warm-up	No automatic failover, so a host failure empties the cache and can interrupt locks and queues until restart	Restart behavior, backup options, and whether your team will accept a cold cache after host loss
Primary with replicas and Sentinel failover	Busy sites where a cache outage would hurt, and the team can run three or more monitored nodes	More moving parts; clients must support Sentinel, and failover can briefly reject writes	Client library and Drupal Redis module support for Sentinel, and the failover timeout your team accepts
Managed Redis or Valkey service	Teams that prefer the provider to handle patching, replacement and multi-zone placement inside their own cloud account	Less control over configuration and eviction internals; cost recurs with capacity and replica count	Supported engine version, which settings are editable, network placement, and the provider's failover behavior
Clustered deployment	Datasets too large for one node, or when sharding across nodes is required for capacity	Drupal cache and lock keys must be checked for cluster compatibility, and multi-key operations are constrained	Whether the Drupal Redis integration and your client library support cluster mode for every cache bin you plan to move
Persistence on	When losing cached lock, flood or queue data on restart would cause real operational harm	Disk writes add latency and storage needs, and restored data may be stale for cache purposes	Snapshot or append-only file choices, and whether queue data is meant to survive a restart at all
Persistence off	Pure cache use where Drupal can rebuild every entry from the database	A restart loses everything, including queue items if they share the same instance	Whether queues and locks use a separate instance, since mixing them with persistence off risks lost work
Eviction policy set to an LRU or LFU variant	Cache-only instances where the memory limit should drop old entries instead of rejecting writes	Evicted entries can include items your team expected to keep, so cache-tag consistency must be verified	Which policy your engine version offers, and whether queue and lock keys are excluded from eviction
Eviction policy set to no eviction	Instances holding queue or lock data that must not be silently dropped	Once memory is full, writes fail, which can break page builds and cron jobs	Memory alarms, headroom plans and what the hosting provider does when the memory limit is reached

How memory limits and eviction policy can break locks and queues

A Redis or Valkey instance that serves cache, locks, flood control and queues has one memory budget and one eviction setting for all of them. The cards below cover the decisions that decide whether a full cache quietly drops the keys Drupal needs to keep running correctly.

Size memory against real cache volume

Cache entries grow with page variants, languages, roles and render cache contexts, so a site's cache footprint can differ sharply from its content volume. Measure the cache bins in a staging copy under realistic traffic, then set maxmemory with headroom for lock, flood and queue keys. Ask the Redis or Valkey service owner which memory figure they will alert on before go-live.

Pick an eviction policy that spares lock keys

The maxmemory-policy setting decides which keys Redis or Valkey removes when memory is full. A policy that evicts from all keys can remove a lock or queue item as readily as a cache entry, while a volatile policy only removes keys that carry a TTL. Confirm with the Drupal Redis module documentation and your Redis or Valkey version which keys carry TTLs, and test the chosen policy under memory pressure.

Separate cache from lock and queue storage

Putting cache bins on one instance and locks, flood control and queues on another, or at least in a separate logical database, stops a cache flood from evicting work items. Separation adds a second service to run and monitor, so weigh that cost against the risk of a queue losing items during a traffic spike. Decide this before the first production deploy, since moving keys later means a planned cutover.

Align persistence with the recovery goal

Snapshots (RDB) and append-only logging (AOF) trade write overhead against how much data a restart can lose. Cache can usually be rebuilt, but a queue item or lock state lost in a crash may mean a missed job or a stuck process. Agree with the platform team how much queue data may be lost in a failover, then set save or appendonly to match that answer and test a restart.

Monitor evictions and fragmentation

A rising evicted_keys count is the first sign that memory pressure is removing data, and mem_fragmentation_ratio shows whether allocated memory is far above what the data uses. Alerts on both, plus queue backlog and lock timeouts in Drupal logs, let the team act before jobs fail silently. Ask the Redis or Valkey operator which metrics their monitoring exports and set thresholds from observed baselines rather than defaults.

Setting up a Redis or Valkey backend for Drupal

This sequence moves Drupal's cache, lock, flood and queue storage off the database and onto a private Redis or Valkey service, with a checked rollout at each stage. The result is a site where cache behavior and locking are verified on one web node before the change reaches the rest of the fleet.

Confirm Drupal core and PHP versions
Before any infrastructure work, the team checks the running Drupal core version and the PHP version on every web node against the supported requirements. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later, so a site on an older PHP runtime must be upgraded first. The check is complete when the version report from each node matches the core release the team intends to run, and the upgrade path for any mismatch is written down.
Deploy the cache service in a private network
The platform or infrastructure team deploys the Redis or Valkey service inside the same private network as the web nodes, with no public address and authentication enabled. Confirm the exact server version and any module compatibility with your Drupal release before selecting the build, since support varies by release. The step is done when a web node can reach the service on the private address and an unauthenticated connection is refused.
Install and configure the Redis module
A developer installs the contributed Redis module through Composer, enables it, and sets the connection details in the site settings file, keeping the password in environment-specific configuration rather than in version control. The module must be configured to route the cache, lock, flood and queue services to Redis, and the team should confirm the module's documentation for Valkey compatibility. The step is done when the site boots on a web node with the services configured and no connection errors in the logs.
Verify the cache bins and services in use
The developer checks which cache bins, lock, flood and queue services are actually resolving to Redis, using the status report and a trace of service resolution on a single request. Bins that remain on the database, such as those tied to specific configuration or entity storage needs, should be listed and accepted deliberately. The check passes when the list of Redis-backed bins matches the written design and no service silently falls back to the database.
Load test on a staging copy
The team restores a recent copy of the production database and files into staging, points it at a Redis or Valkey instance sized like production, and runs a load test covering anonymous and authenticated traffic. Watch memory use, eviction counts, latency and error rates while the test runs, and compare the results with a baseline run on the database backend. The step is complete when the test shows stable memory use, no unexpected evictions for the cache bins that must not be evicted, and no lock timeouts under peak concurrency.
Roll out to one web node first
The operations team enables the Redis configuration on a single web node behind the load balancer, leaving the others on the previous setup while the change is observed. Use a drain or weight adjustment so only a controlled share of requests hit the changed node. The step is complete when the canary node serves traffic for a monitored period with error rates and response times within the agreed thresholds and no cache-related warnings in the logs.
Confirm cache hit and lock behavior after rollout
After the canary is healthy, the team checks cache hit ratios in the Redis service and confirms that locks are acquired and released correctly during cron and queue runs, for example by observing that scheduled jobs do not overlap. Roll the change to the remaining web nodes only when these checks pass, then repeat the same checks on the full fleet. The sequence closes when hit ratios are stable, lock keys expire as designed, and the rollback procedure has been tested against the new configuration.

Keeping the Redis or Valkey service available without losing locks

When the Redis or Valkey service fails or fails over, Drupal does not stop serving pages, but the cache backend stops answering and the site absorbs the load. Every cache get that misses becomes a rebuild, and for cache bins that have moved to Redis, those rebuilds land on the database that was supposed to be offloaded. The more important risk is state that does not come back. Lock entries held by the lock service can disappear mid-operation, so a cron run or a long-running batch may start a second time, and queued items held in Redis can be lost or stranded depending on how the queue backend is configured. Decide before go-live which bins, locks and queues can be rebuilt and which cannot. Confirm with your Redis module and Drupal version how the backend behaves when the connection is refused, and whether the site fails open to the database or returns errors.

The three realistic service designs have different trade-offs. A single instance is the simplest to run and gives the least protection, so a restart clears every key and the database absorbs the cold cache. A replicated setup with Sentinel or a comparable failover manager keeps a copy of the data, but failover is not instantaneous, writes made just before a failure can be lost in replication, and the Drupal client must reconnect to the new primary. A managed high availability offering moves patching and failover mechanics to the provider, but you must confirm the provider's failover behavior, persistence options and whether the Drupal client you use supports its endpoint model. Ask each vendor for the documented failover window and data-loss behavior in writing rather than relying on general statements.

Test the failure, not just the happy path. Stop the primary in a staging environment under representative traffic and record how long the site serves errors, how many requests reach the database, and whether cron or queue workers run twice. Check reconnection behavior: confirm that PHP workers re-establish connections to the new primary without requiring a restart of PHP-FPM, and that persistent connections do not pin stale addresses. Repeat the test during a cron run and during a deploy that clears caches. Record the measured results and set your acceptance thresholds from them, because no published figure should replace your own test data. Ask your partner or internal team to document the runbook for promoting a replica, flushing or not flushing bins, and verifying lock and queue state afterward.

Security and operational controls for the cache service

A Redis or Valkey cache holds rendered pages, render cache entries, sessions-related lookups and user-specific fragments, so it deserves the same access discipline as the database. The cards below cover the controls that keep the cache reachable only by Drupal, the credentials and transport settings around it, and the patching and monitoring routines that run on their own schedule.

Restrict network reachability

Allow connections to the cache port only from the Drupal web and cron hosts, using security groups, firewall rules or a private subnet with no public address. Redis and Valkey do not provide per-user isolation by default, so anyone who reaches the port can read cached entries. Check the rule from a host outside the Drupal tier and confirm that a failed connection is logged. Also confirm that the service does not bind to all interfaces unless the network design requires it.

Enable authentication and TLS

Turn on the server's password or ACL authentication and use a dedicated user with access limited to the commands Drupal needs. Where traffic crosses a segment you do not fully control, encrypt the connection with TLS and configure the Drupal Redis client to verify the server certificate. Confirm the exact authentication and TLS options your chosen Redis or Valkey version supports, and the matching options in the Drupal Redis module, before you write the settings.

Keep credentials out of the code

Put the cache password and any TLS paths into environment variables or a secrets manager, and reference them from settings.php or a per-environment include file that is not committed to the repository. Rotate the password through the same pipeline that deploys Drupal, and plan a short overlap period so web nodes can switch without an outage. Check that deployment logs, debug output and the Drupal status report do not print the connection string.

Patch the cache service on its own schedule

Track Redis or Valkey security releases separately from Drupal core and contributed module updates. A cache server upgrade touches a different component, with its own compatibility and restart risks, so give it a named owner, a test environment and a maintenance window. Before each change, confirm the version against the Drupal Redis module requirements and check the Drupal Security Team advisories for anything that affects the cache integration.

Monitor memory, evictions and connections

Alert on memory use against the configured limit, the eviction counter, the connected client count and the error rate reported by Drupal's watchdog or logging. Rising evictions are an early sign that the cache is too small or the policy is dropping entries that Drupal still needs, which causes cold-cache slowdowns. Set thresholds from your own baseline during load testing, and review them after each release that changes cache behavior.

Limit what the cache can see

Rendered pages and user-specific content can sit in the cache, so a leaked key or unauthorized reader can expose personal data. Keep the cache in a separate database index or instance from queues and locks where practical, and set key prefixes per site on multisite estates. Ask your compliance lead to confirm whether cache contents fall within the data classification and retention rules that apply to the site.

How the setup differs by hosting environment

On a single server or small virtual machine, the Drupal team usually installs and runs Redis or Valkey on the same host or on one adjacent VM. The application team owns the service configuration, the memory limit, the persistence settings and the operating system patches, so there is little separation between the two. Failover is typically a manual rebuild, and cache loss is normally tolerable because Drupal rebuilds cache entries from the database, but the team should confirm that lock and queue data are not lost in a way that affects running jobs.

Ownership: The same people usually manage the web server, database, Redis or Valkey and Drupal, so changes need coordination on one host.
Memory pressure: Redis or Valkey shares RAM with PHP-FPM and the database, so the maxmemory setting must leave room for both.
Persistence: Decide whether snapshots or append-only logging are worth their disk and CPU cost for cache data that Drupal can rebuild.
Backups: Cache data is generally not backed up. Back up the configuration file and the host image instead.
Questions to ask your hosting provider: Can the VM be rebuilt from an image within your recovery goals, and does the provider isolate noisy neighbors from memory-heavy cache workloads?

Before go-live, confirm the restart procedure and that the site degrades correctly when the cache service is unavailable.

In containers and Kubernetes, Redis or Valkey usually runs as a separate workload, either from a maintained chart or from a managed operator, and Drupal pods connect to it over the cluster network. The platform team typically owns the cluster, storage classes, network policies and node placement, while the Drupal team owns the cache settings in the Drupal configuration and the connection details. Failover depends on how the workload is deployed, so the team should confirm whether replicas and automatic promotion are in place rather than assuming them.

Ownership split: Agree in writing which team patches the chart or operator, rotates credentials and sets resource requests and limits.
Memory limits: Container memory limits can kill the cache process abruptly, so set maxmemory below the container limit and test the eviction behavior.
Persistent volumes: Persistence depends on the storage class. Confirm how volumes are reattached after node failure.
Backups: Snapshots of persistent volumes are a platform concern and rarely needed for cache data. Keep the Drupal configuration in version control.
Questions to ask your platform team: Which failover mechanism is deployed, how are pods spread across failure domains, and how are network policies restricting access to the Drupal namespace?

Run a planned node drain during testing to confirm that Drupal reconnects without manual steps.

Limits and what to confirm in your environment

Several parts of a Redis or Valkey cache build depend on versions, runtime requirements and failure behavior that change over time and differ between environments. The cards below list what the team should verify with the module, the vendor and its own test environment before committing to a design.

Contributed Redis module release

Confirm which release of the contributed Redis module supports the Drupal core version you will run at go-live and the one planned for the next upgrade. Module releases track core versions, so a release that works today may not support the core you upgrade to. Check the module's project page on Drupal.org and pin the release in your Composer lock file so the choice is recorded.

PHP version for the target core

The PHP version is set by the Drupal core release, not by the cache service. Drupal 11 requires PHP 8.3 or later, so the Redis client extension and any PHP build used with it must also run on that version. Confirm the extension's PHP support matrix for your runtime before choosing a client library, because a supported Drupal version does not guarantee that the extension is available for your PHP build.

Distribution and client compatibility

Confirm that your chosen Redis or Valkey distribution, the server version and the PHP client library are supported together. Each combination has its own compatibility rules for protocol features, commands and TLS settings. Ask the client library maintainers and the service provider to confirm the combination in writing, then run the cache and lock operations in a staging environment that matches production.

Behavior during a cache outage

Test what the site does when the Redis or Valkey service is unreachable. Decide whether the site should fall back to the database, serve errors, or stop writes to cache-dependent features. Check whether locks and flood control fail open or closed, because a closed failure can block logins or form submissions during an outage. Document the result and rehearse it with the operations team.

Upgrade path for the cache service

Plan how the Redis or Valkey server will be upgraded without emptying the cache in a way that slows the site. Confirm the vendor's supported upgrade sequence for the server version, whether replicas must move first, and how the client library and Drupal module are tested against the new server before rollout. Record the rollback steps for each upgrade.

Capacity and sizing figures

DeployOpen does not set memory, connection or throughput figures for your site without testing. Ask for a load test that uses your real page mix, cache tag volume and authenticated traffic. Confirm memory limits, eviction behavior and connection counts against the chosen service tier before accepting a sizing estimate from any party, including this one.

Questions teams ask before moving Drupal cache to Redis or Valkey

What drives the cost of moving Drupal cache to Redis or Valkey?

The cost depends mostly on how many environments the change touches, how much the existing hosting already has in place, and how much of the Redis service needs to be designed from scratch. The main components are the planning and configuration of the cache backend, the Drupal module and settings work, the sizing and high availability design for the Redis service, load testing, and handover. Ongoing costs are infrastructure for the Redis service and the time your team spends on upgrades and monitoring. Ask any quote to list each component separately, state which environments it covers, and say who runs the Redis service after launch. A figure should follow from the written scope, not from a general estimate.

How long does a Redis or Valkey cache move take?

Duration is set by the number of Drupal sites, the number of environments, whether the Redis service already exists, and how many cache, lock, flood and queue bins are moved off the database. A single site with an existing managed Redis service usually needs less time than a multisite estate that needs new high availability. Testing time grows with traffic, because a realistic load test needs representative data and cache patterns. Ask for the timeline as a list of phases with dependencies, and confirm which phases depend on access to your environments and change windows.

What does our internal team need to provide?

Your team needs to provide access to the Drupal codebase, the staging and production environments, the hosting platform, and the people who approve changes to infrastructure. You also need someone who knows the current cache behavior, such as which pages are cached, how deployments clear caches, and where authenticated traffic is served. Expect to supply the Drupal and PHP versions in use, the database and web server details, and any network rules that control access to a Redis service. Confirm these needs in the written scope so that access requests do not block the schedule.

Can our team move Drupal cache to Redis or Valkey without a partner?

Yes, a team with Drupal and Linux operations experience can make this change alone, and many do. The work is well defined: install or provision the Redis service, configure the Drupal cache backend and bin mappings, set memory and eviction policies, and verify behavior under load. The harder parts are sizing for peak traffic, designing failover, and proving that lock and queue behavior still works across multiple web servers. Decide based on whether someone on your team has run a stateful service in production and has time for load testing.

Is Redis or Valkey the better choice for Drupal?

Both are in-memory data stores that Drupal can use through a contributed Redis module, so the practical choice depends on your licensing policy, supported distributions, and existing tooling. Confirm which product your hosting provider and internal standards support, and check the current module documentation for the version you plan to run. Do not select a product because of a single benchmark. Compare operational fit, such as backup tooling, monitoring integrations, and the upgrade path your team already follows.

How do we test a cache change without affecting production?

Test in a staging environment that matches production in web server count, PHP settings, database version, and Redis configuration. Run a load test that replays representative anonymous and authenticated traffic, then check cache hit rates, memory use, eviction counts, and error logs. Test failure modes too: restart a Redis node, cut the connection from one web server, and confirm that Drupal falls back as designed. Roll out to production in stages, with a rollback plan that returns cache bins to the database.

What changes after the Redis cache goes live?

The database load from cache operations drops, but the Redis service becomes a new production dependency that needs monitoring, patching, backups or persistence decisions, and capacity reviews. Your team must watch memory use and eviction rates, because a cache that fills up can change site behavior. Plan regular Redis upgrades alongside Drupal core releases, which follow a monthly bugfix and quarterly security cadence described in the Drupal release schedule. Ask whether ongoing support, monitoring and upgrades will be covered by a retainer or handled internally.

How DeployOpen scopes and delivers a Drupal cache backend

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including Drupal cache backends. We agree the scope in writing before work starts, then move cache, lock, flood and queue storage to Redis or Valkey in the environments you control.

How we scope

Inventory which cache bins, locks, flood and queue items currently sit in the database and how heavily each one is used.
Agree the Redis or Valkey topology, memory budget, eviction policy and persistence settings before any configuration changes.
Record the written scope, deliverables and timeline with your team, including whether ongoing support is needed as a retainer.

How we build

Configure the Drupal Redis integration in staging with the agreed settings, keeping secrets out of the code base.
Test cache hit behavior, lock handling, cache invalidation on content edits and failover of the Redis service itself.
Run load tests against a copy of production traffic patterns and review results with your platform and security teams.

How we hand over

Document the final configuration, key prefixes, memory limits, eviction policy and the reasons behind each choice.
Provide runbooks for restarts, failover, memory alerts, flushing specific bins and rolling back to database caching.
Walk your operations team through monitoring dashboards and the change process for future Drupal and Redis upgrades.

How we support

Support is available as a retainer covering Drupal and Redis or Valkey upgrades, security patches and configuration reviews.
Review memory usage and eviction trends with your team after launch and adjust sizing when traffic or content volume changes.
Confirm with your hosting provider and Redis or Valkey vendor which versions, support windows and high availability features apply to your environment.