KernelCare ePortal for Larger Hosting Infrastructures

Integrating KernelCare ePortal into Fleet Operations

KernelCare ePortal is the self-managed management and distribution component for KernelCare agents in larger Linux environments. It consolidates patch sets, feeds, and registration keys in a single, controlled location. This allows the administrator to decide not only whether hosts receive patches, but also from which local source and according to which release policy this occurs.

Without ePortal, agents communicate directly with the TuxCare infrastructure. This is usually the simpler approach for small, largely uniform, and Internet-enabled server fleets: there is no additional central platform to update, secure, and monitor. However, as the number of systems grows, this simplicity becomes a disadvantage when traceable approvals or limited network egress are required.

In a hosting fleet, web servers, database servers, virtualization hosts, and management systems often run on different distributions and kernel series. A central Patch Order allows you to provide these technical groups with specific feeds and keys. ePortal is therefore not an alternative to the KernelCare agent, but rather extends its ability to retrieve patch sets by adding local control and distribution capabilities.

Consequently, the benefits do not stem solely from the number of servers. The decisive factors are mandatory patch cycles, testing and verification requirements, network specifications, and the question of whether a central service itself can be operated reliably. These requirements also determine whether local mirroring, caching, or direct retrieval is the appropriate architecture.

Distinguishing Between Live Patching, KernelCare, and LibCare

At Live patching The KernelCare agent regularly checks to see if compatible patch sets are available. It downloads them, verifies them, and installs them in the running kernel. This allows security fixes to take effect without requiring a kernel reboot. Which patch sets are applicable depends on the installed kernel and the supported distribution.

KernelCare refers to the service for live kernel patches. LibCare is distinct from this: It is an optional add-on product for specific userspace components and not another term for kernel patching. ePortal, on the other hand, does not patch the kernel itself, but rather manages patch sets, feeds, and the registration of KernelCare agents in a local enterprise installation.

The former name, KernelCare Plus, should only appear when referencing older documentation. The manufacturer discontinued this product in March 2023 and replaced it with KernelCare. When conducting inventory checks, it is therefore important not to equate installed agents, contracts, and documentation based on historical product names with current components or feature sets.

Live patching is no substitute for a comprehensive maintenance process. Scheduled Reboots They remain necessary, for example, for regular kernel changes, hardware and firmware updates, driver changes, configuration work, or error scenarios that cannot be resolved in real time. An operational strategy should therefore combine reduced exposure through patch sets with continued scheduled reboot windows, rather than eliminating them entirely.

When Centralized Patch Management Makes Economic Sense

ePortal is the right choice when an organization needs not only to distribute patches quickly but also to strictly control their deployment. This includes, for example, separate release groups for Canary hosts, staging, and production; restrictive outbound firewall rules; or records showing which host was assigned to which feed. Many systems running on different platforms also benefit from a centrally managed distribution instance.

The additional benefits must justify the effort. An ePortal instance requires capacity, updates, backups, access control, and monitoring; if high availability is required, replication and network architecture are also needed. For a small number of similar servers with authorized Internet access, direct access via the TuxCare infrastructure is therefore often simpler. Fewer components mean a smaller footprint for in-house operations.

From an economic standpoint, centralized control is particularly important in situations where unplanned concurrency would be costly—such as with many customer web servers, database clusters, or virtualization hosts. A Release process This allows for the simultaneous representation of technical similarities and business risk. Groups should not be formed based solely on location, but should also take into account distribution, kernel series, hypervisor, control panel, hardware, and customer profile.

The security coverage should not be overestimated. KernelCare generally provides live patches for a kernel only as long as its distribution provider releases security updates for the kernel series in question. Furthermore, live patching is not a blanket guarantee that all vulnerabilities have been fixed. Patch status, distribution support, and regular maintenance must be checked separately.

The operational decision is therefore not a blanket statement that „centralized is better.“ ePortal makes sense when local control, tiered distribution, and reliable traceability meet specific requirements. If these requirements are not present, the deliberately simple direct procurement approach may be more robust. In the next step, the desired deployment model determines storage requirements and external dependencies.

Selecting the Right Mirror and Cache

The choice of distribution model determines how independent a hosting fleet is when retrieving patches and how much infrastructure it must operate for that purpose. With direct retrieval, KernelCare agents download patch sets via the TuxCare infrastructure. ePortal, on the other hand, offloads release, local storage, and distribution to a separate instance; it can mirror patch sets as complete or filtered archives or cache them on demand.

A full mirror is useful when patch sets that have already been downloaded must remain available locally even if the external connection is interrupted, or when mandatory internal approvals require it. Filtered mirroring limits archive size and data traffic to distributions that are actually in use. For this to work, the inventory must reliably track which kernel series and architectures the fleet uses; otherwise, an archive will be missing precisely when a host needs it.

The Cache Mode This saves storage space, but it is not synonymous with fully isolated operation. ePortal loads metadata and retrieves patch binaries from the source as needed; according to the documentation, downloaded binaries remain in the local cache for two weeks. This may be sufficient for isolated agent networks, as long as ePortal is allowed to use the permitted upstream path.

