EasyApache builds the web server and the PHP versions your server offers. Everything a client sees in their PHP selector was put there by an EasyApache profile, and anything missing from it cannot be chosen no matter what the account settings say.
It is powerful and it rebuilds the software every site on the server depends on, so the useful knowledge here is mostly about restraint and sequencing.
Profiles
A profile is a saved list of everything to install; the web server, the PHP versions, and each version's extensions.
Before changing anything, save the current configuration as a profile. That is your route back, and it takes one click.
Provisioning a new server becomes applying a saved profile rather than reconstructing choices from memory, which is worth doing even if you never need to roll back.
Install versions, do not remove them
Adding a PHP version is safe. Every existing site keeps whatever it was using, and the new one becomes available to select.
Removing a version is not safe. Every account using it is switched to the server default at the moment of removal, and applications that cannot run on that version break immediately, without warning to their owners.
So the order is: install the new version, move accounts onto it one at a time, confirm each works, and only then consider removing the old one. Weeks apart, not the same afternoon.
Find out who is using a version before removing it
WHM shows PHP version usage per account. Read it before any removal and count what you would be moving.
Pay attention to accounts set to inherit in place of an explicit version. Those follow the server default, so changing the default moves them (and their owners did not choose it) while accounts with an explicit version stay where they are.
Changing the default is therefore a bigger action than it looks, and it is worth telling people before rather than after. There is more on the account side in MultiPHP Manager.
Extensions are per version, and they are the real work
Each PHP version has its own extension set. Installing a new version does not carry the extensions from the old one.
This is where migrations go wrong. The version is available, sites are moved onto it, and something fails with an error naming a missing function, because an extension the application needs was never installed for that version.
Before moving anyone, list what the old version has enabled and make sure the new one matches. Image processing, mail, encryption and database drivers are the usual gaps.
A rebuild interrupts service
Applying a profile rebuilds and restarts the web server. Sites are unavailable during the restart, typically brief, and not zero.
Do it outside peak hours, and not when you are about to leave. If a rebuild fails partway, the server can be left without a working web server, and that is not a state to discover remotely.
Have your rollback profile ready before starting, not after something goes wrong.
Do not install everything
The interface lists a great many packages, and enabling them all is tempting because it removes future decisions.
Every additional package is more to patch, more to break during upgrades, and more surface area. Extensions in particular have had their own vulnerabilities.
Install what your clients use. Add more when someone asks, which is a five-minute job at that point.
Keeping versions current
PHP releases stop receiving security fixes on a published schedule. A version past that date is not merely old: newly discovered vulnerabilities in PHP itself stay unpatched.
Track when each version you offer reaches that point, and start the migration months ahead. The work is not technical; it is persuading clients to update applications, and that takes time you cannot compress.
Leaving an end-of-life version installed because clients have not moved is a decision to run known-vulnerable software. Making it deliberately, with a deadline, is very different from drifting into it.
Ruby, Node and Python are separate
EasyApache handles the web server and PHP. Other language runtimes are installed through their own mechanisms, and cPanel's application manager exposes them to users independently.
So a client asking for a newer Node version is not an EasyApache question. For what they get, see running Node.js and Python applications.
After a rebuild
Check that the web server actually started, not merely that the rebuild reported success. Those are two different things.
Load a few real sites, including one on each PHP version you offer. Then watch the error logs for a day; a missing extension produces a fatal error only on the page that needs it, which may not be the homepage, and troubleshooting common server issues deals with what to do when something did not come back.
PHP versions also disappear through routine panel updates rather than through anything you did, which is why the release tier matters. There is more on choosing one in cPanel Update Preferences and Release Tiers Explained.
Changes to Apache's own configuration need a different route, because the main file is regenerated and hand edits do not survive. For the durable one, see Apache Configuration and the Include Editor in WHM.
Read the profile before applying it
A profile is a description of what the server will have afterwards, and applying one is not additive.
ls /etc/cpanel/ea4/profiles/ 2>/dev/null grep -o '"ea-php[0-9]*"' /etc/cpanel/ea4/profiles/current.json 2>/dev/null | sort -u rpm -qa 2>/dev/null | grep -c '^ea-php'
Save the current state as a profile before changing anything. That file is the fastest route back if a rebuild produces a server missing something a customer relied on.
Compare the package count before and after. A rebuild that reduces it substantially has removed extensions somebody was using, and the reports arrive over the following days rather than immediately.
Watch what breaks in the hour after
A rebuild completes and the sites come back, which is not the same as everything working.
grep -icE 'call to undefined function|not found|fatal' /var/log/apache2/error_log 2>/dev/null
for u in $(ls /var/cpanel/users | head -20); do
printf '%-16s %s\n' "$u" "$(curl -s -o /dev/null -w '%{http_code}' "https://$(grep -m1 "^DNS=" /var/cpanel/users/$u | cut -d= -f2)/")"
done
Undefined function errors are the signature of a missing extension, and they name the function, which names the extension.
Check a sample of customer sites rather than only your own. Extensions used by one framework and not another mean a rebuild can leave nine sites perfect and the tenth broken, and the tenth customer is the one who reports it a week later.