cPanel MultiPHP Manager vs CloudLinux PHP Selector: which to use

Both tools change which PHP version runs a site, both ship as a cPanel UI, and both can coexist on the same server. That overlap is the problem: hosts new to CloudLinux often think Selector replaces MultiPHP Manager (it doesn't), or assume MultiPHP alone is enough on shared hosting (it isn't, if you want users to self-serve). Pick the wrong one and you either drown in "can you switch me to PHP 7.4" tickets or fight extension conflicts on a single-tenant box that didn't need CageFS in the first place.

The short version: MultiPHP Manager is for admins setting a version per domain. PHP Selector is for end users picking their own version and extensions inside CageFS. On a shared host running CloudLinux you want both — MultiPHP sets the system default, Selector lets users override it. This article walks through the architecture, the side-by-side differences, and which combination fits which hosting model.

What each tool actually does

MultiPHP Manager (cPanel native)

MultiPHP Manager lives in WHM → Software → MultiPHP Manager and in the cPanel user panel as Select PHP Version. It changes the handler for a vhost so Apache or LiteSpeed routes requests for that domain to a specific PHP binary. The binaries are ea-php55 through ea-php84 — the EasyApache 4 packages cPanel maintains.

What it controls:

• PHP version per domain (or system default)
• PHP handler (suPHP, CGI, FPM, lsapi, mod_php)
• INI directives via the MultiPHP INI Editor (admin-only, server-wide per version)
• PHP extensions are toggled server-wide via EasyApache 4

What it doesn't do:

• Per-user extension selection
• Hardened PHP for EOL versions (5.6, 7.0, 7.1, 7.2, 7.3 reach end of vendor security support and stop receiving CVE backports)
• End-user php.ini overrides via a GUI
• Anything for users who are jailed in CageFS without explicit MultiPHP handler config

PHP Selector (CloudLinux)

PHP Selector lives in the cPanel user panel as Select PHP Version when CloudLinux is installed — same menu name, different backend. It uses CloudLinux's alt-php binaries (/opt/alt/php55/, /opt/alt/php74/, etc.) which are independent of EasyApache. The selector hooks into the LVE/CageFS namespace so each user sees their chosen version when they shell in or when their site executes PHP.

What it controls:

• PHP version per user, optionally per domain inside that user
• Per-user extension toggles from a list of 120+ alt-php extensions
• Per-user php.ini directives (memory_limit, upload_max_filesize, etc.) without root
• Hardened PHP — alt-php 5.6/7.0/7.1/7.2/7.3 keep receiving CloudLinux-backported CVE fixes after upstream EOL (see hardened PHP for legacy versions)

What it doesn't do:

• Replace MultiPHP Manager for setting the system default — that's still cPanel's job
• Apply if CageFS is disabled for the user (see fix: cannot manage PHP versions when CageFS is disabled)
• Work without a CloudLinux licence

Side-by-side comparison

The biggest mental model shift: MultiPHP changes what the vhost sees. PHP Selector changes what the user sees inside their jail. When both are configured, the selector runs after the handler picks the binary — so a user who picks PHP 8.2 in Selector will run alt-php 8.2 even if MultiPHP Manager has the domain set to ea-php 8.1.

When to use which

Shared hosting (multi-tenant)

Use both. MultiPHP Manager sets a sane default (usually the current stable PHP, e.g. 8.3 in 2026). PHP Selector gives end users a self-service way to override that default when their app needs something specific — a WooCommerce site stuck on PHP 7.4, a WordPress install that breaks on 8.2 because a plugin uses each(), a Joomla 3 site that won't go past 7.4.

Without PHP Selector your support queue fills with version-change requests. Without MultiPHP, new accounts inherit whatever the system PHP happens to be, which is rarely what you want as a default.

Reseller hosting

Same as shared — both. Resellers want the same self-service capability for their own end users, and PHP Selector inherits naturally per-account. See CloudLinux reseller limits in WHM for how to scope this per-reseller.

VPS / dedicated for a single client

MultiPHP only. If one customer owns the whole box and you trust them with PHP version decisions, CageFS isolation buys you nothing and the extra CloudLinux licence is hard to justify. The exception: if that single client runs a CMS stuck on PHP 7.2 or earlier and needs CVE backports — that's worth a CloudLinux licence on its own.

Developer / agency boxes

MultiPHP only, unless you specifically want to test how your apps behave under alt-php extension sets. Most agency builds care more about matching the production PHP version than about per-developer overrides.

How they interact on a CloudLinux + cPanel server

Install order matters. CloudLinux's PHP Selector replaces the "Select PHP Version" cPanel UI shown to end users — but only for users in CageFS. Admins still see MultiPHP Manager in WHM, unchanged. Concretely:

1. Admin sets php8.3 as the system default in MultiPHP Manager.
2. A new cPanel account is created. The user's public_html runs ea-php 8.3 by default.
3. User opens Select PHP Version in cPanel. Because CloudLinux is installed and the user is in CageFS, they see the alt-php selector, not MultiPHP's version dropdown.
4. User picks alt-php 7.4 and enables ioncube. Their site now runs /opt/alt/php74/ with ionCube loaded, regardless of what MultiPHP says about the vhost.
5. Admin changes the vhost to ea-php 8.1 in MultiPHP Manager. The user's selector choice still wins — their requests keep going to alt-php 7.4 via mod_lsapi.

If you want to force all sites onto ea-php (no alt-php override), disable the PHP Selector for that user with selectorctl --disable-user=username, or globally with selectorctl --disable. The user will fall back to the MultiPHP handler.

Common mistakes

Disabling CageFS to "fix" PHP Selector issues. This breaks PHP Selector entirely and you'll see the cannot manage PHP versions error in cPanel. Don't disable CageFS — fix the underlying issue (usually a missing binary in the cage, which you add per CageFS add custom binaries).

Forgetting to set defaults in PHP Selector. Out of the box, Selector shows users PHP 5.4 as the default if you don't configure it. Run selectorctl --set-user-current-php-version=alt-php83 --user=USERNAME or set the server default with selectorctl --set-default-php-version=8.3.

Running mod_php with PHP Selector. mod_php is per-Apache-worker — it can't switch PHP versions per request. Use lsapi (mod_lsapi or LiteSpeed Web Server) or PHP-FPM with the CloudLinux PHP-FPM handler instead. See PHP handlers compared for the full breakdown.

Editing php.ini directly under /opt/cpanel/ea-phpXX/ to change Selector behaviour. That file applies to ea-php, not alt-php. Selector reads /opt/alt/phpXX/etc/php.ini and per-user overrides in /var/cpanel/userdata/USER/.

FAQ

Next steps

• Set up CloudLinux PHP Selector on a cPanel server
• Hardened PHP for legacy versions
• PHP handlers on cPanel compared