cPanel update tiers: EDGE, CURRENT, RELEASE, STABLE, LTS

Every cPanel server subscribes to an update tier, and that tier decides when the next major version arrives. Leave it at the default and a feature release lands on production the week it is promoted. Pin it wrong and you sit on a version that stops receiving updates entirely.

This covers the five tiers, what each one points at right now, how to set them from the shell, and how to stagger a fleet so a bad release never takes out every server at once.

The five tiers

Major versions are even-numbered; odd numbers are internal development builds you will never see. A version walks the tiers in order — EDGE, then CURRENT, then RELEASE, then STABLE — and one version per year is additionally designated LTS.

What the tiers point at today

Do not trust a blog post for this, including this one. cPanel publishes the live tier-to-build mapping as a flat file, and it is the fastest way to answer "am I behind?":

curl -s https://httpupdate.cpanel.net/cpanelsync/TIERS | head -6

As of 25 August 2026 that returns:

edge:11.138.0.1
current:11.138.0.1
release:11.136.0.36
stable:11.136.0.36
lts:11.134.0.52

Two things worth reading off that. First, RELEASE and STABLE currently point at the same build — between major promotions the two tiers converge, and choosing STABLE buys you nothing for weeks at a time. Second, v136's published end of life is August 2026, so the promotion of v138 to RELEASE is imminent. If your fleet is on RELEASE, treat the v138 upgrade as landing within days, not months, and read the v136 release notes for the removals you should already have cleared.

The current LTS is v134 (released January 2026, supported to June 2027). The previous LTS, v110, reaches end of life in December 2026, with Extended Lifecycle Support carrying CentOS 7 and CloudLinux 7 servers on that branch through 1 January 2027 — the same deadline covered in ELS for CentOS 7 on cPanel.

Check what your server is on

/usr/local/cpanel/cpanel -V
cat /etc/cpupdate.conf

A typical /etc/cpupdate.conf:

CPANEL=release
UPDATES=daily
RPMUP=daily
SARULESUP=daily
STAGING_DIR=/usr/local/cpanel

CPANEL also accepts a literal version — 11.136, or a full build like 136.0.36. That pins the server to a branch and stops major upgrades dead, which is occasionally the right call for a box running a fragile third-party integration. It is not a long-term strategy: once the branch goes EOL, you stop getting security fixes.

Set the tier

From the WHM UI: Home → Server Configuration → Update Preferences, pick the tier under cPanel & WHM Updates, and save.

From the shell, edit the file and apply it:

sed -i 's/^CPANEL=.*/CPANEL=stable/' /etc/cpupdate.conf
/usr/local/cpanel/scripts/upcp --cron

--cron runs the update using the preferences in cpupdate.conf, which is what you want for anything scripted. The flags that matter:

• --cron — respect /etc/cpupdate.conf
• --bg — run in the background, logging to /var/cpanel/updatelogs/update.<timestamp>
• --sync — repair the installed version without pulling a newer one
• --force — reinstall everything and upgrade regardless of preferences
• --security — the hourly critical-patch run

Security patches ignore your tier

This is the part hosts get wrong. Choosing STABLE or LTS delays major version upgrades. It does not delay security fixes: cPanel applies critical patches for your current major version hourly via cron, and Technical Security Releases ship to every supported branch at once. The auth-bypass zero-day earlier this year patched branches from 11.86 upward on the same day.

So there is no security argument for sitting on EDGE, and no security penalty for sitting on LTS — as long as your branch is still supported. The moment it goes EOL, that stops being true. If your reason for avoiding upgrades is reboot windows rather than cPanel itself, the answer is KernelCare live patching, not a frozen panel.

Stagger a fleet

Running every server on the same tier means every server takes the same bad release on the same day. A three-ring layout costs nothing:

1. Canary — CURRENT. Two or three servers carrying internal sites and your least demanding customers. They hit the new major version weeks before the fleet does.
2. Production — RELEASE. Everything else, with automatic upgrades left on.
3. Frozen — LTS. Legacy boxes with fragile integrations, on an exit plan with a date.

For finer control, set UPDATES=manual on the production ring and drive upcp from your own cron with jitter, so 200 servers don't all pull at once:

0 4 * * * sleep $((RANDOM \% 7200)); /usr/local/cpanel/scripts/upcp --cron --bg

cPanel already applies a random delay of several business days before automatically upgrading a RELEASE-tier server to a new major version, which is a softer version of the same idea. The manual cron gives you the kill switch: stop the job, and the fleet stops upgrading.

Blockers will stop the upgrade, not warn you

Before each upgrade upcp runs blocker checks — license validity, writable filesystems, RPM database integrity, plus version-specific conditions such as an unsupported OS or an out-of-date MySQL. Blockers cannot be overridden. If one fires, the update fails and the administrator gets an email, so the server quietly stays behind until someone reads it.

The two that bite most often are an OS that a new version has dropped (plan the CentOS 7 to AlmaLinux move before it becomes urgent) and a database version below the new minimum — see upgrading MariaDB/MySQL in WHM. An expired or invalid license is the third: a current cPanel license is what keeps upcp able to fetch anything at all.

Next steps

• cPanel license tiers explained: Admin, Pro, Premier
• cPanel & WHM v136: unified SSL, log retention, removals
• WHM Tweak Settings worth changing