cPanel & WHM Release: New Features and Secure Update Strategies

Clearly Distinguish Between cPanel and WHM

Although cPanel and WHM are part of the same product, they serve different levels of a hosting server. cPanel This is the interface for a single hosting account: Customers use it to manage domains, email accounts, files, databases, and the security features enabled for their account. Which areas are visible and accessible is primarily determined by feature lists, packages, themes, account permissions, and the hosting provider’s configuration.

WHM, on the other hand, is the administrative layer of the hosting panel. Server administrators use it to set up accounts, packages, feature lists, and server-wide services, while managed hosting providers also define standards for provisioning, updates, and support. Depending on the delegated permissions, resellers work within a limited WHM scope; this does not automatically grant them access to the operating system, global services, or all server policies.

A cPanel Update Therefore, this affects more than just a new view in the customer account. Changes can alter the assignment of themes, the features available in package templates, and automated workflows. At the system level, this also includes interfaces, permission checks, installed extensions, and interactions with the operating system. The release tier determines which product version and which build become available for the server; it does not directly determine the visibility of individual features in a specific customer account.

A practical example is the introduction of Meridian: If the theme is specified via a WHM package, this decision affects the user interface of new or assigned accounts. If provisioning scripts also use APIs or if support guides require specific menu paths, the theme policy, package template, and automation must all be reviewed together. Otherwise, a standalone theme change could result in functionality that works correctly but leads to unexpected consequences for customers and support.

Distinguishing Between Version Status, Builds, and Release Tiers

To ensure reliable update planning, you must Major Version, Build and Release Tier should be considered separately. As of the documented status, cPanel & WHM 138 is the most recent released production major version. Version 134 is the current LTS branch with a longer, predictable support window. Although Version 136 explains the origin of individual changes, its regular support ended in August 2026; it is therefore not a viable new upgrade target.

A major version identifies a release branch, such as 138. The build number specifies a particular version within that branch; the changelog documents changes for 138 up to build 138.0.13. This does not mean that every server receives this build or is even updated to 138. The public distribution channel used by the server is also a determining factor.

The Release Tier determines the level of testing and the frequency at which updates are released. LTS, STABLE, RELEASE, CURRENT, and EDGE are therefore not merely labels for the same software version. A server in the LTS tier may intentionally be on a different major version branch than a system in the RELEASE tier, even though 138 is generally the latest production major version.

Special caution is required for version numbers with an odd major version number. These belong to the development release in the EDGE branch and should not be equated with a published production version. Their existence does not indicate that development has been completed or that they are suitable for customer servers. For change management and support communication, administrators should therefore always document the installed version, the specific build, and the selected tier together.

Why a cPanel Update Requires Planning

A Version Change With cPanel & WHM, undoing an upgrade is not without consequences: Downgrading to an earlier major version or an earlier release tier is not supported. For major version jumps, the updater handles the necessary intermediate versions and checks compatibility before each step. This reduces the number of unsuccessful upgrade attempts but does not replace a technical review of your own environment.

Technical requirements can block an update or determine its path. These include the operating system being used and sufficient free memory under /usr/local/cpanel and active blocks by the package manager. As a documented example, Ubuntu 22 cannot be updated to cPanel & WHM 136. Such notices are not a call to switch to an older branch, but rather a reason to clarify the operating system version and the planned migration path in advance.

In addition to the base system, the update includes an operational checklist. The documented changes to SSL API permissions and the removal of accounting helpers indicate that your own automation or billing integrations may be affected. Meridian and CSF changes also make theme assignments, feature lists, local firewall configurations, and related extensions worthwhile points to check. These are not checks promised by the updater, but rather dependencies that you must specifically evaluate in your environment.

As a precautionary measure, the update should only be initiated once a recovery plan tailored to your specific environment, a previously verified backup, and clear lines of responsibility are in place. The vendor’s documentation recommends first staging a new major release on a compatible test system; production should follow in a controlled manner only after you have conducted your own functional tests. Because a downgrade is not supported, a potential restore from backups should not be confused with reverting the release tier.

Select Release Tiers Based on Business Objectives

The release tier determines which development and testing branch a server receives; it is therefore an operational decision and not merely a setting for automatic updates. During its lifecycle, LTS focuses on security, critical, and compatibility updates. STABLE is released less frequently than RELEASE, while RELEASE is the documented standard for new installations.

CURRENT is updated more frequently and may include features that are still under development. EDGE undergoes only basic testing and should therefore be used exclusively in controlled test environments. Odd major version numbers indicate development releases in the EDGE branch; they do not imply production readiness or guaranteed availability of any individual feature.

For predictable shared hosting, LTS This makes sense when a functional state that can be predicted over the long term is more important than a new user interface or early automation features. This does not mean suspending updates: security and critical fixes remain part of operations. RELEASE recommends using new servers, provided that dependencies are checked in advance and maintenance windows are scheduled.

