cPanel Drops Rocky Linux in Version 134 — What ServerSpan Customers Need to Know

cPanel version 134, released in January 2026, blocks upgrades on servers running Rocky Linux 8 or Rocky Linux 9. New cPanel installations on Rocky Linux are also blocked. If your server runs cPanel on Rocky Linux, you must migrate to AlmaLinux before you can receive any future cPanel updates, including security patches. This article covers what changed, how to migrate safely, and why this matters less than you might think if you choose the right hosting stack.

What cPanel Announced

On November 5, 2025, cPanel published a deprecation notice in their Newsroom. The core statement: starting with version 134, cPanel & WHM will discontinue support for Rocky Linux 8 and Rocky Linux 9. The reasoning cPanel gave is that AlmaLinux has achieved higher adoption in the RHEL-compatible ecosystem, and consolidating support on fewer distributions allows them to focus development and support resources more effectively.

Version 134 shipped on January 7, 2026. The upgrade blocker is now active. Servers on Rocky Linux that attempt to upgrade to v134 or later will be stopped by the installer. Servers already on v133 or earlier will continue to function, but they will not receive new features or security updates beyond their current version.

cPanel recommends AlmaLinux 9 or AlmaLinux 10 as the migration target. They reference the AlmaLinux deploy script hosted on GitHub as the supported conversion path. CloudLinux remains supported as well, and cPanel added CloudLinux 10 support in v134 alongside the Rocky Linux removal.

Why Rocky Linux Lost cPanel Support

Both Rocky Linux and AlmaLinux exist because Red Hat ended CentOS Linux as a stable, downstream rebuild of RHEL. CentOS became CentOS Stream, a rolling-release distribution that sits upstream of RHEL rather than downstream. Two projects emerged to fill the gap: Rocky Linux (founded by Gregory Kurtzer, one of the original CentOS founders) and AlmaLinux (backed by CloudLinux Inc.).

From a technical standpoint, Rocky Linux and AlmaLinux are nearly identical. Both are 1:1 binary-compatible rebuilds of RHEL. The differences are in governance, corporate backing, and ecosystem support. AlmaLinux has the backing of CloudLinux, a company with deep roots in the hosting industry through its CloudLinux OS and cPanel partnership. cPanel's parent company, WebPros, also owns Plesk, and the broader WebPros ecosystem has leaned toward AlmaLinux for standardization.

For hosting providers, the practical consequence is simple: if you run cPanel, you now run AlmaLinux, CloudLinux, or Ubuntu. Rocky Linux is no longer an option for maintained cPanel installations.

Who Needs to Act

You need to migrate if all three of these are true: you run cPanel or WHM, your server's operating system is Rocky Linux 8 or 9, and you want to continue receiving cPanel updates (including security patches). If any one of those conditions does not apply, this change does not affect you.

Specifically, this does not affect you if you use DirectAdmin as your control panel. DirectAdmin supports Rocky Linux, AlmaLinux, Debian, Ubuntu, and other distributions with no announced plans to drop any of them. ServerSpan's shared web hosting runs on DirectAdmin with an Nginx + Apache stack, so our shared hosting customers are not impacted by this change at all.

If you run a VPS or dedicated server with cPanel on Rocky Linux, whether managed by us or self-managed, you need to convert to AlmaLinux. The process is well-documented and does not require a full server rebuild.

How to Migrate from Rocky Linux to AlmaLinux

The migration uses the official AlmaLinux deploy script, which handles the in-place conversion by replacing Rocky Linux packages with their AlmaLinux equivalents. The script supports cPanel, Plesk, and DirectAdmin panels. It works on both EL8 and EL9 systems.

Before running anything, take a full server snapshot or backup. This is not optional. If your VPS provider offers snapshot functionality (and most do, including OVH), create one immediately before starting. You should also have direct console access to the server. Do not rely solely on SSH for this operation. If a kernel issue occurs during reboot, you will need out-of-band access to recover.

Pre-Migration Checks

Verify your current OS version and that all packages are up to date:

cat /etc/os-release
dnf update -y

Confirm your cPanel version. You can stay on your current version during the migration. The conversion script changes the OS layer underneath cPanel without touching cPanel's own files:

/usr/local/cpanel/cpanel -V

Verify that your /boot partition has sufficient free space. The AlmaLinux kernel installs alongside existing kernels rather than replacing them. At least 512 MB of free space in /boot is recommended:

