---
title: "Running cPanel at scale: what I learned"
description: "Lessons from years of running large cPanel fleets: staged updates, noisy neighbours, backup windows, and alerts worth waking up for."
date: 2026-04-13
updated: 2026-04-13
tags: [hosting, operations]
url: "https://joshdargie.com/blog/cpanel-at-scale"
author: Josh Dargie
---

I've spent a large part of my career responsible for cPanel fleets, from a handful of servers to hundreds, across the hosting companies [I've worked with](/work). cPanel on one server is a solved problem; the documentation covers it. cPanel on a fleet is a different discipline, and most of what I know about it was learned the expensive way. This one is for the hosting and SaaS folks, not the homeowners.

Here's what I'd tell someone taking over a fleet tomorrow.

## Never update the whole fleet at once

cPanel ships updates constantly, and the automatic nightly update is fine right up until the night it isn't. An update that breaks one server is an incident. The same update applied to your entire fleet overnight is a career event.

The pattern that works is tiers. A canary group of a few servers, ideally ones carrying internal or low-stakes accounts, takes every update first. If nothing burns over a day or two, the update rolls to a broader wave, then the rest. The same staging applies to EasyApache profiles, PHP version rollouts, and OS patches. It costs you being a few days behind the release notes; it buys you never debugging a bad release on three hundred servers at once.

Corollary: fleet consistency is what makes tiers meaningful. If every server has hand-crafted differences, your canaries predict nothing. Config management isn't optional past about ten machines.

## Noisy neighbours are the product problem wearing an ops costume

Shared hosting economics depend on overselling, and overselling means one customer's runaway WordPress cron or brute-forced xmlrpc endpoint can degrade five hundred bystanders. Early in my career we played whack-a-mole: find the process, suspend the account, apologize to the neighbours.

The real fix is per-account resource isolation, CloudLinux being the standard answer in the cPanel world, so one account hitting its ceiling affects only that account. But the deeper lesson is that noisy neighbours are a placement and limits problem, not a policing problem. Decide what an account is entitled to, enforce it mechanically, and publish it honestly (customers can and do ask, as they should: I covered that from the buyer's side in [eight questions to ask a host](/blog/hosting-quote-questions)). Chasing individual offenders doesn't scale. Limits do.

## Backup windows are load, and load is customer experience

Backups are the workload nobody accounts for. A full backup pass is hours of sustained disk I/O, and if every server in the fleet starts at 1 a.m., 1 a.m. is when your fleet is slowest, right when overnight cron jobs, e-commerce order syncs, and your overseas customers are busiest.

Three things made backups stop hurting for me. Stagger start times across the fleet so the load spreads. Prefer incremental strategies over nightly fulls, because copying what changed is a fraction of the I/O of copying everything. And ship backups off the server quickly, because a backup sitting on the same disk as the data is a copy, not a backup. Then actually restore one, on a schedule, from a randomly chosen server. Every word I wrote about [untested restores in migrations](/blog/migrations-go-wrong) applies double when you're the host.

## Monitor for symptoms, not for everything

A big fleet can generate thousands of alerts a day if you let it, and an on-call rotation drowning in noise is functionally the same as no monitoring at all. The pager that cries wolf trains people to sleep through wolves.

What earned its keep: alerting on customer-visible symptoms first. Can a real HTTP request to a real site on this server complete? Is mail queuing abnormally? Is disk going to fill within 24 hours at the current rate? Those pages are always actionable. Load average spikes, single failed services that self-recover, and one-off I/O blips went to a dashboard reviewed in the morning, not to a phone at 3 a.m. The test I applied to every alert rule was simple: if this fires, is there a human action to take right now? If not, it's a metric, not an alert.

## The meta-lesson

None of this is really about cPanel. Staged rollouts, enforced limits, load-aware backups, and symptom-based alerting are just fleet operations, and they'll apply to whatever control panel or platform comes next.

If you're running a growing fleet and some of this list feels uncomfortably familiar, this is exactly the work [I consult on for hosting companies](/hire#hosting), from a one-off review to ongoing help. It's cheaper before the career-event night than after it.