Managing Multiple PHP Versions on cPanel and DirectAdmin Per Site

If you manage more than one website on the same server or hosting account, you almost always run into a familiar problem: one project still needs PHP 7.4, another works best on PHP 8.1, and your newest build really wants PHP 8.2 or 8.3. Updating PHP globally feels risky, but leaving everything on an old version hurts performance, security, and long‑term maintainability. The good news is that both cPanel and DirectAdmin are built to run multiple PHP versions side by side and let you choose the right one per site or even per directory.

In this article, we will walk through how we at dchost manage multiple PHP 7.x/8.x versions on shared hosting, reseller plans, VPS and dedicated servers using cPanel and DirectAdmin. We will focus on practical decisions: which PHP version to choose for WordPress, WooCommerce, Laravel, PrestaShop or custom apps, and how to switch versions safely without taking sites offline. You will see concrete steps, real‑world patterns from agency and freelancer setups, and a strategy you can apply across all your domains.

Why Per‑Site PHP Versions Matter

On a modern hosting stack, running a single PHP version for every domain is rarely ideal. Different applications evolve at different speeds and have their own compatibility windows. Some examples we regularly see on our infrastructure:

• Legacy corporate site running an old CMS that only supports PHP 7.4.
• Busy WooCommerce store whose payment plugins are certified up to PHP 8.1.
• New Laravel or Symfony app built directly against PHP 8.2 / 8.3.

If you upgrade the server globally to PHP 8.2 for the sake of the new project, the older ones can break. If you freeze everything on PHP 7.4, newer apps miss out on performance, security, and language features. Per‑site (or per‑domain) PHP selection solves this tension.

Running the right PHP version per site gives you several concrete benefits:

• Compatibility: Keep older apps online while you refactor or migrate them.
• Security: Move actively developed projects to supported PHP 8.x releases with ongoing security fixes.
• Performance: Newer PHP 8.x versions often deliver noticeable speedups, especially when combined with OPcache and PHP‑FPM.
• Risk management: You can upgrade and test one site at a time instead of performing a risky, all‑or‑nothing switch.

We covered deeper technical aspects of upgrading in our PHP 8.x upgrade checklist for WordPress and Laravel. Here we will focus specifically on how cPanel and DirectAdmin help you run many PHPs on one server cleanly.

How Multi‑PHP Works on cPanel and DirectAdmin

Before clicking any buttons, it helps to understand what is happening under the hood. On a typical dchost server, we install several PHP versions side by side (for example PHP 7.4, 8.0, 8.1, 8.2, 8.3) through the control panel’s build system:

• cPanel uses EasyApache 4 (“ea‑php74”, “ea‑php82”, and so on).
• DirectAdmin uses CustomBuild (php1_release, php2_release, php3_release…).

Each PHP version provides its own binaries and modules. The web server (Apache or LiteSpeed) and PHP handlers (PHP‑FPM, lsphp, or CGI) decide which binary to call for each request. The control panel’s GUI simply writes the correct configuration:

• In cPanel: Apache vhost config and .htaccess directives.
• In DirectAdmin: per‑domain vhost snippets and PHP‑FPM pool settings.

From your point of view, you only choose the version in the interface; the panel ensures requests to example.com use, say, PHP 8.2 while legacy.example.com stays on PHP 7.4.

Multi‑PHP on cPanel (EasyApache 4 + MultiPHP Manager)

On cPanel servers, the key components are:

• EasyApache 4: where server admins enable or disable PHP versions and extensions.
• MultiPHP Manager: where you assign a PHP version per domain or subdomain.
• MultiPHP INI Editor: where you adjust per‑domain php.ini directives like memory_limit or upload_max_filesize.

If PHP‑FPM is enabled, cPanel will also run separate PHP‑FPM pools per domain. This keeps resource usage isolated and makes it easier to fine‑tune performance for busy sites. For users hitting errors like “Resource Limit Reached” or high CPU usage when changing PHP versions, our guide on understanding cPanel resource limits and fixing the ‘Resource Limit Reached’ error is a good companion read.

Multi‑PHP on DirectAdmin (CustomBuild + PHP‑FPM)

DirectAdmin achieves the same goal with slightly different naming:

• CustomBuild: server‑side tool where admins define up to 4 PHP versions (php1_release … php4_release) and choose their modes (php-fpm, lsphp, etc.).
• Per‑Domain PHP version: in the user panel, you can choose which of these PHP slots a given domain will use.

