# Editing an Account

> Change an account's limits, owner details and hosting package after it was created — including what happens when a new limit is smaller than what the account already uses.

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

---

An account is not fixed at the numbers it was sold. A customer upgrades, a plan changes,
an owner's email was mistyped. **Accounts → the account → Overview → Edit account**
changes all of it in one step.

What you can change:

| | |
|---|---|
| **Limits** | Disk quota, monthly bandwidth, mailboxes, MySQL databases, FTP accounts, domain aliases, addon domains, subdomains, applications |
| **Hosting package** | Apply a package (its limits become the account's), or detach from it |
| **Owner details** | Owner name, owner email, description |
| **PHP version** | Move the account onto another version installed on the server |

The primary domain is **not** editable — it is fixed for the life of the account.
Passwords are changed from the account's **Access** section, not here.

## A limit of 0 means unlimited

Everywhere in CorePanel, `0` is not "none" — it is "no limit". An account with
`0` mailboxes can create as many as it wants. This is the same convention used when
creating an account and when defining a [hosting package](https://www.corepanel.net/docs/accounts/hosting-packages).

> **Applications are the exception**
>
> The **Applications** limit reads the other way round: `0` means the account 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. The field says so underneath it in the editor.
>
> Accounts created before this rule carry `0` and therefore run no new applications; raising
> the number is all it takes. Applications already running are left alone — lowering the
> limit below them is refused like any other undersized limit.
Each field in the editor shows what the account currently uses underneath it, so you can
see the headroom you are giving or taking away before saving.

> **Unlimited still has a ceiling**
>
> Domains, subdomains, mail aliases, MySQL users and mailbox filter rules also carry a hard
> per-account ceiling that applies even at `0`. It sits far above anything a real account
> holds and exists to stop a scripted loop against the
> [client panel](https://www.corepanel.net/docs/client-panel#ceilings-under-your-package-limits) from filling the
> server. It is not a limit you set, and an account that reaches one is telling you something
> about that account.
## Limits below current usage are refused

You cannot set a limit below what the account already holds. An account with 12 mailboxes
does not accept a limit of 5, and the panel says so on the field itself as you type:

> The account already uses 12. Lowering the limit below that is not possible.

This is deliberate. The alternative would be for CorePanel to delete a customer's
mailboxes, databases or domains to make the account fit the new number, and no control
panel should ever do that quietly. Free the resources first, then lower the limit.

The refusal is enforced by the server, not just by the form: the whole edit is rejected
and **nothing** is written, so a form with one bad field never applies the other fields
halfway. The error names every resource that is in the way, not just the first one.

![The Edit account dialog: a hosting package selector, a PHP version selector set to PHP 8.4 with an amber warning that saving switches every site of the account straight away, and below them two limits below current usage — the disk quota outlined in red with an amber confirmation to apply 1024 MB anyway to an account already storing 1536 MB, and the mailbox field set to 5 against 12 mailboxes in use, refused outright and blocking the Save changes button](https://www.corepanel.net/_astro/account-edit-limits.CNi0gpZf.svg)

> **Counted against reality, not a stored number**
>
> When you open the editor, CorePanel counts what the account actually holds — mailboxes,
> databases, FTP accounts, aliases, addon domains, subdomains, applications — rather than
> trusting a stored counter. Saving also writes those counts back, so the figures shown in
> the panel are corrected as a side effect of any edit.
## The disk quota is the one exception

Disk space works differently, because the kernel accepts a user being over their limit:
that is what the quota grace period exists for. Lowering an account's disk quota below
what it currently stores is therefore possible — but only on purpose.

Type a quota smaller than current usage and the panel refuses it like any other limit,
plus a checkbox:

> **This quota is below the 1536 MB the account already stores.**
> Apply it anyway. The account goes over quota immediately: it can still be read, but not
> written to until it is back under the limit.

Use it for a real plan downgrade or right after a [migration](https://www.corepanel.net/docs/cpanel-import), and
tell the customer. Do not use it to "make room" in a hurry.

### What "over quota" actually does, and for how long

CorePanel does not write one limit per account but two, and the difference decides
whether the account keeps working:

| | |
|---|---|
| **Soft limit** | The quota you sold. This is the number shown everywhere in the panel. |
| **Hard limit** | Soft + 5 %, with a floor of 50 MB and never more than double the soft limit. |

Between the two, the account is over its allowance but **still writing**, for as long as
the grace period lasts. Past the hard limit, every write is refused **immediately** —
there is no grace period above it.

This matters for a forced downgrade, because that is usually the case you land in. An
account storing 1536 MB that you cap at 1024 MB has a hard limit of 1075 MB, so it is
already above it: writes stop the moment you save, not a week later.

**The grace period is 7 days by default, and CorePanel does not set it.** It belongs to
the filesystem's quota configuration, so the default is whatever ext4 or XFS ships —
7 days for both. Inspect or change it per filesystem on the server:

```bash
# ext4 — show and set the block grace period
setquota -t /home
setquota -t 604800 604800 /home     # 7 days, in seconds

# XFS
xfs_quota -x -c 'timer -u 7days' /home
```

When the grace period expires with the account still above the soft limit, the soft
limit starts behaving like a hard one: writes are refused from then on, exactly as if
the hard limit had been crossed.

Once writes are refused, the failures are spread out and rarely look like a disk
problem: uploads fail, PHP cannot write session files, cron jobs produce half-written
output, and mail to existing mailboxes bounces because Dovecot cannot deliver it.
Reading is unaffected — the site keeps serving and the existing mail is still there.

The account recovers by getting back under the soft limit: free up space and writes
resume, with the grace timer reset. Raising the quota again has the same effect.

What the quota counts in the first place, and how to find bytes an account cannot account
for, is in [Quotas and Usage](https://www.corepanel.net/docs/accounts/quotas).

> **There is no equivalent for counted resources**
>
> Forcing applies to the disk quota alone. No option, in the panel or the CLI, sets a
> mailbox or database limit below what the account holds. A disk quota can be exceeded and
> then walked back; a mailbox over its limit would have to be deleted, and CorePanel will
> not do that.
## Changing the PHP version

The **PHP version** field at the top of the editor lists the versions installed on this
server. Pick another one, save, and the account is on it — no new account, no backup
restore, no downtime.

Each version carries a badge saying how long PHP still supports it — **Supported**,
**Security fixes only** or **End of life** — so the choice is made with that in front of
you rather than after the fact. An end-of-life version can still be selected: an imported
account may need one. See
[How long each version is supported](https://www.corepanel.net/docs/php/how-php-runs#how-long-each-version-is-supported).

It is the one field in this form that is not a number CorePanel stores. Saving it changes
the running server:

1. The account's **php-fpm pool is written on the new version** and starts listening.
2. **Every site of the account is re-pointed** at the new pool, in a single reload.
3. The **pool on the old version is retired**, once nothing routes to it any more.

That order is the reason the sites keep serving throughout: no site is ever pointed at a
pool that does not exist yet, and the old pool only goes away after the last site has left
it. If any step fails, the account stays on the version it had and the rest of the edit is
refused with it — you retry the same form rather than discovering that the limits went
through and the version did not.

The switch covers the whole account, not just the web:

| | |
|---|---|
| **Every domain** | Primary, aliases, addon domains and subdomains — they share one pool |
| **Cron jobs** | A bare `php` in a [cron command](https://www.corepanel.net/docs/accounts/cron-jobs) resolves to the new version |
| **SSH** | The account's `php` on the command line follows too |
| **Webmail** | **Not** affected — Roundcube runs on its own version, whatever the account runs |

> **The interpreter moves, the code does not**
>
> CorePanel switches the version. It does not fix an application that the new version
> rejects — a site on a very old codebase can go from working to a 500 the moment you save.
> Two things are worth checking before you do it on a customer's account:
>
> - **Extensions are per version.** ionCube, imagick or anything else installed for PHP 8.2
>   is not there under 8.4 until you install that version's package too (see
>   [PHP extensions](https://www.corepanel.net/docs/php/extensions)).
> - **A downgrade is as risky as an upgrade.** Modern code on an older interpreter fails
>   just as loudly, and the older version may be the one missing security fixes.
>
> Move a customer with their agreement, and check their site right after saving.
Nothing about the customer's data changes: the same files, the same databases, the same
sessions on disk. Only the interpreter running them.

From the CLI:

```bash
corepanel account update 7 --php 8.4
```

A version the server does not have is refused, and the error names the ones that are
installed. Add a new version to the server with `dnf install` from the CorePanel PHP
stack — see [Server maintenance](https://www.corepanel.net/docs/maintenance).

## Applying a hosting package

Choosing a package in the editor re-applies it: **the package's limits become the
account's limits**, replacing whatever was there. The individual limit fields switch to
the package's values and are locked while it is selected, so you see exactly what is
about to be stored — including whether the package is too small for what the account
already holds, which is refused just like a hand-typed limit.

Choosing **No package (custom limits)** detaches the account from its package. Detaching
changes nothing about the account's limits — it only stops recording which package they
came from.

### Editing a limit by hand keeps the package

An account created from *Business* that you then edit by hand stays a *Business* account,
shown as **Business · customized**. CorePanel keeps the link on purpose:

- you still know which plan the account was sold on;
- re-selecting the package puts the account back on the standard limits in one step;
- the accounts list can still be read by plan.

If you want the account to stop claiming a plan, detach it explicitly.

> **Editing a package does not change existing accounts**
>
> The relationship works one way. Changing a package's limits does not push them to the
> accounts already created from it — see [Hosting Packages](https://www.corepanel.net/docs/accounts/hosting-packages).
> Apply the package again from this editor to bring one account back in line.
## Moving an account to another reseller

If this server hosts for [resellers](https://www.corepanel.net/docs/cli#corepanel-seller), an account can change
hands:

```bash
corepanel account transfer alice --to "Acme Hosting"
```

Ownership is the only thing that changes. Nothing on the server knows which reseller owns
an account — the Linux user, the home directory, the websites, the databases, the mail and
the certificates all belong to the *account* — so **no service is restarted and no site
goes down for a moment**. The account keeps its own limits, its own password and its own
suspension state.

Two things do change, and the command reports both:

- **The hosting package is cleared.** A package belongs to a reseller, and the account is
  leaving that catalog. Its limits are untouched — this is exactly what *No package (custom
  limits)* does above — so what is lost is the label, not the allowance. Put the account on
  one of the new owner's packages afterwards if you want it back on a plan.
- **Past notifications stay behind.** Alerts raised while the old reseller owned the
  account remain that reseller's, because they are a record of what happened, not a view of
  who owns what today.

This is what makes deleting a reseller safe. `corepanel seller delete` is refused while the
reseller still owns anything and there is no cascade, so cancelling a reseller contract can
never delete customer hosting accounts: you move the customers first, then remove the empty
organisation.

### Three transfers are refused

- **Into a reseller that has no room for it.** A transfer raises the destination's totals by
  exactly what creating an account does — one account, and the disk that account was
  assigned — so it is held to the same [ceilings](https://www.corepanel.net/docs/cli#what-the-two-ceilings-do).
  Raise the ceiling, or pick another destination.
- **Into a suspended reseller.** An organisation that is not trading must not take on
  customers: the account would serve normally under an owner whose staff cannot sign in to
  support it.
- **An account that is down *because* its reseller is suspended.** The record of which
  customers to put back lives on the reseller you would be moving it away from, so the new
  owner would inherit a customer they cannot bring back — carrying a reason that stops being
  true the moment it lands. Lift that one account first with `corepanel account unsuspend`,
  which is you deciding it comes back online, and then transfer it.

An account suspended in its **own** right moves normally and stays suspended, with its own
reason intact. That state is the customer's, not the reseller's.

## From the CLI

```bash
# Upgrade: more mailboxes and more disk
corepanel account update 7 --max-emails 100 --quota 20480

# Move the account onto a package, then override one of its limits
corepanel account update 7 --package 3 --max-subdomains 50

# Plan downgrade below what the account currently stores
corepanel account update 7 --quota 1024 --force
```

Only the flags you pass are changed; every other limit is left exactly as it is. Since
`0` means unlimited, **omitting a flag is not the same as passing it with `0`** — a limit
you do not mention is untouched, while `--max-emails 0` grants unlimited mailboxes.
`--max-apps` is the exception in both directions: `--max-apps 0` revokes the application
runtime, and `--max-apps 5` is the only way to grant it.

Resolve an account id with `corepanel account list`. The full flag list is in the
[CLI reference](https://www.corepanel.net/docs/cli).

## When a quota is stored but not enforced

If the server is not enforcing disk quotas yet, a new quota is still stored and the panel
warns that nothing is acting on it. The limit takes effect as soon as quotas are enabled
— you do not have to re-enter it. See [Resource limits](https://www.corepanel.net/docs/accounts#resource-limits).