How to Patch a Mixed RHEL/AlmaLinux/Ubuntu/CentOS Hosting Fleet With One Tool

Where to start the patching process

Start with the inventory, not the product. Run uname -r across the fleet, group the results by kernel build rather than by distro name, and check those builds at patches.kernelcare.com. That list tells you which servers one agent can cover today, which need ELS because their vendor has moved on, and which genuinely need a migration plan.

The operators who patch mixed Linux server fleets should start there rather than with a vendor shortlist. Most of them find the third group is smaller than anticipated.

Linux patch management on a mixed fleet is usually not a migration problem waiting to be solved. It is a coordination problem that a cross-distro, rebootless approach removes, which leaves the reboot calendar covering what it should have covered all along: hardware and non-kernel upgrades.

How to manage patching on mixed Linux servers, step by step

The rollout on a fleet like that one is short enough to write out in full.

Here’s how to manage patching in a mixed server fleet:

1. Inventory every kernel build you run, not every distro name. uname -r across the fleet, grouped.
2. Check those builds at patches.kernelcare.com and separate covered from uncovered.
3. Sort the uncovered into two piles: end-of-life releases, which ELS handles, and anything genuinely unsupported, which needs a migration plan.
4. Deploy the agent to a pilot group, one server per distro family, and confirm patch state before widening.
5. Point air-gapped or panel-restricted servers at ePortal.
6. Retire the reboot calendar for kernel CVEs. Keep it for hardware and non-kernel upgrades, which still need it.
7. The remaining friction is a potential WHM notice. Because live patching corrects the running kernel in memory without changing the installed package version, WHM’s kernel check can still show a reboot prompt on a server that is fully patched, but it is easy to rectify.

Seven steps to patch mixed Linux servers once reboot is no longer part of the picture.

A checklist for teams that patch mixed Linux server fleet environments

Before committing to an approach, run it against these five:

• Does it cover every kernel build in the inventory, verified rather than assumed?
• Does a kernel CVE close without a reboot on every distro you run, or only some?
• Does it keep patching a server after the vendor declares that distro end of life?
• Can it report state for servers with no route to the public internet?
• Does it survive your panel mix, including the servers with no panel at all?

Anything that clears all five will let you patch mixed servers as one operation.

Teams that patch mixed Linux server fleets well are usually the ones that stop treating each distro as its own separate program of work.

Why hosting companies have to patch mixed distro fleet servers

The problem with a mixed fleet is that it accumulates over time. It is not a strategic business decision but a nigh-invisible creep in scope and complexity.

Four forces do most of the accumulating.

• Customers and resellers pick their own OS when you sell them a VPS or a dedicated box, and they rarely pick yours.
• Acquisitions arrive carrying someone else’s standard.
• Panel defaults drifted, so the servers you built in 2018 do not match the ones you built in 2024.
• CentOS ending its lifecycle sent everyone to AlmaLinux or Rocky at different speeds, so some fleets now run the destination and the origin side by side.

The panel layer fragments the same way. Across the hosting providers surveyed for the CloudLinux Web Hosting Trends Report 2026:

• 64% run cPanel/WHM
• 31% are on Plesk
• 23% run DirectAdmin
• 19% maintain custom panels
• 20% have no panel at all

Those figures pass 100% because the same company runs several.

So the average hosting estate fragments on two axes, not one: distro spread and panel spread, multiplied. That is the baseline

 Any approach to Linux patch management that assumes one of each is describing a fleet you do not have.

What Linux server patch management actually costs per distro

The cost is not the patching itself.

Patch management in Linux at the command line is one command, and dnf update has never been the hard part.

The cost is everything wrapped around it.

Where Linux patching breaks down at fleet scale

Run one kernel CVE through a four-distro fleet and watch the work multiply. You confirm the advisory against each distro separately, because Red Hat, Canonical, and SUSE all issue their own.

You wait on each vendor’s build, which lands on each vendor’s schedule. You stage each update through a different package manager: dnf on the RHEL family, apt for Ubuntu patch management and Debian patch management, zypper on SUSE.

Then you reboot, in groups, during night shifts, against a tracking sheet.

In reality, patch management in a mixed Linux server fleet is mostly coordination overhead, and coordination overhead scales with the number of distinct things to coordinate. Four distros is not four times one distro. It is four release calendars that never line up, feeding one reboot queue.

Live patching was supposed to fix the reboot part, and per vendor, it did.

