How to Safely Disable or Remove Unused PHP Versions Without Breaking CloudPanel?

[dpnmw]

I have CloudPanel installed and running on my server, and I noticed that multiple versions of PHP-FPM are installed and running on the system. Specifically, I have PHP versions 7.1, 7.2, 7.3, 7.4, and PHP 8.x versions running simultaneously, but only using 8.3 and 8.4 versions for my projects.

I am concerned about the resource usage of PHP-FPM services for versions that are not in use.

I would like to disable or remove these unused PHP versions to optimize resource usage. However, I want to make sure that I don't accidentally break CloudPanel or any of its core services in the process.

My specific questions are:

Can I safely disable or remove PHP-FPM services for unused PHP versions without affecting CloudPanel's functionality?

If so, what is the recommended approach to ensure I do not disable the PHP version that CloudPanel relies on?

Are there any specific versions of PHP (e.g., PHP 7.1, 7.2) that I should avoid removing, given that CloudPanel may depend on them for system functionality?

What steps should I follow to ensure the safe removal or disabling of PHP versions, and are there any precautions I should take?

I would really appreciate any guidance or best practices on how to proceed safely without causing issues with CloudPanel.

Thank you in advance!

[MPLEXO]

I've been wondering the same. For small VPS server's I was hoping to disable all unneeded services to free up CPU / RAM.
Stopping the service VIA the CLI seems to work, and free up about 300MB of RAM. That makes a big difference on a VPS.

[slaweally]

Friends, I did a small test and you can look here for the results and solution: Cloudpanel Forum

[s-a-s-k-i-a]

CloudPanel's admin UI runs on its own bundled dependencies, separate from the php*-fpm units you provision for sites. So any FPM service not backing a site can be stopped without touching the panel.

CloudPanel's CLI doesn't have a site:list command — the full command list lives in the root-user-commands docs — so for inventory go straight to nginx + pool configs:

# Which PHP-FPM versions do nginx vhosts actually reference?
grep -rEho 'php[0-9]+\.[0-9]+-fpm\.sock|fastcgi_pass.*php[0-9]+' \
    /etc/nginx/sites-enabled/ | sort -u

# Which pools exist beyond the default www.conf?
for d in /etc/php/*/fpm/pool.d/; do
    echo "=== $d ==="
    ls "$d"
done

A version with no nginx references and only www.conf in pool.d/ is unused.

Stop and disable the unused FPM services:

systemctl disable --now php7.1-fpm php7.2-fpm php7.3-fpm php7.4-fpm

That recovers the FPM master + idle workers per version (~50–100 MB each depending on pm.* settings), which is what @MPLEXO was seeing.

Removing the packages is also safe, per-version, once you've re-confirmed nothing references the binary:

grep -rE "php7\.1|/php7\.1" /etc/nginx/ /etc/php/ /etc/cron.d/ 2>/dev/null   # should be empty
apt purge "php7.1*"
apt autoremove

Things to keep:

• Whichever PHP version your sites actually use (from the grep above).
• The CLI default — update-alternatives --display php shows the current php symlink target. Maintenance helpers (cron jobs, WP-CLI wrappers) often call php without a version. Keep that target alive, or repoint it before removing the old version: update-alternatives --set php /usr/bin/php8.3.

Separately — 7.1 through 7.4 are all past upstream EOL, no security patches. Resource recovery is the secondary reason; removing them is the right call on security grounds first.