Set up CloudLinux AccelerateWP on a cPanel hosting server

AccelerateWP is CloudLinux's WordPress performance bundle: object cache (Redis or Memcached), full-page cache, critical CSS generation, image optimisation, lazy loading, and an optional CDN — all configured per-account through cPanel, one toggle per feature, with no plugin install required from the end-user. It's aimed at shared hosts who want to give every WordPress site a measurable Lighthouse bump without building a competing service from scratch.

The free tier ships with any CloudLinux license on cPanel; premium features (critical CSS, unused-CSS removal, WebP image conversion, and the CDN) bill per active site through your CloudLinux account. This guide installs the daemon, turns on the user-facing UI, sets feature policies, and walks through the three diagnostic failures you'll actually see in production.

Prerequisites

You need:

• CloudLinux 7, 8, or 9 with cPanel installed and a current license. If you haven't installed CloudLinux yet, see installing CloudLinux on cPanel.
• Root SSH access.
• mod_lsapi (under Apache) or LiteSpeed lsphp as the PHP handler. AccelerateWP's bootstrap hook needs lsapi/lsphp to inject the object-cache loader; PHP-FPM and CGI are not supported.
• At least one PHP 7.4+ version installed from alt-php — see the PHP Selector setup.
• Redis or Memcached running locally, on a Unix socket or 127.0.0.1. Redis is the recommended backend; Memcached is a supported fallback but loses persistence across restarts.

Budget around 1.2 GB of additional disk under /opt/alt/clwpos/ for the worker binaries and Composer cache.

Step 1 — Install the AccelerateWP daemon

The package set is acceleratewp, but it depends on lvemanager for the WHM UI hooks:

yum install lvemanager
yum install acceleratewp

The binaries are named clwpos (CloudLinux WordPress Optimisation Suite — the original project name) and clwpos-admin. Run the post-install bootstrap:

clwpos-admin --install

This pulls the Composer-based PHP workers into /opt/alt/clwpos/, registers the clwpos-worker systemd unit, and probes the local Redis socket. Expect 90-120 seconds on a 2-vCPU VPS.

Verify the daemon is alive:

systemctl status clwpos-worker
clwpos-admin --status

You should see active (running) and a final status line ending with OK. If --status reports Redis: not found, the daemon failed to detect a key/value backend — see Step 3.

Step 2 — Turn on the user-facing UI

The Site Optimisation icon only appears in cPanel once the WHM-side toggle is on:

WHM → CloudLinux Manager → Site Optimisation → Enabled for end users → Save.

To gate it per-package instead of fleet-wide, set the flag on the package's CloudLinux tab. Packages without the flag never see the icon — useful if you want AccelerateWP to be the differentiator on a paid hosting tier.

Restart cpsrvd so the icon appears immediately rather than after the next cache expiry:

service cpsrvd restart

Step 3 — Configure the object cache backend

AccelerateWP expects Redis on /var/run/redis/redis.sock by default. Install and enable it:

yum install redis
systemctl enable --now redis

Edit /etc/redis.conf:

unixsocket /var/run/redis/redis.sock
unixsocketperm 770
maxmemory 512mb
maxmemory-policy allkeys-lru

Reload Redis and tell clwpos to re-probe:

systemctl restart redis
clwpos-admin --refresh

512 MB of maxmemory comfortably holds the object cache for around 150 active WordPress sites. Scale linearly — at 1,000 sites budget 3-4 GB of RAM for Redis alone, plus headroom for other services.

Step 4 — Set feature policies

Site Optimisation exposes six features end-users can toggle: object_cache, php_x_ray, lszimg (image conversion), lazyload, criticalcss, and unused_css. By default all six are available; in practice you'll want to gate the billable ones.

List the current policy:

clwpos-admin --features list

Disable the two premium features fleet-wide (they hit the CloudLinux billing API on every save):

clwpos-admin --features disable unused_css criticalcss

Then re-enable them per-package for paying customers:

clwpos-admin --features enable criticalcss --package=premium
clwpos-admin --features enable unused_css --package=premium

Policy changes apply on the user's next save — already-enabled sites keep their setting until the user toggles. Document this in your support runbook: a customer downgraded from premium to starter keeps critical CSS active until they next visit the panel.

Step 5 — Verify a user-side install

Log into a cPanel account with at least one WordPress site. Open Site Optimisation, pick the site, toggle Object Caching on. Within 10-15 seconds AccelerateWP drops wp-content/object-cache.php into the site root and the response should start emitting X-Cache: clwpos-cache HIT after a couple of warm-up requests.

From the server side, two diagnostics are worth knowing:

clwpos -u exampleuser status
clwpos -u exampleuser info

status lists enabled features per site. info dumps the per-feature health check — Redis connectivity, plugin file presence, hit ratio over the last hour — and is the first thing to paste into a support ticket when a user reports "the cache isn't working".

Three failure modes you'll see in support

1. Critical CSS stuck in queued state. Critical CSS is generated by a CloudLinux-hosted SaaS endpoint — the worker queues a job and polls for the result. If outbound HTTPS from the server to *.cloudlinux.com is blocked by CSF or ConfigServer, jobs sit in queue forever. Check /var/log/clwpos/main.log for outbound to api.cloudlinux.com failed and whitelist the domain.

2. Object cache silently disabling itself. clwpos refuses to inject object-cache.php if it detects WP Rocket, W3 Total Cache, WP Super Cache, or the LiteSpeed Cache plugin. The user sees the toggle flip back to off after save with no error. Fix: have the user uninstall the third-party plugin, or accept that AccelerateWP is mutually exclusive and document it as such in your KB.

3. lszimg producing oversized WebPs. Image conversion uses ImageMagick with a default quality of 85. On photographic content this sometimes produces WebPs larger than the source JPEG. Tune /etc/clwpos/lszimg.conf and drop quality to 75 for shared hosting — the bandwidth saving matters more than the marginal visual difference, and the conversion stops being a net loss.

Next steps

• Tune the resource ceilings AccelerateWP will push against, especially under critical CSS generation — see CloudLinux LVE tuning without angry customers.
• If you're running LiteSpeed and want LSCache as the primary full-page cache instead, see enable LSCache for WordPress on cPanel.
• Activate or renew a CloudLinux license if your AccelerateWP entitlement isn't current — premium features stop dispatching the moment the parent license lapses.