Getting started with a Plesk reseller account

Plesk comes with some extremely powerful reseller account controls. Unlike cPanel (and WHM), it’s not necessary to learn how to use two completely different panels, Plesk integrates everything beautifully into one easy to manage panel. That said there are a few things to know about the features it includes and the best practices when it comes to organization of your hosting plans.

The overall process flow goes like this: you create a Service Plan as a template that’s used to generate Subscriptions, and each subscription houses one or more Domains and Subdomains.

How to handle billing my clients

Plesk does not include a billing solution. If you wish to also provide complete web hosting automation from order straight through to login to Plesk without your intervention, then you’ll also need to order a billing solution, like WHMCS. With WHMCS you’ll be able to set up order forms, client accounts, invoices, and recurring hosting plans that connect to your Plesk reseller service plans. This way, when a client orders, their chosen product will be automatically provisioned to your reseller account.

If you do not set up a hosting-specific billing solution, you’ll need to create invoices for your clients with the invoicing software of your choice (ex: Square, FreshBooks, QuickBooks, Wave, or PayPal) then manually create and manage their hosting plan (subscription) in Plesk.

What are Plesk Service Plans?

In Plesk, Service Plans are basically templates and restriction controls for the hosting plans you create. If you’ll be offering your clients more than one plan, like one with 5GB storage and one with 20GB, then you’ll want to create one Service Plan for each.

You can also do neat things with service plans from a templating perspective. For example, you can apply configurations, like enabling gzip caching in nginx, to your Service Plan and that config will be automatically enabled on all newly created subscriptions that are generated from the Service Plan.

If you haven’t edited a subscription after creating it (as in, if it’s still synced to the service plan), then you’ll also have the option to sync any changes you make to your Service Plan with all previously created Subscriptions, thusly rolling out any changes across all client subscriptions at once!

Customers, Subscriptions, & Domains: How This Works

Customers are pretty straightforward. For each client you have you should create a Customer in Plesk. Even if they don’t want access now, they might at some point in the future, and ensuring you provide them with their own customer account early on, makes providing that access simple for you in the future. Additionally, it’s simpler to find accounts later on when they’re organized cleanly from the start because you can search for customer names, domains, email accounts, etc. whenever they’re organized accordingly. Customers own one or more subscriptions that they have access to.

Subscriptions are ‘live’ or provisioned versions of a Service Plan. You might also see them called hosting plans, or webspaces – these are all the same thing. You can think of a subscription as a grouping of domains.

They start with one domain – the primary domain – and can have as many add-on domains, subdomains, aliases, email accounts, ftp accounts, etc, as you’ve allowed in its associated Service Plan.

Each subscription is totally segregated from the other subscriptions

Subscription Organizational Structure 1 to 1

For simplicity you may choose to configure Subscriptions and Domains in a 1:1 relationship. To do this whenever you wish to add a domain in Plesk, you can either

1. Go to Subscriptions > Add Subscription, or
2. Go to Domains > Add Domain but be sure to leave the Webspace option at default: create a new webspace/subscription.

This means your account will be organized like this:

• Customer1
  • SubscriptionA
    • DomainA
• Customer2
  • SubscriptionB
    • DomainB
    • Subdomain.DomainB (optional subdomains)
• Customer3
  • SubscriptionC
    • DomainC
    • Subdomain.DomainC (optional subdomains)
  • SubscriptionD
    • DomainD
• etc

Each subscription will always be paired with a domain of the same name (the primary domain name). A customer can have more than one subscription/domain combination as you see in the Customer3 example.

When you add domains as separate subscriptions (1:1), this is how the file system is organized:

• Subscription 1 User Root: /var/www/vhosts/domainone.com
  • Domain 1 Web Root: /var/www/vhosts/domainone.com/httpdocs
• Subscription 2 User root: /var/www/vhosts/domain2.com
  • Domain 2 Web root: /var/www/vhosts/domain2.com/httpdocs
  • Domain 2 Subdomain Web root: /var/www/vhosts/domain2.com/sub.domain2.com
• etc.

Tip: from the perspective of your user, the /var/www/vhosts part does not exist.

Advantage of 1:1

