Retire PHP 8.1 cPanel Sites Safely: Audit, Test and TuxCare ELS

PHP 8.1 stopped receiving security fixes from the PHP project at the end of 2025, EasyApache 4 is retiring the ea-php81 packages, and PHP 8.2 follows on 31 December 2026. A hosting provider therefore has two retirements to plan within a year, and a population of customer sites that will not all be ready. cPanel & WHM 134 introduced integration with TuxCare Extended Lifecycle Support for PHP, which delivers backported security fixes to end-of-life versions. That is a useful bridge, but it is not a substitute for moving sites. This guide sets out a process that keeps the server secure without breaking customers.

Short answer: Count the domains on ea-php81 with whmapi1 php_get_vhost_versions, test a sample on ea-php84, then move sites in waves using the MultiPHP Manager bulk tool or whmapi1 php_set_vhost_versions, and remove the packages once the count reaches zero. TuxCare ELS for PHP, supported through EasyApache 4 since cPanel 134, keeps security patches flowing to the few paid sites that genuinely cannot move yet, but only with a fixed migration date attached.

Know what you are dealing with

Count the sites on each version and identify the ones that are pinned rather than inheriting:

whmapi1 php_get_vhost_versions --output=json \
  | python3 -c 'import sys,json,collections; d=json.load(sys.stdin)["data"]["versions"]; print(collections.Counter((v["version"], v.get("php_fpm",0)) for v in d))'

Then work out why those sites are on 8.1. There are usually three groups: sites where nobody ever changed the setting and which will run fine on 8.4, sites running an old application version that needs updating first, and sites with abandoned or custom code that will need developer work. WP Toolkit’s vulnerable components report on 136 and later helps with the WordPress subset; for the rest, a quick look at the application’s composer.json or the CMS version tells you most of what you need.

Record the audit in a spreadsheet or ticket per customer, because the retirement will take weeks and you will need to know who was contacted and when.

Test the move on a sample

Do not guess at compatibility. Pick sites from each group and switch them temporarily:

whmapi1 php_set_vhost_versions version=ea-php84 vhost=customer-site.example

Load the site, log into its admin area, submit a form, and tail the error log. Deprecation warnings are fine; fatal errors are not. Move it back if it fails and note the reason. The consolidated PHP error log in 136 makes this quicker; on 134 look under the domain’s document root for error_log files or in the FPM log for that domain.

Give customers a self-service path. cPanel → Software → MultiPHP Manager lets them switch their own domain and switch back, and a short note in the customer portal explaining the deadline and the button to press resolves a large share of the work without a ticket.

Where TuxCare ELS fits

TuxCare ELS for PHP provides patched builds of end-of-life PHP versions, backporting security fixes for a subscription fee. cPanel 134 added support for installing these builds through EasyApache 4 in place of the retired ea-php81 packages, so a site that genuinely cannot move keeps receiving security patches. It is the right answer for a small number of sites with a paid customer and a known migration date; it is the wrong answer as a way to avoid the migration altogether, because the cost grows and the application only gets older.

Enabling it requires a TuxCare licence and a repository configuration that TuxCare supplies for your OS. After the repository is in place, the ELS PHP packages appear in the EasyApache 4 customise interface alongside the regular versions. Provision them the same way, and check with:

dnf repolist | grep -i tuxcare
rpm -qa | grep -i 'ea-php81' | head

Package names and version strings for ELS builds differ from the mainline ones, so check the changelog for your build to see what the package set includes. Set a calendar reminder for the ELS renewal date and treat it as the final deadline for any site still on it.

Move the fleet

With testing done, move sites in waves. Use the bulk tool in MultiPHP Manager on 136 and later, or the multi-vhost php_set_vhost_versions call described in Using MultiPHP Manager and the bulk PHP-version tool. Move the “will run fine” group first, wait a week, then the updated-application group, then whatever remains. Announce each wave in advance.

Once no domain remains on 8.1 and no ELS site needs it, remove the packages:

whmapi1 php_get_vhost_versions | grep -c ea-php81
dnf -y remove 'ea-php81*'
whmapi1 php_get_installed_versions

Then start the same cycle for 8.2, which has only a few months left. If the system default is still 8.2, change it to 8.4 now with whmapi1 php_set_system_default_version version=ea-php84, after pinning any domains that must not move.

Verify

Confirm the outcome with a version count and a check that nothing is being served by a retired binary:

whmapi1 php_get_vhost_versions --output=json | grep -c '"ea-php81"'
ls /opt/cpanel/ | grep ea-php

Browse a sample of moved sites, and confirm with WP Toolkit or the customer that admin logins still work. Run our server security audit, which flags end-of-life PHP versions still present on the system.

Common pitfall

The usual failure is a site that was moved, broke silently in a part nobody tested, and was only noticed weeks later when the customer complained about a contact form. Keep the old version installed for two or three weeks after the last wave so a quick switch back is possible, and check the error logs daily during that period. The other trap is leaving ELS in place indefinitely; the site becomes harder to move every month, and the subscription cost eventually exceeds the developer time it was meant to postpone.

Retire PHP 8.1 cPanel at a glance

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

Related guides: Using WP Toolkit Security Risk scores, Smart Update and Vulnerable Components · Certificate lifetimes are shrinking to 47 days: what hosting providers must automate now · LiteSpeed cPanel plugin CVE-2026-48172: the symlink-to-root flaw and how to verify you’re patched.

Frequently asked questions