Configure Moodle Cache API with Redis
Map Moodle caches to Redis to cut database load, then verify with the Caches admin page and redis-cli monitor.
05 Jan 2026, 08:27 UTC

Desired outcome
Moodle repeatedly reads the database for URL caches, language strings, and application state. Under traffic, those reads increase database I/O and slow page delivery. Mapping Moodle's Cache API to Redis moves frequently accessed data into memory, so later requests are served from the cache store instead of the database.
Prerequisites
- A Redis server reachable from the Moodle web server, typically on TCP port 6379.
- The PHP Redis extension installed and enabled on the Moodle web server.
- A Moodle administrator account.
- Command-line access to the Moodle web server and file-system access to the Moodle installation.
Step 1: Confirm the PHP Redis extension
Run this command on the Moodle web server as a user with shell access:
php -m | grep redis
Expected result: a line containing redis. If the command returns nothing, install the extension; for example, the php-redis package on Debian-based systemsand restart the web server or PHP-FPM service before continuing.
Step 2: Add the Redis store
- Log in to Moodle as an administrator.
- Go to Site Administration > Server > Caches.
- Open the Installed stores tab and click Add store.
- Select Redis from the store type list.
- Enter a store name such as
RedisPrimary. - Enter the Redis host, port, password if required, and database index.
- Save the store.
Step 3: Map caches to Redis
- On the Caches page, open the Defined caches tab.
- Find a cache such as
applicationormoodle_urlcache. - Click Edit for that cache.
- Set Primary store to
RedisPrimaryand move it to the top of the priority list. - Save the cache definition.
The application cache holds Moodle-wide configuration and language data. The moodle_urlcache stores generated URLs. Mapping both to Redis removes repeated database reads for those items.
Expected checks
Store status
Return to Site Administration > Server > Caches > Installed stores. The Redis store should report no connection errors. A Connection refused or authentication error means the host, port, or password is wrong, or Redis is not listening on the expected network interface.
Live traffic
Run this command on the Redis server, or another host with network access to Redis:
redis-cli -h 127.0.0.1 -p 6379 monitor
Replace 127.0.0.1 with the Redis host if it is remote. Add -a 'your_password' if Redis requires authentication. Then browse several Moodle course pages. Expect to see GET and SET commands appear in the terminal. If the output stays empty, Moodle is not writing to this Redis instance.
Running monitor on a production Redis instance adds small overhead; use it only briefly for diagnosis.
Limitations
- Redis keeps data mainly in memory. If Redis restarts without RDB or AOF persistence, cached data is lost and Moodle rebuilds it, causing a brief performance dip. Check
appendonly yesor save rules inredis.confif durability across restarts is required. - If Redis reaches its
maxmemorylimit, it may evict keys. Monitor Redis memory usage and adjust the limit or eviction policy if critical cache keys disappear. - If Redis runs on a different host than the Moodle web server, network latency can remove the performance gain. Prefer localhost or the same private network.
Rollback
Changing cache stores changes runtime state. To revert, go to Site Administration > Server > Caches > Defined caches, edit each cache you changed, and restore the previous primary store, typically filecache or dbcache. No database migration is required.
Practical result check
After mapping, reload a Moodle course page and confirm the Caches admin page shows the Redis store as active with zero connection errors. Compare page-load timing before and after under similar load; the database should show fewer repeated queries for cached URLs and application data.
0 replies
A thoughtful contribution can make all the difference. Be the first to share one.