WHM packages: define the standard once instead of per account

A package is a saved set of limits and features that you attach to an account at creation. Build three or four packages once and every account you create afterwards is consistent by default. Skip them and you get thirty accounts that were each configured by hand on a different day.

What a package holds

• Disk quota and monthly bandwidth.
• How many databases, subdomains, aliases and email accounts are permitted.
• The resource ceiling the account runs inside.
• Which feature set the account sees inside its panel.
• Whether the account has a dedicated address.

Attach it once and the account inherits all of it. Change the package later and the accounts on it move together.

Why hand-built accounts rot

The failure is gradual and it always looks the same. Account four needed a bigger quota, so someone raised it on that account only. Account eleven needed an extra database. Account nineteen was created during a hurry and nobody set a ceiling at all. Two years later a site misbehaves and the first question, "is this account configured like the others", takes an hour to answer instead of ten seconds.

Packages make that question trivial. Either the account is on a known package or it is not, and if it is not, that is your answer.

A three package baseline

1. Standard site. What most of your sites get: modest quota, one database, one address, the default ceiling. This should cover the large majority.
2. Busy site. Higher quota and a larger resource ceiling, for the handful that genuinely earn it.
3. Multi-site container. For accounts deliberately holding several small sites: more databases and subdomains, one shared ceiling.

Three is usually enough. The temptation to create a package per customer or per project defeats the purpose, because a package that applies to exactly one account is a hand-built account wearing a hat.

The one thing to decide deliberately

Whether a package assigns a dedicated address matters more than any other setting, because it decides how the site looks from outside rather than how it performs. An account created without one shares an address with whatever else is on it, and moving it later means a change that propagates through DNS.

Get this right at creation. On this platform every site can answer on its own non-consecutive address with private nameservers, and the cheapest moment to arrange that is before the site is live rather than after.

When you change a package

Editing a package affects the accounts using it, so treat it like any other change that touches many things at once:

• Know how many accounts are on the package before you save.
• Raise limits freely. Lowering them can put an account instantly over quota.
• If only one account needs a change, move it to a different package rather than editing the shared one.

That last habit is the whole discipline. The moment you edit a shared package for one account's benefit, the drift starts again.

Auditing what you already have

If your accounts predate this idea, you do not have to rebuild anything. List the accounts, group them by what they actually use, define packages that match those groups, and move accounts onto them. The limits do not change; they simply become named and repeatable.

The reference for each field is at docs.cpanel.net. For deciding which sites belong together in the first place, see Network Planning, and for what the resource ceiling actually governs, Platform and Limits.