Hosting Accounts

Everything CorePanel hosts belongs to an account. An account is one customer, one project or one site, and it owns everything that goes with it: a system user, a home directory, a primary domain, its DNS zone, its mailboxes, its databases, its certificates and its resource limits.

If you have used cPanel or Plesk, this is the same idea as a cPanel account or a Plesk subscription. All CorePanel editions use the same word — account — regardless of whether you host one site or four hundred.

account "example"
├── system user        example  (uid/gid of its own)
├── home               /home/example
│   ├── public_html    the primary domain's document root
│   └── domains        one directory per addon domain and subdomain
├── primary domain     example.com   ── DNS zone, mail identity, TLS certificate
├── secondary domains  aliases and addon domains
├── subdomains         blog.example.com, staging.example.com…
├── mailboxes          info@example.com, …
├── databases          example_shop, example_wp, …
├── cron jobs          run as the account's user
└── limits             disk, bandwidth, mailboxes, databases, domains

What creating an account actually does

Creating an account is a single operation in the panel, but on the server it provisions a full hosting environment:

Created	Detail
A Linux user	Its own uid/gid. Every file, PHP process and cron job of the account runs as this user, isolated from other accounts.
A home directory	/home/<user>, with public_html inside it as the primary domain’s document root and domains/ beside it for every addon domain and subdomain.
An FTP account	Same username, starting with the same password you set.
A web site	A vhost for example.com and www.example.com, served by CoreHttpd with its own PHP-FPM pool.
A DNS zone	example.com on CorePanel’s own PowerDNS, pointing at this server, with the nameservers configured for the server.
A mail identity	The domain can receive and send mail; a DKIM key pair is generated and published.
A TLS certificate	Issued automatically once the domain resolves to this server. See SSL/TLS Certificates.

The order matters for troubleshooting: the system side is provisioned first, and if any database step fails afterwards, CorePanel rolls the system side back. You never end up with a Linux user for an account that does not exist.

The parts of an account

System user and isolation

The Linux user is the isolation boundary. PHP runs in a per-account FPM pool as that user, cron jobs run as that user, uploaded files belong to that user. One account cannot read another account’s files.

The account’s PHP version is chosen when the account is created and is used by every site, subdomain and cron job it owns. When you do not pick one, CorePanel provisions the highest PHP version installed on the server.

Note

The PHP version is set at creation time. There is no in-panel switch to move an existing account to a different PHP version — plan the version when you create the account.

Primary domain

Every account has exactly one primary domain, given when the account is created. It owns public_html, it defines the account’s mail identity, and it cannot be deleted while the account exists (deleting the account is what removes it).

On top of it an account can have domain aliases, addon domains and subdomains — see Domains and Aliases and Subdomains.

Passwords

An account has two credentials that start out identical and then live separate lives:

• the account password (used to log in to the panel as that account), and
• the FTP password of its first FTP user.

Changing one does not change the other. Both can be updated at any time from the account’s Access section.

Account passwords must be at least 12 characters and contain lowercase, uppercase, digits and at least one special character. The panel’s generator produces a compliant one for you.

Resource limits

Every account carries a set of limits. 0 means unlimited — with a single exception, Applications, where 0 means none (see the table below).

Limit	Enforced on
Disk quota (MB)	The account’s uid, by the filesystem — see the note below
Monthly bandwidth (MB)	Traffic accounting
Email accounts	Mailbox creation
MySQL databases	Database creation
FTP accounts	FTP account creation
Domain aliases	Adding an alias
Addon domains	Adding an addon domain
Subdomains	Adding a subdomain
Applications	Creating an application — 0 here means none, not unlimited

Limits can be set one by one when you create the account, or inherited from a hosting package — a template that carries the whole set. When a package is selected, its values win over anything typed in the form.

They are not fixed afterwards: editing the account changes any of them, applies a different package, or detaches the account from the one it has. A limit below what the account already uses is refused, with the disk quota as the single (deliberate) exception.

Disk quotas need filesystem support

CorePanel stores the disk limit for every account regardless, but the kernel only refuses writes when quotas are actually enabled on the filesystem holding /home. On a server where they are not, the panel shows the limit and the measured usage, but nothing stops an account from exceeding it. The quota is enforced per uid, so it counts everything the account owns — not only what is inside the document roots.

The server-wide website limit

The limits above are per account. On top of them, the edition CorePanel is licensed for caps how many websites the whole server may host:

Edition	Websites
Personal (free)	20
Pro	Unlimited
Business	Unlimited

A website is a primary domain or an addon domain — the two kinds that have a document root and serve a site of their own. What does not count:

• Domain aliases (parked domains). They republish the primary domain’s document root, which is already counted. You can keep parking names at the cap.
• Subdomains. Same site, another name below it.

The count is per server, not per account: it is the total of every primary and addon domain across every account. It is deliberately counted by domain and not by account — one account can hold any number of addon domains, each an independent site, so counting accounts would make the limit meaningless.

Where you see it. In two places, both of which only appear on an edition that caps websites — on Pro and Business they are simply not there:

• The Dashboard carries a Websites card under the system metrics: usage, a bar and how many slots are available.
• Accounts, next to the New account button, shows a compact meter reading 12 / 20 websites.

Both turn amber for the last three slots and red when nothing is left. From the shell, corepanel edition websites prints the same figures — and exits 1 when the allowance is exhausted, so a provisioning script can check for room before it starts.

What happens at the cap. New account is disabled, and the addon type disappears from the Add domain dialog — parking a domain still works. The same wall applies from the CLI, from a cPanel import and from a backup restore: all of them refuse up front, before anything is provisioned, rather than leaving a half-created account behind. Deleting a website frees its slot immediately.

Where to manage accounts

Where	What you get
Accounts in the panel	The list of every account: primary domain, usage against quota, and per-account actions.
The account workspace	Opening an account gives you its own sections: Overview, Access, Account domains, Subdomains, SSL, Optimizations, Reverse proxy, Databases and Applications. Edit account, on Overview, changes its limits and owner details.
corepanel account …	The same operations from the command line — see the CLI reference.

Server-wide pages (Email accounts, DNS, WordPress, Cron jobs, Backups, WAF) work across every account and let you pick which one you are working on.

Next steps

• Creating and Deleting Accounts — the create form field by field
• Editing an Account — changing limits, package and owner details
• Hosting Packages — reusable limit templates
• Domains and Aliases — adding more domains to an account
• Files and FTP Access — the home directory layout and FTP
• Databases — MySQL databases, users and the built-in manager