Skip to content

Brands

One OPanel installation serves your own platform brand plus any number of reseller brands — fully white-labeled hosting businesses running on your infrastructure, each with its own name, look, hostnames, staff, customers, plans and prices, and optionally its own Stripe account. There is one level of reselling: a reseller’s brand cannot create brands of its own.

Platform administrators create a brand under Admin → Brands or POST /api/v1/brands, with a slug, a name and, optionally, a panel hostname, SSH hostname, support email and sender details.

  • Panel hostname: point its DNS at your edge servers. The edge serves the panel there with its own certificate, HSTS and body limits, issued automatically on first request. It’s reserved the moment it’s set — a customer can never add it, or a wildcard covering it, as a domain.
  • SSH hostname: what the brand’s customers are shown for SFTP and SSH.
  • Limits: maxCustomers and maxSites cap what the brand can create; 0 means no limit. Only the platform can raise them.

Retiring a brand (POST /api/v1/brands/{id}/retire) releases its hostnames and stops it taking new customers; it’s refused while any of its customers is still open, and is final.

A brand’s own administrators can change its name, support address, sender name, colors, logo, dark logo and favicon — everything a customer sees. Hostnames, the sender address, limits and the Stripe account stay with the platform, since they touch routing, certificates, deliverability reputation and money.

Every email a brand’s customers receive goes out in that brand’s name, logo and colors, from its own sender address, with a reply-to at its support address. Every site’s suspended and maintenance pages carry the same branding.

A person is either platform staff or staff of exactly one brand — never both — and a brand’s staff are members of that brand’s customers only.

Area Brand admin Brand support
The brand’s customers: details, members, closing/reopening change read
Their sites, domains, databases, files, terminal, cron, backups, WordPress, jobs, audit log change (as a customer owner) read
Suspending/reactivating the brand’s sites and subscriptions yes —
The brand’s plans, prices and WordPress update policy change read
The brand’s presentation and staff change read

Platform-only, never available to any brand’s staff: servers, pools, placement, moves, rollouts, cluster-wide IP blocking, malware settings, backup destinations, email and platform billing settings, platform staff, and other brands. Every listing (customers, sites, subscriptions, plans, jobs, audit log) a brand’s staff see is scoped to their own brand automatically.

Invite staff under Admin → Brands → [brand] → Staff or POST /api/v1/brands/{id}/staff. An unknown email address becomes an invited account with a link in the brand’s own branding; resend it any time with POST /api/v1/brands/{id}/staff/{userId}/invitation.

Before sign-in, the brand of a request is whichever brand’s panel hostname it was sent to (or your platform brand, for any other hostname) — that decides the sign-in page, the plans shown at signup, and checkout. On a reseller’s own hostname, a request can never do more than that brand’s own staff could: a platform administrator who happens to sign in on a reseller’s hostname sees none of the platform’s own administration there. Platform staff always sign in on the platform’s own hostnames.

By default a brand bills through your platform’s Stripe account. To give a brand its own, platform staff set PATCH /api/v1/brands/{id}/billing with its Stripe secret key and webhook secret. From then on, that brand’s checkout, customer portal and every subscription sync run against its own Stripe account, with its own webhook endpoint (https://<brand panel hostname>/api/v1/billing/stripe/webhook/<brand ID> — shown on the brand’s Payments page). Every customer records which account bills them, so a webhook event only ever touches that account’s own customers.

See Billing for the lifecycle every brand’s subscriptions follow.