Red Hat ships kpatch. Canonical ships Livepatch. SUSE ships its own. Oracle ships Ksplice.

Each works, and each stops at the edge of its own distribution. Deploy all four, and you have added four agents, four entitlement models, and four consoles to the thing you were already coordinating.

The panel tax nobody puts in the estimate

Here is the part enterprise patching content never covers, because enterprise patching does not have this problem.

In an enterprise, a reboot goes to a change advisory board and internal users get an email.

In hosting, a reboot goes to people paying you for uptime who did not consent to your planned downtime. Resellers have their own customers underneath them, so one notice fans out through two layers of relationship before it reaches whoever’s site goes dark.

Some will open a ticket the moment a site stops answering, announced or not.

That is the real unit cost of a reboot here: not the 90 seconds of downtime, but the notice, the ticket, and the reseller you talk down afterward.

Per-distro tooling at a glance

Read down the right-hand column and the pattern is the whole argument. Red Hat patching, Ubuntu patching, CentOS patch management, Debian patch management, and SUSE live patching are each excellent inside their own boundary and absent outside it.

Live kernel patching RHEL-side means kpatch; on Ubuntu it means Ubuntu live patch; neither crosses over.

That is not a criticism of engineering. It is a statement about scope. Most Linux patching best practices guides stop at “standardize your distros.”

Are you ready to rebuild your fleet?

What Linux patch management in mixed distro environments has to do

Before shopping, write down what the job requires. Patch management across a mixed Linux fleet comes down to four hard requirements, and most vendors are built to handle two of them well.

• One agent, every distro family you actually run. Not “supports RHEL and Ubuntu” on a datasheet, but the specific point releases and kernel builds in your inventory today. Including the CloudLinux and AlmaLinux boxes that generic tools treat as an afterthought.
• No reboot for kernel security fixes. If patching a kernel CVE still means scheduling a reboot, you’ve only automated the easy half of the job — finding the fix, not applying it without downtime.
• Coverage that outlives the distro’s official support window. Every real fleet has systems running past end-of-life, and those are exactly the ones still exposed to new CVEs.
• One console for fleet state, including servers with no route to the public internet.

In a mixed-distro environment, it’s the second and third requirements — live patching and extended-life coverage — that decide whether the deployment actually works.

How to judge Linux patch management software for a hosting fleet

The question that separates products quickly is not “which distros do you support” but this:

What happens to a kernel CVE, from disclosure to patched, on every box, without scheduling a reboot window?

Ask any patch management software vendor to walk that path end to end for a fleet like yours. Most answers arrive at a scheduling feature, which you already have.

Then ask what happens to servers running a release the vendor has stopped supporting. Good vendors will have an answer other than “migrate them.” Linux security patching that quietly excludes your oldest, most fragile boxes is not fleet coverage.

What server patch management tools usually miss

Generic server patch management tools are built around inventory and orchestration. They report what is installed, what is missing, and push updates on a schedule. Useful, but also where most of them stop, because the reboot sits outside their scope by design.

The gap shows in hosting-specific details:

• Multi-tenant blast radius, where an unpatched kernel lets one compromised account escalate to root and reach every other account on the box.
• Panel behavior, which most server patch management tools do not attempt.
• End-of-life hosts, which inventory tooling is good at flagging and bad at fixing.

The limitations of Linux patch management tools for mixed fleets

Shortlists of the best Linux patch management tools mix three product categories, which is why they are hard to act on.

Sorting by what each one removes from your week works better.

• Configuration management (Ansible, Puppet, Chef). Good at pushing the same action across a heterogeneous fleet. dnf here, apt there, no complaint. They automate the part before the reboot.
• Patch orchestration platforms. Inventory, compliance reporting, scheduled deployment, dashboards. Strong on audit evidence. The reboot remains yours.
• Open-source fleet managers (Uyuni, Landscape, Katello). Real cross-distro coverage and real operational weight to run. Still reboot-based.
• Vendor live patching (kpatch, Livepatch, Ksplice, SUSE live patching). Removes the reboot, inside one vendor’s boundary. Running several to cover a mixed fleet reintroduces the fragmentation you were trying to remove.

Most comparisons of Linux patch management tools treat that fourth row as a footnote. On a hosting fleet, it is the only row that changes the shape of the work.

The best patching tools for mixed hosting servers are the ones that make the reboot calendar shorter rather than better organized.

How KernelCare and Endless Lifecycle Support cover the whole fleet

Two products work in tandem to simplify and optimize the server patching process:

