WHMCS System Requirements & Best Server Setup

WHMCS's official system requirements are a floor, not a target. Running on the minimum spec is how you end up with 5-second page loads, failed crons, and timed-out provisioning. This is the spec sheet I use for hosting clients ranging from a 50-customer reseller to a 50,000-customer hosting brand.

The official minimums (and why they're not enough)

WHMCS's published requirements at the time of writing:

• PHP 8.1+ (8.2/8.3 supported on current WHMCS versions).
• MySQL 5.7+ or MariaDB 10.3+.
• ionCube Loader 12+ (PHP 8.x compatible).
• 1 GB RAM (technically; not really).
• ~500 MB disk for WHMCS itself.
• PHP extensions: curl, gd, json, mbstring, mysqli, openssl, pdo, pdo_mysql, xml, zip, intl.

Meeting these gets you a WHMCS that boots. It does not get you a WHMCS that runs a real hosting business reliably.

What I actually deploy on

WHMCS is single-instance by design — it doesn't scale horizontally for the main app. Scaling means: stronger hardware, MySQL on a separate box, caching layer, and aggressive cron-task splitting.

PHP — the right version, the right configuration

Version. PHP 8.2 is the sweet spot at the time of writing. PHP 8.3 works but some less-maintained third-party modules may not be ready. PHP 8.1 is the safe fallback if you're stuck on older WHMCS.

php.ini values that matter:

memory_limit = 512M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M

; Critical for cron tasks that take longer
max_input_time = 120

; OPcache — non-optional for production
opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 20000
opcache.revalidate_freq = 60
opcache.validate_timestamps = 1   ; set to 0 only if you have a deploy step that clears OPcache

; ionCube
zend_extension = ioncube_loader

The single largest perceived-performance gain on a fresh WHMCS install: enable OPcache. It eliminates PHP file parsing on every request. WHMCS is PHP-heavy; OPcache is the difference between 800ms and 200ms page loads.

MySQL — the version, the config, the engine

Version: MySQL 8.0 or MariaDB 10.6+. Both are well-supported. I prefer MariaDB for new installs; it's a drop-in replacement and tends to be smoother on lower-RAM boxes.

Engine: InnoDB. All tables. WHMCS ships with InnoDB defaults, but old installs that migrated up from MySQL 5.x sometimes still have MyISAM tables. Convert them:

SELECT table_name
FROM information_schema.tables
WHERE table_schema = 'your_whmcs_db' AND engine = 'MyISAM';

-- For each result:
ALTER TABLE tblxxxxx ENGINE=InnoDB;

my.cnf values that matter (assuming 8 GB RAM, dedicated to MySQL):

[mysqld]
innodb_buffer_pool_size = 5G        # ~70% of RAM for DB server, less if shared
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 2  # safer than 0, faster than 1
innodb_flush_method = O_DIRECT
innodb_file_per_table = 1

max_connections = 200
table_open_cache = 4000
tmp_table_size = 64M
max_heap_table_size = 64M

# Disable the query cache — it hurts more than helps in modern MySQL
query_cache_type = 0
query_cache_size = 0

# Logging
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Restart MySQL after changes. Take a DB backup first.

Web server — Apache vs nginx vs LiteSpeed

All three work. My order of preference:

1. LiteSpeed (or OpenLiteSpeed). Faster than Apache for PHP-FPM workloads. Compatible with .htaccess files. Easy upgrade from Apache.
2. nginx + PHP-FPM. Standard, fast, well-documented. No .htaccess support; you'll port WHMCS's rewrites into nginx config.
3. Apache + PHP-FPM (mod_php is dead, don't bother). Slowest of the three but everyone knows it.

Whatever you pick, run PHP via FPM, not as a CGI or mod_php. Tune the FPM pool to match traffic:

; /etc/php-fpm.d/whmcs.conf
pm = dynamic
pm.max_children = 30        ; budget: each PHP worker uses ~50-80 MB
pm.start_servers = 5
pm.min_spare_servers = 3
pm.max_spare_servers = 8
pm.max_requests = 500

Caching layer — Redis or Memcached

Once you're past ~500 customers, raw PHP page generation gets slow. Add Redis:

# Install
yum install redis    # or apt install redis-server

# /etc/redis.conf — minimal tweaks
maxmemory 512mb
maxmemory-policy allkeys-lru

Then wire WHMCS to use Redis via session storage and any module that supports it. The official WHMCS docs cover Redis session config; many marketplace modules support Redis for their own caching.

HTTPS, TLS, and TLS hardening

WHMCS handles money. Run real TLS (Let's Encrypt or paid cert), with these settings as a minimum:

• TLS 1.2 + TLS 1.3 only. Disable TLS 1.0 and 1.1.
• Strong cipher suite (modern, not legacy).
• HSTS header.
• Force HTTPS on every page including the admin path.

Use SSL Labs' test to verify. Target an A+ rating.

Disk & storage

• SSD or NVMe. Spinning disk is no longer acceptable for a production WHMCS install.
• Separate /var/lib/mysql onto its own disk for larger installs — protects against single-disk saturation.
• Backups go off-server. rsync nightly to S3 / Backblaze B2 / a separate VPS.

My recommended stack for a fresh WHMCS deploy

How to verify your stack is sized right

1. Server load. uptime should show 1-min load below your CPU count. Sustained higher = upgrade.
2. MySQL connections. SHOW STATUS LIKE 'Threads_connected'. Should be under 50% of max_connections at peak.
3. PHP-FPM saturation. Check pm.status. If active processes hits max_children regularly, raise max_children or add RAM.
4. Page load. Customer-facing admin pages should render under 1 second. Anything over 2 seconds in the 95th percentile is a problem.
5. Cron completion time. Should complete in well under 5 minutes (so the next cron doesn't overlap).

Common pitfalls

"Shared hosting works for WHMCS." It boots. It doesn't run a real business. Outbound SMTP is throttled, cron limits are tight, no Redis, no MySQL tuning. Move off shared hosting before you have 50 customers.

"PHP 8.x broke my modules." Test in staging first. Some older modules use deprecated PHP features; updates are usually available.

"MySQL is slow but I have plenty of CPU/RAM." The defaults are designed for 256 MB RAM machines from 2010. Tune innodb_buffer_pool_size first.

"OPcache is enabled but pages are still slow." Check opcache.max_accelerated_files — if it's lower than the actual file count, OPcache thrashes. Bump to 20000.

My take — what to spend money on

If you have $X to spend on WHMCS infrastructure, in priority order:

1. NVMe storage. Single biggest perceived-speed improvement.
2. Enough RAM to hold the InnoDB buffer pool + all hot pages. 8 GB minimum on any serious install.
3. Redis. Free, but takes RAM and config time.
4. A managed MySQL service (DigitalOcean Managed DBs, AWS RDS) if you don't want to operate MySQL yourself.
5. CDN for static assets — Cloudflare free tier works.

Adding CPU cores rarely helps WHMCS. It's not a CPU-bound app; it's a database + disk + network app.

Going further

• Official WHMCS system requirements
• Recommended PHP settings
• My troubleshooting guide — what to look at when performance degrades.

I size, deploy, and tune WHMCS servers for hosting businesses. If you're outgrowing your current setup or starting fresh, tell me about your scale and I'll spec the right stack + send a quote in 24 hours.