df -h /boot

Running the Conversion

Download and run the AlmaLinux deploy script:

curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.sh

The script performs several operations: it detects your current distribution, verifies compatibility, downloads AlmaLinux release packages, swaps out Rocky Linux repositories and branding packages, and synchronizes all installed packages to the AlmaLinux equivalents. On a server with a few hundred packages, this typically takes 10 to 20 minutes depending on network speed and disk I/O.

Watch the output for errors. A successful conversion ends with a message confirming that the migration to AlmaLinux is completed.

Post-Migration Verification

Reboot the server to load the new AlmaLinux kernel:

reboot

After the reboot, verify the OS change:

cat /etc/os-release
cat /etc/redhat-release

Both outputs should reference AlmaLinux. Next, verify the boot kernel is the AlmaLinux version:

grubby --info DEFAULT | grep AlmaLinux

Check that cPanel services are running:

/usr/local/cpanel/cpanel -V
systemctl status cpanel
whmapi1 version

Verify web services, mail, and DNS are functional. Spot-check a few sites. Run a quick test on SSL certificate renewal if you use AutoSSL. Then, once you are satisfied, upgrade cPanel to v134:

/usr/local/cpanel/scripts/upcp

What If You Stay on Rocky Linux

If you choose not to migrate, your server will continue running on cPanel v133 (or whatever version you are currently on). cPanel will not force-remove itself. Your websites, email, and databases will keep working. However, you will stop receiving cPanel updates. That includes security patches.

In our experience managing production servers, running outdated control panel software is a significant risk. cPanel vulnerabilities are actively targeted because cPanel servers are identifiable by their default ports (2082, 2083, 2086, 2087) and common URL patterns. A server running a known-vulnerable cPanel version with no path to updates is a server that will eventually be compromised. The question is when, not if.

The practical advice is straightforward: migrate to AlmaLinux now, or plan your exit from cPanel entirely.

AlmaLinux vs CloudLinux: Which Migration Target

cPanel v134 supports AlmaLinux 8, AlmaLinux 9, AlmaLinux 10, CloudLinux 8, CloudLinux 9, CloudLinux 10, and Ubuntu 22 and 24 LTS. If you are migrating from Rocky Linux, the most direct path is AlmaLinux because the conversion is an in-place package swap with no reinstallation required.

CloudLinux is worth considering if you run a multi-tenant shared hosting server. It adds CageFS (per-user filesystem isolation), LVE (lightweight virtual environment resource limits per account), hardened PHP with HardenedPHP providing extended lifecycle support for older PHP versions, and kernel-level protections against symlink attacks. These features are specifically designed for hosting providers who put many customers on a single server. CloudLinux requires a separate license on top of the cPanel license.

For VPS users running a single site or a small number of sites, AlmaLinux is the straightforward choice. It provides the same RHEL compatibility without an additional license cost. The packages, security updates, and kernel track RHEL releases just as Rocky Linux did.

If you are currently on Rocky Linux 8, this is also a good time to evaluate whether you should jump to version 9 or even 10 instead of converting to AlmaLinux 8. Rocky Linux 8 (and by extension AlmaLinux 8) reaches end-of-life in May 2029. AlmaLinux 9 extends to May 2032. If you plan to keep this server running for more than two to three years, migrating to AlmaLinux 9 saves you a future major-version upgrade. The AlmaLinux deploy script handles cross-version migration from Rocky 8 to AlmaLinux 8 and Rocky 9 to AlmaLinux 9. Going from Rocky 8 directly to AlmaLinux 9 requires a two-step process: convert to AlmaLinux 8 first, then use the ELevate tool to upgrade from 8 to 9.

The Broader Pattern: Control Panel Vendor Lock-In

This is not the first time cPanel has forced a migration. When CentOS 7 reached end of life in June 2024, cPanel introduced Extended Lifecycle Support fees for servers that had not yet migrated. Before that, cPanel's aggressive pricing changes in 2019 (switching from a per-server license to per-account pricing) pushed costs up dramatically for providers with many accounts. Each of these events forced hosting providers and their customers into unplanned work with non-negotiable deadlines.

The Rocky Linux decision follows the same pattern. An upstream vendor makes a business decision, and everyone downstream scrambles. If you manage your own servers, these disruptions are part of the job. If you are paying for managed hosting, your provider should be absorbing this complexity for you.