• KernelCare for live kernel patching
• Endless Lifecycle Support (ELS) for the fleet members the vendor has already abandoned

They work across numerous distro versions.

One Linux patch management tool across 60+ distro versions

KernelCare applies security fixes to the running kernel in memory. A kernel module pauses processes for nanoseconds, redirects the vulnerable code path to a corrected version, and resumes. The agent checks for new patches every four hours and applies them automatically. Nothing restarts, and no notice goes to a customer.

What matters for a mixed fleet is the coverage list: CloudLinux, AlmaLinux, RHEL, Ubuntu, Debian, Rocky, Oracle Linux, and more, across 60+ distro versions from a single agent. One patching tool, one deployment method, one cadence, whatever a given box happens to be running.

Coverage is per kernel build, not per distro name, so verify your specific kernels rather than assuming a family is covered end to end. And KernelCare patches the kernel; KernelCare+ extends the same approach to glibc and OpenSSL, licensed separately.

For servers that cannot reach the public internet, or when you want fleet state in one view, ePortal is the on-premises patch server: it mirrors the patch feed inside your network and reports which servers are current.

Patch management for Linux releases the vendor already dropped

The CentOS 7 boxes are the part no live-patching vendor answers by default, because there is no upstream fix to apply. That is what ELS is for. It tracks new CVEs, backports the fix to the end-of-life build, tests it, signs it, and publishes it to a repository your package manager pulls like any other update.

Same version, no migration, no schema changes.

ELS has patched 5,000+ CVEs across 10,000+ open-source packages on that model. For hosting fleets, the relevant coverage is end-of-life operating systems plus the components underneath them: MariaDB, MySQL, Apache, PHP, glibc, OpenSSL, OpenSSH.

With the two tools, Linux patching stops being distro-conditional. Supported boxes get live kernel patches, end-of-life boxes get backported fixes through the same package manager, and both report into the same place.

This product pairing was built for patch management for fleets that mix the two.

OCLC reported a 72% reduction in patching time and a 90% reduction in vulnerability exposure window after moving to live patching.

What this looks like on a 40-server fleet

A composite, drawn from the shape of fleets we see rather than from one account.

40 servers. 24 AlmaLinux 9 behind cPanel/WHM running shared hosting at roughly 180 accounts per box. 12 Ubuntu 22.04 behind Plesk, mostly VPS and reseller. Four CentOS 7 machines carrying legacy customers whose applications nobody wants to touch.

Standard patching process

A kernel CVE drops on a Tuesday.

The AlmaLinux boxes have no first-party live patching, so 24 servers need a reboot: 24 maintenance notices, roughly 4,300 affected accounts.

The Ubuntu servers are covered by Livepatch, using a different agent and console to be covered.

The four CentOS 7 machines get nothing.

Two patching systems, one uncovered group, and a reboot calendar that takes most of two weeks to drain because you can only take down so many shared boxes a night.

KernelCare + ESL patching process

Same CVE.

KernelCare patches the running kernel on 36 of the 40 servers within its next check cycle.

The four CentOS 7 boxes receive a backported patch through ELS via yum, which they were already configured to pull.

Nobody reboots. No maintenance notice goes out, so no reseller forwards one, so no ticket arrives asking why a site was down at 2 a.m.

Frequently Asked Questions

Common questions from hosting providers evaluating Endless Lifecycle Support

Yes, for kernel security patching. KernelCare covers 60+ distro versions from one agent, including RHEL, AlmaLinux, Rocky, CloudLinux, Ubuntu, Debian, and Oracle Linux. Coverage is per kernel build, so check your specific builds at patches.kernelcare.com.

The mechanism is the same: the fix goes into the running kernel in memory rather than into the on-disk package. What differs between vendor tools is scope. kpatch covers Red Hat kernels; Canonical Livepatch covers Ubuntu LTS kernels. KernelCare applies one method across both.

Live patching alone cannot help, because there is no upstream fix to apply. Endless Lifecycle Support backports security fixes to the end-of-life build and delivers them through your existing package manager, so those servers keep receiving patches without a migration.

Patching happens at the kernel level, below the panel, so the panel does not block it. WHM’s kernel check compares package versions and can still display a reboot notice on a patched server. TuxCare’s support KB documents the behavior and the fix.

It applies the same upstream security fix to the same running code. The practical difference favors live patching: a reboot-based fix protects nothing until the reboot happens, and that gap is usually measured in weeks.