Skip to content 
TuxCare's KernelCare Patch Feed provides live updates for the Linux kernel and key components, allowing me to patch critical vulnerabilities without rebooting and keep services running. With the KernelCare Patch I reduce the attack window, manage the rollout via feeds, and automatically secure heterogeneous Linux environments.
Key points
The following points outline the most important aspects concisely and clearly.
- Live Patching It eliminates downtime because I apply kernel fixes while the system is running, and sessions remain active.
- Patch Feeds Enable production, testing, and delayed rollouts—all controlled through simple configuration.
- Automation Checks every four hours, safely downloads patches, and applies them without restarting.
- ePortal It supplies isolated networks locally, while the cloud portal serves open systems directly.
- CVE Coverage Protects the kernel, older distributions via ELS, and libraries such as OpenSSL using LibCare.
What does the KernelCare Patch Feed do?
I keep my Linux server With the KernelCare Patch Feed, I can continuously maintain security without disrupting scheduled maintenance windows. The service provides tested live patches that I load directly into the running kernel, closing critical vulnerabilities in minutes instead of days. This is how I ensure Workloads such as databases, container hosts, or virtualization servers, while users continue working. I reduce the risk of errors because there are no manual restart chains and no sessions are interrupted. At the same time, I improve the response time to CVEs, since the feed provides patches promptly and I can fine-tune the rollout. In this way, security shifts from being reactive to being predictable, without compromising availability.
How Live Patching Works Without a Reboot
I'm installing a lightweight Agent, which, by default, checks for new patches every four hours, cryptographically verifies them, and loads them directly into the running kernel. The process has minimal impact on the system, the services remain responsive, and I don’t have to coordinate any downtime. I control automatic updates via a simple toggle, allowing me to choose between immediate security or a controlled delay depending on the environment. For a more in-depth overview of security through live kernel updates, see KernelCare Enterprise Security. This allows me to maintain control while significantly reducing the effort required for manual patch windows. The result: less risk, fewer night shifts, and higher service quality for critical systems.
Controlling Feeds: Production, Test, and Delay
I choose the right Feed per system, thereby defining the speed and risk profile. The production feed contains fully tested live patches ready for immediate use. The test feed provides the latest fixes for rigorous QA processes before I release them to production. Delayed feeds (12h, 24h, 48h) hide the most recent changes so that I can schedule additional observation windows. I configure the selection in kcare.conf Configure it using the PREFIX variable and combine it with auto-update options. This creates a clear, reproducible update strategy for heterogeneous fleets.
| Feed | Intended use | Risk | Time until rollout | Configuration | Typical scenario |
|---|---|---|---|---|---|
| Production | Immediately Secure live patches | Low | Immediately after approval | PREFIX=prod (default) | Widespread use on production hosts |
| Test | Latest Patches for QA | Medium | Quick, before production | PREFIX=test | Preliminary testing in staging environments |
| 12h/24h/48h | Delayed Delivery | Low | After 12, 24, or 48 hours | PREFIX=12h|24h|48h | Conservative Rollouts in Regulated Environments |
Secure Delivery: Cloud Portal and ePortal
I connect systems with Internet I go directly to the cloud portal and have the agent retrieve the patches on schedule. In isolated networks, I use a local ePortal that mirrors patches internally and delivers them to hosts according to defined rules. This allows me to comply with air-gap requirements while still distributing the latest fixes via internal channels. I assign each server to a feed and deployment policy, allowing me to control the timing and priority for each group. I take advantage of this separation in hybrid setups that combine the cloud and a data center. The result is a consistent, secure supply across all zones.
Automation and Control in Everyday Life
I'll have the agent check all four Hours Check, download signed patches, and apply them directly. If necessary, I temporarily disable AUTO_UPDATE and schedule deployments specifically during maintenance windows, without requiring a reboot. Sticky tags help me lock in a defined patch status for specific server groups and upgrade them only as needed. To compare different live patching approaches, I use the overview at Live Kernel Patching Comparison. I document decisions with version-specific details and complete audits more quickly because the process remains traceable. This allows me to combine speed with clear governance.
CVE Coverage and Legacy Support
I am counting on a broad CVE-Coverage across a wide range of kernel versions. Even if distributors do not address individual vulnerabilities, the feed provides appropriate fixes for affected systems. Through ELS, I receive security updates for older distributions such as CentOS 7 or Ubuntu 18.04 and can also keep legacy hosts secure. With LibCare, I further harden OpenSSL and glibc via live patching, which reduces the attack surface in cryptographic libraries. This keeps the entire platform—kernel and libraries—up to date without requiring operational intervention in the running service. In this way, I ensure compliance goals are met and reduce technical debt.
Benefits in Hosting and Server Operations
I hold Web server, databases, and container nodes are accessible at all times because I apply kernel patches without a reboot. Hosting customers, in particular, appreciate continuous availability, fewer maintenance windows, and consistent response times. I reduce the support burden by eliminating nightly reboots and session interruptions. Anyone weighing the cost-effectiveness can find more information at Cost-Effectiveness of Live Patching Orientation. For multi-client platforms such as WordPress or e-commerce hosting, this approach pays off in terms of service levels and customer satisfaction. This is how I strengthen my offering with tangible security and predictable operations.
Step-by-Step Introduction
I start with a clear Policy: Which systems receive production patches, and which ones go through testing or are delayed? Then I automatically install the agent via my configuration management system and register hosts using a license key. I configure AUTO_UPDATE appropriately for each environment, define sticky tags for QA and production, and document the statuses. Next, I integrate KernelCare into existing automation tools so that live patching becomes part of standard operations. Finally, I set up monitoring and reporting so that I can keep track of effectiveness, patch statuses, and deviations at all times. After the first cycle, a reliable, repeatable process is established.
Practical Tips for Long-Term Operation
I am validating Patches in a representative staging environment that realistically mirrors my production workloads. For critical windows, I set up delayed feeds so I can observe the effects before rolling them out to production. I combine rollouts with metrics such as latency, error rates, and kernel messages to detect side effects early on. For air-gapped setups, I schedule the replication of the ePortal at fixed intervals and secure the system against unauthorized access. In addition, I have a fallback plan in place: I temporarily disable auto-update when an exceptional situation arises and then selectively raise the level again. This keeps operations predictable while still being fast enough to address urgent gaps.
Architecture and Security Model
I rely on a clearly defined chain of trust: The agent communicates with the feed via secure connections, checks the signatures of the patch packages, and verifies their integrity before applying them. This prevents tampering during transmission. Patches are injected at runtime as secure code changes—targeted specifically at functions that are vulnerable. This allows me to reduce the volume of changes and minimize risks. The patching mechanism monitors consistency points to ensure I do not trigger race conditions or deadlocks. For hosts with Secure Boot, I ensure that the chain of trust for the involved components is correct, so that policies are adhered to even during live patches. In FIPS-regulated environments, I make sure that the cryptographic primitives used are compliant. It’s also important to me that the agent operates according to the principle of least privilege, logs relevant actions, and leaves traceable evidence for audits. This way, I combine enhanced security with a conservative, reproducible deployment path.
Compatibility, Special Cases, and Limitations
I use KernelCare in heterogeneous fleets—bare-metal servers, virtual machines, and cloud instances can all be patched equally well. I keep a close eye on third-party drivers and kernel modules: If a patch targets a feature that a proprietary driver also modifies, I schedule a stage test. As a general rule, not every major kernel change can be patched live. Structural changes or ABI modifications still require traditional updates with a reboot. The same applies to issues such as CPU microcode or firmware adjustments. I also take into account interactions with security mechanisms like SELinux/AppArmor and verify that audit logs remain complete. For crash dumps (kdump), I test whether the dump paths continue to function as expected after patching. This allows me to identify limitations in advance and avoid typical integration pitfalls.
Live Patching in Container and Kubernetes Environments
I keep Kubernetes workers stable through live patching without having to drain nodes or move pods. This is especially advantageous for stateful workloads or large clusters because it allows me to schedule rollouts independently of the orchestrator. In practice, I assign nodes to groups (e.g., prod, test, 24h) and set the feed prefixes group-wide. On container hosts, it doesn’t matter how many containers are running—the underlying host kernel is patched. I combine this with metrics from the cluster (API latency, pod restarts, node condition) to quickly identify side effects. For managed Kubernetes, I pay close attention to which parts I control myself and which the provider handles, so that responsibilities remain clear. This way, I seamlessly integrate live patching into DevOps and GitOps workflows.
Performance Overhead and Resource Usage
I plan live patching so that ongoing workloads remain undisturbed. The agent operates in a resource-efficient manner; retrieving and applying patches causes only brief, low-level spikes in load. As a rule, these are barely measurable amid the noise of normal system activity. Nevertheless, I monitor CPU, memory, and latency during and after the patching window to verify baselines. I also monitor the scheduling behavior of critical systems with real-time requirements. Practical insight: Conservative feeds combined with brief telemetry checks after installation provide me with assurance without compromising availability. If a system is temporarily under heavy load, I deliberately postpone patching by disabling AUTO_UPDATE until load conditions are more favorable.
Monitoring, Reporting, and Audits
I integrate live patching into my monitoring: The patch status for each host, the feeds used, the time of the last update, and any discrepancies are displayed in my dashboards. In addition, I centrally log kernel messages and security events so I can keep track of correlations between updates and metrics. For audits, I document: Who changed which policy and when? Which systems use sticky tags? Which CVEs were resolved via a feed? This kind of documentation helps me justify technical and organizational measures in certified environments (e.g., ISO 27001). Reports also help me with post-mortems: If an incident occurs, I quickly check whether a patch was applied immediately beforehand and what the rollback procedure looks like. This allows me to professionalize operations beyond mere patching.
Rollback and contingency plan
I define in advance how I’ll proceed in case of discrepancies: disable AUTO_UPDATE, mark the affected group with a sticky tag, and, if necessary, roll back the patch status. It’s important to me that I perform rollbacks in a targeted and traceable manner, ideally starting with only a small subset of hosts. I keep playbooks on hand that describe the steps—including validation checks after the rollback. In special cases, I plan for a coordinated reboot, such as when a downstream fix requires structural kernel changes. The emergency plan also includes communication channels: Who notifies SRE, Security, product teams, and—if necessary—customers? This ensures that even unexpected situations remain manageable without panic.
Change Management and Governance
I integrate live patching into my change management process without routing every fix through a full CAB. Instead, I work with standard changes for defined feeds and narrowly defined approval criteria. For exceptions—such as very new patches in test feeds—I use quick, low-risk changes with clear rollback criteria. Documentation is key: I keep track of which hosts use which feed and when, and when sticky tags are applied. This keeps audits efficient and allows me to reproduce, if necessary, why a system had a specific patch status on a given date. This governance builds trust without slowing down the time-to-patch.
Common Pitfalls in Practice
- I don't rely solely on automatic updates: Critical systems also have additional manual checkpoints.
- I don't mix feeds randomly: I follow a clear strategy for each host or group to ensure consistency.
- I specifically test proprietary drivers: particularly for storage/HBA and high-throughput networking.
- I am planning air-gap updates: ePortal replication at fixed intervals, and maintaining strict control over signatures and access rights.
- I take measurements before and after the patch: Baselines help identify anomalies, rather than relying on gut feelings.
- I'm setting the expectations: Live patching reduces, but does not eliminate, the need for every reboot when structural changes are made.
Summary
With KernelCare Patch Feed I avoid reboots, patch CVEs quickly, and keep services online at all times. I select feeds based on risk tolerance, use ePortal for isolated networks, and integrate live patching into existing operational processes. The combination of automation, feed control, and sticky tags gives me speed without losing control. ELS and LibCare extend protection to older distributions and critical libraries, which measurably improves the security status. For hosting, cloud, and data centers, this approach provides a clear solution to the trade-off between availability and security. This is how I implement live kernel patching as an integral part of my Linux Security-Strategy—reliable, transparent, and without downtime.
