Separate the control layers
Ask which named person can perform each consequential action, what system it affects, and which document grants that authority. A license does not itself grant Linux root, a WHM role, shell access, or server responsibility. A hosting operator may maintain software without granting the customer the same permissions.
License, platform, panel, and application are separate
Separate these layers: the platform provider and its VM/network contract; root or system operator and OS/services; panel administrator and enabled account functions; reseller and its granted WHM permissions; cPanel account and account tools; WordPress site or network admin and application settings/code; database credential holder and database actions. A database grant does not itself grant operating-system authority.
Build a matrix from evidence, not menu labels
Use a row per layer and action. “Unknown” is the right entry until a role record, contract clause, or named operator answers. Record grant, scope, cross-account effect, and verifier.
| Layer / actor | Capability to establish | Scope and cross-account effect | Evidence and verifier |
|---|---|---|---|
| Platform provider | VM, network, console, recovery, contracted support | Instance, host, or service boundary? | Service contract; named provider contact |
| Root / system operator | OS, SSH, services, runtime, database, reboot | Whole server or delegated scope? | Access policy and support terms; operator |
| WHM root / reseller | Account, package, and server functions allowed by role | Owned accounts or broader accounts? | Role and ACL; panel administrator |
| cPanel account / SPanel edition | Enabled account tools and edition entitlements | One account; limits and exclusions? | Exact SKU, version, grant, contract; provider |
| WordPress site / network admin | Application code, settings, users, content | One site or network-wide changes? | WP role and configuration; site owner |
| Database credential holder | Read, write, schema, export, or restore | Which database and tables? | Grant and recovery procedure; DB owner |
A visible control is not proof of isolation
A menu item does not prove which OS identity, file permissions, process pool, or database grant performs an action. A separate login does not prove one account cannot affect another. WordPress administrators may change application code without root; a root operator may affect the host and many accounts. Ask for the actual boundary and accountable party. See the hub’s responsibility map for the wider owner chain.
Read cPanel and WHM grants narrowly
cPanel and WHM have different users and permissions. The vendor’s login documentation says cPanel login uses a cPanel account, WHM uses root or reseller privileges, and the provider controls command-line access. A cPanel login does not establish WHM or shell authority. Ask who holds credentials, what the role can do, and who performs work beyond it.
Reseller permissions vary
The reseller guide describes privileges over accounts, packages, and server functions. Its “All Features” example grants full WHM functionality, overrides reseller limits, and exposes accounts the reseller does not own. This is a maximal example, not every reseller account; a limited ACL can allow fewer operations.
Request the exact ACL. Ask whether it can create accounts, change packages or PHP handlers, manage databases, mail, DNS or SSL, restart services, view logs, use terminal access, or affect other accounts. Treat each as an open question; public vendor documentation does not enable it on a host.
Account tools do not equal WordPress or host authority
Creating a database user, changing a domain’s PHP version, restarting a service, restoring an account copy, and changing a plugin are distinct tasks with potentially different operators. Ask who controls package limits and database access, can inspect logs, and handles an issue crossing from WordPress into PHP or the database.
A successful login does not establish installed version, OS, SSH permission, cross-account visibility, or support inclusion. Obtain a written answer tied to the selected product and account.
Evidence to request
Record exact product/edition, role and ACL, root/SSH clauses, installed panel and OS versions if confirmed, and support scope/exclusions. Add the source date and confirmer. If the grant is unavailable, say so; a request is not a grant.
Check SPanel features against the edition
The SPanel vendor’s features page lists website/WordPress, database and email tools, SShield, SSL, monitoring, reseller functions, per-account controls, and backups. It distinguishes Managed and Unmanaged license options. This does not identify a host’s edition, enabled functions, operator, or support contract. Check the selected offer and written terms.
A listed feature is not an entitlement or outcome
For each feature, record edition/version, inclusion, scope, authorized user, and support party. Listed resource controls do not establish your quota. A security name proves no universal protection, and a restore button proves neither a recoverable copy nor application consistency.
Ask where copies live and who can retrieve them
The full-backup API describes a copy under the account home directory and optional FTP transfer. This does not establish off-host independence, post-cancel retention, protection from root deletion, or consistency between WordPress files and database. Ask about components, destination, credentials, retention, deletion access, and retrieval terms. The copy and custody worksheet covers recovery.
Tie every answer to the purchased SKU
Ask the seller to name edition/version, license holder, included functions, root/operator arrangement, and support provider. For copies, ask who schedules and retrieves them and where they live. Save the dated answer. Vendor feature material does not identify your bundle or prove a live-site result.
Treat versions and OS requirements as dated evidence
Lifecycle pages describe vendor releases, not a particular machine. The captured cPanel versions page, modified October 2, 2026, listed version 138 with approximate November 2026 end of life and version 134 LTS with approximate June 2027 end of life. Recheck these near-term dates. They do not identify a provider’s installed tier.
Vendor lifecycle is not host inventory
Do not infer a server’s version from the vendor table. Ask the operator for installed version/tier, check date, update policy, upgrade owner, and deferral process. Name who assesses compatibility and can reverse an upgrade.
Installation prerequisites do not establish your OS
The cPanel installation guide (captured 2026-11-06) says to install on a freshly installed operating system and to log in as root. Its separate Ubuntu system requirements page (captured 2026-11-06) says cPanel & WHM can be installed on Ubuntu 24.04 LTS and describes minimum installation requirements. These are upstream installation prerequisites; they do not establish your VPS’s OS, installed panel, entitlement, or root grant. Keep the selected host’s OS and permissions unknown until its operator confirms them.
Keep a dated verification record
Record product, edition, installed version/tier, OS, entitlement, source, check date, upgrade owner, and review date. The release-tier details above rely on C021, a rendered excerpt captured 2026-11-06, rather than a retained raw HTML capture; it is not host inventory. The installation sources are separate full raw HTML captures: CPANELINSTALL.html (SHA-256 fb0a4e8fc0dddf098b8c8560469415a5bb9c60432be953a46117836c6b61f033) and CPANELUBUNTU.html (SHA-256 d0b34b05d3abaa96b13ac185fd08acca8b811ad7e61286f445a01153238f48de), both captured 2026-11-06. The first documents fresh-OS and root-login installation prerequisites; the second documents Ubuntu 24.04 LTS and minimum system requirements. These are upstream requirements only: neither capture establishes the selected host’s OS, installed panel, entitlement, or root grant. Capture dates describe source collection, not host state. Recheck vendor pages and get a provider-specific answer.
Assign each duty to a named owner
Map grants to responsibilities: “can do” and “must do” differ. A permitted user may not be contracted to maintain a setting; provider support does not necessarily give the customer operating access. Name decision-maker, authorized operator, grant evidence, validation owner, and reversal authority.
Responsibility worksheet
Complete each relevant row. Use “request only” when you can file a ticket but cannot act, and “not stated” when no written duty exists. A vendor feature page is not your contract.
| Duty | Named accountable owner | Operator / actual grant | Written responsibility and evidence | Validation and rollback owner |
|---|---|---|---|---|
| Panel license, install, renewal | ________ | ________ | ________ | ________ |
| OS, SSH, patching, reboot | ________ | ________ | ________ | ________ |
| Panel upgrade and account ACL | ________ | ________ | ________ | ________ |
| PHP runtime and database service | ________ | ________ | ________ | ________ |
| WordPress core, plugins, themes | ________ | ________ | ________ | ________ |
| DNS, mail, and certificates | ________ | ________ | ________ | ________ |
| Copy custody and incident escalation | ________ | ________ | ________ | ________ |
Example: an agency has WordPress access but no shell
Suppose an agency can update plugins in WordPress, has no shell/root, and a hosting operator says they can restart services. A reseller account is called limited. This does not answer who can install PHP extensions, create DB users, restore a database, change mail, inspect logs, or handle code issues. Record separate requests and obtain the ACL and written operator scope; do not guess the configuration.
For a plugin, name approver and validator. For a PHP extension or restart, ask who performs it, affected scope, and reversal owner. For DB recovery, identify credentials, copy custodian, and application-data verifier. Actual terms decide these assignments.
A missing answer is a decision result
If owner, grant, validation, or reversal path is missing, mark “verify before purchase or change.” Do not write “the panel handles it.” Host operations and application support may differ. Compare scope and exclusions with the support and update map; a license does not define service.
Resolve missing grants or stop
Use this sequence to evaluate service or plan a future change. It records questions; no account was inspected, setting altered, or restore tested.
Five steps to close an authority gap
- Name the edition and operator. Record provider, product/SKU, panel edition and version if confirmed, account, and the person responsible for answering.
- Request the actual grant. Ask for the role/ACL, account scope, root or SSH policy, and actions that can be requested versus executed.
- Map the duty. Add accountable owner, operator, contract or policy locator, approval path, and any cross-account effect to the worksheet.
- Define verification. Name who would confirm the intended result and what evidence they would review after a separately approved change.
- Escalate or stop. Obtain a written answer from the provider or responsible administrator. Leave the task unapproved when the grant, support boundary, or owner remains unclear.
Do not proceed without a reversal owner
Before a later change, name reversal authority, known-good state/copy, copy custodian, and application approver. If no one can authorize reversal, stop and resolve custody first. A feature or backup label proves neither independent custody nor successful recovery. Return to the WordPress VPS responsibility map for platform, application, and recovery owners.
Decision: proceed to a separately approved operational plan only when the exact authority, written duty, validation owner, and reversal path are known. Otherwise the useful answer is “unresolved—verify before purchase or change.”
Sources and scope
- cPanel: Guide to Reseller Accounts — reseller permissions and ACL examples.
- cPanel: How to Log in to Your Server or Account — cPanel, WHM, and CLI access distinction.
- SPanel Features and SPanel file/generatefullbackup API documentation (captured 2026-11-06) — the API describes a generated archive placed in the selected account’s home directory, with optional FTP transfer; this does not establish off-host custody or selected-host entitlement.
- cPanel Installation and System Requirements for Ubuntu (both captured 2026-11-06) — upstream install prerequisites and supported Ubuntu requirement, not evidence about a selected host’s OS or grants.
- cPanel Product Versions and Release Process — dated release-tier information that requires rechecking.
These primary vendor sources explain product behavior and requirements within their stated scope. They do not establish a selected host’s installed version, OS, grant, isolation, edition, support contract, backup independence, or recovery result. No host or WordPress installation was inspected.
Page status: Draft — verify dated product claims and host-specific terms before publication. Research captured 2026-11-06.