Most modern DirectAdmin setups we deploy use PHP‑FPM for all versions. Each domain can then have its own FPM pool, resource limits, and configuration. At a higher level, this is the same pattern we describe in our article on running multiple PHP‑FPM pools per site; DirectAdmin simply handles the plumbing for you.

Choosing the Right PHP 7.x/8.x Version Per Site

Having many versions available is useful, but it raises an obvious question: which PHP version should you actually choose for each project? Here is how we typically approach it when designing or tuning hosting for our customers.

General decision rules

• Prefer the latest stable PHP 8.x that your application officially supports.
• Avoid PHP 7.x for new projects; use it only as a temporary bridge for legacy code while you plan a migration.
• Match framework and CMS compatibility (WordPress, Laravel, PrestaShop, Magento, custom apps).
• Upgrade gradually (7.4 → 8.0 → 8.1/8.2) if you maintain large, complex codebases.

Below is a quick, real‑world matrix. Always verify against your specific theme, plugin, or framework versions, but this gives you a practical starting point.

WordPress and WooCommerce

• New or actively maintained sites: aim for PHP 8.1 or 8.2. Most current WordPress and plugin ecosystems support these versions well.
• Heavily customized or older themes/plugins: start with PHP 8.0, fix incompatibilities, then move toward 8.1/8.2.
• Only keep PHP 7.4 if some critical plugin or theme vendor explicitly requires it and you have a clear plan to replace or refactor.

If you run a busy store, combining a modern PHP 8.x version with proper object caching and database tuning can make a large difference. We explore this in detail in our WooCommerce MySQL/InnoDB tuning checklist and our WooCommerce‑specific hosting guides.

Laravel, Symfony and modern PHP frameworks

• Recent Laravel (9/10/11) and Symfony versions are typically tested against PHP 8.1+ or 8.2+. Use the newest version supported by your framework release.
• For greenfield applications where you control all code, we usually recommend PHP 8.2 or 8.3 combined with tuned PHP‑FPM pools.
• For older, large Laravel apps still on PHP 7.4, plan staged upgrades (7.4 → 8.0 → 8.1/8.2), using feature flags and thorough testing.

PrestaShop, Magento and other e‑commerce platforms

E‑commerce platforms often have strict version matrices for PHP because of their large, complex ecosystems:

• PrestaShop: check the official docs for your exact release; many recent versions work well with PHP 8.1, older ones might need 7.4 or 8.0. We discuss this in the PrestaShop hosting guide with PHP, MySQL, caching and CDN settings.
• Magento: typically lags slightly behind the newest PHP. Use whatever PHP 8.x version the vendor certifies for your Magento release.

For these platforms, stability is often more important than being on the absolute latest PHP build. It is better to run the officially supported PHP version plus strong caching and database tuning than to jump ahead and risk subtle checkout bugs.

Legacy custom applications

Legacy in‑house apps are where multiple PHP versions really pay off. We often see older custom CRM, intranet or reporting tools that:

• Use deprecated functions removed in PHP 8.x.
• Rely on libraries that are no longer maintained.
• Have no automated tests.

In these cases we recommend:

1. Keep the app online on PHP 7.4 (or the minimum needed version), isolated to its own domain.
2. Lock down access with strong authentication and network rules.
3. Prepare a migration or rewrite plan while new projects move forward on PHP 8.x.

Checklist before changing PHP version for any site

Regardless of the platform, use this simple checklist before switching PHP versions on cPanel or DirectAdmin:

• Backups: ensure you have a recent full backup and test restore path.
• Staging environment: clone the site to a staging subdomain and test there first. Our guide on creating a WordPress staging environment on cPanel walks through this workflow.
• Error visibility: enable logging (display_errors=Off, log_errors=On) so issues go to logs rather than visitors.
• Maintenance window: schedule the cutover during a low‑traffic period if the site is critical.

Managing Multiple PHP Versions in cPanel: Step‑by‑Step

Let’s look at the concrete steps you can take on cPanel servers. The exact screens may vary slightly by theme, but the logic is the same.

1. Server‑level setup (for VPS/dedicated and resellers)

If you manage a cPanel server via WHM (for example on a dchost VPS or dedicated server):

1. Log in to WHM as root or reseller with sufficient privileges.
2. Go to “EasyApache 4”.
3. In the PHP Versions section, enable the versions you need (e.g. ea‑php74, ea‑php81, ea‑php82).
4. Select common extensions (intl, mbstring, gd, imagick, pdo_mysql, etc.) for each version according to your applications.
5. Provision the profile so WHM installs the chosen versions.

