Skip to content

cPanel hosting

CloudPress sells two quite different kinds of hosting from the same workspace. A managed WordPress site is a stack CloudPress builds and runs for you, one site at a time. A cPanel hosting account is a classic shared-hosting account on a cPanel server: CloudPress orders it, bills it, sizes it and lets you into it, and you run what's inside with cPanel's own tools.

That difference isn't a feature list — it's a division of labour, and it decides which product you should be on. This page explains where the line falls, why the dashboard knows some things about a cPanel account instantly and others only after a delay, and what a package actually caps.

The short version

  • A cPanel account lives on a cPanel hosting server, not in the container stack that runs a managed WordPress site.
  • CloudPress operates the account's outside: ordering, billing, package size, domains, password, access, and cancellation.
  • cPanel operates the account's inside: files, databases, mailboxes, cron, and whatever software you install.
  • Your workspace doesn't contain the account — it holds a link to it, and shows you a copy of what the cPanel side reports.
  • cPanel hosting is enabled per workspace, and there is no switch you can throw yourself.

Two products, two operating models

Both products are ordered through the same cart and invoiced as subscriptions, so the commercial half is identical. What differs is who is holding the wrench.

Managed WordPress site cPanel hosting account
Where it runs A group of containers CloudPress provisions per site An account on a cPanel hosting server
What CloudPress operates The whole runtime — WordPress, database, cache, file access, edge security The account's lifecycle: order, package, domains, password, access, suspension, deletion
What you operate Your site's content, plugins and themes Everything inside the account, through cPanel
Unit of purchase One site One account, holding one or more websites plus mailboxes within its caps
Day-to-day tooling The CloudPress dashboard The cPanel control panel

For what a managed WordPress site is made of, see The platform. For a feature-by-feature comparison of the two products, see cPanel hosting: overview.

Where the line actually falls

The dashboard's cPanel surface is deliberately small. It is the accounts list, the account's domains, its package, its password, its connection settings, and a one-click route into the control panel. That is the whole of it.

Everything else about a cPanel account is cPanel's job. Files, databases, mailboxes, cron jobs, redirects, the applications you install — none of them have a screen in the CloudPress dashboard, because the account is a cPanel account and cPanel already manages them. The site-level tooling you may have seen in a WordPress site's sidebar has no counterpart on a cPanel account either: those screens drive a runtime CloudPress operates, and this is not one.

The parts CloudPress does keep are the ones that touch money, identity or the address of your sites:

  • Ordering and provisioning. Buying a package creates the account on a hosting server, generates its username and an initial password, and links it to your workspace.
  • Billing. A cPanel account is a subscription like any other. It renews, it can be resized against the same subscription, and cancelling it credits the unused part of the term. Several accounts can share one billing bucket — see Billing.
  • Suspension for non-payment. An unpaid invoice suspends the account on the hosting server, and settling the invoice lifts the suspension again. While it's suspended, changing the package is refused.
  • Cancellation and the retention window. Deleting an account suspends it and schedules its removal rather than destroying it immediately. While it is scheduled for deletion the account is locked: its package can't be changed, its password can't be reset and its domains can't be added or removed until it is restored. See Deleting and recovering an account.
  • Domains and DNS. Adding a domain to the account is done from the dashboard or the API, and CloudPress also builds the DNS zone that points the name at the hosting server.
  • Access. The one-click sign-in and the cPanel password reset both run through CloudPress's own credentials for the hosting server, so no password is passed around to get you in.

Which one should you be on

The useful question isn't which product has more features — it's how much of the operating you want to do.

Choose a managed WordPress site when the thing you're running is a WordPress site and you'd rather not think about the machine under it. CloudPress runs the stack, and the dashboard gives you backups, caching, the CDN and Shield's edge security for that site.

Choose cPanel hosting when the account is the unit you want, not the site. One account holds its websites and its mailboxes under a single package and a single subscription; it will run PHP applications that aren't WordPress; and it gives you the familiar control panel to do it in. You don't need a WordPress site — or any site at all — to have one.

They aren't exclusive. A workspace with cPanel hosting enabled can hold managed WordPress sites and cPanel accounts side by side, and more than one of each.

