A package is a template. It holds the limits an account is created with, and its only job is to stop you from typing the same fifteen numbers every time you add a customer.
In WHM, Packages → Add a Package. The fields are unremarkable. What is worth understanding is which of them actually bind, and what happens to accounts that already exist when you change one.
The limits that matter, and the ones that do not
Disk quota and monthly bandwidth are the two customers understand and the two that cause support tickets. Set them to numbers you can defend rather than round marketing figures.
Maximum addon domains, subdomains, parked domains. These decide whether one customer can host six businesses on a plan you priced for one. This is the field resellers most often leave open by accident.
Maximum email accounts, databases, FTP accounts. Rarely the constraint, occasionally the abuse vector.
Maximum hourly email. Worth a real number. An account compromised at three in the morning sends until something stops it, and this is the something.
What is not in the package is the processing allowance: entry processes, CPU, memory. Those come from the server's resource limits in place of the package, and they are usually what a busy site hits first.
Why unlimited is a trap
Setting disk to unlimited does not give the customer more space. The server has the space it has. What it removes is the only warning you would have received before one account consumed all of it.
With a quota, the account stops and one customer contacts you. Without one, the partition fills and every account on the server stops writing at the same moment, email rejected, uploads failing, databases refusing writes, for people who did nothing wrong.
Sell generous numbers if you like. Sell finite ones.
The feature list is the other half of the package
Each package points at a feature list, which decides what appears in the customer's cPanel. That is where you remove tools you do not want a shared-hosting customer using, and where you can quietly hide interfaces that only generate confusion on your plans.
Feature lists are managed separately and shared across packages. There is more on building them in WHM Feature Manager and feature lists.
Editing a package does not edit the accounts on it
This is the behaviour that surprises almost everyone.
A package supplies values at creation time. Change the package afterwards and accounts already created from it keep exactly the limits they were given. Nothing propagates.
To move existing accounts onto the new numbers, use Change Package on each account, or the account-modification screens. If you have twenty accounts on a plan you just resized, that is twenty deliberate actions: not an oversight in WHM, but a consequence of the fact that many of those accounts may have been adjusted individually since.
The practical habit: when you change a package, immediately decide whether existing accounts should follow, and do it in the same sitting. A package and its accounts drifting apart is how a customer ends up on limits nobody remembers setting.
Naming
Package names appear in WHM lists, in backups, and in transfers to other servers. Name them for what they contain (starter-10g, business-50g) rather than for the customer who first bought one. Plans outlive customers, and a package called johns-special is unreadable within a year.
Resellers get their own package namespace, prefixed with the reseller's username, so two resellers can both have a starter without colliding.
Before you create the first account
Decide the package first. Creating an account with the wrong one and fixing it later works, but the account's quota, feature list and domain limits all have to be corrected individually, which is exactly the work packages exist to avoid.
Creating multiple cPanel accounts at once walks through doing this in bulk once the package is settled, and the WHM account functions reference walks through the per-account screens.
Three objects that get confused
A package, a feature list and a privilege set are separate things in WHM, and treating them as one is the source of most surprises.
The package sets quantities: disk, bandwidth, how many databases, how many mailboxes. The feature list decides which icons the customer sees at all. The privileges apply to resellers rather than to accounts, and control what they may do to other people's accounts.
The practical consequence: raising a limit in a package does not reveal a tool the feature list hides, and hiding a tool in the feature list does not reduce what the account may consume. Two customers on the same package can see entirely different control panels. For the second of the three, see WHM Feature Manager and feature lists.
What the package does not control
Reading a package suggests it defines everything about the account. It does not, and the omissions are the ones customers complain about.
quota -s -u username ls /var/cpanel/users/username >/dev/null && grep -E 'MAXPOP|MAXSQL|BWLIMIT' /var/cpanel/users/username
Processor time, memory, concurrent processes and input/output rate are governed separately on servers that limit them at all: not by the package. An account can be well inside every package limit and still be throttled, which reads as "the site is slow and I have space left".
The inode allowance is the other frequent gap. A package with a generous disk quota and a low file allowance stops accepting files while showing plenty of free space, and the message the customer receives explains neither. There is more on what is enforced where in managing disk quotas and bandwidth in WHM.
Moving an account between packages
Changing an account's package applies the new limits immediately, and the direction matters.
Upgrading is uneventful: the ceilings rise and nothing else changes. Downgrading is not. An account already using more disk than the new package allows lands over quota the moment the change is applied, at which point it cannot write, receive mail, or in some configurations serve pages that need to write.
du -sh /home/username grep -c . /etc/userdatadomains
Read the current usage before downgrading rather than after, and where the account is above the new limit, deal with that first. The same applies to counts. An account with twelve databases moved to a package permitting five keeps all twelve and cannot create another, which is confusing rather than harmful. There is more on the customer-facing half in upgrading or downgrading client accounts.
Keep the list short enough to audit
Packages accumulate. A special arrangement for one customer becomes a package, and two years later nobody knows which are in use.
ls /var/cpanel/packages/ for p in /var/cpanel/packages/*; do n=$(basename "$p") printf '%-28s %s\n' "$n" "$(grep -l "PLAN=$n" /var/cpanel/users/* 2>/dev/null | wc -l)" done
That prints each package with the number of accounts on it. Packages with zero accounts are either retired or were never used, and both are worth removing. A short list is one somebody can reason about when choosing a plan for a new customer.
Where a package exists for exactly one customer, consider whether the exception is worth keeping. Bespoke limits set directly on an account are easier to justify than a package nobody else will ever be offered.
