Guide CyberPanel: Change the PHP Version of One Website (and Per-Site PHP Settings)

Guide CyberPanel: Change the PHP Version of One Website (and Per-Site PHP Settings) - Printable Version

+- AdminsForum (https://adminsforum.com)
+-- Forum: Free & open-source control panels (https://adminsforum.com/Forum-free-open-source-control-panels)
+--- Forum: CyberPanel (https://adminsforum.com/Forum-cyberpanel)
+---- Forum: CyberPanel Guides & Tutorials (https://adminsforum.com/Forum-cyberpanel-guides-tutorials)
+----- Forum: CyberPanel PHP & LSPHP Guides (https://adminsforum.com/Forum-cyberpanel-php-lsphp-guides)
+----- Thread: Guide CyberPanel: Change the PHP Version of One Website (and Per-Site PHP Settings) (/Thread-guide-cyberpanel-change-the-php-version-of-one-website-and-per-site-php-settings)

CyberPanel: Change the PHP Version of One Website (and Per-Site PHP Settings) - JAY - 10-26-2026

CyberPanel: Change the PHP Version of One Website (and Per-Site PHP Settings)

CyberPanel lets every website run its own PHP version. That's useful when an old plugin or script breaks on a new PHP, or when you want to test PHP 8.4 on one site before moving the rest. Changing it takes one click, but two things catch people out: the switch isn't instant, and SSH/cron still use the server's default PHP. Then there's the next question: how do you give one site more memory or a bigger upload limit? On CyberPanel with OpenLiteSpeed, the usual cPanel tricks don't work. We tested all of it on our server.

Which PHP versions you have
Each version lives in its own folder:

Code:

ls -d /usr/local/lsws/lsphp*

Ours had

Code:

lsphp81

Code:

lsphp85

. A version only shows up in the panel's dropdowns if it's installed. Missing extensions per version are covered in our PHP extensions guide.

Step 1: Change the PHP version in the panel
Websites > List Websites > Manage (for a subdomain or addon domain: Websites > List Child Domains > Manage). We used our test subdomain

Code:

blog.cyber.adminslab.com

, which ran PHP 8.3.
Open the site, scroll to Configurations and click Change PHP:
[Image: attachment.php?aid=563]

Pick the version and click Change PHP. The panel says PHP successfully changed. One small trap: on our build the dropdown is empty when the page opens, so the panel doesn't tell you which version the site uses right now. Check it from SSH before and after (Step 2).

What the button actually does: it edits one line in the site's OpenLiteSpeed config,

Code:

/usr/local/lsws/conf/vhosts/yoursite/vhost.conf

Code:

path /usr/local/lsws/lsphp82/bin/lsphp

Nothing else in the file changes, so your other vHost settings stay as they are.

Step 2: Check that the site really switched
Put a tiny test file in the site folder (as the site user, so it gets the right owner):

Code:

cd /home/yourdomain.com/public_html
echo '<?php echo PHP_VERSION, "\n";' > v.php
chown SITEUSER:SITEUSER v.php
curl -s https://yourdomain.com/v.php

Our check on the test site, switched to PHP 8.2:
[Image: attachment.php?aid=564]

The config says

Code:

lsphp82

, the website answers 8.2.35, but

Code:

php -v

on the command line still says 8.3.36. Two lessons from this:

Give it a few seconds. Our very first request right after the click still came back as 8.3.36; the old PHP processes finish their work first. Within about 10 to 30 seconds every request was on the new version, both times we switched. No manual restart needed.
The command line doesn't follow.
Code:
php
in SSH, cron jobs, Composer and WP-CLI use the server's default PHP, not the site's. If your site runs 8.2, call that version's binary directly:

Code:

/usr/local/lsws/lsphp82/bin/php -v
/usr/local/lsws/lsphp82/bin/php /home/yourdomain.com/public_html/cron.php
/usr/local/lsws/lsphp82/bin/php /usr/local/bin/composer install

That matters most for cron jobs and for Laravel's artisan: a script that works on the site can fail from cron because it runs on a different PHP.

Delete

Code:

v.php

when you're done.

Step 3: Change PHP settings for one site only
Server > PHP > Edit PHP Configs changes

Code:

php.ini

for every site on that PHP version (see our php.ini guide). Often you only want one site to get more memory or a bigger upload limit. We tried the three usual ways on the same site:

Code:
.user.ini
in the site folder with
Code:
post_max_size = 77M
Code:
.htaccess
with
Code:
php_value upload_max_filesize 64M
Code:
phpIniOverride
in the site's vHost config with
Code:
upload_max_filesize 64M
and
Code:
memory_limit 256M

Here is our test with all three in place on the same site:
[Image: attachment.php?aid=565]

.user.ini: ignored.
Code:
post_max_size
stayed at the server's 8M, also after the 5-minute
Code:
user_ini.cache_ttl
and with fresh PHP processes.
.htaccess php_value: ignored. OpenLiteSpeed reads rewrite rules from
Code:
.htaccess
, but not PHP settings. No error either, which is why people don't notice. (On LiteSpeed Enterprise this line does work.)
vHost phpIniOverride: works. 256M and 64M, right after a restart.

So on CyberPanel with OpenLiteSpeed, per-site PHP settings go into the vHost config.
In the panel it's vHost Conf on the same page. Ours, after the change:
[Image: attachment.php?aid=566]

Find the existing block (it's empty by default) and add your settings inside:

Code:

phpIniOverride  {
php_value upload_max_filesize 64M
php_value post_max_size 64M
php_admin_value memory_limit 256M
}

Click Save. If the change doesn't show up on the site, restart OpenLiteSpeed from SSH:

Code:

/usr/local/lsws/bin/lswsctrl restart

(a graceful restart, visitors don't notice).

Notes:

Code:
php_value
can be changed again by the site's own code (
Code:
ini_set()
);
Code:
php_admin_value
can't. Use
Code:
php_admin_value
for limits you want to enforce, such as
Code:
memory_limit
.
When you raise uploads, set
Code:
post_max_size
at least as high as
Code:
upload_max_filesize
. Otherwise the smaller one wins.
The block survived a PHP version change: we switched the site 8.3 > 8.2 > 8.3 in the panel and the override was still there and active.
There are two
Code:
phpIniOverride
blocks in the file on our build: one near the top and one inside the SSL section at the bottom. The top one is the one that counted in our test.
Typos in the vHost config can take the site down. Keep a copy before you edit:
Code:
cp vhost.conf /root/vhost.conf.bak
.

Before you switch a live site

Check that your plugins/themes or framework support the target version. WordPress core runs on all current versions, plugins are the usual problem.
Install the same extensions for the new version (
Code:
lsphp82-curl
,
Code:
-intl
,
Code:
-imagick
and so on). A missing extension is the most common cause of a 500 error after a PHP switch.
Copy any custom
Code:
php.ini
settings to the new version: each one has its own file, e.g.
Code:
/usr/local/lsws/lsphp82/etc/php/8.2/litespeed/php.ini
.
Watch the site's error log for a few minutes after switching:
Code:
/home/yourdomain.com/logs/yourdomain.com.error_log
.

More CyberPanel guides

Tested on CyberPanel 3.0 (build 8, OpenLiteSpeed edition) on Ubuntu 24.04, October 2026. Menu names can change slightly between versions.