WHM Server Configuration: The Settings That Matter on a Fresh Install

A fresh WHM installation hands you several hundred settings and no indication of which ones matter. Most of the defaults are reasonable and can be left alone for years. About a dozen are not, and those dozen decide whether the server is secure, whether mail is delivered, and whether you can recover when something breaks. This is a walkthrough of those, in the order you actually meet them.

It is also worth saying plainly at the start: WHM is a control panel for a server you administer. Installing it does not make the server somebody else’s responsibility. That distinction becomes relevant at the end.

Before the wizard: what the installer expects
The initial setup wizard, step by step
Tweak Settings, and the handful worth changing
Security hardening, which is the part that matters
Backups, and testing that they work
What you have actually signed up for
How this fits the rest of the stack
FAQ

Before the wizard: what the installer expects

The installation is one command run as root on a fresh, minimal operating system, and it takes a considerable time. Two prerequisites cause most failed installs:

A clean machine. cPanel and WHM expect to own the server. Installing over an existing web server, mail server or control panel produces conflicts that are far harder to resolve than a reinstall.
A resolvable hostname. The server needs a fully qualified hostname that is not the same as any domain you intend to host on it. Something like server1.yourdomain.com, with a DNS record actually pointing at the server. Setting a hostname you have not created a record for causes mail problems that surface days later and are traced back with difficulty.

Set the hostname and its DNS record before you start the installer, not after.

The initial setup wizard, step by step

On first login WHM runs a wizard. The steps and what to do with them:

Agreement. Read or do not, but note the licence is per server and recurring. It is a real line in the monthly cost.
Networking. Confirm the hostname, and set resolvers. Use two or three that you trust and that answer quickly, because DNS latency here affects every lookup the server makes.
IP addresses. Add any additional addresses the server has. This matters if you plan to give certain sites their own address for mail reputation reasons.
Nameservers. Decide now whether this server is authoritative for DNS. If you already use an external DNS provider, choose to disable the nameserver software rather than run something you are not using — it is one less service to patch.
Services. Turn off what you will not use. An FTP server nobody has ever connected to is an open port and a log full of brute-force attempts.
Quotas. Enable filesystem quotas if you intend to sell or allocate space. Enabling them later is possible and more annoying.

The wizard is not the end of configuration. It is the part that cannot be skipped.

Tweak Settings, and the handful worth changing

Server Configuration → Tweak Settings is the long list. The ones worth attention on a new server:

Initial default and quota for accounts. Set these to match the plans you intend to offer, or you will edit every account by hand.
Send notifications when a disk or memory threshold is reached. On by default in most versions; confirm it, and confirm the address it sends to is one somebody reads.
Proxy subdomains. These create automatic cpanel. and webmail. subdomains. Convenient, and worth understanding rather than leaving on by accident.
Maximum emails per hour per domain. Set it. An unset limit means one compromised contact form gets the server’s address onto a blocklist within an hour, and getting off one is a slow process.
PHP handler and default version. Decide deliberately. The default is not always the version your applications want.

Under Server Configuration → Basic WebHost Manager Setup, set the contact address and, if you offer nameservers, the ones you settled on in the wizard.

Security hardening, which is the part that matters

A default WHM install is functional rather than hardened. The list that closes most of the gap:

Change the SSH port and disable root password login. Keys only. This single change eliminates the overwhelming majority of the noise in your auth log.
Install and configure a brute-force protection service. WHM ships with one; make sure it is enabled and that its trigger thresholds are sane, and allowlist your own address before you lock yourself out. People do lock themselves out.
Run the security advisor. WHM has one built in, under Security Center. It produces a genuinely useful list and most items can be resolved from its own page.
Enable a firewall with a default-deny inbound policy and open only what you use.
Turn on automatic updates for the operating system and the panel, at least for security patches. Deferred patching is how servers end up compromised, and the deferral is always accidental.
Set up mail authentication properly. SPF and DKIM records for every domain, and a reverse DNS record for the server’s address that matches its hostname. Without these, mail from the server goes to spam, and no amount of server tuning fixes it.

Backups, and testing that they work

Under Backup → Backup Configuration, enable backups and then make three decisions properly.

Where they go. A backup on the same server protects you from a mistake, not from a failure. Configure a remote destination — another server or object storage — so the backup survives the machine.

How often, and how many. Daily with a week retained, plus weekly with a month retained, is a reasonable starting point for most servers. Retention is what saves you when a problem is discovered late.

What is included. Confirm databases and mail are in the set, not just the home directories. It is a common and painful gap.

Then restore one. Take a single account, restore it onto a test server, and confirm the site comes up and the database is intact. A backup configuration that has never been restored from is a checkbox, not a recovery plan.

What you have actually signed up for

With that done the server works, and it is worth being clear about the ongoing commitment, because it is the thing nobody puts in the tutorial.

You now own: operating system patching, panel updates and the occasional upgrade that breaks something, certificate renewals, disk space, mail reputation and blocklist removals, the firewall, intrusion response, backup verification, and the licence fee — which is per server, monthly, and scales with the number of accounts.

For somebody hosting many sites, or reselling, that is a sensible trade. The control is real, the per-site cost at volume is low, and WHM is genuinely good at the job it does.

For somebody running a handful of their own applications, it is a large amount of undifferentiated work to take on in exchange for a control panel. That is the honest calculation, and it is worth making deliberately rather than defaulting into it because WHM is what the VPS offered.

How this fits the rest of the stack

The comparison worth making is not WHM against another control panel. It is the full cost of a server you administer — licence, patching, backups, mail reputation, your own hours — against a platform where those are included in the plan. It is easier to judge with the numbers side by side, and the RunxBuild hosting calculator lists services, databases, storage and bandwidth as separate lines so the comparison is against something specific rather than a vague sense that managing it yourself is cheaper.

RunxBuild deploys applications from a repository with build logs, a live route, environment variables, custom domains, runtime logs and rollback to a previous deploy, and managed databases with backups and private networking handled. There is no panel to patch and no licence, which removes most of the list above. For a server that genuinely needs per-account isolation and reseller features, WHM remains the right tool.

Useful related references:

FAQ

What should I configure first in WHM?

The hostname and its DNS record, before installing. Then the initial setup wizard for networking, resolvers and nameservers, then security: SSH keys with password login disabled, brute-force protection, a firewall, and automatic security updates. Backups with a remote destination come immediately after.

Does WHM need a licence?

Yes. cPanel and WHM are commercial software licensed per server on a recurring basis, with pricing tiered by the number of accounts. It is a genuine monthly cost that belongs in any comparison against alternatives, and it is separate from what the server itself costs.

What hostname should I use for a WHM server?

A fully qualified subdomain that is not a site you plan to host, such as server1 followed by your domain, with a DNS record pointing at the server and matching reverse DNS. Getting this wrong causes mail delivery problems that appear later and are hard to trace back.

How do I secure a new WHM server?

Keys-only SSH on a non-default port, brute-force protection enabled with your own address allowlisted, a default-deny firewall, automatic security updates, and the built-in security advisor worked through. Then SPF, DKIM and reverse DNS so mail is actually delivered.

Where should WHM backups be stored?

Somewhere other than the server being backed up. A remote destination such as another server or object storage means the backup survives the machine failing. Then restore one onto a test server, because an untested backup configuration is not a recovery plan.