Keeping many accounts consistent: the settings worth standardising

Thirty accounts configured slightly differently is thirty separate things to debug. The fix is not documentation nobody reads; it is choosing a small number of settings that must be identical everywhere and refusing to let them drift.

The settings actually worth standardising

1. The package. Every account on a named package, never hand-built. This alone covers quotas, limits and feature access.
2. PHP version. One current version for everything, with a written list of the exceptions and the reason each was pinned.
3. Caching configuration. Same policy, same exclusions, same time to live on every site.
4. Certificate handling. Automatic issuance and renewal on, everywhere, so no site quietly expires.
5. Backup schedule. One schedule, and one place you can confirm it ran.
6. Address assignment. Every account on its own dedicated address, and a list of which is which.

Six items. Anything longer stops being a standard and becomes a wish.

What deliberately should not be standardised

Resist uniformity where it costs you something:

• Passwords. Never the same across accounts. Isolation between accounts is worthless if one credential opens all of them.
• Addresses. The entire point is that they differ.
• Cron schedules. Identical timings mean every site does its heavy work in the same minute, which is a self inflicted load spike.
• Resource ceilings. The busy site and the brochure site have different needs, which is why more than one package exists.

Detecting drift

Drift is silent, so you have to go looking. A short quarterly pass is enough:

1. List accounts and their packages. Anything not on a known package is drift.
2. List PHP versions. Anything off the standard should be on your exceptions list, and if it is not, find out why.
3. Check one page per site for a cache hit. Silent caching failures show up here.
4. Check certificate expiry dates. One outlier means renewal is broken for that account.
5. Compare the address list against your records.

Each of these is a list you can read in a minute from WHM. The value is not in any single check; it is that five minutes a quarter keeps a network knowable.

Write the exceptions down, not the rules

Long configuration documents go stale and nobody reads them. What genuinely earns its keep is a short list of departures from the standard: which account, what is different, why, and whether it can be removed yet.

A site pinned to an old PHP version for a reason nobody recorded becomes a site nobody dares touch, and that is how a network accumulates untouchable corners. One line at the time of the decision prevents it.

Standardise at creation, not afterwards

Everything above is far cheaper when a new site starts correctly than when it is corrected later. Account created on the right package, address assigned before the domain points anywhere, certificate issued, caching applied, backup schedule confirmed. That is a five minute checklist that saves hours.

A repeatable sequence for adding a site is in Launch Playbooks, and the routines for keeping an existing estate healthy are in Running Your Estate. For which sites belong in which account before you create anything, see Network Planning.

The configuration reference is at docs.cpanel.net.