Designing hosting plans #

This page is for product managers and system administrators who together design the plans of an Exponential hosting offer. It answers: what are the building blocks of a plan, which technical choices sit behind each block, how do you set the limits of a plan, and what do typical plan families look like?

The page gives structure, not prices. Your costs, your hardware and your market decide the figures; the project's sources publish none, and this help does not invent any.

Contents #

1. The building blocks
2. Technical choices behind each block
3. Setting limits from measurements
4. Plan families
5. Add-ons
6. A plan sheet to copy
7. Common mistakes

The building blocks #

Every Exponential hosting plan is a combination of these blocks. Write down, for each plan, what it includes.

Technical choices behind each block #

Engine #

Chapter 8 recommends Exponential Velocity "for every stage" and calls FrankenPHP a production-ready alternative. Velocity is a long-running process; on shared hosting that forbids long-running processes, plans use Apache or nginx with PHP-FPM instead. A plan family can therefore split along this line:

• shared plans on Apache or nginx with one PHP-FPM pool per customer;
• VPS, dedicated and managed plans on Velocity, with its own worker pool per site.

Details: Choosing a web server, Velocity for hosts.

Database #

SQLite 3 is the default and, with the driver Exponential ships, "a full production database for a site served from one machine" (Database support). It needs no database server, so it costs a host nothing extra to provide. A plan that promises several web nodes needs a database server, PostgreSQL first (Databases in the official order).

Storage and backups #

A complete backup "is the database and the files": var/storage, settings/override and settings/siteaccess (Database support). Size the backup storage of a plan from those directories, not from the whole installation; the code itself can be fetched again from Git or Composer. See What to back up.

Isolation #

Plans that share a machine need operating-system isolation between customers. Chapter 8 names this as a reason to keep a traditional web server: "when several customers on one machine need operating-system isolation from each other". See Multi-tenant isolation.

Setting limits from measurements #

The installation book gives few hard numbers and says so: "the documentation gives few hard numbers, and this book does not invent others" (2.10). What it does state:

Everything else comes from your own measurements. A method:

1. Install a reference site on the hardware the plan will use (a site package with demo content is a fair start, see Site packages).
2. Measure it with the benchmark command (Benchmarking a hosted site) with the caches cold and warm.
3. Watch memory per worker or per PHP-FPM child, database size and var/ growth for a representative period.
4. Set each plan limit with headroom over what you measured, and write down how you measured it.
5. Measure again after each Exponential minor release and each PHP upgrade.

Plan families #

Templates, not recommendations. Replace every <...> with your own figure.

Add-ons #

Options a host can sell separately, each backed by a feature in the sources:

A plan sheet to copy #

Plan name:            <name>
Audience:             <who it is for>
Engine:               <Velocity | FrankenPHP | Apache + PHP-FPM | nginx + PHP-FPM>
PHP versions:         <list>; who chooses: <host | customer>
Database:             <engine, version>; dedicated or shared: <...>
Isolation:            <system user + pool | VM | container | machine>
Limits:               storage <...>, workers or FPM children <...>, database size <...>
  measured on:        <hardware>, <date>, method: <benchmark command, content set>
Backups:              <what>, <how often>, kept <how long>, stored <where>, restore tested <how often>
Environments:         <production | + staging>
Updates:              <who>, <when>, announced <how>
Support tier:         <tier name>  (see the support tiers sheet)
Add-ons available:    <list>
Not included:         <list, for example custom development>

Common mistakes #

• Promising a capacity you have not measured. Measure first; see above.
• Leaving restore out of the plan. A backup plan without a restore test is incomplete.
• Offering Velocity on a platform that stops long-running processes. Check before you sell it.
• Mixing customers in one PHP-FPM pool. Give each site its own system user and pool.
• Calling a plan by the old product name. The product is Exponential; see Brand and naming rules.

Related pages #

• SLA options
• Support tiers
• Billing and metering options
• Choosing a hosting model
• Sizing memory, CPU and disk
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.