How to host multiple client websites on one VPS — without per-account fees

Here's a number that surprises people the first time they run it: a €13/month Hetzner CAX21 (4 vCPU, 8 GB RAM) will comfortably host a dozen small-business WordPress sites and still have headroom to spare. The hardware to run many sites on one box has been cheap for years. So why does hosting five clients so often cost five times as much?

The answer is licensing, not compute. cPanel, Plesk and most managed platforms charge per account — every client you add bumps your bill, whether or not the server is doing any more work. This guide is about escaping that: how to safely run multiple client sites on a single VPS, what "safely" actually requires, and how to do it without paying a tax on every account.

The per-account tax, in real numbers

Per-account pricing looks harmless when you have two clients. It compounds badly as you grow. Here's roughly what the same handful of sites costs across common options (list prices, mid-2026):

The exact figures move with promotions and tiers, but the shape never changes: per-account pricing makes your cost scale with your success. The 40th client costs you the same in compute as the 4th and generates the same revenue — but the licence quietly eats the margin. A flat-fee model breaks that link: you pay once, and every additional client is pure margin against a VPS bill that barely moves.

That's the commercial case. But the reason people don't just cram every site onto one box is the technical one — and it's the part worth getting right.

The real challenge: isolation, not capacity

Putting ten sites on one server is easy. Putting ten sites on one server safely — so that one hacked or misbehaving site can't read, starve, or take down the other nine — is the actual craft of multi-tenant hosting. These principles apply on any Linux box, with any panel or none:

1. One Linux user per site

The single most important rule. Each site should run as its own dedicated system user, with files owned by that user and permissions that stop other users reading them. If every site runs as www-data, a single compromised WordPress plugin can read every other site's wp-config.php — database passwords included. Separate users turn a site-level breach into a site-level problem instead of a server-level one.

2. A dedicated PHP-FPM pool per site

Don't share one PHP process pool across tenants. Give each site its own PHP-FPM pool running as its Linux user. This does two things: it enforces the user isolation above at the PHP layer, and it lets you cap resources per site (pm.max_children, memory limits) so one busy site can't consume every PHP worker and stall the others. As a bonus, each pool can run a different PHP version — legacy client on 7.4, modern app on 8.4, same server.

3. open_basedir, so PHP can't wander

Even with separate users, a misconfigured script can try to read outside its directory. Set open_basedir per pool to pin each site's PHP to its own document root (and its temp dir). It's a cheap, defence-in-depth backstop: if isolation #1 ever slips, this catches the wanderer.

4. One database and one DB user per site

Never share a MySQL/MariaDB user across client sites, and never hand a site an account with global privileges. Each site gets its own database and a dedicated user granted rights to only that database. A leaked credential then exposes one client's data, not your whole estate.

5. Disk quotas, so nobody starves the box

On a shared box, one client's runaway logs, bloated uploads or forgotten backups can fill the disk — and a full disk takes down every site, including the panel itself. Set a per-site disk quota. It converts "the server is down" into "one client hit their limit," which is a support ticket, not an outage.

6. Independent logs, backups and firewalling

Give each site its own access/error logs so you can diagnose one client without grepping a shared firehose. Back up each site independently so you can restore one without touching the others. And harden the box as a whole — a firewall (UFW), brute-force banning (Fail2ban), and ideally a behavioural layer (CrowdSec) — because on a multi-tenant server an attack on one site is an attack on the neighbourhood.

Do all six and one VPS becomes a genuinely safe home for many clients. Skip any of them and you've built a single point of catastrophic, cross-tenant failure.

Doing this by hand is fiddly — and easy to get subtly wrong

None of the six is exotic. But wiring them up correctly for every new site — a fresh Linux user, an FPM pool with the right open_basedir and limits, an isolated DB and user, a quota, log paths, a vhost, an auto-renewing certificate — is a lot of moving parts to assemble by hand, every time, without a typo that quietly breaks the isolation you thought you had. That's exactly the repetitive, security-critical setup a control panel exists to standardise.

This is where a panel you own earns its keep. ShadowPanel provisions every new site with the whole isolation checklist applied by default:

• A dedicated Linux user per site, files owned by that user with www-data group and locked-down permissions.
• An isolated PHP-FPM pool running as that user, with open_basedir enforced and its own PHP version (5.6 → 8.4).
• Its own database and DB user, scoped to that site alone.
• Per-site disk quotas you set in the UI, plus live usage tracking.
• Separate nginx vhost and logs, and free auto-renewing Let's Encrypt SSL per domain.
• A hardened host by default — UFW, Fail2ban, CrowdSec, and ClamAV scanning on uploads.

And it's a flat licence, not a per-account charge — so the isolation you'd have to hand-build for every client comes for free with every client.

A concrete setup: five clients on one CAX21

Here's a realistic run:

1. Provision a VPS — a Hetzner CAX21 (4 vCPU, 8 GB RAM, ~€13/mo) is a sensible starting point for a dozen small sites.

2. Install ShadowPanel and activate your licence:

   curl -fsSL https://shadowpanel.de/install.sh | bash
   

3. Add each client's site. Point the domain, and the panel provisions the Linux user, FPM pool, database, quota, vhost and SSL in one step — the full isolation checklist, applied identically every time.

4. Set a disk quota per site so no single client can fill the box.

5. Watch resource use. As the server fills, the per-pool limits keep any one busy site from starving the rest; when you outgrow the box, move a heavy client to a second VPS — the flat licence doesn't punish you for running more than one panel.

Five clients, one server, one predictable bill — and each site sealed off from the others.

Honest caveats

• One box is one basket. Isolation protects tenants from each other; it doesn't protect them from a host-level failure. For anything mission-critical, spread clients across two or three VPSes rather than betting a whole book of business on a single machine.
• RAM is the real ceiling, not the licence. A dozen idle brochure sites are trivial; a dozen busy WooCommerce stores are not. Watch memory and move up a VPS tier (or out to a second box) before you're swapping.
• A panel automates the setup, not the judgement. ShadowPanel applies the isolation for you, but you still own capacity planning, updates and backups. That's the trade for owning the stack instead of renting per account.

The bottom line

Hosting many client sites on one VPS was never blocked by hardware — a cheap server has had the capacity for years. It was blocked by two things: getting the per-site isolation right, and not paying a per-account fee for the privilege. Nail the six isolation principles — separate users, per-site FPM pools, open_basedir, isolated databases, quotas, independent logs and backups — and one box safely holds a dozen clients. ShadowPanel applies that whole checklist to every site by default, on a single flat licence, so your costs stay flat while your client list grows.

If you're doing this to resell hosting under your own brand, pair it with white-label: see White-label hosting for agencies.

See pricing → · Download ShadowPanel →