This is the structural fact behind most of the page's remaining behaviour.

A managed WordPress site is CloudPress's own record from end to end. A cPanel account is not: the account itself belongs to the cPanel platform, which keeps its own records of usernames, packages, disk usage, domains and mailboxes. What your workspace holds is a link — a small record saying this cPanel username belongs to this workspace, plus the things CloudPress is responsible for: the subscription it bills against, the package you bought, and whether it has been scheduled for deletion.

So a cPanel account you can see in the dashboard is really two records read together, and each side answers different questions:

Held by CloudPress Held by the cPanel platform
Which workspace owns the account The account itself — username, package, server
The subscription and the package you paid for Disk used against quota
Deletion state and the removal date The account's domains and mailboxes
Suspension for an unpaid invoice Everything inside the account 
flowchart LR
    you([You])
    subgraph cp["CloudPress"]
        dash["Dashboard"]
        link["Account link<br/>ownership, subscription,<br/>package, deletion state"]
        copy[("Copy of the cPanel<br/>platform's records")]
    end
    subgraph ext["cPanel hosting server"]
        acct["Your cPanel account<br/>files, databases, mailboxes"]
        panel["cPanel control panel"]
    end
    you -->|manage the account| dash
    you -->|one-click sign-in| panel
    dash --- link
    dash -->|reads| copy
    copy -. refreshes .-> acct
    dash -->|order, resize, suspend, remove| acct
    panel --- acct

Two consequences are worth holding on to. Access follows the link, so a cPanel account is reachable from the workspace it is linked to — if an account you expect isn't in the list, the usual reason is that you're working in a different workspace, not that the account is gone. And a workspace can also carry an identity on the cPanel side: a customer key that is unique to it, so accounts recorded under that key can only ever belong to that one workspace. It is one of the two things that make a workspace a cPanel workspace at all — see Availability is decided per workspace.

Why some values in the dashboard lag reality

Because CloudPress reads most of a cPanel account's state from the cPanel side rather than owning it, the accounts list is served from a copy that refreshes on a short interval rather than by querying the hosting server on every page load. That keeps the list fast, and it's why timings differ depending on where a change was made:

  • Changes you make through CloudPress appear straight away. Ordering, resizing and deleting all refresh that copy as part of the action.
  • Changes you make inside cPanel take a few minutes. Nothing tells the dashboard you added an addon domain in the control panel, so the value stands until the copy next refreshes — up to about ten minutes for domain figures.
  • Some values never lag, because CloudPress owns them. The package shown on the account is the one recorded when you bought it, so a package change reads correctly the moment it is applied, even before the cPanel side has caught up.
  • Some screens skip the copy entirely. The account's Domains screen reads the account's domains from the hosting server as you open it, which is why a domain you added in cPanel shows there before it shows in the list.
  • When the cPanel side can't be read at all, the list says so rather than showing a half-built page — a temporary read failure affects every account in the list at once, and clears by itself.

If a figure looks stale right after you did something in cPanel — a mailbox you deleted, a domain you removed — give it a few minutes and reload before concluding the change didn't take.

What a package caps

A cPanel package isn't one pooled allowance. It sets three separate caps, and each is a hard limit in its own right:

Cap What it limits
Storage Total disk the account may use
Mail accounts How many mailboxes the account may hold
Websites How many sites the account may host — the main domain plus its add-on domains

The packages are named Mini, Basic, Pro and Max, smallest to largest — no cap gets smaller as you move up the range. What each tier actually includes is priced and published per workspace, so the package cards in the dashboard are the authority on the figures rather than anything written here.

Because the caps are separate, being well inside one buys you nothing on another, and reaching one doesn't touch the others. What happens at a cap depends on which side of the line enforces it:

  • Storage and mailboxes are enforced by the hosting server, since files and mailboxes are created inside cPanel. CloudPress reads the figures, shows disk used against quota, and uses the counts for the check below.
  • Website capacity is enforced in the dashboard as well. Adding an add-on domain or an alias past what the account's package allows is refused before the request is sent, and the counters mark that kind as full.
  • A downgrade is refused when the account doesn't fit the smaller package. Any of the three caps can block it, the reason is spelled out per package, and the same check runs again when you submit. An upgrade is never blocked this way — it can only make the caps bigger.