The choice should also be compatible with the test environment. As with other hosting panels, it is not a single version number that matters, but rather the interaction between the panel, extensions, operating system, and customer stack. The article Plan Plesk Updates for Hosting Providers in a Controlled Manner illustrates this general principle for another platform. According to the update documentation, a delay of several business days applies only to automatic upgrades to the next major version in the RELEASE tier and only under the conditions specified there; EDGE, CURRENT, STABLE, and LTS are exempt from this.

Check out the new features in Version 138

Version 138 introduces Meridian as the customer interface. For WHM administrators, it’s not just the updated layout that matters: theme selection, package assignment, feature lists, training materials, and support workflows must all align. The release tier determines whether the required product and build version is available on the server; however, which areas a single account can view depends primarily on the theme, package, feature lists, and provider configuration.

With Meridian, a widespread migration without a policy in place is risky. Accounts created with Meridian that have never used Jupiter cannot switch back to Jupiter on their own. However, administrators can set the theme via WHM, a package, or the API. Therefore, package templates and communication with a small pilot group should be finalized before a broad rollout.

The WHM-API-1 Function set_primary_domain_docroot This feature allows you to change the document root of a primary domain and has been backported to versions 134 and 136. This simplifies provisioning or migration, but does not replace the need to test the application. A CMS, a redirect, file permissions, or a deployment script may still rely on the previous path; a successful updater run does not automatically detect this business-specific assumption.

Starting with build 138.0.10, API functions for retrieving SSL certificates and keys require the feature sslinstall or sslmanager. Limited feature lists and external billing integrations must therefore be carefully reviewed. In addition, cPanel removed obsolete helper files from Cpanel/Accounting; Direct integrations with custom billing solutions require customization; they are not automatically resolved compatibility issues.

Build 138.0.13 also changes the requirements for Reseller ACLs when configuring name servers. Resellers who manage DNS clustering may need the privilege all, to change the server's name server settings. Therefore, before updating, review delegated operating models, the roles of the resellers involved, and automated DNS cluster processes. This privilege significantly expands access and should not be granted across the board, but only after a role and security review.

Prepare Updates with Inventory and Pilot Testing

Before the update, the current state is first assessed: installed version, release tier, operating system, third-party plugins, custom API calls, firewall configurations, and backup and recovery procedures. The version can be determined in the terminal without making any system changes. This inventory links technical components to the people responsible for them and prevents unclear dependencies from becoming apparent only after the update.

/usr/local/cpanel/cpanel -V

For an upgrade run, cPanel requires at least 5 GB of free disk space under /usr/local/cpanel. Active package manager locks can block the process; the operating system path may also impose limitations depending on the version. These issues must be addressed before the maintenance window, as must a restore operation, the procedure for which and the access rights involved must be clarified in advance.

This is followed by Staging on a separate, comparable test system. There, the relevant packages, themes, plugins, and API integrations are tested using simulated test accounts. Test typical workflows such as login, certificate automation, provisioning, and application operation. The vendor’s documentation explicitly recommends staging the upgrade on a test system first before updating the production system.

A production pilot should be handled separately. Real customer accounts are included only after explicit approval, on a limited scale, with monitoring, and through a clearly defined support channel. Determine in advance which functional tests will be performed, who will make decisions in the event of a failure, and what recovery options are available for the respective account or server. Testing on simulated accounts does not replace this operational approval; conversely, a customer test is not risk-free staging.

In WHM, „Upgrade to Latest Version“ updates to the latest build of the selected release tier. This feature therefore does not guarantee an upgrade to the most recent major version. Additionally, an automatic delay may apply for RELEASE; a forced update bypasses this delay. Security-related operational measures involving access controls, backups, and firewalls should be maintained in parallel with the update process; the article explains the practical basics. Hosting Control Panel Security in WHM and cPanel.

Operate Meridian and CSF in a controlled manner

In cPanel & WHM 138, Meridian is more than just a new customer interface. The theme groups tasks into categories such as websites, email, files, databases, security, and performance. Therefore, what matters for day-to-day operations is not just whether the interface looks good, but whether customers can still easily find and perform the intended tasks using the features they’ve subscribed to.

Before approval, the administrator should issue a binding Theme Policy Define: Which accounts receive Meridian, which package templates assign the theme, and which feature lists restrict individual functions? These settings go hand in hand. While a package can specify a theme, a feature missing from the feature list will still not be available for the associated account.

In practice, it is advisable to use a limited pilot group with representative pricing plans, such as a basic web hosting account, an account with multiple domains, and a reseller scenario. Be sure to test typical support processes such as mailbox management, database access, and security features. Customer communications should specify the timing, visible changes, and an accessible support channel, rather than announcing the change as purely cosmetic.

