Patching mixed Linux fleets without downtime: CloudLinux guide
CloudLinux explains how to manage patches on servers running different distributions using KernelCare and ELS, eliminating scheduled reboots.
UptimeMag editorial team · 22 September 2026 · 2 min read
CloudLinux published an operational guide on 22 September 2026 on its blog on how to manage security patches across fleets of servers running different Linux distributions, a common challenge for hosting providers managing infrastructure that has accumulated servers over time across cPanel, Plesk and panel-less machines. The source is the official CloudLinux blog at blog.cloudlinux.com/patch-mixed-distro-fleet.
The problem: fragmentation on two axes
According to data from the CloudLinux Web Hosting Trends Report 2026 cited in the article, among surveyed hosting providers:
| Panel | Provider share |
|---|---|
| cPanel/WHM | 64% |
| Plesk | 31% |
| DirectAdmin | 23% |
| Custom panels | 19% |
| No panel | 20% |
Percentages exceed 100% because many providers use multiple panels simultaneously. CloudLinux observes that the average fleet fragments along two axes at once—distributions and panels—which multiplies operational complexity rather than merely adding to it.
The proposed solution: KernelCare and ELS
CloudLinux presents two products as an answer to the problem. KernelCare applies patches to the running kernel in memory, without reboot and without prior customer notification, with a single agent covering CloudLinux, AlmaLinux, RHEL, Ubuntu, Debian, Rocky Linux and Oracle Linux. ELS (Extended Lifecycle Support) keeps software current via the existing package manager and without migrations, software which vendors have declared end-of-life: CentOS 7, MariaDB, MySQL, Apache, PHP and base libraries including glibc, OpenSSL and OpenSSH.
Recommended procedure
The guide outlines an operational sequence in seven steps: take inventory of every kernel build in use with uname -r across your entire fleet, grouped by build not by distribution name; verify coverage at patches.kernelcare.com; separate unsupported kernels between those at end-of-life (manageable with ELS) and those genuinely unsupported, which require a migration plan; deploy the agent to a pilot group, one server per distribution family; point air-gapped or panel-constrained servers towards ePortal; and finally retire the kernel CVE reboot schedule, maintaining it only for hardware updates and non-kernel patches.
The article also notes a practical detail: since live patching fixes the kernel in memory without changing the installed package version, WHM may continue to show a reboot warning even on an already patched server.
KoaVM, Koapanel, Koabilling, Prime Server and 1PrimeCDN are not mentioned in this article.
Written with the help of artificial intelligence and checked by the editors (EU AI Act, art. 50). Source: CloudLinux – sicurezza e rilasci.