Account Packages

Create and manage the hosting plans you assign to customer accounts.

Where to find it: Sign in as root, open Server > Configuration, then choose Account Packages.

Available to: Root and resellers. A reseller sees only delegated accounts and provider-approved packages or features.

What this page does

These pages convert product plans into enforceable policy: quotas, CPU/RAM/process controls, domains, mail, databases, FTP, shell access, feature visibility, and default settings.

Before you start

Plan changes can affect more than one account, while account defaults normally affect future account creation. Check the page's apply scope before assuming existing customers will change automatically.

Why use it — and when not to

Use Account Packages for policy that should be repeatable. A one-account exception belongs in the account workflow, and a changed reusable definition must not be assumed to have rewritten every existing account.

How to use it

1. Review the hosting plans already available.
2. Create a plan or open one to change its allowances and features.
3. Check how a plan change applies to accounts that already use it.

Resource ceilings and rollout to existing accounts

Account packages combine a feature profile with disk, CPU, memory, process, inode, I/O bandwidth/IOPS, domain, database, PostgreSQL database/user, mail, and FTP limits. Shell choices distinguish disabled login, normal Bash, and Jail Shell where supported. A dedicated-IP setting is separate from those resource limits.

Account-package resource ceilings use -1 for unlimited where indicated by the field; reseller capacity fields use 0 for unlimited. Do not copy one convention into the other. Finite quota/cgroup values require host support; unsupported capability is not fixed by raising the number.

Editing the reusable package and applying changes to existing assigned accounts are separate choices. Review Apply changes to existing accounts before saving a rollout. Partial API updates preserve omitted fields; they should not erase stored limits when a capability is temporarily unavailable.