ePortal is the on-prem patch distributor for KernelCare. Once it is online, your fleet pulls signed patchsets from a host on your network instead of every server reaching out to patches.kernelcare.com. That is the only realistic way to live-patch kernels inside a PCI segment, a defence network, or any environment with strict egress rules.

This walks through provisioning the VM, the installer, the first patch sync, and pointing agents at it. End-to-end on a clean RHEL 9 box: about 30 minutes.

Provision the VM

ePortal is a Django app backed by SQLite (or PostgreSQL for larger fleets) with an Nginx front-end. Size it for the agents, not the patches — the feed itself is under 5 GB.

OS: RHEL, AlmaLinux, or Rocky Linux 8 or 9. Ubuntu builds exist but the RPM path is the supported one.
CPU: 4 vCPU is enough up to ~2,000 agents.
RAM: 8 GB.
Disk: 50 GB on /var — patch feeds, logs, and the SQLite DB live there.
Network: agents reach the ePortal on TCP 443. The ePortal itself needs outbound HTTPS to repo.tuxcare.com either directly or via an HTTP proxy.

Set a real hostname before you start — the registration URL the agents receive is baked from it:

hostnamectl set-hostname eportal.example.com

Run the installer

The TuxCare installer pulls the right RPMs, sets up Nginx, generates a self-signed cert, and creates the admin user.

curl -s -o /tmp/install.sh https://repo.tuxcare.com/kc-eportal/install.sh
bash /tmp/install.sh

Replace the self-signed cert with a real one before opening the UI to operators — drop the cert and key in /etc/nginx/ssl/eportal.{crt,key} and reload Nginx. Let's Encrypt works if the box can reach the ACME endpoints; otherwise issue from your internal CA.

Initialise

eportal-cli init

This creates the admin account, prompts for the upstream TuxCare API key (the one tied to your KernelCare subscription — find it under your KernelCare license account), and writes /etc/eportal/config.yml. If the host is fully air-gapped, set proxy: to your HTTP forward proxy in the same file — the installer happily uses a Squid or tinyproxy hop.

Sync the patch feed

The ePortal does not pull patches automatically until you tell it to. Run the first download manually so you can see any TLS or proxy errors:

eportal-cli download-feeds

Expect ~3-4 GB on the first run across all supported kernel families. Subsequent syncs are deltas — usually under 100 MB per day. Add a systemd timer or a cron entry:

echo "0 */6 * * * root eportal-cli download-feeds >> /var/log/eportal/sync.log 2>&1" \
  > /etc/cron.d/eportal-sync

Stage feeds for test vs prod

In the UI under Feeds, create two feeds — test and prod. Point test at the upstream main channel directly; point prod at test with a 72-hour delay. New patches land in test immediately, your canary servers register against it, and prod only sees patches that have survived three days on the test ring. That is the same pattern covered in the production rollout guide.

Register servers against the ePortal

Generate a key per server group (web tier, DB tier, etc.) from Keys → Add Key, or via CLI:

eportal-cli key add --name web-tier

On each agent host:

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

--update pulls the current patchset immediately. The patch is loaded into the running kernel without a reboot — verify with kcarectl --info, which should show kernel_id matching what ePortal reports for that feed. For the cPanel-specific deployment notes, see KernelCare on cPanel.

Pin agents to a feed

Servers default to the feed attached to the key they registered with. Move a server to a different feed by re-registering or via the UI under Servers → Edit. Re-registration is cheap — it doesn't consume a seat.

Partial air-gap with a proxy

Fully isolated networks need the offline mirror approach: rsync the patch feed to portable media and import with eportal-cli download-feeds --from-dir /mnt/usb/feeds. Most deployments aren't that strict — a forwarding HTTPS proxy with repo.tuxcare.com on its allow list is the path of least resistance. Configure it in /etc/eportal/config.yml:

proxy:
  http: http://proxy.example.com:3128
  https: http://proxy.example.com:3128

No agent-side proxy config is needed — agents only ever talk to your ePortal.

Does KernelCare ePortal need internet access?+

Only the ePortal itself needs outbound HTTPS to repo.tuxcare.com (direct or via proxy). The agents only talk to your ePortal, never to TuxCare.

How many servers can one ePortal handle?+

A 4 vCPU / 8 GB VM comfortably serves ~2,000 agents on 6-hour check-ins. Scale vertically or switch the backend to PostgreSQL above that.

Can I delay patches before they hit production?+

Yes — chain feeds. Create a 'prod' feed that mirrors 'test' with a 48-72 hour delay so canary servers catch regressions before production sees the patch.

What happens if the ePortal goes down?+

Already-loaded patches stay loaded in kernel memory. Agents simply cannot fetch new patchsets until the ePortal returns. A reboot reverts to the on-disk kernel, which is fine — the next agent check-in re-applies.

Do I need a separate license for the ePortal?+

No. ePortal is included with any KernelCare subscription — you pay per agent seat, not per ePortal instance.

Next steps

Plan the rollout itself with the KernelCare onboarding playbook.
Patch cPanel boxes specifically with KernelCare on cPanel.
Volume pricing or air-gap-specific terms: talk to sales or buy a KernelCare license direct.

Install KernelCare ePortal for an air-gapped patching fleet