Set up reseller accounts and plans in Plesk

A Plesk reseller is the closest thing the panel has to a multi-tenant sublease. The reseller gets their own Plesk login (the Reseller Panel), creates customers and subscriptions up to the limits you set, and rebrands the panel as their own — without touching the rest of the server. The model is different from cPanel's: in WHM you flag an account as a reseller and hand it ACLs, but in Plesk you build a reseller plan, then create a reseller account that subscribes to it. Get the plan limits and overuse policy right and you have a sellable product. Get them wrong and one reseller fills the disk.

This guide covers the full path: create the reseller plan, set limits and permissions, provision the reseller account, decide your overselling stance, and rebrand. Both the GUI path and the plesk bin CLI are shown — script it once and reseller onboarding becomes a single command.

Reseller plan vs customer plan vs subscription

Plesk has three layers, and conflating them is the most common setup mistake:

• Reseller plan — the template that defines what a reseller gets: total disk, total traffic, how many domains and customers they can create, and which permissions (overselling, custom plans, DNS) they hold.
• Service plan (customer plan) — the template a reseller or admin uses to create subscriptions for end customers. A reseller can use your shared plans or, if permitted, create their own.
• Subscription — an actual hosting account tied to a domain. This is what a website lives on.

A reseller account is created from a reseller plan. The reseller then carves their pool into subscriptions. Everything the reseller can do downstream is bounded by the reseller plan's limits and permissions.

Create the reseller plan

In the Server Administration Panel → Service Plans → Reseller Plans → Add Plan, or via CLI:

plesk bin reseller_plan --create "Reseller-Starter"

Then set the resource ceiling. These are the aggregate limits across everything the reseller creates:

plesk bin reseller_plan -u "Reseller-Starter" \
  -disk-space 100G \
  -max-traffic 1000G \
  -max-dom 50 \
  -max-clients 25

-max-dom caps total subscriptions; -max-clients caps how many customer accounts the reseller can register. Set both explicitly — the defaults are unlimited, which is almost never what you want to sell.

Set permissions

Permissions decide what the reseller can do, separate from how much they can consume. The high-impact ones:

plesk bin reseller_plan -u "Reseller-Starter" \
  -create_clients true \
  -manage_dns true \
  -manage_php_settings true \
  -manage_crontab true \
  -allow_oversell false

• -create_clients — lets the reseller register customer accounts (not just bare subscriptions). Keep on for a real reseller programme.
• -manage_dns — the reseller manages DNS zones for their domains. Usually yes.
• -allow_oversell — the overselling switch. See below; default it to false.
• Leave anything that touches server-wide state off. Resellers cannot restart services or edit server settings regardless, but permissions like custom plan creation should be a deliberate choice, not a default.

If you want the reseller to define their own customer-facing service plans rather than only using yours, enable that permission — but their plans are still hard-capped by the reseller plan's aggregate limits, so they can't conjure a 1 TB plan out of a 100 GB pool.

Decide your overselling policy

Overselling is the lever that makes reseller hosting profitable — and the one that takes down servers. With overselling off, Plesk sums the allocations of every subscription a reseller creates and blocks them once the total hits the plan limit: a 100 GB reseller selling 10 GB plans can create exactly 10. With overselling on, the reseller is governed by actual usage, not allocation — they can create 50 subscriptions of 10 GB each as long as real consumption stays under 100 GB.

Overselling is standard practice because most accounts use a fraction of their quota. The risk is the tail: if usage spikes past the pool, the overuse policy decides what happens. Set it deliberately:

• block — hard-stop writes when the limit is hit. Safest for the server, worst for the customer experience.
• notify — email the reseller, keep serving.
• normal — enforce per-subscription limits but don't suspend the reseller.
• not_suspend / not_suspend_notify — never suspend the reseller account on overuse.

For a paid reseller you trust, notify plus monitoring is the usual choice. For a cheap high-churn tier, block protects you from the one reseller who oversells 50:1 and then has a customer go viral. Whatever you pick, the resource isolation has to come from underneath — Plesk limits cap disk and traffic, but they don't stop a runaway PHP process from eating CPU. For any serious reseller programme on a shared box, CloudLinux LVE is not optional.

Create the reseller account

With the plan defined, provision the reseller and subscribe them to it:

plesk bin reseller --create jdoe \
  -name "J Doe Hosting" \
  -passwd 'StrongPassphraseHere' \
  -email jdoe@example.com \
  -plan-name "Reseller-Starter"

The reseller logs in at the same Plesk URL with their credentials and lands in the Reseller Panel — a scoped view that shows only their customers, subscriptions, and limits. They never see the Server Administration Panel.

Rebrand the panel

A reseller wants their customers to see their brand, not yours. Two things to set:

• Custom logo and panel name — the reseller sets these themselves under Reseller Panel → My Profile → Interface customisation, so this is mostly a documentation item for your onboarding email.
• Nameservers — for white-label DNS, the reseller's customers should see ns1.theirbrand.com rather than yours. Add A records pointing the reseller's nameservers at your IPs, and have the reseller register glue records at their registrar. Without glue, the branded nameservers won't resolve — this is the single most common white-label support ticket.

Unlike cPanel, Plesk doesn't issue a dedicated IP per reseller by default, and you rarely need one — SNI HTTPS and Let's Encrypt SAN certificates work fine on the shared IP. Allocate a dedicated IPv4 only for a mail-reputation or payment-gateway requirement, then assign it under Tools & Settings → IP Addresses and reallocate it to the reseller.

How this differs from WHM resellers

If you run both panels, the mental shift matters. In cPanel you grant a reseller ACLs directly on their account and the danger is over-granting a single checkbox like "All Features". In Plesk the danger is different: the permissions list is narrower and safer by default, but the limits default to unlimited, so the failure mode is a reseller filling the box rather than gaining root-adjacent powers. Plesk's overuse policy also has no clean WHM equivalent — it's a genuinely useful knob for capping the overselling tail.

FAQ

Next steps

• Sizing the host before you sell reseller slots? Plesk license tiers explained shows where the Web Admin / Web Pro / Web Host brackets break, and Web Pro vs Web Host covers which edition actually permits resellers.
• For the resource-isolation half of the story, pair Plesk with CloudLinux LVE tuning so one reseller's customer can't starve the others.
• Standing up the server from scratch? Install Plesk on AlmaLinux 9, then activate a Plesk license on the edition that matches your reseller count, or contact sales for volume pricing.