# Hosting Packages

> Reusable plan templates — disk, bandwidth, mailboxes, databases, domains — applied to accounts at creation so every customer on the same plan gets the same limits.

Source: https://www.corepanel.net/docs/accounts/hosting-packages/
Last updated: 2026-09-07
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

A **hosting package** is a plan template: a named set of resource limits you define once
and apply to accounts when you create them. Instead of typing "5 GB, 20 mailboxes,
5 databases" for every new customer, you define a *Starter* package and select it.

Packages are what turn CorePanel from "a server with sites on it" into something you can
sell a plan from: the same package always produces the same account.

## What a package defines

| Limit | Unit |
|---|---|
| Disk quota | MB |
| Monthly bandwidth | MB |
| Email accounts | count |
| MySQL databases | count |
| FTP accounts | count |
| Domain aliases | count |
| Subdomains | count |
| Applications | count |

**`0` means unlimited** for every one of them — that is the convention across the whole
panel, not just here — **except Applications**, which reads the other way round.

> **Applications: `0` means *none***
>
> The Applications limit is the one field in CorePanel where `0` does not mean unlimited: it
> means the accounts on this package may not run [applications](https://www.corepanel.net/docs/applications) at all,
> and there is no value meaning unlimited. An application is a long-running program with its
> own memory and network namespace, so it is granted deliberately, by naming a number.
>
> A package you created before this field existed carries `0`, so it grants no applications.
> Edit the package and set the number you want to sell.
A package also has a **name** and an optional **description**, both for your own use in
the accounts list and the package catalog.

> **No PHP version in a package**
>
> Packages deliberately do not carry a PHP version. The PHP version is a property of the
> account: it is chosen when the account is created (defaulting to the highest installed on
> the server) and changed per account afterwards, so a package stays valid as PHP versions
> come and go on the platform — and re-applying a package never moves a customer's sites
> onto another interpreter behind your back.
## Creating a package

Go to **Hosting packages → New package**, fill in the name and the limits, and save. The
catalog lists every package with its limits, and packages can be edited or deleted at any
time.

## Applying a package to an account

In **Accounts → Add account**, pick the package from the *Hosting package* selector. The
manual limit fields disappear: the package's values are what the account gets.

> **Package limits win — including the zeros**
>
> When a package is selected, **all** of the account's limits come from it. A limit the
> package leaves at `0` makes that resource unlimited on the account, even if you had typed
> a number into the form before selecting the package. Review the package's values, not the
> form's.
>
> The same rule applied to Applications works the other way: a package with `0` applications
> takes the application runtime *away* from an account you apply it to. If the account is
> already running more applications than the package grants, the change is refused rather
> than applied.
Selecting no package (*No package — custom limits*) lets you type each limit for that one
account.

## Changing a package later

Editing a package changes the **template**, not the accounts already created from it.
Each account carries its own copy of the limits it was created with, so:

- editing a package affects only accounts created **after** the change;
- to change an existing account's limits, [edit the account itself](https://www.corepanel.net/docs/accounts/editing)
  from its **Overview** section;
- deleting a package does not touch any account created from it.

This is deliberate: a plan's definition changing should never silently re-provision live
customers.

To bring one account back onto the plan's current values, re-apply the package from the
account editor: its limits replace the account's. An account whose limits were edited by
hand stays on its package and is shown as **customized**, so you can always tell which
accounts have drifted from the plan they were sold on.

## Packages and resellers

Packages belong to a **seller**. Each seller manages their own catalog, which is what keeps
[reseller](https://www.corepanel.net/docs/resellers) plans separate on a shared server: a reseller cannot edit or
delete a plan that is not theirs. On a single-operator server everything belongs to the default seller and this
is invisible — you just have one catalog.

An account may be **placed on its own reseller's plans and on the server owner's**, in that
order. Both are real: a reseller writes plans of their own, and the server owner's catalog
is what everyone can sell from.

A migration from cPanel fills both. cPanel keeps one flat list of plans and encodes the
owner in the name — `acmehost_starter` is the reseller acmehost's `starter` — so the import
files each prefixed plan under the reseller it names, with the prefix removed. Plans whose
prefix names nobody stay with the server owner under the name they had.

A package reference does not survive a change of owner. Transferring an account to
another reseller clears it — the limits the account already has are untouched, but it is
no longer described by a plan its new owner does not have.

## A practical set of packages

A common starting point for a shared-hosting server:

| Package | Disk | Bandwidth | Mailboxes | Databases | Aliases | Subdomains |
|---|---|---|---|---|---|---|
| Starter | 5 000 | 50 000 | 10 | 2 | 2 | 5 |
| Business | 25 000 | 250 000 | 50 | 10 | 10 | 25 |
| Unlimited | 0 | 0 | 0 | 0 | 0 | 0 |

Set the disk quota to a number you can actually enforce — see
[Quotas and Usage](https://www.corepanel.net/docs/accounts/quotas).