Introduction

OPanel is a hosting control plane for Debian. It runs a complete web hosting business on a single server, and when you join more servers they form a cluster that customers and staff treat as one large machine.

If you know cPanel, WHM and WHMCS, the fastest way to place OPanel is by comparison:

If you know…	OPanel’s equivalent is…
WHM (the operator side)	The operator console: servers, plans, customers, subscriptions and billing, seen by your staff
cPanel (the customer side)	The customer portal: sites, domains, databases, files, SSH, backups, seen by your customers
WHMCS / Blesta / HostBill	Built-in storefront and billing: Stripe Checkout, invoices, dunning, suspension — or drive an external one of those through the API

Unlike cPanel/WHM, all three sit on one codebase and one API: the operator console and the customer portal are two views of the same data, and everything either of them can do, a script can do too, through a documented, versioned API.

The concept model

Everything in OPanel hangs off one chain of ownership:

Platform (your installation)
 └─ Brand (yours, or a reseller's white-labeled brand)
     └─ Customer (a person, company or agency — the billing entity)
         ├─ Users, via memberships (owner, admin, developer, billing, viewer)
         └─ Subscription (an instance of a plan: limits, billing status)
             └─ Site (a WordPress, PHP or static site)
                 ├─ Domains (primary, aliases, redirects)
                 ├─ Databases and database users
                 └─ Cron jobs, backups, SSH access

A few things about this model are worth knowing up front:

Users are not customers. A user is a login (email, password, two-factor). It can belong to several customers at once with a different role on each, which is how an agency manages 40 clients from one account — something cPanel cannot do.
A subscription is a plan in force. Buying a plan creates a subscription, which carries the plan’s limits and the site or sites it applies to. Changing plans changes the subscription, not the site.
A site is the isolation and placement unit. Every site is its own Unix user, its own systemd sandbox, its own PHP-FPM master, and lives on exactly one web server at a time (moved between servers when needed, automatically or by an operator).
Brands are real tenants, not a coat of paint. A brand has its own customers, staff, plans, prices, panel hostname and, optionally, its own Stripe account. Platform staff see and manage every brand; a brand’s own staff see only their brand.

Servers and roles

A single server is a cluster of one. Every server that joins a cluster takes on one or more roles:

Role	What it does
`control`	Runs the controller: the API, the web UI, the job engine, billing and the cluster’s certificate authority
`web`	Hosts sites: nginx, PHP-FPM, Valkey
`edge`	Terminates public HTTP/HTTPS/HTTP/3 traffic, issues certificates, runs the WAF
`ssh`	The customer-facing SFTP/SSH gateway
`db`	Customer MariaDB databases
`cache`	A shared Valkey pool

opanel install gives the first server every role. As you grow, opanel join adds servers with just the roles they need, and OPanel places new sites, balances load and moves sites between servers on its own. See Cluster.

How to read these docs

Getting started walks through requirements, installation and the first hour with a fresh installation.
Running the platform is for the people who operate the servers: clustering, security, performance, backups and updates.
Billing and resellers covers plans, Stripe, external billing systems and white-label brands.
Customer guide is written for the people who actually run sites on OPanel — hosting or reseller staff can point customers straight at it.
Migrations covers moving existing WordPress sites and other sources onto OPanel.
Reference has the full CLI and the public API.