An ePortal server operating in a fully isolated environment must be evaluated separately. New patch archives must then be applied via a separately scheduled manual transfer. To do this, define source verification, integrity and signature checks, media or network authorization, import order, and responsibilities. Neither filtered nor full mirroring automatically generates this process; they only determine which archives ePortal maintains locally.

Storage planning should not stop at the size of the current archive. TuxCare recommends SSD storage with at least 100 IOPS and a growth rate of approximately 4 to 5 GiB per month as a guideline for ePortal. These manufacturer specifications are no substitute for capacity planning: recovery objectives, parallel rollouts, network latencies, the number of kernel variants, and monitoring requirements can have a greater impact on the architecture than available disk capacity.

Setting Up Patch Rings for Hosting Fleets

Patch rings enable a controlled rollout from a centrally available patch set. A small canary group receives the release first, followed by staging, a limited production group, and finally full production. Each ring requires predefined monitoring metrics and a designated point of responsibility; without these criteria, a delay merely shifts the risk rather than mitigating it.

For the production rings, Stable The intended channel. Testing is suitable for a separate, carefully controlled evaluation process because this channel includes all available patch sets and may therefore contain additional patch sets that have not yet been marked for Stable. According to the documentation, Unstable is an early-access channel and is not recommended. Testing and Unstable should therefore not be treated as general production-ready channels.

Rings should be organized based on technical similarities rather than just data center location. Relevant factors include the distribution and kernel series, hardware platform, virtualization, control panel, web server stack, and customer profile. A canary host with a different kernel series or virtualization technology can only partially replicate the behavior of a production target system. For shared hosting, resource profiles and configurations of the CloudLinux LVE Managers in this assessment, because they can affect load and failure patterns.

Special caution is required for new ePortal instances. According to the manufacturer, ePortal checks for new patch sets every ten minutes and downloads them, but does not automatically make them available to every feed. When archives are loaded for the first time, the patch sets they contain are assigned the same release date. Therefore, a delay that has already been configured can result in the entire initial set being included in an automatically updated feed once the delay expires.

Therefore, during the initial synchronization, hold off on automatically updating production feeds and their production key mappings. Load the initial data set completely, verify it along with the feed configuration, and only then assign keys to the intended rings in a controlled manner or enable their automatic updates. The delay logic is then used for newly arriving patch sets; it does not reliably separate the historical initial data set of a new instance.

Separate Feeds, Keys, and Clients

Feeds represent the technical side of rollout rings: They connect the patch channel and delay logic to a group of systems. Registration keys can be linked to feeds and assigned server limits. This allows an operator, for example, to provide internal platforms, managed server offerings, and separate customer environments with different release paths without having to change the agent configuration individually on each host.

However, this mapping does not constitute a complete safety boundary. The optional function Business Units It supports multi-tenancy in the ePortal, but does not replace network segmentation, an authorization model, or separate administrative responsibilities. Logging, secret management, and verifying who is authorized to create keys or modify feeds must also be planned and regularly monitored independently of the product’s functionality.

In client environments, separating patch management from other forms of hosting isolation is particularly important. A key can limit the intended feed assignment and the number of registrable servers, but it does not prevent cross-access to other infrastructure components. Process and file system isolation remain separate tasks; for more on this, see the article on CloudLinux SecureLVE the account and website levels.

Starting with ePortal 2.14-1, API keys can be used for the public API as an alternative to basic authentication. The ePortal administration interface allows, among other things, individually revocable API keys and an optional expiration date. This facilitates separate permissions for CMDB integrations or configuration automation, provided that the rights of the associated user account are deliberately restricted.

Store tokens as secrets in a secret management system, not in playbooks, images, shell histories, or tickets. This is an operational security measure and not a feature automatically enforced by ePortal. A practical process assigns each key an owner, a purpose, permitted products, a server limit, and a rotation date.

API keys should be specifically revoked in the event of a system change, a role change, or when automation access is no longer needed. You should handle registration keys differently: According to the documentation, removing such a key also removes all servers registered under it from ePortal. Therefore, before deleting a key, plan to migrate to a new key or re-register the affected hosts, and then verify their feed assignments and check-in statuses.

Operating Replication and TLS Reliably

For a Highly Available Patch Distribution Several ePortal nodes are combined so that KernelCare agents communicate with a shared cluster DNS name or an HTTP load balancer. For administrative tasks, however, you use a controlled, node-specific admin endpoint. According to the manufacturer, you must not use the shared cluster endpoint for operations in the ePortal administration interface.

Before going live, the architecture should consider more than just the failure of an ePortal server. Other relevant factors include DNS resolution, load balancers, certificates, storage for patch archives, the connection to the patch source, and accessibility from every network segment. A second node without coordinated network and operational monitoring provides only limited improvement in availability; in the event of a failure, it may even mask abnormal conditions.

The nodes synchronize changes via replication. This synchronization is not necessarily visible immediately. Especially with round-robin, an agent that has just registered may first reach the first node for registration and, immediately afterward, a node that has not yet been synchronized for the update. Automation workflows should therefore include a short wait or a retry mechanism with a limited number of attempts, rather than treating an immediately following patch retrieval as a reliable final state.

