Run One Domain on a Different PHP Version with cPanel MultiPHP Manager

The problem this solves

A shared cPanel account often ends up hosting two generations of software: a legacy app that breaks on PHP 8, and a modern CMS that requires it. The server-wide default PHP version can't satisfy both. cPanel's per-domain PHP selection lets each domain run its own interpreter, so you can upgrade the new site without touching the old one — or hold the legacy site back while everything else moves forward.

The useful takeaway: the switch itself takes under a minute in the MultiPHP Manager interface, but the real work is confirming extensions, php.ini settings, and cron jobs follow the new version. Those are the three places switches silently fail.

First, find out which selector your account uses

There are two common per-domain PHP systems on cPanel servers, and they are mutually exclusive:

• MultiPHP Manager — cPanel/WHM's native tool. It assigns each domain a PHP version served through PHP-FPM (a process manager that runs PHP as a dedicated pool per domain).
• CloudLinux "Select PHP Version" — a vendor layer (alt-php, sometimes with HardenedPHP for end-of-life versions). Common on hosts running CloudLinux OS.

Do not mix them, and do not hand-edit the AddHandler lines either system writes into .htaccess — the manager will overwrite or conflict with manual edits. If you see both tools in cPanel, or neither, ask your hosting provider which one governs your account before changing anything. The steps below assume MultiPHP Manager; the CloudLinux flow is similar in spirit but lives under "Select PHP Version." UI placement and available versions vary by cPanel release and provider, so treat exact labels as approximate.

Prerequisites

• cPanel access with MultiPHP Manager enabled (if it's missing, your host has restricted it — open a ticket).
• The PHP versions your application actually supports. Check the vendor's requirements page; don't guess.
• A maintenance window or staging copy if the site is production-critical. The switch applies immediately — there is no "scheduled" mode.
• A list of PHP extensions the site needs (e.g., mysqli, gd, intl, mbstring). You'll re-verify these after the switch.

Switching the domain's PHP version

1. Log in to cPanel and open MultiPHP Manager (usually under the Software section).
2. In the domain list, tick the checkbox for the domain or subdomain you want to change. Subdomains and addon domains are selected independently — changing the main domain does not cascade.
3. From the PHP version dropdown, choose the target version. Prefer a currently supported branch; end-of-life versions may still appear (especially under HardenedPHP) but receive no upstream security fixes.
4. Click Apply. cPanel updates the domain's configuration to route requests to the selected PHP-FPM pool. The change takes effect within seconds.

Verify the switch actually happened

Opcode caches can briefly serve stale responses, so verify with a fresh request rather than assuming success.

1. Confirm the reported version. Create a temporary file info.php in the domain's document root containing only:

<?php phpinfo();

Load it in a browser before and after the switch and check the version banner at the top. Delete the file afterward — a public phpinfo() page leaks configuration details useful to attackers. Alternatively, many CMSes report the PHP version on an admin health or system status page, which avoids creating the file at all.

2. Confirm extensions. Extension settings are per-version: enabling intl under PHP 8.1 does not enable it under 8.3. On the phpinfo() page (before deleting it) or in cPanel's PHP options interface, check that every extension your app needs exists for the new version. A missing extension typically surfaces as a fatal "Call to undefined function" or "Class not found" error.

3. Exercise critical paths. Log in, submit a form, and hit any URL that writes to the database. Then check the account's error_log (in the document root, or via cPanel's Errors interface) for new warnings — deprecated-function notices are early signs the app isn't fully compatible with the new version.

Don't forget cron and CLI PHP

The web handler and the command-line PHP binary are configured separately. A cron job like php /home/user/app/schedule.php uses the account's CLI default, which may not match the version you just set for the web. The result is a site that works in the browser but whose scheduled tasks silently fail or run under the wrong runtime.

Fix this by calling the versioned binary explicitly in the cron command. On EasyApache systems the binaries live at paths like /opt/cpanel/ea-php82/root/usr/bin/php; CloudLinux uses its own alt-php paths. Exact paths vary — list them from cPanel Terminal or SSH (permissions permitting) with:

ls /opt/cpanel/ | grep ea-php

Then run the cron command manually once with the chosen binary and confirm it exits cleanly before relying on the schedule. The same applies to WP-CLI and Composer invocations.

Recovery if the site breaks

Rollback is the same operation in reverse: return to MultiPHP Manager, select the domain, choose the previous version, and apply. There is no separate backup to restore because the switch only changes which interpreter handles requests — your files and database are untouched.

If the site fatals after switching, in order:

1. Revert the PHP version in MultiPHP Manager.
2. Check error_log for the failing extension or deprecated function — it tells you exactly what to fix before retrying.
3. If the error persists after reverting, clear any application-level or opcode cache, since cached bytecode can outlive the switch by a few minutes.

Once the site is stable on the new version, remove the temporary info.php and note the working configuration somewhere. The next PHP upgrade will be the same exercise with less guesswork.