WHM administers the server and every account on it; cPanel administers one account. If you have root on the machine you get both, and if you are a hosting customer you almost certainly get only cPanel.
That one sentence resolves most of the confusion, but the consequences are worth spelling out, because the most common version of this question is really “why can I not find the setting the tutorial mentioned”, and the answer is nearly always that the setting lives one level up from where you are looking.
Table of contents
- Two levels, two audiences
- Which one has your setting
- The reseller layer in the middle
- What this means when you are debugging
- Whether either is the right layer for you
- How this fits the rest of the stack
- FAQ
Two levels, two audiences
The split is about scope, and everything else follows from it.
WHM operates on the server. It creates and suspends accounts, defines hosting packages with their disk and bandwidth limits, manages system services, installs and updates software, configures the firewall, handles server-wide certificates, and sets what each account is allowed to do. It runs as root.
cPanel operates inside one account. It manages that account’s files, its databases, its email, its domains and its certificates. It cannot see other accounts on the same machine and cannot change anything at the server level.
The relationship is strictly one-directional. WHM creates cPanel accounts. A cPanel account cannot create anything in WHM, and cannot see that WHM exists.
Three roles map onto this cleanly. A shared hosting customer has cPanel. A reseller has a restricted WHM that creates cPanel accounts within a quota. A server owner has full root WHM plus a cPanel account for each site.
Which one has your setting
This is the practical question and it has a reliable rule: if the setting affects more than one website, it is in WHM.
In WHM, at the server level:
- Creating, suspending and terminating accounts
- Which PHP versions exist on the server at all
- The mail server, its ports and its server-wide spam configuration
- Firewall rules and server-level IP blocking
- Backup configuration for the whole machine
- Service restarts, updates and the panel’s own version
In cPanel, inside one account:
- Files, directories and per-account FTP users
- Databases for that account and their users
- Which of the available PHP versions this account uses
- Mailboxes, forwarders and autoresponders for its domains
- Its own domains, subdomains, redirects and DNS records
- Its own certificate status and cron jobs
The PHP entry appears in both lists and that is deliberate, because it is the most common source of confusion. WHM decides which versions are installed on the server; cPanel picks from that list. If the version you want is not in the cPanel dropdown, no amount of clicking in cPanel will add it. Ask your host.
The reseller layer in the middle
Reseller accounts are the reason this arrangement exists at all, and they explain the design better than either interface does alone.
A reseller buys capacity and resells it. They get a WHM login restricted to their own accounts: they can create, suspend and terminate customers within a quota, define their own packages, and brand the interface, but they cannot restart the mail server or affect anyone else’s customers.
This is why cPanel is deliberately sealed off. The whole product assumes multi-tenancy where tenants must not be able to see or affect each other, and that assumption shapes every permission boundary in it.
It also explains something that frustrates single-site owners: features you would expect to control are unavailable because they are shared infrastructure. That is not the host being unhelpful, it is the tenancy model working as designed.
What this means when you are debugging
Knowing which level you are on saves real time when something breaks. A short triage order:
- Read the error log in cPanel under Metrics. Account-level problems, which is most of them, show up here first.
- Check whether the problem is one site or every site on the server. One site is a cPanel problem. All sites is a WHM or service problem, and if you do not have WHM it is a support ticket.
- Check account resource limits. Hitting a package limit on disk, inodes, processes or memory produces symptoms that look like application bugs and are not.
- If the fix requires a service restart, a firewall change, or installing something server-wide, you need WHM. Stop trying to do it from cPanel.
That third point deserves emphasis. Inode limits in particular cause confusing failures: uploads fail, sessions break, and the disk usage figure looks fine, because you have run out of file count rather than space.
Whether either is the right layer for you
The cPanel and WHM split is an excellent design for a specific business, which is selling hosting accounts to people who need isolated control over a website they did not build the infrastructure for.
It is a poor fit for a team shipping an application from a repository. Neither level gives you a build step, an atomic deploy, a rollback or configuration in version control, because the model assumes files uploaded to a long-lived server rather than an artefact built from a commit.
If you find yourself wanting WHM mostly so you can install a runtime and configure a reverse proxy, the thing you actually want is a deploy target rather than a server. On RunxBuild that is a repository connection, a build log, a live route, environment variables and a rollback to the previous deploy, and the account boundary that WHM provides is a team rather than a system user.
And if the appeal of cPanel is specifically the WordPress workflow, the two features that carry it are a file manager and a database browser. RunxBuild’s managed WordPress includes both in the dashboard without the surrounding server administration surface, which is documented under WordPress files.
How this fits the rest of the stack
Whichever layer you land on, the costs sit in more than one place: the server, the panel licence, the backups and the bandwidth are separate lines, and the panel is the one most often missing from a comparison. The RunxBuild hosting calculator prices the managed alternative so the comparison is against a full total rather than an instance price.
Useful related references:
- Hosted Services: The Difference Between Renting Software and Owning the Runtime
- Python Not Equal: != vs is not, and Why the Difference Bites
- MySQL to MySQL: Migrating a Database Between Servers
- Services on RunxBuild
FAQ
Do I need both cPanel and WHM?
Only if you administer a server. WHM is the server-level interface and requires root access; cPanel is the per-account interface. Shared hosting customers get cPanel alone and their host operates WHM. Server owners get both and use each for different things.
Why can I not change the PHP version I need?
WHM controls which PHP versions are installed on the server, and cPanel only lets you choose from that list. If the version you want is not in the dropdown, it is not installed, and only someone with WHM access can add it. On shared hosting that means asking your host.
What is a reseller account?
A restricted WHM login that lets you create and manage cPanel accounts within a quota you have purchased, without server-level privileges. It exists so hosting can be resold: you can create, suspend and brand customer accounts but cannot restart services or affect other resellers’ customers.
Can I access WHM on shared hosting?
No. WHM requires root-level access to the server, and shared hosting deliberately withholds it because one customer having it would compromise the isolation of every other account on the machine. Server-level changes on shared hosting go through your host’s support.
Is one of them more secure than the other?
They protect different things. WHM is the higher-value target because it has root and controls every account, so it should be behind multi-factor authentication and restricted by address where possible. A compromised cPanel account affects one site; a compromised WHM affects the whole server.