CyberPanel PHP versions and LiteSpeed Cache per site

CyberPanel PHP versions are managed per website, so one site can run PHP 8.1 while another runs PHP 8.3 on the same server. This guide installs an extra lsphp build, assigns it to a site, and turns on LiteSpeed Cache for WordPress, then verifies both with commands you can repeat any time.

CyberPanel runs on OpenLiteSpeed, which executes PHP through its own lsphp binaries rather than through a system-wide PHP-FPM pool. That is why the PHP version you see in the panel is not the same as what php -v reports on the command line, and why a site can keep an old version after an upgrade until you change the vhost mapping.

Before you start

You need:

• A Linux VPS with CyberPanel installed and reachable at https://203.0.113.10:8090. If you have not installed it yet, follow how to install CyberPanel on Ubuntu or AlmaLinux.
• Root SSH access to the server.
• An existing website in CyberPanel, for example example.com.
• A WordPress install on that site if you want to test LiteSpeed Cache.

Confirm the running OpenLiteSpeed and panel services before you change anything:

systemctl status lsws --no-pager
systemctl status lscpd --no-pager

The panel user interface changes slightly between CyberPanel releases. Menu names below match recent 2.x versions; if a label differs on your build, check the CyberPanel documentation for your release.

Choose the CyberPanel PHP versions you need

List the lsphp builds already on the server:

ls -1 /usr/local/lsws | grep '^lsphp'

Show the exact version of each binary:

for v in /usr/local/lsws/lsphp*/bin/php; do echo -n "$v -> "; "$v" -v | head -n1; done

If the version you want is missing, install it from the LiteSpeed repository that CyberPanel already configured. On AlmaLinux or Rocky 8/9:

dnf install -y lsphp82 lsphp82-common lsphp82-mysqlnd lsphp82-pdo lsphp82-opcache lsphp82-imagick lsphp82-intl

On Ubuntu 22.04/24.04 or Debian 12:

apt update
apt install -y lsphp82 lsphp82-common lsphp82-mysqlnd lsphp82-opcache lsphp82-imagick lsphp82-intl

Change 82 to the branch you want (81, 83, and so on). Always install mysqlnd, pdo and opcache with the core package, or WordPress will fail with a database connection error the moment you switch the site over.

You can also install and manage versions from the panel under PHP, which lists the available builds and their extension packages. Use whichever route you prefer, but do not mix the two halfway through an install.

Register the new binary with OpenLiteSpeed and restart:

systemctl restart lsws
systemctl status lsws --no-pager

Assign a PHP version to a website

In the panel, open Websites → List Websites, click Manage next to example.com, and open Modify Website (some builds label this Application or PHP Version). Pick the new version from the PHP Version dropdown and save.

CyberPanel rewrites the site's vhost configuration. Verify what the site actually points at:

grep -n 'lsphp' /usr/local/lsws/conf/vhosts/example.com/vhconf.conf

You should see a line mapping the script handler to the new external application, for example lsapi:lsphp82. The matching extprocessor block lives in /usr/local/lsws/conf/httpd_config.conf.

Then confirm the version the site really serves:

curl -s https://example.com/ | grep -o 'PHP/[0-9.]*' | head -n1

If your site hides the PHP version, create a temporary info.php with <?php phpinfo; in the document root, open it in a browser, read the version, then delete the file immediately.

Enable LiteSpeed Cache for WordPress

OpenLiteSpeed includes the LiteSpeed Cache engine, and CyberPanel installs the LSCWP plugin when it provisions WordPress. For an existing site, install it with WP-CLI as the site owner:

sudo -u deploy wp plugin install litespeed-cache --activate --path=/home/example.com/public_html

Replace deploy with the account that owns the site's files. Then open wp-admin → LiteSpeed Cache → Cache and turn caching on, set a sensible public cache TTL (for example 604800 seconds), and enable Cache Logged-in Users only if you understand the risk of showing cached pages to logged-in accounts.

Purge with:

sudo -u deploy wp litespeed-purge all --path=/home/example.com/public_html

If the litespeed-purge command is not available, purge from LiteSpeed Cache → Toolbox in wp-admin instead. Also open LiteSpeed Cache → Presets and apply the preset that matches your theme to get CSS, JS and image optimisation configured in one step.

Check it works

Request a page twice. The first request primes the cache; the second should be a hit:

curl -sI https://example.com/ | grep -i 'x-litespeed-cache'
curl -sI https://example.com/ | grep -i 'x-litespeed-cache'

Expect x-litespeed-cache: miss first, then x-litespeed-cache: hit. Test with a browser in a private window too, because logged-in sessions usually bypass the public cache.

For PHP, check the handler in the vhost again and confirm the site responds without 500 or 503 errors:

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/

A 200 means the new lsphp build is serving the site with its extensions loaded.

Troubleshooting

• Site still reports the old PHP version after saving. The vhost mapping did not change. Run the grep on vhconf.conf, save the website again in Modify Website, and restart lsws.
• HTTP 500 or 503 right after switching PHP. The new build is missing an extension such as mysqlnd, pdo or intl. Install the matching lsphpXX-* packages, restart lsws, then read /usr/local/lsws/logs/error.log and /usr/local/lsws/logs/stderr.log for the exact function that is undefined.
• No x-litespeed-cache header at all. Either the plugin is inactive, caching is disabled, or the request is being served by a redirect to HTTPS that the cache skips. Check LiteSpeed Cache → Cache and test the final https:// URL directly.
• Plugin reports that LiteSpeed Cache is not supported. The site is not served by OpenLiteSpeed, or the cache module is disabled. Confirm lsws is the web server and check the response headers.
• wp commands fail with permission errors. Run them with sudo -u as the site owner, not as root, so generated files keep the correct ownership.

Next steps

• Compare per-site PHP handling with changing the PHP version in OpenLiteSpeed.
• Building the stack from scratch? See install WordPress on a LEMP stack.
• Hitting memory errors after a PHP switch? Read fix PHP "Allowed memory size exhausted".