Roll out KernelCare across a production fleet without a window

KernelCare's pitch is no-reboot patching, which means the rollout itself should not need a maintenance window either. It does need a staged plan. Push a bad patchset to 500 servers in a single Ansible run and you'll find out fast why nobody does that, even with --unload available.

This is the rollout playbook we recommend for a typical 100-500 server hosting fleet. Three rings, three weeks, monitoring wired up before the second ring starts.

Phase 1 — Pilot (week 1-2)

Pick 3-5 non-critical servers that still represent real kernel and workload variety: one Apache box, one MariaDB read replica, one Redis cache, one box running whatever exotic NIC driver your platform team complains about. Avoid your customer-facing edge tier for now.

yum -y install kernelcare
kcarectl --register <pilot-key>
kcarectl --set-patch-server https://eportal.example.com
kcarectl --update
kcarectl --info

The pilot key should be tied to a test feed in your ePortal — patches from TuxCare land here immediately. Set up the ePortal itself first if you haven't; see install KernelCare ePortal air-gapped.

Let them run for two weeks. Watch for:

• Kernel panics or oopses in dmesg after kcarectl --update.
• Driver regressions — particularly Mellanox, Intel ICE, and the in-tree XFS layer.
• Application-layer weirdness on long-running daemons (NGINX, MariaDB) — extremely rare, but the pilot exists to catch it.

If anything misbehaves, kcarectl --unload reverts in-memory patches without a reboot. Log the patch ID and open a TuxCare support ticket — they triage regressions fast for paying customers.

Phase 2 — Tier 2 (week 3)

Once the pilot is clean for 14 days, expand to staging and your lowest-traffic production tier. Aim for 20-50 servers — enough to surface workload-correlated issues, small enough to triage.

This is the ring where config management takes over. Ansible example:

- hosts: kernelcare_tier2
  become: true
  vars:
    kc_eportal: https://eportal.example.com
    kc_key: "{{ vault_kc_tier2_key }}"
  tasks:
    - name: install kernelcare
      yum: { name: kernelcare, state: present }
    - name: register
      command: kcarectl --register {{ kc_key }}
      args: { creates: /var/cache/kcare/registered }
    - name: point at eportal
      command: kcarectl --set-patch-server {{ kc_eportal }}
    - name: apply current patchset
      command: kcarectl --update

Tier 2 should register against the same test feed as the pilot for the first three days, then move to a prod feed with a 72-hour delay relative to test. Promote feeds in the ePortal UI under Feeds → Promote.

Phase 3 — Full rollout (week 4+)

Push to the remaining servers in batches of 10-20% per day, weighted by tier. The Ansible playbook stays the same; only the host pattern and the registration key change. By this point, the prod feed is the source of truth, and patches have had at least 72 hours on the pilot and tier 2 rings before any production server sees them.

Monitoring

The fastest way to surface trouble is to parse kcarectl --info into Prometheus via the node_exporter textfile collector. Drop this script in /etc/cron.d/kcare-metrics:

*/5 * * * * root /usr/local/bin/kcare-metrics.sh > /var/lib/node_exporter/textfile_collector/kcare.prom

kcare-metrics.sh:

#!/bin/bash
info=$(kcarectl --info)
patch_level=$(echo "$info" | awk '/^patch_level:/ {print $2}')
applied_at=$(echo "$info" | awk '/^applied:/ {print $2}')
echo "kcare_patch_level $patch_level"
echo "kcare_patch_applied_timestamp $(date -d "$applied_at" +%s)"

Alert when time() - kcare_patch_applied_timestamp > 86400 and the ePortal reports a newer patch_level for that server's feed — that's a stuck agent, not a missing patch.

The complementary check is on the ePortal itself:

eportal-cli servers list --inactive 86400

Anything in that list hasn't checked in for 24 hours. Investigate before the next patch window.

Rollback path

The rollback story has two layers. Use the first for transient issues, the second for genuine regressions.

1. kcarectl --unload — reverts in-memory patches on a single host without rebooting. The kernel returns to its on-disk state. Use this to triage one box.
2. Roll the feed back in ePortal — if a patch breaks at scale, promote an older patchset to your prod feed. Every agent that next runs --update (the default cron is hourly) drops the bad patch and applies the old one. No reboot.

For the agent itself, dnf history undo plus the steps in upgrade KernelCare agent and ePortal covers the RPM downgrade path.

What rollout does not replace

KernelCare patches kernel and libcare-covered userspace. It does not patch:

• Application code (your nginx, MariaDB, etc. binaries — those still need yum update plus a service restart).
• Container base images.
• Anything that's already been backported by your distro vendor — KernelCare detects and skips those.

You still need a quarterly reboot window for distro kernel upgrades. KernelCare buys you the months in between.

Next steps

• Buy seats or get volume pricing: KernelCare license.
• Stand up the on-prem patch distributor: install KernelCare ePortal air-gapped.
• cPanel-specific deployment notes: KernelCare on cPanel.