Hosting Packages

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 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.

SSH access a package gives

Under SSH access a package decides what its accounts can reach over SSH and SFTP from their first minute:

Control	What it does
Access level	The level a new account starts at: Off, SFTP only — what a new package starts at: file transfer, jailed to the home, no shell — or Shell, a jailed shell. Shell from the panel is listed as not available yet until the web terminal ships
Highest level allowed	The ceiling a reseller cannot raise one of these accounts above. It cannot be below the access level. Set it to Shell to sell a plan with SSH. A reseller’s own packages reach Shell only with its May give accounts an SSH shell privilege
Allow the account password over SFTP	On by default. The account can transfer files with its panel password, with no expiry, instead of needing a key first. Not applied when the access level is Shell
Shell resources	Shown when the ceiling is Shell: memory, CPU, tasks, open files, file size and concurrent logins for the account’s shell. Memory, CPU and tasks are one budget for its SSH sessions and cron jobs together; its PHP has its own limits. 0 means no limit. A new account copies them; change one account’s later in its SSH section

That last switch is on deliberately. The account already gets an FTP password the moment it is created, so refusing it an SFTP one does not withhold a credential — it sends the customer to the weaker protocol. SFTP goes over the same port as SSH, inside the jail, with the brute-force guard watching it.

Two things it never does:

• It does not give a shell. The password opens file transfer and nothing else. Moving an account to a shell level withdraws the grant, and the account needs an SSH key from then on.
• It does not reach accounts that already exist. Like every other value here it is copied when the account is created. Turning it on does not grant a password to anybody, and turning it off does not take one away — for that, revoke it on the account.

If SSH brute-force protection is off, the account is created without the password, whatever the package says: a password with nothing counting failed attempts is exactly what the guard exists to prevent. The account’s SSH section then shows it as keys-only, and you can grant the password once protection is on.

A reseller’s package can only grant what the reseller may grant. Without May allow SSH password login in its settings, accounts a reseller creates come out keys-only even from a package whose switch is on.

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 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 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.