Next, verify PHP‑FPM:

1. Still in WHM, go to “MultiPHP Manager”.
2. Enable PHP‑FPM for domains that receive higher traffic; leave very small or static sites on CGI only if needed.

On managed dchost servers, we typically pre‑configure a reasonable set of PHP versions and FPM defaults, then tweak them per project.

2. Per‑domain PHP selection in cPanel

As a cPanel account user (shared hosting or reseller client), you can choose PHP versions per domain without accessing WHM:

1. Log in to cPanel.
2. Open “MultiPHP Manager”.
3. Select one or more domains and subdomains from the list.
4. Use the dropdown on the right to choose the desired PHP version (e.g. PHP 8.1, PHP 8.2).
5. Click “Apply”.

The change is usually effective within seconds. Apache is reconfigured behind the scenes, and new requests to that domain will be served by the selected PHP version.

3. Adjusting PHP settings per domain (MultiPHP INI Editor)

Switching versions is only half the story; you often need to tune per‑site PHP settings:

1. In cPanel, open “MultiPHP INI Editor”.
2. Choose your domain from the dropdown.
3. Adjust key directives such as:
   • memory_limit (e.g. 256M or 512M for heavier apps)
   • upload_max_filesize and post_max_size
   • max_execution_time (useful for imports or backups)
4. Save changes.

These settings are stored in a per‑domain configuration and applied only to that site, regardless of which PHP version it uses.

4. Advanced: per‑directory overrides with .htaccess

Sometimes you want a different PHP version for a specific subdirectory (for example /old‑app inside the same domain). On EasyApache 4 systems this is less common, but still possible. In many cases MultiPHP Manager is enough; if you go lower level:

• Check with support or documentation for the correct AddHandler or SetHandler directives for your environment (ea‑php82, lsapi, etc.).
• Add these directives to a .htaccess file in the target directory.
• Test carefully, because misconfigured handlers can cause 500 errors.

For most users, we recommend keeping things at the domain level via MultiPHP Manager; it is safer and easier to maintain, especially when your team changes over time.

Managing Multiple PHP Versions in DirectAdmin: Step‑by‑Step

Now let’s look at the DirectAdmin side. The underlying idea is the same, but the interface and terminology differ slightly.

1. Server‑level setup with CustomBuild

If you administer a DirectAdmin VPS or dedicated server at dchost, you configure PHP versions through CustomBuild:

1. SSH into the server as root.
2. Run ./build options in the CustomBuild directory (usually /usr/local/directadmin/custombuild).
3. Set php1_release, php2_release, php3_release, etc. to the versions you need (for example 7.4, 8.0, 8.1, 8.2).
4. Set php1_mode, php2_mode to php-fpm (recommended for performance and isolation).
5. Save and run ./build php n (or ./build all d in some environments) to compile/install the chosen releases.

Once this is done, end users can pick among these versions per domain without touching the server internals.

2. Per‑domain PHP selection in DirectAdmin

As a DirectAdmin user:

1. Log in to the DirectAdmin user panel.
2. Go to “Domain Setup” (or “Account Manager > Domain Setup” depending on skin).
3. Select the domain you want to adjust.
4. Look for “PHP Version Selector” or a similar option.
5. Choose which PHP slot to use (PHP 8.1, PHP 8.2, etc., corresponding to php1_release, php2_release on the server).
6. Save.

New requests for that domain will now be handled by the selected PHP version using its dedicated PHP‑FPM pool.

3. Per‑domain PHP‑FPM and ini tuning

DirectAdmin typically exposes PHP‑FPM and php.ini options either through the GUI or via configuration files. Common tasks include:

• Increasing memory_limit for heavy sites.
• Adjusting pm.max_children and other FPM pool settings for busier domains.
• Configuring separate error logs per site to make debugging easier after a PHP upgrade.

If you are hosting many sites or running an agency stack on a DirectAdmin VPS, combining this with a solid architecture is important. We discussed multi‑site hosting patterns in our piece on hosting architecture for agencies managing 20+ WordPress sites on one stack.

A Practical Strategy for Agencies, Resellers and Multi‑Site Owners

Running many sites on one server is not just a technical exercise; it also requires policy. Here is a pragmatic strategy we use when onboarding agency and reseller customers to dchost infrastructure.

1. Classify your sites by risk and flexibility

Create three simple buckets:

