With cPanel & WHM 134, released as the LTS branch in January 2026, Rocky Linux 8 and 9 were dropped from the supported operating system list. A Rocky server can stay on 133 but will never receive a newer version, which in 2026 means missing a steady stream of root-escalation security fixes. cPanel’s answer is an in-place deployment script that converts the operating system to AlmaLinux of the same major version, keeping accounts, databases and configuration intact. This guide walks through the conversion and the verification that matters.
Applies to cPanel & WHM 133 on Rocky Linux 8 and 9 to AlmaLinux 8 and 9, then cPanel & WHM 134+
Table of Contents
Short answer: A Rocky Linux cPanel server is stuck at version 133 and no longer receives security releases, so convert it in place to AlmaLinux of the same major version using cPanel’s deployment script, run inside screen after a verified backup and a hypervisor snapshot. Once the reboot shows AlmaLinux in /etc/os-release, set CPANEL=lts or release in /etc/cpupdate.conf, run /scripts/upcp --force and confirm accounts, mail and databases still work.
Why you cannot wait
Since April 2026 cPanel has shipped an emergency or targeted security release roughly every two to three weeks, several of them fixing flaws that let any cPanel account or an unauthenticated visitor gain root. Those builds ship only for supported tiers on supported operating systems. A Rocky server pinned at 133 will receive none of them. Check where you stand right now:
whmapi1 version
cat /etc/os-release | grep -E '^(NAME|VERSION_ID)'
grep CPANEL /etc/cpupdate.confIf you see Rocky Linux and a version below 134, plan the conversion this week rather than next quarter. If your server is still Rocky 8, the sensible path is convert to AlmaLinux 8, then upgrade the OS to 9 or 10 using ELevate as described in Upgrading a cPanel server’s OS with ELevate.
Prepare the server
The conversion swaps the distribution packages and branding underneath a running system. It is well tested but it is still a major operation, so treat it as one.
- Take a full backup and confirm it restores. WHM → Backup → Backup Configuration should already be pointed at remote storage; run a manual backup and test a restore of one account elsewhere. Our backup-verify script checks that the archives are complete.
- Take a snapshot at the hypervisor level if the server is virtual. This is your fastest rollback.
- Bring cPanel fully up to date on 133 with
/scripts/upcp --forceand reboot into the latest kernel. - Remove or note third-party repositories. Anything that pins packages to Rocky-specific builds (custom kernels, unusual
dnfmodules) will confuse the conversion. Rundnf repolistandrpm -qa --qf '%{NAME} %{VENDOR}\n' | grep -vi -E 'cpanel|almalinux|rocky|cloudlinux'to see what is foreign. - Check free space; the conversion redownloads a large portion of the base system. Keep at least 5 GB free on
/. - Disable KernelCare temporarily if it is installed, and note your CSF or firewall configuration so it can be restored if the conversion removes a package.
Run the conversion
cPanel provides a deployment script for this purpose; the current version and its download location are documented in the cPanel changelog and knowledge base for your build, so fetch the script from cPanel’s own download host rather than a mirror. Run it in a screen session, because a dropped SSH connection halfway through a distribution swap is the worst outcome. The script performs its own pre-flight checks and stops if it finds a blocker such as an unsupported kernel, a broken RPM database or a non-cPanel control panel component. Fix whatever it reports and rerun it; do not force past the checks.
The conversion typically takes twenty to forty minutes. It replaces the rocky-release package family with the AlmaLinux equivalents, swaps repository definitions, reinstalls packages from AlmaLinux mirrors and rebuilds the kernel entries. It will reboot the server at least once. Do not run other package operations in parallel and do not let a cron job start an upcp run during the process; disable automatic updates in WHM for the duration and re-enable them afterwards.
After the reboot
Confirm the distribution changed and that cPanel now sees a supported platform:
cat /etc/os-release
cat /etc/redhat-release
rpm -qa | grep -i rockyThe last command should return nothing. Then update cPanel to the tier you want. Edit /etc/cpupdate.conf so CPANEL=lts or CPANEL=release, then run /scripts/upcp --force. The update should proceed past 133 for the first time; watch the log at /var/cpanel/updatelogs/ for warnings.
Rebuild the pieces that depend on the base system:
/scripts/check_cpanel_pkgs --fix
/usr/local/cpanel/scripts/rpmup
/scripts/restartsrv_httpd
/scripts/restartsrv_exim
/scripts/restartsrv_mysqlRe-enable KernelCare with kcarectl --update if you use it, and run csf -ra to confirm the firewall loaded cleanly. Run dnf repolist again and make sure only AlmaLinux and cPanel repositories remain.
Verify
The verification you care about is whether accounts still work end to end:
- Browse to several hosted sites, including one using a non-default PHP version and one with PHP-FPM enabled.
- Check
uapi --user=someuser Mysql list_databasesand log into a database from a site. - Send and receive mail on a hosted domain; the Dovecot and Exim packages are cPanel-built so they should be untouched, but confirm with
/scripts/restartsrv_dovecot --status. - Confirm
whmapi1 versionnow reports 134.x or 138.x and that WHM → Server Configuration → Update Preferences shows no blocker.
Run our server security audit afterwards to confirm nothing in the hardening baseline regressed.
Common pitfall
The conversion script refuses to run on systems with non-standard kernels, most often cloud-provider kernels or a stale kernel-plus install. Boot into the standard kernel package and remove the others before starting. The other frequent surprise is a server that was itself migrated from CentOS years ago and still carries leftover centos-* packages; the script will list them and you must remove them by hand first. If the conversion fails partway, do not attempt manual repair on a production box: roll back to the snapshot, resolve the reported blocker, and run it again.
Rocky Linux cPanel to AlmaLinux at a glance
Official documentation: cPanel & WHM documentation, AlmaLinux wiki, Linux man pages.
Related guides: Upgrading a cPanel server’s OS with ELevate: AlmaLinux 8 → 9 → 10 · Choosing a VPS for a cPanel or DirectAdmin server in 2026 · How to install cPanel & WHM on AlmaLinux 10 (2026 checklist).
Frequently asked questions
Does cPanel still support Rocky Linux 8 or 9?
No. cPanel & WHM 134, the January 2026 LTS release, removed Rocky Linux 8 and 9 from the supported list. A Rocky server can remain on 133 but receives no further feature or security releases.
How long does the Rocky to AlmaLinux conversion take on a cPanel server?
Typically twenty to forty minutes including at least one reboot, plus the time for the backup and snapshot beforehand and the upcp run afterwards. Plan a maintenance window of two hours to be safe.
Can I go straight from Rocky 8 to AlmaLinux 9 or 10?
Not in one step. The conversion script swaps distributions at the same major version, so Rocky 8 becomes AlmaLinux 8 first; then ELevate carries the server to AlmaLinux 9 and, if wanted, 10 as separate upgrades.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- cPanel & WHM 133 on Rocky Linux 8 and 9 to AlmaLinux 8 and 9, then cPanel & WHM 134+
- Last full review
- Next review