Isolate noisy tenants with cPanel MultiPHP Manager and per-domain PHP-FPM

The problem is one noisy site, not PHP itself

In shared hosting a single site with a runaway loop or a traffic spike can starve the rest of the server. With a single global PHP handler everyone shares the same worker pool, so one tenant's problem becomes everyone's latency.

cPanel & WHM's MultiPHP Manager with per-domain PHP-FPM gives you a practical way to break that coupling. Each domain can run its own PHP version and its own FPM pool, so resource limits and version choices are per-tenant instead of server-wide.

What MultiPHP Manager changes

MultiPHP Manager lets an administrator assign different PHP versions, installed via EasyApache 4, to individual domains or accounts. EasyApache 4 packages PHP as separate RPMs, so adding or removing a version is a package operation, not a recompile.

When PHP-FPM is enabled for a domain, cPanel creates a separate FPM pool for that account. Under the default configuration the pool runs as the account user, which preserves file-permission isolation compared with a single mod_php style handler.

WHM exposes per-domain FPM knobs such as max children, process idle timeout and max requests. Those are the levers you use to trade memory use against concurrency for each tenant.

Worked example: legacy site alongside current sites

Scenario: a legacy application requires an older PHP branch while new sites should run a current branch. With MultiPHP Manager you can keep both on the same server.

In WHM open MultiPHP Manager. Select the legacy domain and set its PHP version to the older branch that is still available in EasyApache 4 for your cPanel release. Enable PHP-FPM for that domain. Set a conservative max_children based on the site's typical memory use and the server's capacity.

Select a new domain and assign a current PHP branch, also with PHP-FPM enabled. The two pools are independent. A traffic spike on the new site cannot exhaust workers for the legacy site, and you can migrate tenants incrementally instead of a risky big-bang cutover.

Before changing production tenants, test on a staging copy. Switching handler or version can break sites that rely on version-specific extensions.

Verify the assignment safely

Verification is manual and should be done on a test domain first.

In WHM, open MultiPHP Manager and confirm the assigned PHP version and PHP-FPM status for the test domain. Check the domain's pool config file under the PHP-FPM configuration directory for the account to confirm the pool name and limits.

Create a phpinfo page on the test domain, e.g. public_html/phpinfo.php containing . Access it via HTTPS as the site owner. Confirm the reported PHP version and Server API shows FPM/FastCGI. Remove the file immediately after checking; phpinfo exposes configuration details.

Observe memory while the domain is under load. On the server as root, watch free -m and the FPM pool status or logs to confirm max_children is sized safely and workers are not being killed.

Trade-off and limitation

Each PHP-FPM pool reserves memory for its workers. Enabling FPM for many busy domains without tuning max_children can cause memory pressure and OOM kills on small VPS instances. Start conservative and increase only with evidence.

Available PHP versions depend on the cPanel & WHM release and the EasyApache 4 repository at the time. End-of-life branches may be removed from newer profiles, so pinning a legacy site is temporary.

Rollback is straightforward when you only change settings in MultiPHP Manager: reopen MultiPHP Manager for the domain and revert the PHP version or disable PHP-FPM, then reload the relevant FPM service. Always verify the site after a change.

Actionable closing

Use per-domain PHP-FPM to isolate tenants and to allow incremental PHP upgrades. Assign versions in MultiPHP Manager, set pool limits per tenant, verify with phpinfo and pool config, and monitor memory after changes. Current verification is required because paths and UI labels can shift with cPanel releases.