Longer periods of disconnection are also part of the failure scenario. According to the documentation, replication logs are retained for seven days; if a node remains disconnected for longer than that, it may miss some changes. The Replication Delay It is therefore an operational status, not merely a diagnostic value. After network disruptions, you should therefore check feed assignments, the key set, and the patch archive on the returning node before it resumes handling agent requests as usual.

Replication occurs via HTTP. Without appropriate TLS security, the replication data is therefore transmitted in plain text. Segment this traffic to at least a trusted network, or configure TLS appropriately for your architecture. For agent endpoints that are accessible externally or across networks, a verifiable certificate chain is a key component of the TLS Termination; Disabling certificate verification is not an acceptable long-term solution.

If a reverse proxy is set up in front of ePortal, allowed hostnames must be configured so that ePortal limits host header requests. The proxy must also correctly pass through the original host header and the X-Forwarded-Proto header. Otherwise, incorrect external URLs, redirection issues, or an incorrect determination of the protocol being used may occur. This header configuration should therefore be part of every proxy change and its acceptance testing.

Establish Documentation, Backups, and Monitoring

Controllable live patching requires recurring verification, not just a successful initial installation. Record at least each host’s feed assignment, the last agent check-in, the reported patch status, and the status of the registration keys. Supplement this data with the responsible teams and a traceable approval decision. This allows you to determine specifically, in the event of a security alert, which group is using which deployment method.

Other regular checks include storage growth, free space for archives, the replication status, and the rotation or revocation of keys that are no longer needed. API keys are better suited for automated queries than shared administrator passwords because they can be managed individually, revoked, and optionally assigned an expiration date. As an operational security measure, store them in a secret management system, not in images, playbooks, or tickets.

For an existing cluster, the following non-disruptive test call is a suitable component for monitoring or a scheduled health check. It returns a machine-readable summary status, including replication delay. If a problem occurs, the call terminates with exit code 1; the monitoring system should trigger an alert for this condition but further narrow down the cause using node and network data.

kc.eportal replication --short-status

ePortal distinguishes between a data backup archive run and a database-only backup. The complete command syntax is kc.eportal backup <path_to_archive>; it creates a backup archive that includes the patch set files. Using kc.eportal backup-db <path_to_backup> In contrast, you are only backing up the databases without patch set files. This second method is suitable for configuration and server data, but not for local patch archiving.

These ePortal backups do not automatically include the entire environment. Operating system configuration, reverse proxy and load balancer configuration, TLS certificates and private keys, DNS settings, and external firewall or secret management configurations require their own backup and restore rules. For each backup type, define the purpose, retention period, storage location, and the responsible recovery path.

During a restore, the ePortal service must be stopped. Plan for this service interruption, notify any affected operations teams as needed, and then specifically verify data consistency and accessibility for agents. A backup is considered complete only after a controlled, planned Restore as reliable. In this context, a test must not inadvertently alter production feeds or key mappings.

Evaluate Fault Patterns and Operational Decisions

If expected patches do not arrive, you must first distinguish between a lack of availability, a failure to retrieve the patch, and a lack of approval. Check the installed agent and ePortal versions, the assigned key and feed, the appropriate distribution along with the kernel series, and the connection to the patch source. A patch may also be missing if the distribution provider no longer provides security updates for the relevant kernel series; live patching does not remove this limitation.

Historical manufacturer notes regarding older component versions should not be interpreted as permanent version specifications. A note from December 2025 concerned, among other things, KernelCare Agent 3.x and ePortal 2.20 in the context of a new signed patch format. Before applying updates, you should therefore check the current Compatibility matrix, the versions that are actually installed, and the internally approved update sequence.

In cache mode, a cache miss—especially when external access is restricted—can delay patch retrieval because the required binary file is not yet stored locally. This does not indicate fully isolated operation. For restrictive zones, specify which connections are permitted, how missing archives are transferred, and who is responsible for authorizing, ensuring the integrity of, and timing this transfer.

Another common issue is an unexpectedly broad rollout after the initial download of patch archives to a new instance. Since the archives downloaded for the first time are treated as new by the delay logic, a delay set in advance does not reliably prevent them from being deployed simultaneously. Hold off on automatic feed updates and production key mappings during the initial synchronization, verify the initial inventory, and only then activate the production rings in a controlled manner.

Replication gaps following a prolonged node outage and faulty reverse proxies require different measures: The former require a synchronization of the node’s state, while the latter require a verification of TLS, allowed hostnames, and forwarded headers. Both cases should be addressed in runbooks with clear escalation procedures. A blanket restart resolves neither missing data nor an incorrect trust boundary.

ePortal is particularly useful when patch rings, local distribution, controlled network egress, or verifiable approvals are actually required. For a small, homogeneous, and Internet-enabled server fleet, direct access via the TuxCare infrastructure is often simpler. The decision should therefore weigh the additional operational overhead against specific control and audit requirements, not solely against the number of servers.