Guide Upgrade CyberPanel Safely: What the Upgrade Changed on Our Server (Tested)

Guide Upgrade CyberPanel Safely: What the Upgrade Changed on Our Server (Tested) - 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 Security Guides (https://adminsforum.com/Forum-cyberpanel-security-guides)
+----- Thread: Guide Upgrade CyberPanel Safely: What the Upgrade Changed on Our Server (Tested) (/Thread-guide-upgrade-cyberpanel-safely-what-the-upgrade-changed-on-our-server-tested)

Upgrade CyberPanel Safely: What the Upgrade Changed on Our Server (Tested) - JAY - 10-27-2026

Upgrade CyberPanel Safely: What the Upgrade Changed on Our Server (Tested)

Sooner or later CyberPanel shows a yellow note on Version Management: Latest commit does not match, please upgrade CyberPanel. Ours said that even though both sides showed version 3.0, build 8: the code on GitHub had simply moved on. The upgrade itself is one command, but it rebuilds a lot: OpenLiteSpeed, ModSecurity, the panel's Python packages. So we did it properly on our test server (CyberPanel 3.0, Ubuntu 24.04, 4 websites, mail, fail2ban and lots of hand-made config changes from our other guides) and compared everything before and after.

Short version: it took about 4.5 minutes, all sites came back, and none of our own config edits were overwritten. But the upgrade opened a new port (4190) to the whole internet, added two cron jobs and replaced the panel's SSL certificate. Details below.

Step 1: Check what you have
In the panel:

Code:

https://YOUR-SERVER-IP:8090/base/versionManagment

(yes, with that spelling) shows current and latest version, build and commit. From SSH:

Code:

git -C /usr/local/CyberCP log -1 --format='%h %cd'
git -C /usr/local/CyberCP branch
df -h /

Ours: branch

Code:

v3.0.8

, commit

Code:

324f18ad

from October 23. The panel said the latest was

Code:

12a529ee

; when we upgraded a day later we got

Code:

b36940aad

. The stable branch changes often, so "latest" is a moving target. Make sure you have a few GB free on disk; our backup in Step 2 alone was 700 MB.

Step 2: Back up first
The best backup is a snapshot of the whole VPS at your provider, if they offer it. That's the only "undo button" that really covers everything. On top of that (or if you have no snapshots), save the panel, the web server config and all databases:

Code:

mkdir -p /root/pre-upgrade && cd /root/pre-upgrade
tar czf cybercp.tgz /usr/local/CyberCP /usr/local/lsws/conf /etc/cyberpanel
mysqldump -uroot -p"$(cat /etc/cyberpanel/mysqlPassword)" --all-databases --single-transaction | gzip > all-db.sql.gz
ls -lh

CyberPanel keeps the MySQL root password in

Code:

/etc/cyberpanel/mysqlPassword

; the

Code:

$(cat ...)

passes it without printing it on screen. We got 701 MB for the files (most of it is the panel's Python environment) and 611 KB for the databases. All our sites worked afterwards, but a fresh website backup doesn't hurt, ideally copied off the server.

Step 3: Take a "before" picture
This is the step most people skip, and the only way to know afterwards what the upgrade changed. Checksums of all config files that matter, plus cron, firewall and running services:

Code:

mkdir -p /root/pre
D='/usr/local/lsws/conf /etc/postfix /etc/dovecot /etc/fail2ban /etc/ssh'
find $D -type f -exec md5sum {} + | sort -k2 > /root/pre/conf.md5
md5sum /usr/local/lsws/lsphp*/etc/php/*/litespeed/php.ini >> /root/pre/conf.md5
crontab -l > /root/pre/cron.txt
firewall-cmd --list-all > /root/pre/fw.txt
systemctl list-units --type=service --state=running --no-legend | awk '{print $1}' > /root/pre/svc.txt

And note the HTTP status of each website and of the panel, for example with

Code:

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

. All of ours answered 200.

Step 4: Run the upgrade
The official command, as root:

Code:

sh <(curl https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh || wget -O - https://raw.githubusercontent.com/usmannasir/cyberpanel/stable/preUpgrade.sh)

Run it in
Code:
screen
or
Code:
tmux
if you're on SSH, or from your provider's VNC console like we did. If your connection drops halfway, the upgrade dies halfway.
It asks: Press the Enter key to continue with latest version, or enter specific version. Enter (or waiting 10 seconds) means latest stable.
To keep a log, add
Code:
2>&1 | tee /root/upgrade.log
at the end. Ours had 4,369 lines.

What it did on our server: updated the package lists, downloaded and verified (SHA256) its own OpenLiteSpeed and ModSecurity builds (about 80 MB), reinstalled the panel's Python packages (Django 4.2.14 and friends), restarted the panel and the web terminal. Started at 04:11:20, done at 04:15:52.
The end of the output:
[Image: attachment.php?aid=587]

Step 5: Check that everything still works
Right after the upgrade, same check as before:
[Image: attachment.php?aid=588]

All 4 sites and the panel: 200.

Code:

lshttpd -v

still reported LiteSpeed 2.5.5. (apt also updated a package called

Code:

openlitespeed

from 1.9.3 to 1.9.4 during the run, but the server still reported the same 2.5.5 build.) Postfix, Dovecot, OpenLiteSpeed and the panel service (

Code:

lscpd

) were active, and all four fail2ban jails were still running. Log in to the panel and click through a few pages too.

Step 6: What the upgrade changed
1. Config files: our edits survived.

Code:

mkdir -p /root/post
find $D -type f -exec md5sum {} + | sort -k2 > /root/post/conf.md5
md5sum /usr/local/lsws/lsphp*/etc/php/*/litespeed/php.ini >> /root/post/conf.md5
diff <(sort -k2 /root/pre/conf.md5) <(sort -k2 /root/post/conf.md5)

We compared the checksums of all 599 files:
[Image: attachment.php?aid=589]

Only side files changed: new

Code:

vhost.conf.txt

copies next to every site's

Code:

vhost.conf

Code:

.txt

templates, and

Code:

httpd_config.conf.dpkg

(the package's default config, left there by apt instead of overwriting ours). The live

Code:

httpd_config.conf

was untouched, as were all

Code:

vhost.conf

files with our per-site PHP settings, all php.ini files, Postfix, Dovecot, our fail2ban fixes and our SSH settings. That's one test on one version; the before/after check is how you find out on yours.

2. Services, cron and firewall: three surprises.

Code:

for f in svc cron fw; do echo "== $f"; diff /root/pre/$f.txt /root/post/$f.txt; done

Then services, root's crontab and the firewall:
[Image: attachment.php?aid=590]

Two new cron jobs for root:
Code:
run_scheduled_scans
every minute and
Code:
pdnsHealthCheck.py
every 5 minutes. Our own cron jobs were still there. If you manage root's crontab yourself, know that the upgrade adds to it.
A new firewall rule: port 4190 open to everyone, for IPv4 (
Code:
0.0.0.0/0
) and IPv6. Nobody asked us about it.
Services:
Code:
packagekit
was running afterwards (apt starts it); nothing we use went missing.

3. Port 4190 (ManageSieve).
Port 4190 is ManageSieve, part of the Dovecot mail server:
[Image: attachment.php?aid=591]

Code:

ss -ltnp | grep ':4190 '
grep -n 4190 /root/upgrade.log

Dovecot listens on all addresses, and the upgrade log says it plainly: Sieve port 4190 added to firewall successfully. ManageSieve lets mail programs (for example Thunderbird with a Sieve add-on) edit server-side filter rules like "move mails from X to folder Y". It's one more login on the internet that bots can guess passwords against. If none of your mail users manage filters from a desktop mail program, close it:

Code:

P='port port="4190" protocol="tcp" accept'
firewall-cmd --permanent --remove-rich-rule="rule family=ipv4 source address=0.0.0.0/0 $P"
firewall-cmd --permanent --remove-rich-rule="rule family=ipv6 $P"
firewall-cmd --reload
firewall-cmd --list-all | grep -c 4190

Our result:
[Image: attachment.php?aid=592]

means the rule is gone. Dovecot still listens, so webmail on the same server can still use it locally. You can also delete the rule on the panel's firewall page (firewall guide). Check again after the next upgrade, it may add the rule back.

4. A new certificate for the panel.
The panel itself also got a new certificate:
[Image: attachment.php?aid=593]

Code:

ls -l /usr/local/lscp/conf/*.pem
echo | openssl s_client -connect 127.0.0.1:8090 2>/dev/null | openssl x509 -noout -issuer -dates

Code:

cert.pem

and

Code:

key.pem

were written at 04:15, during the upgrade: a new self-signed certificate (

Code:

CN = www.example.com

) valid until 2029. Chrome showed its "Your connection is not private" warning for port 8090 again. Our server only had the default self-signed one, so nothing was lost here. If you put a real certificate on the panel (hostname SSL), check port 8090 in your browser after every upgrade and issue it again if it's gone.

If something breaks
We didn't need it, but this is what the backups from Step 2 are for. A provider snapshot is the fastest way back. Without one: first read the end of

Code:

/root/upgrade.log

for the error. The

Code:

tar

archive holds the old panel and web server config, and

Code:

all-db.sql.gz

the databases, including the panel's own database, so you can put back exactly what you had. CyberPanel can also install a specific branch instead of the latest; type it at the version prompt from Step 4.

Checklist

Provider snapshot, or at least files + database dump, and enough free disk.
"Before" checksums, cron, firewall, services and site status saved.
Upgrade run in
Code:
screen
/
Code:
tmux
or the console, with a log.
Sites and panel answer, mail and fail2ban running.
Diff of configs, cron and firewall. Close port 4190 if you don't use ManageSieve.
Panel certificate: still the one you want?

More CyberPanel guides

Tested upgrading CyberPanel 3.0 (branch v3.0.8) on Ubuntu 24.04 with OpenLiteSpeed, October 2026. What an upgrade changes depends on the version you come from and the one you get; run the before/after check on yours.