The switch back to Jupiter must be part of this plan. Accounts created with Meridian that have never used Jupiter cannot switch back to Jupiter on their own. Administrators can still change the theme in WHM, via a package, or through the API. Consequently, the theme assignment and the responsible process must be determined before new accounts are created with Meridian by default.

CSF should be considered separately from the main cPanel & WHM release. WebPros provides the fork as a separately versioned package for supported cPanel & WHM versions. cpanel-csf Ready; it is installed and updated via the cPanel package manager. The previously announced migration of unsupported or outdated CSF installations to the supported fork has been backported to all supported cPanel & WHM versions. Therefore, the CSF version cannot be reliably determined based solely on the installed cPanel build.

To run the test, you'll need the installed cPanel-CSF Package Status, the separate CSF changelog, the status of the package manager, and the local configuration. Back up and compare your own rules, allow and deny lists, hooks, notifications, as well as plugins or deployment scripts. Additionally, check whether any external tools require files or commands from a previous CSF installation. The cPanel build remains relevant in the general context of updates, but it does not replace this package check or the evaluation of the local firewall configuration.

Systematically Narrow Down Errors After the Update

If features stop working after an update, the analysis begins with the selected release tier and the build that is actually installed. The most recent major version is not automatically the version on a server; what matters is which build was delivered in the configured tier. Also, make a note of the time, the affected accounts, and the specific feature before making any changes intended to fix the issue.

Next, you'll analyze update logs and identify any potential Upgrade Blocker . For major version jumps, the updater skips intermediate versions and performs compatibility checks; active package manager locks or incorrect operating system paths can affect the process. An aborted or only partially completed upgrade does not justify blindly repeating the process with forced options; instead, the logged cause should be clarified first.

Next, test dependencies in a specific order: first, your own WHM or cPanel API calls; then, feature lists and theme assignments; followed by plugins and firewall rules. This approach helps distinguish between a central permission change and an issue related to a single customer account or an extension. Changes should be documented in a traceable manner and, whenever possible, tested first on a staging environment or an isolated account.

One specific issue involves SSL automation: Starting with build 138.0.10, API functions for retrieving SSL certificates and keys require the feature sslinstall or sslmanager. If a script no longer returns certificate data after the update, you should first check the feature list assigned to the account and the permissions for the access method being used—not just the network or certificate inventory.

Even if the document root has changed, a successful API call does not necessarily mean the website is functioning properly. The function set_primary_domain_docroot You can set the path for the primary domain, while CMS configurations, redirects, file permissions, vHost settings, or deployment scripts may still point to the old path. Therefore, test the front end, the administration area, and the application's write operations separately.

Customly integrated accounting integrations may also be affected because outdated PHP helper files from Cpanel/Accounting have been removed. If a billing process is business-critical and no compatible workaround is available, suspending maintenance or restoring from a verified backup is more appropriate than performing another forced update. Vendor documentation and logs then provide the basis for a robust workaround plan.

Establish a binding update strategy

A sound update strategy begins with the operational goal, not with the highest visible version number. Key factors include the support period, the need for new features, the expected impact on customers, available testing capacity, third-party dependencies, and security operations. These criteria must be evaluated on a per-server-group basis: a shared-hosting cluster, a new managed platform, and an internal test system all have different risks and change cycles.

LTS is suitable when long-term stability is more important than a constant stream of new features. During its lifecycle, this branch primarily receives security, critical, and compatibility updates. LTS therefore does not mean suspending updates, nor does it replace backup, recovery, and dependency testing. For established shared hosting providers, this limitation on feature changes can make support costs more predictable.

STABLE is released less frequently than RELEASE and has undergone more public testing. RELEASE is fully functional and is the standard for new installations. Both are viable options when new features are needed but testing must take place before widespread deployment. Which of the two levels is appropriate therefore depends on whether earlier availability or an additional testing period is more important for the respective platform.

CURRENT is updated more frequently and may include features that are still under development. EDGE undergoes only basic testing and is intended exclusively for controlled test environments. Odd major version numbers correspond to development releases in the EDGE branch; they do not indicate that a feature is stable enough for production use. Therefore, EDGE is not a shortcut to earlier features for production customer servers.

Place the Release Policy Set forth in writing: the number of allowed instances per server class, the individuals responsible for approvals, the minimum scope of the staging test, maintenance windows, and criteria for termination. A delay of several business days applies exclusively to automatic upgrades to the next major version in the RELEASE tier, provided that the upgrade is not initiated manually or forced and skips only one major version. EDGE, CURRENT, STABLE, LTS, and hard-coded version numbers are not subject to this delay.

Typical mistakes include using EDGE in production and hard-coding individual build numbers in /etc/cpupdate.conf, a lack of staging, and the assumption that LTS does not require security updates. Equating a successful updater run with technical approval is equally problematic. Only when customer functions, automations, plugins, and protective mechanisms have been tested to the planned extent does a technical update become a controlled operational change.