The hosting server is the final authority on limits

A package name doesn't always mean the same numbers. Accounts created under an earlier generation of packages can carry more generous limits than a current package of the same name, and a limit can also have been adjusted for an individual account. So the dashboard reads each account's own limits from the hosting server rather than assuming the catalogue figures, and where it can't read them it lets the server decide instead of blocking you. If the counters on the Domains screen don't match what a package card advertises, the counters are the ones describing your account.

To move a cap, change the package — see Resizing your cPanel package.

Where mail-only accounts fit

Some workspaces hold accounts that were sold as mail hosting rather than web hosting. The dashboard calls these MailXXL accounts, and they are a different kind of record on the cPanel side: they have no hosting package, so none of the website caps above apply to them.

They sit in the same list as hosting accounts and read the same way, and their rows offer most of the same actions — the sign-in button, the connection settings, the password change and deletion. Two things differ:

  • A plan change goes through support. Choosing Upgrade / Downgrade on a mail-only account opens a contact-support panel instead of the package cards, because there is no self-service package to move between.
  • There is no domain management action. The dashboard's Domains screen is part of the hosting-account surface, so a mail-only account doesn't offer it.

Mail-only accounts are not the same thing as CloudPress's own mailbox hosting, which is a separate product with its own screens in the workspace sidebar — see Ordering a Mailspace.

Availability is decided per workspace

cPanel hosting isn't a feature every workspace has, and unlike most of the dashboard it isn't switched on globally either. Two conditions have to hold before the cPanel Accounts item appears in the workspace sidebar: the platform has to have a cPanel connection configured at all, and your workspace has to be one that already has cPanel hosting.

That second condition is what makes cPanel different from the rest of the products documented here, and it follows directly from the link model above. A workspace qualifies because the cPanel side already knows it — either it carries the customer identity that identifies its accounts there, or it already has at least one cPanel account linked to it. There is nothing to derive from a plan or a role, and consequently nothing you can toggle in Settings: a workspace with no relationship to the cPanel platform has nothing to list and nothing to link a new account to.

The practical shape of it:

  • If the sidebar item isn't there, opening a cPanel URL directly returns you to the dashboard with "cPanel hosting is not available for this workspace." Nothing is broken — contact us if you want cPanel hosting added.
  • Once a workspace has an account, it stays enabled — including for the whole retention window after you delete your last one, so you can still restore or purge it.
  • The workspace also has to be on a paid plan. A trial workspace is sent to the plan-upgrade screen with "Activate a paid plan to use cPanel hosting."

What you can automate, and what you can't

The REST API covers the whole of CloudPress's half of the division of labour: listing accounts, viewing one, ordering, changing the package, cancelling, changing the cPanel password, purging a cancelled account, managing the account's domains, and minting a control-panel session. Reads and writes go through the same machinery the dashboard uses, so there is one provisioning, pricing and billing path rather than two that can drift apart.

One capability is still dashboard-only: restoring an account that is pending deletion. That isn't an oversight — recovery is a re-purchase. Deleting an account cancels its subscription outright, so bringing it back means building a cart for the package and settling a payment, which is a checkout flow rather than an API call. Everything else about the retention window, including purging early, is automatable.

Two things about the write endpoints follow from where the dashboard draws its own lines rather than from the API:

  • They can't be reached with an OAuth access token today. Every cPanel write — the money-moving ones and the newer password, purge, domain and session endpoints alike — accepts an API key or a signed-in dashboard session only, and refuses an OAuth token whatever scopes it carries. Reads are the exception, and work with the cpanel:read scope. Where the dashboard asks a human to re-confirm their identity, the API substitutes a first-class credential plus a role check on the workspace that owns the account: a token proves the caller is authorised, but it can't prove someone is at the keyboard.
  • They respect the same locks the dashboard does. A trial workspace is refused, and an account scheduled for deletion is locked against password and domain changes until it is restored.

Full parameters and error codes are on the cPanel Accounts API reference.