No. WHMCS has no built-in Redis cache, and its documentation does not mention Redis. It describes two session stores, PHP files and the WHMCS database, and it tells you to switch PHP OPcache off. What speeds up a self-hosted WHMCS installation is a correct MySQL configuration, debug logging turned off, two configuration.php switches, lean custom code and enough RAM.
I rewrote this guide on 10 October 2026 against the WHMCS 9.0 documentation. The earlier version recommended OPcache, and WHMCS says the opposite. Each claim names its source page.
Does WHMCS support Redis caching?
No. The WHMCS documentation has no page about Redis, and its pages on performance, sessions and system requirements never name Redis, Memcached or any other object cache.
| Layer | What the WHMCS documentation says | What to do |
|---|---|---|
| Redis object cache | Nothing. No documented setting exists. | Nothing to switch on. |
| PHP OPcache | "We strongly discourage enabling OPcache on your WHMCS installation's server." | Turn it off for the PHP that runs WHMCS. |
| Template cache | WHMCS caches templates into static files in the templates_c folder. | Empty it after a template change. |
| PHP sessions | Two stores are supported: PHP files, the default, and the WHMCS database. | Keep files, or set $session_handling = 'database';. |
Should you enable PHP OPcache for WHMCS?
No. WHMCS asks you to disable it. Its OPcache Warnings page says OPcache "can cause serious problems with old data caches that WHMCS cannot control" and can stop PHP scripts from running each time WHMCS executes them. Check your own install:
- Open Configuration > System Health in the admin area. An enabled extension shows there as an "OPcache Status" warning.
- The symptom WHMCS describes is stale cached data or scripts that do not run. Its one named example is a "Gateway Activation Failed" error when you activate the PayPal Payments module.
- The documented fix is to deactivate the extension in your control panel, or to remove the
opcache.enablelines fromphp.ini.
On a managed or shared server, your host makes that change. If other sites there depend on OPcache, ask whether the PHP configuration that runs WHMCS can have it off.
What speeds up WHMCS, according to its documentation?
Less logging, two configuration switches, leaner custom code, a faster mail provider and smaller tables speed up WHMCS, according to its Optimize Performance page. Its explanation of slow pages is plain: more data means a larger database, and looping through it takes longer.
| Change | Where | Why, according to the documentation |
|---|---|---|
| Turn off debug logging | SQL Error Reporting and Hooks Debug on the Other tab at Configuration > System Settings > General Settings. Module Debug Log at Configuration > System Logs. | Left on, they "can and will increase the database size exponentially". |
| Disable ticket counts | Add $disable_admin_ticket_page_counts = true; to configuration.php. | WHMCS stops counting tickets per status every time you open a ticket. |
| Disable the services count in the client list | Add $disable_clients_list_services_summary = true; to configuration.php. | The list at Clients > View/Search Clients loads without counting each client's services. |
| Review custom code | Hooks, addons and third-party modules. | "Third-party customizations can slow the performance of WHMCS." |
| Check the mail provider | The mail provider set in General Settings. | Slow orders, ticket replies and invoices are "often caused by connection issues" to the email provider. |
| Prune logs and optimize tables | Utilities > System > System Cleanup, and the table optimization button at Utilities > System > Database Status. | From those two pages: pruning logs shrinks the database, and optimizing tables removes overhead. |
This applies to self-hosted installs. WHMCS Cloud does not currently give direct access to files or the database.
Which MySQL or MariaDB settings does WHMCS ask for?
WHMCS asks for a handful of values in the mysqld section of my.cnf, usually /etc/my.cnf on cPanel servers. The Optimize Performance page gives starting points, and System Health raises a "MySQL Server Configuration Check" warning below certain minimums.
| Setting | Documented starting point | System Health warns below |
|---|---|---|
max_connections | A low value like 50, raised to match available RAM | Not checked |
wait_timeout | At least 300 | 300 |
interactive_timeout | Not listed | 300 |
connect_timeout | Not listed | 10 |
max_allowed_packet | 16 MB | 4 MB |
sort_buffer_size | 2 to 4 MB | Not checked |
read_buffer_size | 2 to 4 MB | Not checked |
WHMCS says to restart MySQL after changing these and let it run for 48 hours. Two more rules come from the System Requirements page. WHMCS does not support MySQL strict mode, so keep STRICT_TRANS_TABLES and ERROR_FOR_DIVISION_BY_ZERO off. And MySQL is the requirement, while MariaDB "may also work for some installations", so on MariaDB check each variable against that server's own documentation first.
Which PHP version and memory limit should WHMCS use?
Use a PHP version that your WHMCS version lists as supported, and give PHP the recommended memory instead of the minimum. On the review date, the System Requirements page listed PHP 8.2 or 8.3 for the supported WHMCS versions, with a 64 MB memory limit as the minimum and 128 MB as the recommendation. Each PHP version needs its own minimum ionCube Loader version, and WHMCS warns when the cron job and the web server run different PHP versions, so change both together. On server size, the documentation's rule is simple: more RAM and processing power mean better performance.
What is the WHMCS template cache, and when do you clear it?
The template cache is the templates_c folder, where WHMCS keeps static copies of its templates so pages load faster. Empty it when a template change does not show up: at Utilities > System > System Cleanup, open the Simple tab and click Go next to Empty Template Cache. The folder must be writeable.
How does the WHMCS cron job affect speed?
The cron job matters most once a day, when the heavy daily tasks run. WHMCS recommends running crons/cron.php every five minutes, and the daily tasks start in the hour you choose under Time of Day at Configuration > System Settings > Automation Settings.
That run creates invoices, processes payments, suspends overdue services and makes the database backup, which the documentation calls "CPU, memory, and disk intensive". If the admin area drags at the same time every day, move Time of Day to your quietest hour.
The System Cron page also documents the skip and do arguments for running one task on its own schedule. For the backup, that pattern looks like this:
*/5 * * * * php -q /path/to/cron.php skip --DatabaseBackup
30 3 * * * php -q /path/to/cron.php do --DatabaseBackupThe do argument forces the task and does not change WHMCS's internal schedule, so try it on a staging copy first. The basic cron setup is in how to set up WHMCS.
Can you store WHMCS sessions in Redis?
PHP can, but WHMCS does not document it, so I treat it as unsupported. The phpredis extension adds a Redis session handler that you configure in php.ini:
session.save_handler = redis
session.save_path = "tcp://127.0.0.1:6379"Three facts make me cautious:
- The WHMCS Sessions page lists exactly two stores for self-hosted installs: file-backed and database-backed.
- System Health has a check named "The PHP Session save path is not writeable", which tests
session.save_pathwith PHP'sis_writeablefunction. Atcp://address is not a writeable folder, so I expect that check to complain. No WHMCS page I found covers a non-file handler. - The phpredis README says session locking is off by default, and that with the default read timeout PHP can hang if Redis stops answering.
To share sessions between two web servers, use the documented route: add $session_handling = 'database'; to configuration.php. WHMCS makes no speed claim for it, and neither do I.
When is Redis worth adding to a WHMCS server?
Redis is worth adding only when your own custom code needs a cache, and it is not a general fix for a slow WHMCS. A module or hook is ordinary PHP, so it can use phpredis to keep a slow outside API's answer for a few minutes. The ClientAreaPage hook runs on every client area page, so a slow call inside it is paid on every view. The limits:
- WHMCS will not use it. Clients, invoices and tickets still come from MySQL on every request.
- Do not cache money or access. Balances, invoice status and suspension state must be read live.
- It is one more service. Someone has to patch it, monitor it and keep it private to the WHMCS server.
- It can fail. Your code needs a fallback to the direct call, or the client area goes down with Redis.
- It hides slow code. Fix a hook that runs a heavy query on every page before you cache around it. My WHMCS hooks guide shows how to check what a hook does.
How do you find what is slowing WHMCS down?
Start with the checks that cost nothing, and change one thing at a time.
- Open Configuration > System Health and clear the warnings for OPcache Status, MySQL Server Configuration Check, PHP Memory Limit and System Cron Tasks.
- Turn the debug logs off.
- Note which pages are slow. Ticket pages and the client list point to the two
configuration.phpswitches. Pages that send email point to the mail provider. - Note when it is slow. The same time every day points to the daily cron run or the backup.
- On a staging copy, deactivate custom hooks and addons one at a time, and time the same page after each.
- Only then change MySQL values or the server size.
Time the same page with the same account before and after each change, in your browser's network panel. I quote no typical gain, because it depends on your data, hardware and custom code. If you want me to run this review, it is part of my WHMCS support and maintenance work, the server side sits under hosting infrastructure consulting, and the scoping call is free and takes about 30 minutes.
Last reviewed 10 October 2026. Disclosure: I am a freelance WHMCS developer and I sell WHMCS maintenance and performance work, so I am not neutral. I am CTO at ElySpace, a freelance developer for Marmaids LLC, and founder of WHMCSPilot and MagizAI. Settings change between WHMCS versions, so check the linked pages for yours.
