WHMCS system requirements, as docs.whmcs.com listed them when I read the pages on 12 October 2026: Linux with Apache 2.x, PHP 8.2 or 8.3 for WHMCS 9.0, ionCube Loader 13.0.2 or higher on PHP 8.2 or 14.4.0 or higher on PHP 8.3, MySQL with 8.x recommended, and a PHP memory limit of 64 MB (128 MB recommended). The 9.1 beta needs ionCube Loader 15.0.0 and adds PHP 8.4.
What are the WHMCS system requirements?
The current list is a LAMP stack plus ionCube Loader. This is the table on the WHMCS 9.0 System Requirements page, which was last modified on 4 August 2026 when I read it. It applies to self-hosted installs only. WHMCS Cloud handles the server for you.
| Component | Required | Recommended |
|---|---|---|
| Operating system | Linux | None listed |
| Web server | Apache 2.x, any virtual host or server-wide PHP handler | mod_rewrite |
| PHP | 8.2 or 8.3 | None listed |
| ionCube Loader | 13.0.2 or higher on PHP 8.2, 14.4.0 or higher on PHP 8.3 | None listed |
| PHP memory limit | 64 MB | 128 MB |
| MySQL | 5.2 | 8.x |
| Required PHP extensions | Default compiled extensions, cURL 7.36 or higher with SSL, GD2, IMAP, ionCube Loader, JSON, PDO, PDO_MySQL built with mysqlnd, Reflection, XML | BC Math, Fileinfo, GMP, iconv, Intl, mbstring, OpenSSL 1.0.1c or higher with TLS 1.2 or higher, SOAP |
| Database collation | None listed | utf8_unicode_ci |
WHMCS gives no CPU, RAM or disk figures. The page says memory and disk needs vary with the size and activity of the install. Nginx works on some installs, but WHMCS only offers limited help with it, and Windows is not supported.
Which PHP version does WHMCS support?
It depends on the WHMCS version. Three versions were supported on 12 October 2026, and each release note lists its own minimum and recommended versions:
| WHMCS version and tier | PHP | ionCube Loader | MySQL (minimum, recommended) | Anticipated end of life |
|---|---|---|---|---|
| 9.1, Beta | 8.2 minimum, 8.4 recommended | 15.0.0 | 5.2, 8.0 | 30 September 2027 |
| 9.0, General Availability | 8.2 or 8.3 | 13.0.2 on PHP 8.2, 14.4.0 on PHP 8.3 | 5.2, 8.0 | 31 December 2026 |
| 8.13, Long-Term Support | 7.2, 7.3, 7.4, 8.1, 8.2 or 8.3 | 10.2.0 on 7.2, 10.3.1 on 7.3, 10.4.3 on 7.4, 12.0.1 on 8.1, 13.0.2 on 8.2, 14.4.0 on 8.3 | 5.2, 8.0 | Not yet set |
The order of upgrades matters more than the numbers. The 9.1 release notes say to install ionCube Loader 15.0.0 before updating to 9.1, and to update to 9.1 before moving to PHP 8.4. The 8.13 notes say the same about PHP 8.3: WHMCS first, then PHP. Updates also only appear at Utilities > Update WHMCS when the server runs a compatible PHP version.
One inconsistency: on the day I read them, the 9.1 System Requirements page still showed the 9.0 table, while the 9.1 release notes asked for ionCube Loader 15.0.0 and added PHP 8.4. For a 9.1 install I follow the release notes, because they are version specific. Recheck both before you act.
Which ionCube Loader version does WHMCS need?
You need the loader that matches both your PHP version and your WHMCS version, as in the table above. WHMCS ships its code encoded, and ionCube Loader is the PHP extension that decodes it. WHMCS Support does not help with loader problems; the documentation sends you to ionCube.
- Check it. PHP Info should show an Additional Modules section with ionCube Loader in it. WHMCS shows PHP Info at Utilities > System > PHP Info.
- Install it on cPanel and WHM. In WHM, open EasyApache, find the
ioncubeXXpackage for your PHP version in the PHP Extensions list and finish the build. The documented command line equivalent, as root, isyum install ea-phpYY-php-ioncubeXX. - Without root. You cannot install it yourself. Ask the host.
Third-party modules are the usual surprise. Utilities > System > PHP Version Compatibility scans the install for ionCube-encoded files and reports which PHP versions can decode each one. It skips /vendor, /attachments, /downloads and the template cache. It only checks decoding, not PHP syntax, and a file listed under Encoding Compatibility Unknown means you ask the vendor. The PHP Version Compatibility page explains the report.
Which MySQL version does WHMCS need, and does MariaDB work?
The tables list MySQL 5.2 as the minimum and MySQL 8 as the recommendation. MariaDB is described as a binary-compatible alternative that "may also work for some installations", which is not the same as supported. Three database details cause more trouble than the version:
- Strict mode. WHMCS does not support
STRICT_TRANS_TABLESorERROR_FOR_DIVISION_BY_ZERO. The documented fix is an emptysql_mode=line in the MySQL configuration (/etc/my.cnfon cPanel servers) and a MySQL restart. It needs root. - Privileges. Installing needs ALTER, CREATE, DROP, INDEX, LOCK TABLES, SELECT, INSERT, UPDATE and DELETE. You can remove the first four for daily running, but updates and module activation need them back.
- The driver. PDO_MySQL must be built with mysqlnd, not libmysqlclient. On CloudLinux, System Health asks for
nd_pdo_mysqlinstead ofpdo_mysql.
Which PHP settings does WHMCS check?
Beyond the extensions, a handful of settings decide whether WHMCS and its Automatic Updater work. The updater figures come from Updating WHMCS.
| Setting | What WHMCS asks for |
|---|---|
memory_limit | 64 MB minimum, 128 MB recommended and required by the Automatic Updater |
max_execution_time | 60 seconds or more for the Automatic Updater |
allow_url_fopen | Enabled for the Automatic Updater |
open_basedir | Disabled, or including the whole WHMCS root, /dev/null and any directories you moved out of it |
Zip extension or proc_open | One of them enabled, plus 250 MB of free disk, for the Automatic Updater |
session.auto_start | Off, or admin and client logins are not kept |
disable_functions | Must not list any function WHMCS requires |
| OPcache | Off. WHMCS strongly discourages it because of stale cached data |
The cron matters too. If the command line PHP that runs crons/cron.php is a different version or timezone from the web PHP, WHMCS warns about it. My WHMCS cron guide shows how to compare the two.
What does the WHMCS System Health page check?
System Health, at Configuration > System Health, compares the running server with what WHMCS expects and lists anything off as a Warning or as Needing Attention. These are the checks that relate to requirements, from the System Health page:
| Check | What it flags |
|---|---|
| PHP Version | PHP is not compatible with the installed WHMCS version |
| Required and Recommended PHP Extensions, Required PHP Functions | Missing extensions, or functions blocked by disable_functions |
| PHP Memory Limit | Below the recommended value (Warning) or the minimum (Needing Attention) |
| MySQL Server Configuration Check | connect_timeout under 10, wait_timeout or interactive_timeout under 300, max_allowed_packet under 4 MB |
| OPcache Status | OPcache is enabled |
| Cron PHP Version Mismatch, Cron PHP Timezone | The cron and the web server use different PHP versions or timezones. The version check clears only after the next daily cron run |
| cURL/TLS/OpenSSL, SSL Support in cURL | cURL older than 7.36.0, OpenSSL older than 1.0.1c, or no SSL in cURL |
| Automatic Update Requirements | The server fails one of the updater requirements |
| Legacy Smarty Tags, Deprecated Modules | Templates or modules that WHMCS 9.0 no longer supports |
I read System Health before any change and again after it. A clean page is not proof that third-party modules work, because it does not test them.
What should you check before a WHMCS upgrade?
Check that the server meets the requirements of the version you are going to, and of every version in between. The Updating Through EOL Versions page says you may have to stop between versions to update the server.
- Read the release notes of the target version, including the upgrade requirements table.
- Install the ionCube Loader the target needs, before the WHMCS update.
- Run Utilities > System > PHP Version Compatibility and ask each module vendor about the target PHP version.
- For 9.0 and later, run the Smarty Compatibility Report under Reports > Reports and remove legacy Smarty tags.
- Back up the database and files, and run the update on a test copy first.
- Update WHMCS, then PHP, in the order the release notes give.
- Watch System Health for the 24 hours after the update, as WHMCS recommends.
A worked example from these tables: an install on 8.12 with PHP 8.1 cannot go straight to 9.0, which needs PHP 8.2. 8.13 runs on PHP 8.1, 8.2 and 8.3, so the path is 8.13 first, then PHP 8.2 or 8.3 with the matching loader, then 9.0. My WHMCS upgrade guide covers the update itself.
What should you check before moving WHMCS to a new server?
The new server must meet the requirements of the WHMCS version you already run, not just the latest one. The official move checklist puts the requirements check third, after disabling the old cron and taking a database backup. On the new server I confirm:
- The same PHP version as the old server, or one the installed WHMCS supports, with its matching ionCube Loader.
- Every module still decodes on that PHP, checked with the compatibility report on a test copy.
- Strict mode is off, the collation is right and the MySQL timeouts pass the System Health check.
- The cron runs the same PHP as the website.
- Custom paths in
configuration.php, such as$attachments_dir,$templates_compiledirand$crons_dir, match the new directory layout.
The license must also be reissued for the new location. The rest of the move is in how to migrate WHMCS.
What do the WHMCS requirements not tell you?
They tell you what WHMCS needs, not whether your setup will behave. The gaps I plan around:
- Sizing. No CPU or RAM guidance exists, so size from your own load and resize from measurements.
- Shared hosting. Without root you cannot install ionCube, change
sql_modeor turn off OPcache server-wide. Confirm the host will do it before you buy. - MariaDB and Nginx. Both run on real installs, but neither is fully supported, so problems there are yours to solve.
- Modules. Marketplace and custom modules can have their own requirements. A module that only decodes on an older PHP blocks the whole upgrade.
- Dates. Supported versions and end-of-life dates change every few months. Treat the tables here as a snapshot of 12 October 2026.
If a module or a customization is what stands between you and a supported version, that is the kind of work I take on under WHMCS support and maintenance or as part of a WHMCS migration.
Last reviewed 12 October 2026. Disclosure: I sell WHMCS and web development work, so I am not neutral. I am CTO at ElySpace, a freelance developer for Marmaids LLC, and founder of WHMCSPilot and MagizAI.
