# CorePanel CLI > Command-line reference for the corepanel CLI — service status, initial setup, admin listing, mail synchronization, and cron jobs. Source: https://www.corepanel.net/docs/cli/ Last updated: 2026-09-14 Part of the CorePanel documentation — https://www.corepanel.net/docs --- The `corepanel` command-line interface is the administrative tool for operating a CorePanel server from the shell. It talks directly to `corepanel-core` over a local Unix socket, so it is ideal for initial provisioning, automation, and troubleshooting — no browser required. > **Run as root** > > Most CLI commands operate on system-level state and connect to a privileged socket. Run > `corepanel` as `root` (or via `sudo`) unless a command explicitly states otherwise. ## Overview ```bash corepanel system init # provision a fresh server corepanel status # are the services up? corepanel account … # hosting accounts: create, update, import, back up, restore corepanel domain / subdomain … # domains, aliases and subdomains corepanel mail … # mailboxes, forwarders, antispam corepanel cron … # per-account cron jobs corepanel wp … # WordPress installations corepanel app … # application runtime corepanel quota … # disk quotas corepanel ssl … # commercial certificates corepanel firewall … # host firewall (firewalld) corepanel license / edition … # licensing and the edition in effect corepanel notifications … # what the server has been trying to tell you ``` Every group answers `--help`, and so does every command inside it. ## Naming an account Every command that acts on a hosting account takes it as ``, and accepts any of three spellings: | Spelling | Example | |----------|---------| | Linux username | `corepanel domain list acmecorp` | | Any domain the account owns — primary, alias or addon | `corepanel domain list example.com` | | Any subdomain of one of those | `corepanel domain list shop.example.com` | | Numeric account id (the legacy `dom-{id}` form works too) | `corepanel domain list 7` | Reach for the username. It is what appears in your billing system, in `/etc/passwd` and in a support ticket, so it is the name you already know — whereas the numeric id is an internal row number you would have to look up first. The id keeps working everywhere it ever did, so existing scripts need no change. > **Names are matched exactly** > > `acme` does **not** resolve to `acmecorp`. A partial name is an error, never a guess about > which customer was meant — deleting or suspending the wrong account is not something an > apology fixes. To search, use > [`corepanel account list --search`](#corepanel-account-list), which is a substring match > and a different job. > > Case is ignored, so `ACMECORP` and `acmecorp` are the same account. A reference that names no account fails with a non-zero exit status, and that includes ids: `corepanel domain list 999` reports that no account matches rather than printing an empty list, which would read like a real answer for an account that was never there. There is no ambiguity for CorePanel to resolve: a domain always contains a dot and a Linux username never can, and CorePanel never creates a username made only of digits — so a bare number is always an id. ## `corepanel ssl` Manages certificates bought from a commercial CA. Every site already gets a free certificate, issued and renewed automatically — this command group is for the case where the certificate has to come from somewhere else: an OV/EV certificate, a corporate CA, or an organisation's policy. ```bash corepanel ssl list [--json] corepanel ssl show [--json] corepanel ssl upload --cert FILE --key FILE [--chain FILE] corepanel ssl delete [--yes] ``` Three rules explain the whole group: - **An installed certificate is never replaced by a renewal.** It lives in its own store, which nothing automatic writes to, and is served ahead of the automatic certificate. - **Expiry degrades, it does not break.** A bought certificate does not renew itself, so the panel warns from 30 days out. If it lapses anyway, the site falls back to its automatic certificate and keeps serving valid TLS — under a different issuer, which is why the warning matters. - **Installing requires Pro or Business; listing, inspecting and removing do not.** A server whose licence lapsed is never stuck with a certificate it cannot manage. ### `corepanel ssl list` Lists every commercial certificate on the server with its issuer, expiry date and time remaining. The **exit status is 1 when at least one certificate is inside its 30-day warning window or already expired**, so it can be watched from monitoring without parsing the output. A server with no commercial certificates is not a problem: the list is empty and the status stays 0. ### `corepanel ssl show` Shows one host's certificate: subject, issuer, the names it covers, its validity window, the chain length and the SHA-256 fingerprint. The private key is never shown. ### `corepanel ssl upload` Installs a certificate. The material is read from **files**, not arguments: a private key on a command line ends up in the shell history and is visible to every user on the box through the process list. `--chain` is optional — some CAs append the intermediate to the certificate itself, others mail it separately. The upload is refused when: | Refusal | Why it matters | |---------|----------------| | The chain does not reach a trusted CA | The failure that works in the browser you test with (it cached the issuer elsewhere) and breaks on Android and `curl` | | The key does not match the certificate | Would take TLS down on the next handshake | | The certificate does not cover the host | Name mismatch in every browser | | Expired, or not yet valid | Cannot secure anything | | Self-signed | A trust error for every visitor | Nothing is written unless every check passes, so a rejected upload leaves the site exactly as it was. Installing over an existing certificate is how a renewal is applied. ### `corepanel ssl delete` Removes a host's certificate and its private key, returning the host to the automatic certificate from the next connection on. This is also the way back if an installed certificate turns out to be wrong. Because the key is deleted, the command asks for confirmation; a non-interactive run must pass `--yes`. ```bash # Monitoring: alert before a certificate runs out corepanel ssl list >/dev/null || echo "a certificate needs attention" # Install a certificate whose CA sent the bundle separately corepanel ssl upload example.com \ --cert /root/example.com.crt \ --key /root/example.com.key \ --chain /root/example.com.ca-bundle # Apply a renewal: same command, new files corepanel ssl upload example.com --cert new.crt --key new.key --chain new.ca-bundle # Scripting: days left on every certificate corepanel ssl list --json | jq -r '.[] | "\(.host) \(.daysRemaining)"' # Go back to the automatic certificate corepanel ssl delete example.com --yes ``` bash corepanel [command] [subcommand] [flags] ``` | Command | Description | |---------|-------------| | `corepanel system init` | Interactive wizard to initialize a fresh server | | `corepanel status` | Show the status of all CorePanel services | | `corepanel quota` | Enable disk quotas, inspect state and usage, and set per-account limits | | `corepanel account list` | List hosting accounts with their ids, usernames and domains | | `corepanel account create` | Create a new hosting account and its primary domain | | `corepanel account update` | Change an account's limits, owner details, hosting package or PHP version | | `corepanel account suspend` / `unsuspend` | Suspend a hosting account across every plane, and lift it again | | `corepanel account transfer` | Move a hosting account to another reseller | | `corepanel account panel` | Show or change whether an account may sign in to the client panel | | `corepanel account import` | Import a cPanel account (or preview with `--dry-run`) | | `corepanel account backup` | Create a full local backup of a hosting account | | `corepanel account restore` | Restore a hosting account from a cpbackup archive | | `corepanel account backup-schedule` | Manage recurring backup schedules and retention | | `corepanel domain` | List, add and remove an account's secondary (alias/addon) domains | | `corepanel subdomain` | List, add, tune and remove an account's subdomains | | `corepanel app` | Run and publish an account's persistent applications | | `corepanel cron` | Manage an account's cron jobs | | `corepanel wp` | Install, update, harden and roll back WordPress sites | | `corepanel seller` | Create, edit, suspend and delete the resellers this server hosts for | | `corepanel admin` | Create, list and delete the people who sign in to the panel | | `corepanel mail sync` | Resynchronize the Postfix lookup database | | `corepanel mail list` | List the mailboxes of a domain | | `corepanel mail delete` | Delete a mailbox and its Maildir | | `corepanel mail quota` | Set a mailbox storage quota | | `corepanel mail suspend` / `activate` | Suspend or reactivate a mailbox | | `corepanel mail forwarder` | Manage mail forwarders (aliases) | | `corepanel mail catchall` | Manage a domain catch-all | | `corepanel mail redirect` | Redirect all mail for a domain to another domain | | `corepanel mail vacation` | Manage a mailbox vacation autoresponder | | `corepanel mail filter` | Manage mailbox Sieve filter rules | | `corepanel mail spam` | Manage spam thresholds and allow/deny lists | | `corepanel mail deliverability` | Check whether mail leaving this server is accepted | | `corepanel edition websites` | Show how many websites the edition allows and how many are in use | | `corepanel license` | Buy, activate, inspect, refresh or release this server’s license | | `corepanel telemetry` | Turn this server’s daily check-in on or off | | `corepanel ssl` | Install and manage certificates bought from a commercial CA | | `corepanel version` | Print the CLI build version | Run `corepanel [command] --help` at any time to see the available subcommands and flags. ## `corepanel system init` Interactive wizard that initializes a fresh CorePanel server. It detects the server identity, sets the panel domain (the FQDN used to access CorePanel), validates DNS, sets the administrator identity, and generates (or reuses) the administrator password. ```bash corepanel system init ``` The wizard walks through six steps: detecting the public IP, prompting for the panel domain, checking DNS resolution against the server IP (advisory, non-blocking), prompting for the admin email, preparing the admin password, and applying the configuration. The panel domain is a DNS name pointing at the server — not the machine's OS hostname, which is only offered as the default when it happens to be a fully qualified domain name. ### The panel domain is optional You do not need a domain to finish the setup. Leave the prompt blank — or run unattended on a server whose hostname is not an FQDN, which is what cloud images and provisioning systems give you (`almalinux-2gb-nyc1-01`) — and CorePanel is served on `https://` with a self-signed certificate. The panel then asks for the domain on first login, together with the nameservers. Set it whenever you are ready, from the panel or by re-running this command with `--domain`. Once the name resolves to this server, a trusted certificate is issued automatically. A domain passed explicitly with `--domain` is still validated: a value that is not an FQDN is an error, not a silent fallback to the IP. Nameservers and company details are **not** asked here. The panel's initial configuration wizard collects them on first login and keeps opening until they are set — see [Initial Server Setup](https://www.corepanel.net/docs/initial-setup). ### Flags | Flag | Description | |------|-------------| | `--domain ` | Panel domain — the FQDN used to access CorePanel (e.g. `panel.example.com`). Optional; without it the panel is served on the server's IP | | `--admin-name ` | Administrator display name (default `Administrator`) | | `--admin-email ` | Administrator email for notifications and Let's Encrypt | | `--admin-password ` | Administrator password (generated if omitted) | | `--no-interactive` | Skip all prompts; use flags and defaults for scripted provisioning | `--hostname ` is retained as a **deprecated alias** for `--domain`. ### Non-interactive provisioning For automated installs, pass the values as flags and disable prompts: ```bash corepanel system init \ --domain panel.example.com \ --admin-email admin@example.com \ --no-interactive ``` When there is no domain yet — a cloud image, a marketplace image, a CI run — omit `--domain` entirely and the install still completes: ```bash corepanel system init \ --admin-email admin@example.com \ --no-interactive ``` When `--admin-password` is omitted, a strong 16-character password is generated and stored at `/root/.corepanel_password` (mode `0600`). If that file already contains a password, it is reused instead of generating a new one. > **Full walkthrough** > > See the [Initial Server Setup](https://www.corepanel.net/docs/initial-setup) guide for an annotated, step-by-step run of > the interactive wizard. ## `corepanel status` Displays the status of all CorePanel services — `corepanel-api`, `corepanel-auth`, `corepanel-core`, and `corepanel-sys` — in a table. For each service it shows the systemd active state, the detailed sub-state (running, exited, failed, …), and the availability of its sockets. ```bash corepanel status ``` ``` +----------------+--------+---------+---------------------------------+ | Service | Active | Status | Sockets | +----------------+--------+---------+---------------------------------+ | corepanel-api | active | running | ● 127.0.0.1:16087 | | corepanel-auth | active | running | ● corepanel-ftp-auth.sock | | | | | ● corepanel-mail-auth.sock | | | | | ● ftp-getcert.sock | | corepanel-core | active | running | ● corepanel-core.sock | | corepanel-sys | active | running | ● corepanel-sys.sock | +----------------+--------+---------+---------------------------------+ ``` Socket indicators: `●` means the socket (or TCP port) is available, `○` means it is unavailable. Use this command as a first check when the panel or a subsystem is not responding. ## `corepanel quota` Manages disk quotas: the server's quota state, what each account is using, and the per-account limits. Usage is measured by the kernel's per-uid quota accounting, so these commands always report the state of that accounting alongside the figures. With accounting off there is nothing to measure, and a usage of zero would read as an empty account rather than as "not measured". Limits are stored either way and take effect when quotas are enabled. ### `corepanel quota enable` Turns disk quotas on for this server: enables the kernel's per-account accounting **and enforcement**, applies every account's stored limit, and measures what each one is using. Until this is run, CorePanel stores the quota an account was sold but nothing measures or enforces it. Quota accounting is a property of how the filesystem was **mounted**, which is why enabling it is a deliberate act and never something a package upgrade does on its own. What the command can finish depends on the filesystem: | Filesystem | What happens | Reboot | |---|---|---| | ext2/3/4 | the option is added to `/etc/fstab` and the filesystem is remounted | no | | XFS, separate `/home` | unmounted and mounted again, when nothing holds it open | only if busy | | XFS on `/` | configured on the kernel command line with `grubby` | **yes** | The output distinguishes *configured* from *active*. On a root XFS — the usual server layout — nothing is measured or limited until the machine reboots, and the command says so instead of reporting success. ```bash corepanel quota enable [--json] ``` ``` Disk quotas are CONFIGURED but NOT yet active — this server must be rebooted. disk quotas are configured on the kernel command line and start at the next reboot Configured in: the kernel command line (grubby) grubby --update-kernel=ALL --args=rootflags=uquota Usage figures stay unavailable and no limit is enforced until this server reboots. ``` > **An account already over its limit is not cut off** > > Enabling quotas on a populated server does not break the accounts that turn out to be too > big. The kernel's hard limit sits above the quota, so such an account goes over its stated > size — and is warned — before any write is refused. They are listed at the end of the > command's output, and `corepanel quota list` shows them at any time. ### `corepanel quota status` Shows the quota state of the filesystem backing the account home directories. The three layers are reported separately because they fail separately: - **Accounting** — is the kernel counting bytes per account at all. - **Enforcement** — is it refusing writes past a limit. - **Reboot required** — quotas are configured but the filesystem has not been mounted with them yet. On a root filesystem this is the normal state between enabling quotas and restarting the server. ```bash corepanel quota status [--json] ``` ``` Disk quotas: ACTIVE (accounting + enforcement) Filesystem : /dev/sda4 on / (xfs) Separate /home : no Accounting : on Enforcement : on App data counted: yes ``` `App data counted` reports whether `/var/opt/userapps` shares the quota filesystem. When `/home` is a **separate partition** it does not, and application data is therefore excluded from every usage figure — the tidier-looking layout is the one that measures less. ### `corepanel quota list` Lists per-account disk usage, largest first. Disk and database sizes are shown in separate columns and are deliberately **not** added together: only the disk figure is accounted by the kernel and enforced against, because the MySQL data directory belongs to the `mysql` user and no per-uid quota can see it. ```bash corepanel quota list [--search ] [--json] ``` When quotas are inactive the command prints a warning *before* the table: the figures are then whatever was last measured, not current usage. ### `corepanel quota inspect` Shows **where** an account's disk usage is, not just how much it is. ```bash corepanel quota inspect [--deep] [--json] ``` A disk quota counts every file the account's Linux user owns on the filesystem — not the contents of its home directory. Usually those are the same thing. When they are not, the account sees a figure it cannot explain and cannot reduce, because the files are somewhere it cannot even list. Some of that is **by design**, and the report says so: | Location | What is there | |----------|---------------| | `/opt/userapps/` | A published application's program and releases. **Root** owns the code — deliberately out of reach of the account's own FTP, so it cannot replace the binary systemd is executing — so this normally contributes nothing to the quota; it is checked because anything account-owned that lands here would | | `/var/opt/userapps/` | That application's data, which the account owns and survives every deploy | | `/var/spool/cron/` | The account's crontab | | `/var/spool/mail/` | The system mail spool | | `/tmp`, `/var/tmp` | **Not** by design: files left there still count against the quota | The full picture of what a quota counts is in [Quotas and Usage](https://www.corepanel.net/docs/accounts/quotas). The rest is the reason this command exists: files that ended up owned by an account by accident. The account cannot delete them, so a quota applied on top of them puts it permanently over its limit with nothing it can do. Anything the scan cannot place is reported as unexplained. `--deep` sweeps the entire filesystem to locate it and groups the results by directory. That takes minutes on a busy server, which is why it is not the default. ``` Disk usage of example.com (user example, uid 1007) Counted by the kernel : 1.2 GiB Inside the home : 840.0 MiB (/home/example) Outside the home : 384.0 MiB +----------------------------+-----------+-------+-----------+---------------------------+ | LOCATION | SIZE | ENTRIES | BY DESIGN | WHAT IT IS | +----------------------------+-----------+-------+-----------+---------------------------+ | /home/example | 840.0 MiB | 9214 | yes | home directory | | /opt/userapps/example | 320.0 MiB | 412 | yes | published application ... | | /var/opt/userapps/example | 64.0 MiB | 88 | yes | application data ... | +----------------------------+-----------+-------+-----------+---------------------------+ ``` ### `corepanel quota set` Sets an account's disk quota in MB. A quota of `0` removes the limit. ```bash corepanel quota set ``` ```bash # 20 GB for account 12, and no limit at all for dom-7 corepanel quota set 12 20480 corepanel quota set dom-7 0 ``` The kernel gets a **hard limit slightly above the quota** — 5 %, at least 50 MB, never more than double it. That margin is the grace window, and it is not generosity: at exactly 100 % the failures are indirect and ugly. PHP cannot write its session files, Dovecot cannot deliver and mail bounces, cron jobs fail half-way. The account goes over its stated quota, and is warned, before writes are refused. If the account is already above the new quota, the command says so — its grace period starts immediately. On a server where quotas are not active the limit is still stored, and applies as soon as they are enabled. ### `corepanel quota apply` Pushes every account's stored quota to the kernel and reports which accounts are already over theirs. ```bash corepanel quota apply [--dry-run] ``` This is what a server needs when its accounts **predate** disk quotas: the limits are in CorePanel's database, but the kernel has never been told about them. It is also the repair path for a limit whose push failed when the account was created. Run `--dry-run` first. Before enforcement is switched on, the number that matters is how many accounts are *already* over their limit — those are exactly the ones whose writes will start failing. ### `corepanel quota refresh` Forces an immediate refresh of the stored usage instead of waiting for the hourly job. ```bash corepanel quota refresh ``` When quotas are inactive nothing is measured and the stored figures are left untouched. They are never zeroed — "cannot measure" must not be recorded as "uses nothing". ## `corepanel account list` Lists hosting accounts with their **id, username and primary domain**. Any of the three works as the `` argument of every other command (see [Naming an account](#naming-an-account)), so this is a way to browse the server rather than a step you have to run before doing anything else. ```bash corepanel account list ``` ### Flags | Flag | Description | |------|-------------| | `--search ` | Filter accounts (case-insensitive substring over the names an account is reachable by: username, primary domain, addon domains and subdomains) | | `--json` | Output the account list as JSON for scripting | The default table lists ID, Domain, User, Seller, Email (used/limit), DBs (used/limit), Quota MB (used/limit), and Package; a limit of `∞` means unlimited. The command pages through core transparently, so every matching account is returned in one call. ### Examples ```bash # List every hosting account corepanel account list # Find an account when you only remember part of the name corepanel account list --search example # Scripting: extract the account id for a domain corepanel account list --search example.com --json | jq '.[0].accountId' ``` ## `corepanel account create` Creates a new hosting account together with its primary domain. The domain is passed as a positional argument; core provisions the Linux user, web vhost, DNS, and mail records. ```bash corepanel account create example.com ``` ### Password handling The account password can be supplied in three ways, listed from most to least secure: 1. **`--password-stdin`** — read the password from standard input. Best for automation, since the secret never appears in the shell history or the process list. 2. **Interactive prompt** — when no password flag is given and the session is attached to a terminal, the CLI prompts for the password with hidden input. 3. **`--password `** — pass it directly. Convenient but visible in the shell history and in `ps`. The password must meet core's strength requirements: at least 12 characters including lower-case, upper-case, a digit and a special character. ### Flags | Flag | Description | |------|-------------| | `--password ` | Account password (prefer `--password-stdin` or the prompt) | | `--password-stdin` | Read the account password from standard input | | `--username ` | Linux username for the account. Defaults to a name derived from the domain. Lowercase letters and digits only, not starting with a digit, at most 16 characters; a name already taken by an account, an administrator or a system user is refused | | `--owner-name ` | Owner full name | | `--owner-email ` | Owner email address | | `--description ` | Free-form account description | | `--quota ` | Disk quota in MB (`0` = unlimited) | | `--max-emails ` | Maximum number of mailboxes (`0` = unlimited) | | `--max-databases ` | Maximum number of MySQL databases (`0` = unlimited) | | `--max-ftp ` | Maximum number of FTP accounts (`0` = unlimited) | | `--max-apps ` | Applications the account may run. **`0` = none**, not unlimited, and there is no unlimited value — an account created without this flag cannot run [applications](https://www.corepanel.net/docs/applications) | | `--plan ` | Hosting plan name to associate with the account | | `--php ` | PHP version to provision (e.g. `8.3`). Defaults to the highest version installed on the server. | > **Default PHP version** > > When `--php` is omitted, core provisions the account with the **highest PHP version installed** > on the server. Pass `--php ` to pin a specific one. ```bash # Interactive password prompt, default (highest) PHP version corepanel account create example.com # Scripted: read the password from stdin, pin PHP 8.3 and a 5 GB quota printf '%s' "$ACCOUNT_PASSWORD" | \ corepanel account create example.com --password-stdin --php 8.3 --quota 5120 ``` On success the command prints the account ID, Linux username, domain, and home directory. ## `corepanel account update` Changes an existing account's limits, owner details, hosting package or PHP version (`core.UpdateAccount`). The account is passed as a positional argument — its username, any domain it owns, or the numeric id from `corepanel account list`; the `dom-` form is accepted too. ```bash corepanel account update [flags] ``` **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. ### Flags | Flag | Description | |------|-------------| | `--owner-name ` | Owner full name | | `--owner-email ` | Owner email address | | `--description ` | Free-form account description | | `--quota ` | Disk quota in MB (`0` = unlimited) | | `--max-bandwidth ` | Monthly bandwidth allowance in MB (`0` = unlimited) | | `--max-emails ` | Maximum number of mailboxes (`0` = unlimited) | | `--max-databases ` | Maximum number of MySQL databases (`0` = unlimited) | | `--max-ftp ` | Maximum number of FTP accounts (`0` = unlimited) | | `--max-aliases ` | Maximum number of domain aliases (`0` = unlimited) | | `--max-subdomains ` | Maximum number of subdomains (`0` = unlimited) | | `--max-addon ` | Maximum number of addon domains (`0` = unlimited) | | `--max-apps ` | Applications the account may run. **`0` = none**, not unlimited — the one limit that reads the other way round. Lowering it below the applications already running is refused | | `--package ` | Apply a hosting package; its limits become the account's. Any limit flag given alongside it still wins. `0` detaches the account without changing a limit. | | `--php ` | Move the account to another **installed** PHP version (e.g. `8.3`). Not a limit — see below | | `--force` | Allow a disk quota below current usage, leaving the account over quota | | `--keep-mail` | Keep **receiving** mail while the account is suspended — on by default; `--keep-mail=false` bounces instead (sending is cut either way) | > **A limit below current usage is refused** > > The command fails and names every resource in the way > (`maxEmails: 5 requested, 12 already in use`), and **nothing** is written. CorePanel will > not delete a customer's mailboxes or databases to make an account fit a smaller number. > > The disk quota is the only exception, and only with `--force`: the account is then over > quota — readable, but writes are refused as soon as it crosses the hard limit (the sold > quota plus 5 %), which a real downgrade does immediately. Below that, it keeps writing > until the filesystem's grace period runs out — 7 days by default. See > [Editing an Account](https://www.corepanel.net/docs/accounts/editing) for what that means in practice. > **`--php` changes the running server, not a stored number** > > It rewrites the account's php-fpm pool on the new version, re-points every one of its > sites in a single reload, and retires the old pool once nothing uses it — so the sites > keep serving throughout. It also moves the `php` the account's cron jobs and SSH sessions > resolve; webmail keeps its own version. > > Applied **before** everything else in the request: a version this server does not have > refuses the whole edit (the error names the versions that are installed) rather than > leaving the limits stored and the version unchanged. Extensions are per version and do not > follow — see [Changing the PHP version](https://www.corepanel.net/docs/accounts/editing#changing-the-php-version). ```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 # Move a customer off an end-of-life PHP release corepanel account update 7 --php 8.4 ``` An account created from a package stays linked to it after a manual edit and is reported as customized — see [Editing an Account](https://www.corepanel.net/docs/accounts/editing). ## `corepanel account suspend` / `corepanel account unsuspend` Suspends a hosting account across every plane it touches, and lifts it again (`core.SuspendAccount` / `core.UnsuspendAccount`). ``` corepanel account suspend [--reason ] corepanel account unsuspend ``` `` is the username, any domain the account owns, or the numeric id. A name that matches more than one account is refused rather than guessed. | Plane | While suspended | |---|---| | Websites | Every domain of the account serves a **403** suspension page | | Applications | Stopped; ones already stopped by their owner stay stopped | | Cron | Jobs stop running, definitions untouched | | FTP | Login refused | | Mail — sending | Rejected at `MAIL FROM` with `550` | | Mail — receiving | Rejected with `550` unless the account keeps its mail | | Mail — reading | Works normally, webmail included | | Data | Untouched — nothing is deleted | Flags: | Flag | Meaning | |---|---| | `--reason ` | Recorded for the operator and shown in the panel. Never published: the suspension page says nothing about why | `suspend` requires **CorePanel Business**. `unsuspend` is **not** gated on any edition, so a licence that lapses while an account is suspended can never leave a customer's sites dark with no way back. ``` # Suspend by domain, with a note for your own record corepanel account suspend example.com --reason "invoice 4471 unpaid" # Lift it again by account id corepanel account unsuspend 7 ``` `corepanel account list` shows a `Status` column, and `--json` carries `suspended`, `suspendedAt` and `suspendReason`. See [Suspending an Account](https://www.corepanel.net/docs/accounts/suspension) for why a suspended customer can still read their mail. ## `corepanel account transfer` Moves a hosting account to another reseller (`core.TransferAccount`). ``` corepanel account transfer --to ``` `` is the username, any domain the account owns, or the numeric id; `` is a seller id or name. Ownership is the only thing that changes — nothing on the server knows which reseller owns an account, so no service is restarted and no site goes down. The account keeps its own limits, its own password and its own suspension state. | Flag | Meaning | |---|---| | `--to ` | The reseller that will own the account, by id or name (**required**) | Two things move with it, and the command reports both: - the account's **hosting package is cleared**, because a package belongs to a reseller and the account is leaving that catalog. Limits are untouched — put the account on one of the new owner's packages with `corepanel account update --package `; - past **notifications stay** with the reseller that owned the account when they happened. Refused when the destination reseller is suspended, and when the account is currently down *because its own reseller is suspended* — lift that account first with `corepanel account unsuspend`, which is you deciding it comes back online. An account suspended in its own right moves normally and stays suspended. ``` # Hand a customer to another reseller corepanel account transfer alice --to "Acme Hosting" # Take a reseller's customers over before removing the organisation corepanel account transfer example.com --to 1 corepanel seller delete "Acme Hosting" ``` See [Editing an Account](https://www.corepanel.net/docs/accounts/editing) for the whole picture. ## `corepanel account panel` Shows or changes whether a hosting account may sign in to the [**client panel**](https://www.corepanel.net/docs/client-panel) (`core.GetAccountPanelAccess` / `core.SetAccountPanelAccess`). ``` corepanel account panel status corepanel account panel enable corepanel account panel disable ``` `` is the username, any domain the account owns, or the numeric id. There is no panel user to create and no panel password to set. The account signs in with the username and password it already has — the same ones that open FTP and SSH. These commands only decide whether that credential also opens the panel. To change the password itself, use the account's password controls; there is one place to do it, not two. `status` prints four separate things, because "my customer cannot log in" is usually not the flag: | Line | What it means | |---|---| | `panel access` | This account's flag — what `enable` and `disable` set | | `licence` | Whether the client panel exists on this server at all (**CorePanel Business**) | | `suspended` | A suspended account is refused, with its own message | | `password` | An imported or weak credential must be changed before anything else | | `can sign in` | The four above, resolved in the order the server enforces them | ``` $ corepanel account panel status example.com account: acmecorp (example.com) (id 7) panel access: enabled licence: the client panel is available on this server suspended: no password: must be changed at next sign-in (imported from another panel, never checked against this server's policy) last sign-in: never can sign in: yes, but only to change its password ``` `disable` revokes **self-service, not hosting**. Websites, mail, FTP and SSH are untouched, and the same password keeps working everywhere it worked before. Sessions that are already open are refused on their next request: the server re-reads this flag on every call rather than trusting the session token. Both commands are idempotent, and **neither is gated by the licence**. Revoking access has to keep working on a server whose licence has lapsed, and gating `enable` would leave you able to turn access off and unable to turn it back on. The licence is enforced at the login itself. ## `corepanel account import` Imports a cPanel account into CorePanel from a `cpmove-.tar.gz` / backup archive — or from an already-extracted account directory. With `--dry-run` the archive is parsed server-side and the plan is printed (`core.PreviewImport`, read-only); without it, the import runs (`core.ImportAccount`). ```bash # Preview (read-only) corepanel account import --dry-run # Run the import corepanel account import [--package ] [--preserve-uid] ``` ### Flags | Flag | Description | |------|-------------| | `--dry-run` | Parse and validate the archive, print the plan, and touch nothing | | `--seller ` | Target seller id (default: primary seller) | | `--package ` | Target hosting package id; its limits drive the account | | `--preserve-uid` | Preserve the source UID/GID via `useradd -u/-g` | | `--on-conflict abort\|skip` | Policy when the linux user or primary domain already exists (default `abort`) | | `--report ` | Write the JSON import report to this path | The `` path is resolved on the machine running `corepanel-core` (the archive must already be staged on the server) and is sent as an absolute path. **Dry-run** reports: - the detected source panel and version; - the account identity (Linux user, UID/GID, plan, contact) — and whether the source has it **suspended**, which is marked beside the name because such an account is imported suspended; - resource counts — domains, mailboxes, forwarders, databases, DB users, DNS records, FTP accounts, cron jobs, certificates; - **credential compatibility** — which passwords carry across verbatim versus which need a reset (cPanel `$6$`/`$5$`/`$1$`, bcrypt and `$y$` yescrypt hashes are preserved); - **conflicts** against existing CorePanel accounts and domains; - every parse **warning** (anything skipped or unsupported — nothing is dropped silently). A mailbox or FTP login the source had **locked** arrives closed (inactive), keeping the password stored behind the lock marker. It is not counted among the credentials needing a reset: there is nothing to reset, and reopening it is a decision rather than a chore. An account suspended on the source arrives **suspended**, keeping the source's own suspension date: its sites serve the [suspension page](https://www.corepanel.net/docs/accounts/suspension) and its logins stay closed until an administrator lifts it. A site that does not answer after importing one of these is the correct outcome, not a failed import. **Real import** creates the system account preserving the source username, UID/GID (with `--preserve-uid`) and password hash where the scheme is compatible, then provisions the CorePanel account, the primary domain (vhost + managed DNS zone), the FTP accounts and the primary domain's mailboxes with their credentials carried over verbatim. A credential whose scheme cannot be preserved gets a random password and is flagged for a reset (never surfaced in plaintext). It also restores the account's **heavy data**: the home directory (site files and Maildir messages), the MySQL databases (schema + data) and their users (source password hashes preserved), the crontab (imported as panel-managed cron jobs), and the primary domain's TLS certificate (installed verbatim when not self-signed). Addon/subdomain provisioning, source DNS-record import and mail forwarders remain later phases and are listed as `deferred` in the report. The job outcome is persisted and can be polled via `core.GetImportJob` or listed via `core.ListImportJobs`. Examples: ```bash # Preview a staged cpmove archive without importing corepanel account import /var/lib/corepanel/import/cpmove-example.tar.gz --dry-run # Preview an already-extracted account directory corepanel account import /var/lib/corepanel/import/job-42/cpmove-example --dry-run # Run the import into package 3, preserving the original UID/GID corepanel account import /var/lib/corepanel/import/cpmove-example.tar.gz \ --package 3 --preserve-uid --report /root/import-example.json ``` ## `corepanel account backup` Creates a full local backup of a hosting account. Every MySQL database is dumped with `mysqldump --single-transaction`, each database user's credential is preserved, and the home directory (files + Maildir) is archived into a self-describing `cpbackup--.tar` archive under `/var/lib/corepanel/backups//`. Local backups and their schedules are available in every edition; copying an archive to a remote destination (S3-compatible storage or SFTP) is a Pro/Business feature. ```bash corepanel account backup [--wait] [--dest ] ``` The backup runs asynchronously server-side and prints a job id. Pass `--wait` to block until it finishes and print the resulting archive path and status. ```bash # Start a backup and return immediately with the job id corepanel account backup pxdemo # Start a backup and block until it completes corepanel account backup pxdemo --wait # Back up and push the archive off this server corepanel account backup pxdemo --dest offsite --wait # Show the status and report of a backup job corepanel account backup-status 7 ``` The local copy is kept even when a destination is configured, so a destination that is unreachable degrades the job to `partial` with the reason in its report — it never costs you the backup. ## `corepanel account restore` Restores a hosting account from a `cpbackup--.tar` archive produced by `corepanel account backup`. Recreates the system account (preserving UID/GID and the password hash where compatible), the CorePanel account row and primary domain, every secondary domain (aliases and addons) and subdomain — each with its vhost and managed DNS zone — the home directory (files + Maildir), MySQL databases + users with preserved credentials, FTP accounts, and every mailbox login (primary and addon domains) with its password hash carried over verbatim. ```bash corepanel account restore [--on-conflict abort|skip] [--dry-run] [--wait] corepanel account restore --dest --remote-key [--on-conflict abort|skip] [--dry-run] [--wait] ``` Use `--dry-run` to preview what would be restored without touching the system, and `--wait` to block until the restore finishes and print the per-resource report. With `--dest` and `--remote-key` the archive is pulled from a [remote destination](#corepanel-backup-destination) instead of read from local disk: it is downloaded into a private staging directory, restored, and the download removed — the copy at the destination is left alone. This path is never gated by edition, because pulling a backup back is recovery. ```bash # Preview a restore corepanel account restore /var/lib/corepanel/backups/cph2/cpbackup-cph2-20260721T090349Z.tar --dry-run --wait # Restore, blocking until done corepanel account restore /var/lib/corepanel/backups/cph2/cpbackup-cph2-20260721T090349Z.tar --wait ``` ## `corepanel account backup-schedule` Manages recurring backup schedules and their retention. A schedule targets one account (`--user`) or every account (`--all`), fires on a cron expression or a `daily`/`weekly`/`monthly` preset, and prunes only its own old archives. CorePanel runs an in-process scheduler that polls every minute, so no OS crontab entry is created. Retention never deletes a manual backup and always keeps at least the most recent scheduled archive per account. `run` starts the run in the background and returns immediately; track progress with the schedule's last status or `corepanel account backup-status`. ```bash corepanel account backup-schedule list corepanel account backup-schedule create (--user | --all) [--cron "m h dom mon dow" | --frequency daily|weekly|monthly] [--keep N] [--days N] [--name