• Active projects: you can change code, update plugins, and fix issues quickly.
• Stable but maintained: sites that receive updates, but are business‑critical and risk‑averse.
• Legacy/blocked: you cannot touch the code easily; upgrades are politically or technically difficult.

2. Assign PHP versions per bucket

• Active projects: run on the newest stable PHP 8.x version supported by your stack (for example PHP 8.2), and plan fast adoption when new minor versions are released.
• Stable but maintained: run on a slightly more conservative PHP 8.x (for example 8.1 or 8.2), upgrade once or twice a year after testing.
• Legacy/blocked: isolate on PHP 7.4 or the lowest viable version, tighten security, and document a long‑term exit plan.

3. Standardize your upgrade workflow

For each site, upgrades should follow a consistent pattern instead of ad‑hoc changes in production. A solid flow looks like this:

1. Clone to staging (subdomain or separate account).
2. Deploy code via Git so you can roll back quickly if needed; see our guide on Git deployment workflows on cPanel, Plesk and VPS.
3. Switch PHP version on staging and test key flows (login, forms, checkout, admin screens).
4. Fix deprecations and errors, commit, and redeploy.
5. Schedule production upgrade and repeat the same PHP switch + deploy combo.

For WordPress and WooCommerce, combining staging, proper backups, and per‑site PHP settings is the basis of safe updates. We describe that philosophy in our article on safe WooCommerce updates on shared hosting and VPS.

Common Pitfalls When Running Multiple PHP Versions (and How We Handle Them)

Multi‑PHP setups are powerful, but there are a few recurring issues we see when teams start using them more actively.

1. Missing or mismatched PHP extensions

Each PHP version has its own set of compiled extensions. You might have imagick enabled on PHP 7.4 but not on 8.2. Symptoms include white screens, 500 errors, or “Class not found” messages only after changing versions.

How we handle it:

• Standardize a base set of extensions (intl, mbstring, gd, zip, pdo_mysql, xml, curl, etc.) across all PHP versions on the server.
• Document any project‑specific extensions and ensure they are installed for all target versions before switching.

2. php.ini differences breaking uploads or long tasks

When you switch PHP versions, the effective php.ini may change. Limits like upload_max_filesize, post_max_size, and max_execution_time can suddenly become lower than what your app needs.

How we handle it:

• After every PHP switch, double‑check and adjust these values via MultiPHP INI Editor (cPanel) or per‑domain settings (DirectAdmin).
• Test file uploads, imports, and backup plugins explicitly.

3. Performance regressions due to untuned PHP‑FPM

Moving from PHP 7.4 to 8.1 or 8.2 usually improves performance, but if PHP‑FPM pool settings are too tight, you might see slowdowns or 502/503 errors under load.

How we handle it:

• Review pm.max_children, pm.max_requests, and related FPM directives when upgrading.
• Combine PHP tuning with caching and database optimisation, as described in our guide on server‑side secrets that make WordPress fly (PHP‑FPM, OPcache, Redis and MySQL tuning).

4. Silent deprecations and future breaks

PHP 8.x introduces new deprecations. Even if everything “seems fine” after switching, your logs might be full of warnings that will become fatal errors in future versions.

How we handle it:

• Turn on error logging and periodically review logs, especially after a version change.
• Use staging to upgrade not just to the currently supported version, but also test the next minor (e.g. test 8.3 early while running 8.2 in production).

Bringing Your PHP Versions Under Control

Managing multiple PHP versions on cPanel and DirectAdmin is not about ticking a checkbox once and forgetting it. It is about having a clear, repeatable strategy for each site on your hosting stack: which PHP version it runs, how it is configured, and when it will be upgraded next. With the right approach, you can keep legacy applications online, modern projects fast and secure, and your overall platform predictable.

On our shared hosting, reseller plans, VPS, dedicated servers and colocation setups at dchost, we design the infrastructure specifically to support this kind of per‑site PHP management. Whether you manage a single WooCommerce store or dozens of client sites, you can use MultiPHP Manager on cPanel or the PHP selector in DirectAdmin to align each domain with the most appropriate PHP 7.x/8.x version, backed by good staging, backup and monitoring practices.

If you are unsure which PHP versions to provide on a new server, or you want help planning a large‑scale upgrade across many sites, our team can review your current stack, suggest a version strategy, and configure your cPanel or DirectAdmin environment accordingly. The result is a calmer, more controlled hosting experience where PHP upgrades become a routine operation rather than a source of anxiety.