It’s simpler to grasp if you’re coming from shared hosting where you only ever have a list of domains and no heirarchy nor segregation between domains.

Disadvantage of 1:1

If someone, like a new developer, needs SSH or FTP access to multiple sites, you’ll need to create an account for them in each subscription.

If you or the the customer ever wish to separate their service to their own direct hosting plan with Websavers, they’ll also need a reseller hosting plan because each of our hosting plans is one Plesk subscription.

Subscription Organizational Structure 1 to Many

Sometimes you will have customers that have multiple domains associated with their organization. For example, a fictional matress company supersoftmattresses.com may have three different subsites for each of their 3 major types of mattresses. Given that the sites are all for the same company and same purpose, it would make sense to have them organized as part of the same subscrition. That structure looks like this:

• Customer: John Softy @ Super Soft Mattresses
  • Subscription: supersoftmattresses.com
    • Primary Domain: supersoftmattresses.com
    • Addon Domain: feathermattress.com
    • Addon Domain: foammattress.com
    • Addon Domain: springmattress.com
    • Subdomain: development.springmattress.com
  • Subscription: johnsofty.com
    • Primary Domain: johnsofty.com
    • Subdomain: staging.johnsofty.com

As you can see in the example above, you can still have that customer own additional subscriptions when it makes sense, like if John has a personal site as well. Note: this isn’t required – johnsofty.com could be another addon domain within supersoftmattresses.com if you prefer it.

Subdomains are provided as examples here where you’ve got development or staging happening on one of the sites.

When you add domains within the same subscription (1:Many), this is how the file system is organized:

• Subscription User Root: /var/www/vhosts/primarydomain.com/
• Primary Domain Web Root: /var/www/vhosts/primarydomain.com/httpdocs
• Addon Domain 1 Web root: /var/www/vhosts/primarydomain.com/addondomain1.com
• Addon Domain 2 Web root: /var/www/vhosts/primarydomain.com/addondomain2.net
• etc.

This is why a single subscription user can have access to all the domains within that subscription.

Tip: from the perspective of your user, the /var/www/vhosts part does not exist.

Advantages of 1:Many

The advantage of 1:Many is that the subscription username, which is used to access the subscription via SSH; SFTP; and FTPS, can then access all the sites within that subscription. In the example above, that user would have access to everything under the supersoftmattresses.com subscription, but NOT the johnsofty.com subscription. This type of multi-domain access is not possible when you create them as a 1:1 organizational structure.

If the customer ever needs to be spun out into their own direct shared hosting account, having a singular subscription with many domains in it (owned by that customer) is a considerably simpler and faster migration process. Note: if the likely upgrade path is to a VPS, with a mid-tier Plesk license you gain multi-subscription support anyway, so this advantage is somewhat lessened in such a case.

Disadvantages of 1:Many

Domains that share the same subscription can be tricky to separate in the future, should you ever wish to do so. This is for two reasons: 1) many web apps rely on an unchanging file location on disk, and 2) the database must be moved separately when a domain is separated from its subscription.

How do I pick whether to use 1:1 or 1:Many?

The natural next question is then: if a customer has two domains, should I set them up with two subscriptions (one for each domain) or one subscription that houses both domains?

We prefer to tackle this decision by answering these two questions (which are really different versions of the same question):

1. Is there’s a chance the domains will need to be separated later? It’s much simpler to do so if they’re separate subscriptions, so if the answer is yes, then use separate subscriptions!
2. Are the domains actually related? For example, if the primary domain is BestBuy.com and you’re setting up a careers site at bestbuy-jobs.com, then you should absolutely add bestbuy-jobs.com to the BestBuy.com subscription. This is because they are two separate sites but they are a part of the same company. On the flip side, if they want to set up a website for their CEO CorieBarry.com, it might be best to set that up under its own subscription, as Corie could move on to a different company in the future and it’ll be super easy and fast to simply move that domain’s subscription to a new Customer.

If I choose 1:Many, how do I pick the primary domain?

We recommend that the primary domain be the company or owner of the account’s main site. Another approach that often ends up at the same domain is to answer this question: what domain would you be least likely to ever need to delete?

---