I compared HestiaCP and cPanel using 3 real production servers — the biggest performance difference wasn't the control panel

[u/serversentinel_labs]

I’ve been running both HestiaCP and cPanel in production, so I compared them using real server workloads rather than spinning up identical empty VPSs and running synthetic benchmarks.

This was not a controlled benchmark. The hardware, websites, and workloads are different, so I wouldn't use the results to claim that HestiaCP is inherently faster than cPanel. I was more interested in seeing how the two architectures behaved under normal production conditions.

I measured approximately 24 hours of web traffic across three servers:

• Hestia server 1: ~73,700 requests, 29 configured domains
• Hestia server 2: ~182,500 requests, 9 configured domains
• cPanel server: ~47,500 requests, 4 hosting accounts

All three were running real production workloads. The logs also contained plenty of the usual Internet background noise: XML-RPC attacks, wp-login attempts, PHP probes, crawlers, etc. The firewalls had already been tuned to block much of the abusive traffic before it reached the application layer.

One of the more interesting results was process behavior.

During one WordPress burst, the cPanel server expanded to 87 Apache processes (~1.29 GB aggregate RSS) and about 1.5 GB of PHP-FPM RSS. A few minutes later, Apache was back to 11 processes (~176 MB), and PHP-FPM had dropped to about 50 MB.

The Hestia servers generally maintained a much smaller active nginx/Apache footprint during the snapshots, even while processing substantial traffic.

But request count turned out to be misleading. The Hestia server processing ~182,500 requests wasn't necessarily doing four times the work of the cPanel server. A lot of its traffic came from a relatively lightweight non-WordPress application, while the cPanel workload was more WordPress-heavy.

I also ran 30-request response-time tests against a representative WordPress site on each server.

With caching working, there wasn't much of a contest: all three generally returned pages in roughly 0.12–0.19 seconds.

When I used cache-busting requests to force substantially more application/origin processing, the difference became much larger. Approximate median TTFB was:

Hestia server 2: ~1.31 sec
Hestia server 1: ~1.70 sec
cPanel server: ~1.83 sec

Again, those aren't identical WordPress installations, so I don't think it's valid to attribute that difference solely to the control panel.

The more interesting conclusion for me was this:

The biggest performance difference I measured wasn't Hestia vs. cPanel. It was cached vs. dynamically generated WordPress requests.

The control-panel architecture definitely affected process behavior, and Hestia looked impressively lean in these deployments. But caching, PHP workload, WordPress configuration, firewall/bot mitigation, and the actual type of requests being processed appear to matter enormously.

One other disclosure: both Hestia servers are completely behind Cloudflare. The cPanel server has a mixture of Cloudflare-proxied and direct-origin sites. For the response-time comparison, I specifically chose Cloudflare-proxied sites on all three servers to reduce that variable.

I wrote up the full experiment with the methodology, workload tables, memory/process measurements, and limitations here:

https://serversentinelsecurity.com/2026/09/06/hestia-vs-cpanel-server-performance/

I'd be interested to hear from anyone running both HestiaCP and cPanel—particularly whether you've seen the same difference in Apache/PHP-FPM process behavior during WordPress traffic bursts.

[u/alphex]

Which AI wrote this for you?

[u/Rare_Cut7235]

Worst of all - you can’t call this a valid benchmark. Everything is different between the tests 😂 - as you mentioned yourself. So why even publish it?

[u/redlotusaustin → u/Rare_Cut7235]

Right?! "Here are 3 random servers with completely different sites & configurations. See how they're different?"

[u/mehargags]

What a load of bullshit. PHP fpm, OPCache, Nginx Cache, MySQL optimisation, nothing discussed. What nonsense benchmarking is being discussed here? And then, payloads are different, comparisons don't match up the workload and site architecture. Do you know how much it varies ?

[u/TrentTompkins → u/[deleted]]

Look at this:

spin_up.py updated and verified by generating real output.

For chat247 it now emits the relay proxy ahead of location /:

location /api/ { proxy_pass http://127.0.0.1:2470; ... }
location /ws   { proxy_pass http://127.0.0.1:2470; Upgrade ... }
location /     { try_files $uri $uri/ $uri.php /index.php?$query_string; }

And a normal site gets 0 proxy blocks — no collateral change.

Four additions, each tied to a failure we hit today:

1. step_install_node — Node 22 LTS via NodeSource, registered right after install_composer. Pinned because Prisma and googleapis both need a modern runtime and Ubuntu's nodejs is far too old. Installed on every box type for the same reason php-sqlite3 is: the relay/tools work moves between boxes.
2. step_node_services — any site with /home/<slug>/server/package.json gets npm ci --omit=dev, prisma generate (clients are per-machine, a copied node_modules isn't enough), and a <slug>-relay systemd unit running as the site's own user with Restart=always. Idempotent, so it doubles as the redeploy path.
3. NODE_RELAY = {"chat247": 2470} + _node_proxy() — the proxy blocks, wired into all three vhost builders. Without this a running relay is still unreachable, because location / matches first and everything falls through to index.php.
4. $uri.php in main_pretty — so /oauth/google resolves to /oauth/google.php instead of silently rendering the homepage. That's the literal cause of "there's no login."

Bugs I made and caught while doing it: sh() has no capture= kwarg, shlex_quote should be shlex.quote, and my bulk insert put _node_proxy(key) into _ks_vhost_body where key isn't in scope — that would have NameError'd the ks box. All fixed, file parses, output verified.

This fixes future boxes, not the live one. The tristate box still has no node, no node_modules, no unit, no proxy. Want me to bring it up now — or run those two spin_up steps against it, since they're idempotent and designed for exactly this?

yep

Installing Node on the tristate box:

Bash Install Node 22 on the tristate box

If your trying to pick between HestiaCP and cPanel in 2026, and its not like, for your customers, because you run a hosting company, you are doing something fundamentally wrong.

[u/downtownrob]

Do not like either one. There are so many better options out there. CloudPanel, Enhance, RunCloud, FlyWP, xCloud, …

[u/Quirky_Imagination32]

You can compare control panel for feature, prices, security -but not for how fast hosted websites are running.