Choosing a cPanel update tier in 2026: LTS 134, RELEASE 138 or STABLE 110 (EOL December 2026)

A practical comparison of the cPanel & WHM update tiers as they stand in late 2026, with guidance on which servers belong on LTS 134, which can run RELEASE 138, and why anything still on 110 needs a plan now.

Published 29 Sep 2026Updated 3 Oct 2026 6 min read By srvScripts team

The cPanel & WHM update tier decides which major version a server receives, how often it changes, and for how long it keeps getting security fixes. In 2026 the choice has become more consequential than it used to be, because a run of root-escalation vulnerabilities has meant patched builds every few weeks, and only supported tiers receive them. This guide explains the tiers as they stand at the end of September 2026 and gives a straightforward rule for choosing.

Short answer: Put production servers on LTS (version 134, supported until June 2027) unless a named feature such as the unified SSL/TLS interface, Meridian, Ask AI, the Node.js Toolkit or MCP requires RELEASE (version 138). Keep one staging server on RELEASE or CURRENT to preview changes, and move anything still on STABLE 110 to LTS before November, because 110 stops receiving security fixes in December 2026. Set the tier with the CPANEL= line in /etc/cpupdate.conf and run /scripts/upcp --force.

The tiers as of now

The tier is set by the CPANEL= line in /etc/cpupdate.conf, or through WHM → Server Configuration → Update Preferences. Each named tier currently maps to a specific major version.

LTS is version 134, released in January 2026 with support until June 2027. It is the branch intended for production servers that want the fewest surprises: security and bug fixes, no feature churn.
RELEASE is version 138, published in July 2026. It gets new features first once they have passed through CURRENT, and it will roll forward to 140 when that version is promoted. 136 (April 2026) is the previous RELEASE and still receives fixes as a supported version.
CURRENT tracks the same version as RELEASE most of the time, with slightly earlier access to point releases.
EDGE is 140, the in-development branch. It is for test servers only.
STABLE is the legacy long-term branch still on version 110, and it reaches end of life in December 2026. After that date it receives no security fixes at all.

Latest builds at the time of writing are around 138.0.10 and 136.0.44. The exact number matters less than confirming the server is on a build that includes the most recent security release, which you can do with whmapi1 version.

What LTS 134 gives you

LTS is the correct tier for the majority of shared and reseller servers. It has received every emergency security build of 2026, including the April fix for CVE-2026-41940 and the September fixes for CVE-2026-87899 and its companions, so staying on LTS is not a compromise on security. What you give up is the new feature set that arrived in 136 and 138: the unified SSL/TLS interface, bulk PHP version management, consolidated PHP error logs, short-lived ACME certificates, the Meridian theme, Ask AI, Nova, MCP support and in-place domain renames. If none of those features are on your roadmap, LTS is the quieter life.

Set it with:

sed -i 's/^CPANEL=.*/CPANEL=lts/' /etc/cpupdate.conf
/scripts/upcp --force

One caution: LTS 134 dropped Rocky Linux and requires a supported OS list of AlmaLinux 8/9/10, CloudLinux 8/9/10 or Ubuntu 22.04/24.04. A Rocky server cannot move to 134 at all; see migrating a Rocky server to AlmaLinux.

What RELEASE 138 gives you

RELEASE is right for servers where your customers or your own tooling need the current feature set. Specifically, 136 and above are required if you want the unified SSL/TLS interface, Sectigo as the default AutoSSL provider, the bulk PHP tool or the WP Toolkit security risk scores, and 138 is required for Meridian, Ask AI, Nova, the Node.js Toolkit, MCP and domain rename. RELEASE also has an operating-system caveat: Ubuntu 22.04 was last supported in 136, so a 138 server on Ubuntu must be on 24.04.

The cost of RELEASE is change. Each promotion brings interface adjustments and occasionally removed features; 136 removed Ruby on Rails and RubyGems support and 140 will remove AWStats, Webalizer and Analog once GoAccess is in place. If you run RELEASE, read the changelog when a version promotes and keep a staging server one tier ahead.

Why STABLE 110 needs a plan now

Version 110 has received security backports through 2026, with builds such as 110.0.143 shipped alongside the newer branches, but that stops in December 2026. After that any server on 110 is exposed to every future disclosure. Given the pattern this year, that is not a theoretical risk.

Moving from 110 to 134 is a multi-version jump and cPanel updates only one major version per upcp run, so it can take several update cycles. Practical steps:

Confirm the OS is supported by 134; a 110 server is often on an operating system that is not, in which case the migration is a new server plus a transfer, as described in Transferring accounts with the WHM Transfer Tool.
Check WHM → Server Configuration → Update Preferences for any listed blocker, such as an unsupported MySQL version or an EA4 profile that no longer exists on the target.
Set CPANEL=lts, run /scripts/upcp --force, review /var/cpanel/updatelogs/, and repeat until whmapi1 version reports 134.

Do this before November so there is time to fix whatever the upgrade uncovers.

A simple decision rule

Put every production server on LTS unless a named feature requires RELEASE. Put a staging server on RELEASE or CURRENT regardless, so you see what is coming. Never leave a customer-facing server on STABLE or EDGE. Whatever the tier, keep automatic updates enabled in WHM → Update Preferences and let the daily upcp run; the emergency builds in 2026 have arrived on a cadence that manual updating cannot keep up with across a fleet.

Verify

Check the tier and build on each server and compare against the latest published build for that tier:

grep ^CPANEL /etc/cpupdate.conf
whmapi1 version
tail -n 30 /var/cpanel/updatelogs/last

If the reported build is older than the most recent security release for your tier, run /scripts/upcp --force and read the log for the reason it lagged.

Common pitfall

Servers sometimes stay on an old version despite a correct tier setting because a blocker is silently preventing the upgrade, most often an old MySQL, an unsupported OS, or a removed EA4 package. The daily update log will say so, but nobody reads it until something breaks. Put a weekly whmapi1 version check into your monitoring, and alert when a server falls more than one point release behind its tier.

CPanel update tier at a glance

Choosing a cPanel update tier in 2026 summary card: Put production servers on LTS (version 134, supported until June 2027) unless a named feature such as the unified… — In short: Put production servers on LTS (version 134, supported until June 2027) unless a named feature such as the unified SSL/TLS interface, Meridian, Ask AI, the Node.js Toolkit or MCP requires RELEASE (version 138).

Official documentation: cPanel & WHM documentation, Linux man pages.

Frequently asked questions

Does LTS 134 still receive the 2026 security fixes?

Yes. Every emergency build this year, from the April CVE-2026-41940 fix to the September CVE-2026-87899 fixes, shipped for 134 alongside 136 and 138, so staying on LTS costs features, not security.

How long does moving a server from STABLE 110 to LTS 134 take?

upcp upgrades one major version per run, so the jump takes several update cycles plus time to clear any blocker such as an unsupported MySQL version or OS; start well before November to leave room for surprises.

Can I move a server from RELEASE 138 back to LTS 134?

No. cPanel does not support downgrading major versions; setting CPANEL=lts on a 138 server simply holds it until LTS catches up, so treat a move to RELEASE as one-way.