Tell it once
Pick a profile when you install, or let the installer choose from the machine. Later you can add the modules a small server left out, in Modules, without reinstalling.
Sizing, plans and the capacity planner
In preview
The server's size decides what is installed and how it is tuned. Plans then say what a customer gets, and the planner tells you how many more accounts fit before you run out of disk, memory or CPU.
Built and lab-tested
- Five install profiles chosen by memory and CPU: Micro (up to 1.5 GB), Small (up to 4 GB), Standard (up to 16 GB), Large and Cluster. A container with a 1 GB limit counts as a 1 GB server.
- Tuning is applied, not just shown: on a 1 GB and a 4 GB test server nginx ran 1 and 4 workers, MariaDB had a 96 MB and a 608 MB buffer pool, and each site got 3 and 5 PHP workers. A value you set by hand is kept and the preview says so; a value the engine refuses to start with is rolled back.
- Re-tune: when memory or disk moves by more than 10 percent, or the CPU count changes, a proposal with the per-value changes is stored. Nothing is applied until an administrator applies it.
- Plans carry limits that every module enforces, and a plan says which modules it includes. An account's memory and CPU become its systemd slice (a 256 MB, 50 percent plan showed MemoryMax and CPUQuota to match).
- The capacity planner works per server on disk, memory and CPU: how many accounts of a plan fit on an empty server, how many still fit now, the bottleneck, and what-if for adding accounts or servers. It exports CSV or JSON and warns at 85 and 95 percent.
- Overselling rules for disk, memory and CPU at server, reseller and plan level (off, warn or allow; the strictest wins). Off refuses with the name of the resource.
- Plan changes for all accounts, only new ones, or selected ones; the old limits are kept as a frozen "(previous)" plan. A plan in use cannot be deleted until its accounts have moved. Plans export and import as a document, and presets (Starter, Business, Agency, Reseller, Dedicated) are generated from the usable capacity.
- Modules on and off at runtime, with a plan of what stops and what depends on it. The data stays. In the lab a disabled CDN module was gone, stayed gone after a panel restart and came back when enabled.
Not there yet
- Disk quotas need a filesystem with user quotas; the lab's had none, so real quotas were not tested.
- The plan editor's newer sections (included modules, who may be given a plan) were proven through the API, not saved through the screen.
- The Apply button and the Modules page were type-checked and built, not walked in a browser at phone width.
Every action in this area is in the panel, one keystroke away in the command palette (Ctrl K), on the command line and in the API, and most changes can be previewed as a plan first. Built and tested in our lab; RespireCloud is not released yet.
