A cPanel package is a named set of quotas — disk, bandwidth, email accounts, databases, addon domains — that you assign to hosting accounts so they all get the same allowances. Resellers create packages to carve their allocation into sellable plans, and the quotas are a model of hosting that predates how most applications are actually run today.
If you administer WHM or resell hosting, packages are the mechanism you work with daily. If you are reading a hosting plan that lists unlimited databases and 50GB of disk, you are reading a package. Either way, some of these quotas constrain you meaningfully, some are theatre, and the one that actually stops people is usually not listed.
Table of contents
- What a package is and where it lives
- The quotas, and what each actually limits
- Unlimited, and what really stops you
- Feature lists and the settings that matter
- Reseller packages, and pricing them
- Translating a package into a modern plan
- How this fits the rest of the stack
- FAQ
What a package is and where it lives
In WHM, a package is a saved set of resource limits. When you create a cPanel account you assign it a package, and the account inherits every limit from it. Change the package and every account on it changes.
That last property is the reason packages exist rather than setting limits per account. A reseller with sixty clients on a Starter package can adjust the disk quota once instead of sixty times.
Packages are found under WHM, Packages, Add a Package, and the same fields appear when creating an account. A reseller’s own allocation caps what their packages can offer — if the reseller has 100GB, they cannot create a package granting 200GB, though they can oversell if the parent host permits it.
Overselling is worth naming since it explains a lot about shared hosting. A reseller with 100GB may create fifty packages of 10GB each on the assumption that nobody uses their full allocation. This is normal and usually fine, and it is also why a plan advertising a large quota may behave as though the resource is contended — because it is.
The quotas, and what each actually limits
Disk quota. Total storage for the account, including the website files, email, databases, and logs. Email is the one that surprises people — a mailbox nobody empties can consume the whole quota and take the website down with it, because the account cannot write.
Monthly bandwidth. Data transferred out. Exceeding it typically suspends the account until the next cycle, which is a harsher failure than being billed for overage. Worth knowing which behaviour your host uses.
Addon domains, parked domains, subdomains. How many separate sites and aliases the account can host. An addon domain is a full separate site; a parked domain is an alias to an existing one.
Email accounts, forwarders, mailing lists. Straightforward counts.
Databases. How many MySQL or Postgres databases the account may create. Often advertised as unlimited, which brings us to the next section.
FTP accounts, and shell access as a yes-or-no.
CPU, memory, and process limits, applied through the server’s resource-limiting layer. These are the ones that actually determine performance, and they are the least prominent on any marketing page.
Unlimited, and what really stops you
Unlimited databases on shared hosting means the account may create as many as it likes on the one MySQL server that every account on the machine shares. The count is unlimited; the capacity is not. Fifty databases on a shared instance perform like fifty databases on a shared instance.
Unlimited disk and unlimited bandwidth are similar. There is a limit — it is in the acceptable use policy rather than the package, expressed as normal usage or something equivalent, and enforced by a human when you become noticeable.
The limit that genuinely stops people, and that is almost never advertised, is inodes. An inode is a filesystem entry, so one file or directory is one inode, and shared hosts cap them because filesystem metadata is a shared resource that backups and filesystem checks have to traverse.
A typical cap is between 100,000 and 500,000. That sounds enormous until you consider what consumes it: a WordPress install is tens of thousands of files, a node_modules directory can be a hundred thousand on its own, a cache directory can generate them without limit, and every email message is a file.
Hitting the inode limit means the account cannot create files, which presents as a site that suddenly cannot write uploads, cannot update, and cannot cache — while the disk usage graph shows plenty of space free. It is one of the more confusing failure modes in shared hosting and it is worth checking your inode usage before it happens:
# Count files under the account
find /home/username -type f | wc -l
# Filesystem inode usage
df -iFeature lists and the settings that matter
Alongside quotas, a package references a feature list controlling which cPanel tools the account can see — the file manager, phpMyAdmin, cron jobs, SSH, the backup tool, one-click installers.
Two entries are worth thinking about rather than accepting the default.
Shell access. Off by default on most shared packages, for good reasons around isolation. Turning it on is what allows WP-CLI, Composer, git, and any sane deployment process. A package without shell access forces file-manager-and-FTP workflows, which is a real constraint on anyone technical.
Cron jobs. Frequently allowed but with a minimum interval, which matters if the application expects a per-minute cron. WordPress in particular has an internal scheduler that is triggered by visitors rather than by real cron, and moving it to a real cron entry is a standard fix for scheduled tasks not running on quiet sites.
Also check the PHP version selector. A package that pins an old PHP version, or that does not allow per-account selection, is a problem the moment an application requires something newer.
Reseller packages, and pricing them
If you are reselling, the package is your product definition, and a few things make the difference between a profitable set of plans and a difficult one.
- Base the tiers on what clients actually differ in, which is usually traffic and number of sites rather than disk.
- Set inode limits explicitly and mention them, so a client hitting one has been told rather than surprised.
- Leave headroom in every quota. A client sitting at 98 percent generates a support ticket; one at 60 percent does not.
- Decide the bandwidth overage behaviour deliberately. Suspension protects the server and creates an emergency; overage billing is gentler and needs a cap.
- Include backups in the package or state plainly that they are not included. Ambiguity here becomes an argument at the worst possible time.
On pricing: the temptation is to compete on quota size, because that is what the comparison tables show. It is a poor position, because someone will always advertise a larger unlimited. Competing on support responsiveness, uptime, and whether a human answers is harder to copy and produces clients who stay.
Price against your real cost per account, including your time. A reseller plan divided by sixty clients is the infrastructure cost; the support hours are the rest, and they are what determines whether the business works.
Translating a package into a modern plan
The cPanel model measures disk, bandwidth, and object counts because it was designed when a website was files in a directory and the constraint was storage. Application hosting is measured differently, and the translation is worth understanding whether you are moving or just comparing.
Modern plans are priced on CPU and memory, because those determine whether an application responds under load. Storage and bandwidth are separate line items rather than the headline. The equivalences look roughly like this:
- Disk quota becomes storage attached to a service, sized to what you actually store rather than to a plan tier.
- Bandwidth becomes an included allowance with a per-gigabyte rate after — on RunxBuild static sites, 120GB included then $0.10 per GB.
- Addon domains become custom domains on a project, without a count.
- Databases become managed instances with their own plan and their own connection limit, rather than a count of databases on a shared server.
- Email accounts do not translate at all, because application platforms generally do not provide mail. That is a genuine gap when moving from cPanel and it is better to discover it now than mid-migration.
- CPU and memory limits become the plan itself — explicit rather than buried in a resource-limiting layer.
The email point is the one that catches people. cPanel bundles web and mail, and most application platforms do not. Moving means putting mail somewhere else — a dedicated mail provider — which is generally an improvement in reliability and is nonetheless a task nobody plans for.
Whether the shift is worth making depends on what you are running. A collection of small brochure sites is well served by the cPanel model and always has been. An application that needs a specific runtime version, a background worker, and a deploy pipeline is fighting the model rather than using it.
How this fits the rest of the stack
A cPanel package is a quota model designed around disk and object counts, and the quota that actually stops accounts — inodes — is usually the one nobody publishes. If you are reading a package to compare it with an application platform, the translation runs through CPU and memory rather than disk, and email is the piece that does not carry across. The RunxBuild hosting calculator prices services, managed databases, storage, and bandwidth separately, which makes the comparison against a bundled package straightforward once you know what is in the bundle.
Useful related references:
- cPanel Control Panel: What It Does, What It Costs, and When to Skip It
- npm list Global Packages: Seeing What You Installed and Cleaning It Up
- GitLab Packages API: Publishing Artifacts with curl and a Job Token
- Services on RunxBuild
FAQ
What is a cPanel package?
A saved set of resource limits in WHM — disk, bandwidth, email accounts, databases, addon domains, and CPU or memory caps — that you assign to hosting accounts so they all inherit the same allowances. Changing the package changes every account on it, which is why resellers use packages rather than setting limits per account.
What does unlimited databases actually mean on shared hosting?
That the account may create as many as it likes on the single database server shared with every other account on the machine. The count is unlimited; the capacity is shared and finite. The same applies to unlimited disk and bandwidth, where the real limit lives in the acceptable use policy rather than the package.
What are inodes and why do they matter?
An inode is a filesystem entry, so one file or directory is one inode. Shared hosts cap them, commonly between 100,000 and 500,000, because filesystem metadata is a shared resource. WordPress installs, node_modules, cache directories, and email messages consume them quickly. Hitting the cap means the account cannot create files while the disk graph still shows free space.
How do I set up reseller packages in WHM?
WHM, Packages, Add a Package, then define the quotas and attach a feature list. Base tiers on what clients actually differ in — traffic and number of sites more than disk — set inode limits explicitly and tell clients about them, and leave headroom so accounts are not sitting at 98 percent generating support tickets.
How does a cPanel package compare to a modern hosting plan?
cPanel measures disk, bandwidth, and object counts; application platforms are priced on CPU and memory, with storage and bandwidth as separate lines. Addon domains become custom domains without a count, and databases become managed instances with their own plan. Email is the piece that does not translate, since most application platforms do not provide mail.