Plans and performance
A plan (a package) decides what an account may use. BHPanel enforces every resource limit in the kernel, so one busy or hacked site slows down only itself — never the server and never its neighbours.
Plans are made under Accounts › Packages › Create package. Saving a plan applies it straight away to every account on it, running processes included. Re-apply puts every account of a plan back on its limits.
The resource limits
| Limit | Default | What it does |
|---|---|---|
| Disk (MB) | 1024 | The account's disk quota. 0 = no limit (only on the administrator's own plans). |
| Files (inodes) | 100000 | How many files the account may have. |
| Web traffic (GB/month) | 0 = unlimited | Over the allowance, the account's sites show a "509 Bandwidth Limit Exceeded" page until the 1st of the month, or until the plan is raised. Certificates still renew. |
| CPU (%) | 25 | 100 = one full core. |
| Memory (MB) | 512 | The hard ceiling. The account is slowed down from 75% of it, and it never swaps. |
| Processes | 50 | Every PHP worker, cron job and shell counts. |
| PHP workers | automatic (16) | How many requests the account's PHP serves at once (12–256). |
| PHP cache (MB) | automatic | OPcache size, never more than a quarter of the memory. |
| I/O weight | 100 | A share of the disk — only on disks whose scheduler supports it, which most VPS disks do not. |
| Disk IO speed (MB/s) | 0 = no ceiling | A hard read/write ceiling, which works everywhere. |
CPU, memory and processes must always have a value: 0 means unlimited
to the kernel.
What it may create sets how many websites, databases (MySQL, PostgreSQL, MongoDB), Node.js and Python apps, cron jobs, mailboxes, FTP users and collaborators an account may have, and its outbound mail recipients per hour (default 50).
Shared services protects what every account shares: database connections per user (default 30), the longest database query (60 s), and — on Nginx + Apache — requests per second per website (30 per visitor address; images, scripts and styles get four times as much), the request burst and connections per visitor. Over the limit a visitor gets a polite 429 instead of the server slowing down for everyone.
Sizing plans that perform
PHP is where most of the memory goes. As a rule of thumb, a WordPress or WooCommerce PHP worker uses 50–100 MB, so the memory limit must cover the workers you allow plus the database's share:
| Kind of site | CPU | Memory | Processes | PHP workers |
|---|---|---|---|---|
| Small brochure / blog | 25–50% | 512 MB | 50 | 12 |
| Busy WordPress | 100% | 1–2 GB | 100 | 16–24 |
| WooCommerce shop | 100–200% | 2–3 GB | 150 | 24–32 |
Workers beyond what memory allows are stopped by the kernel rather than served, so raising workers without memory does not help.
Every site benefits from caching:
- Page cache. On Nginx + Apache, switch on Vinyl Cache under Server › Web server (default 256 MB, pages kept 10 minutes). Signed-in users, carts, checkouts and admin pages are never cached. Add the free WordPress plugin Proxy Cache Purge so a site clears its cache when it publishes. Each site can switch it off, or clear its own cache. On OpenLiteSpeed, use the LiteSpeed Cache plugin instead.
- Object cache. Every account can have its own Redis or Memcached
(on
127.0.0.1, no password, reachable by that account only), sized from its plan's memory. For WordPress, use the Redis Object Cache plugin. - PHP version. 8.5 is the recommended default (newest versions sometimes lag for extensions). Set the server's default under Software › PHP; each account and each site can choose its own.
The web stack
Server › Web server chooses for the whole server:
| Nginx + Apache (default) | OpenLiteSpeed | |
|---|---|---|
.htaccess |
everything | rewrite rules only |
| Page cache | Vinyl Cache, every site | LiteSpeed Cache plugin |
| Per-website request limits | enforced | not enforced |
| Dedicated IPs | yes | no |
| Uploads checked for malware | before PHP sees them | the moment they are saved |
Only check — don't switch tests the change first. Switch installs the new server beside the old one, compares how every site answers, and switches back by itself if any site answers worse. Every site is unreachable for a few seconds during the swap.
If OpenLiteSpeed did not install by itself (before version 0.2.79 the
switch only installed Nginx + Apache), install it from the terminal as root,
then use Switch again:
bhpanelctl ols.install
It installs OpenLiteSpeed beside the running web server and leaves it stopped; your sites keep answering. When it has finished, the Versions row on Server › Web server shows its version.
Resellers
On a reseller plan, disk, web traffic and accounts are the reseller's pool to share among its customers, and CPU, memory and processes are shared by the reseller and all its customers together. The other figures are the most any one of its accounts may have.
A reseller's disk is a hard limit on what is used: at 100% nothing new can be written until usage is back under 95% (the reseller is warned at 80% and 90%). Reseller may oversell lets a reseller sell more than its pool.
Server › Basic setup › Overselling disk decides whether plans together may sell more disk than the server holds; the card shows how much is sold.
Other plan options
SSH access, a dedicated IP (Nginx + Apache, with a free address under Server › Network), server backups and customers' own backups, containers, and — for reseller plans — Reseller backs up customers to its own remote (see Backups).