This is one of the reasons we chose DirectAdmin as the panel for our shared and reseller hosting infrastructure. DirectAdmin has a different licensing model, a lighter resource footprint, and broader OS compatibility. It does not dictate which Linux distribution you run. When you are not tied to a single vendor's OS requirements, you have the flexibility to make infrastructure decisions based on technical merit rather than panel compatibility.

What ServerSpan Customers Should Do

If you are on our shared or reseller web hosting, you do not need to do anything. Our infrastructure uses DirectAdmin, and this cPanel change does not affect you.

If you use our cPanel management service on your own VPS or dedicated server, we will handle the Rocky Linux to AlmaLinux migration for you. We schedule the conversion during a maintenance window, take a snapshot before starting, run the migration, verify all services, and upgrade cPanel to the latest version. The typical downtime is one reboot cycle, usually under five minutes.

If you manage your own cPanel server and want help with the migration, we offer this as part of our Linux administration services. A one-time migration engagement covers the snapshot, conversion, verification, and cPanel upgrade.

If you are considering this an opportunity to move away from cPanel entirely, our DirectAdmin management service includes migration from cPanel to DirectAdmin. The migration preserves accounts, domains, email, databases, and files. DirectAdmin can import cPanel backup archives (cpmove-user.tar.gz format) directly.

Whatever path you take, do not leave a Rocky Linux + cPanel server sitting without a plan. The update blocker is active now, and every day without security patches increases your exposure. For a broader perspective on how we approach hosting infrastructure decisions, including panel choice and data center selection, see our page on why customers choose ServerSpan. And if you are evaluating control panels as part of this migration, our DirectAdmin vs cPanel comparison covers the practical differences in depth.

A Technical Decision or a Commercial One?

cPanel framed this change as a resource optimization decision. That framing deserves scrutiny.

Rocky Linux and AlmaLinux are 1:1 binary-compatible rebuilds of RHEL. They produce the same RPMs from the same sources. The kernel is the same. The ABI is the same. The system libraries, glibc, OpenSSL, and systemd versions are identical for any given RHEL point release. A cPanel EasyApache RPM that installs on AlmaLinux 9.5 installs on Rocky Linux 9.5 without modification. There is no technical divergence between the two distributions that would create a meaningful difference in testing, packaging, or support burden. When cPanel says they need to "focus resources," the obvious question is: focus them on what, exactly? The testing matrix is the same.

The corporate relationships tell a clearer story. AlmaLinux was created and is primarily sponsored by CloudLinux Inc. through the AlmaLinux OS Foundation. CloudLinux also produces CloudLinux OS, a paid distribution that adds CageFS, LVE resource limits, HardenedPHP, and KernelCare on top of the RHEL base. WebPros International, cPanel's parent company, has maintained a deep commercial partnership with CloudLinux for over a decade. CageFS, LVE, and HardenedPHP all integrate directly into cPanel and WHM. These are not arm's-length relationships.

Version 134 itself reveals the direction. Alongside the Rocky Linux removal, cPanel shipped native integration for TuxCare Extended Lifecycle Support for PHP, a paid product from TuxCare (a CloudLinux Inc. subsidiary). The commercial pipeline is becoming visible: migrate everyone to AlmaLinux (free, governed by a foundation controlled by CloudLinux Inc.), then upsell to CloudLinux OS for multi-tenant isolation features, then upsell further with TuxCare for extended PHP version support and KernelCare for live kernel patching. Each layer adds a license fee. Each layer is controlled by the same corporate family.

This does not mean AlmaLinux itself will become a paid product. The foundation structure and open-source licensing make a direct paywall impractical because it would trigger an immediate community fork, exactly as happened with CentOS. The more likely model mirrors what Red Hat built: keep the base OS free, but make the value-added ecosystem around it the revenue engine. If every cPanel server in the world runs AlmaLinux, every cPanel server is one sales conversation away from a CloudLinux license.

None of this is speculative in the conspiratorial sense. These are publicly documented corporate relationships, product announcements shipped in the same release, and a pattern of ecosystem consolidation that any server administrator can verify. What it means for you as a hosting customer is straightforward: understand that your control panel vendor's OS decisions may be driven by partnership economics rather than technical necessity. Factor that into your infrastructure planning. And if vendor-driven migrations every few years do not fit your operational model, consider hosting stacks where the panel does not dictate your operating system choice.