FPM Resource Limiter — The Free CloudLinux Alternative I Built After My Server Burned Down (Twice)

If you manage a shared cPanel server and you’ve ever been woken up at 3am by monitoring alerts because one site decided to eat all 8 cores — this post is for you.

I spent two weeks fighting a server that kept going down. Multiple times a day. Clients calling, emails piling up, the whole thing. After fixing six different untuned cPanel defaults that should have never been defaults in the first place, I realized there was one problem left that no amount of tuning could fix: any single site on the box could still consume all server resources and take everyone else down with it.

The “proper” solution is CloudLinux with LVE containers. At $15-30/month. Forever. For what is essentially one feature I actually need — per-user resource limits.

So I built my own. For free. And it works.

The problem: cPanel’s default PHP-FPM settings are insane

When you create a new cPanel account, PHP-FPM gets a pool with pm.max_children = 5. That’s the maximum number of simultaneous PHP requests that site can process.

Five sounds reasonable until you realize:

• It’s the same 5 for your flagship WooCommerce store doing $50k/month and the abandoned blog you forgot about
• When you manually bump it to 15 (because 5 causes 503 errors on busy sites), every site gets 15
• 44 domains × 15 workers = 660 worst-case simultaneous PHP processes
• On an 8-core server
• That’s 82 PHP processes per core
• Each one consuming 50-100MB of RAM

It’s not a question of if the server goes down. It’s when.

What actually happened

Here’s the highlight reel of my two-week crisis:

Week 1: Server load hits 27. SSH barely responds. The culprit? A neglected WordPress site with 30 plugins, WooCommerce installed but not used, and a broken caching plugin. It was consuming 265% CPU — over 3 full cores — just sitting there serving a handful of visitors. Meanwhile, paying customers couldn’t load their sites.

Week 2, incident 1: Facebook’s Open Graph crawler discovers a WooCommerce product page with ?add_to_wishlist= in the URL. Being a good bot, it follows every link it finds. Those links happen to include every combination of add_to_wishlist × add_to_cart × product_id. Each URL is unique and uncacheable. The site hits 588% CPU. The server collapses. Every site goes down for 20 minutes.

Week 2, incident 2: The same pattern repeats. Different site this time. Same result — one site monopolizes the box, everyone suffers.

I fixed the immediate fires (blocked the bot patterns, capped the neglected site, converted one site to static HTML), but the structural vulnerability remained. On a shared server with no per-user limits, any site is one bad plugin or one bot flood away from killing everything.

CloudLinux vs. what I actually need

CloudLinux’s LVE (Lightweight Virtual Environment) does a lot:

• Per-user CPU limits
• Per-user memory limits
• Per-user I/O limits
• Per-user process limits
• A nice WHM UI

But let me be honest about what was actually causing my crashes: PHP processes. Every single incident traced back to too many PHP-FPM workers consuming too much CPU. Not memory (29GB is plenty). Not I/O (SSDs). Not process count.

The single most effective control is pm.max_children per domain. If a neglected site can only spawn 3 PHP workers, it physically can’t consume more than 3 cores. Your flagship store with 15 workers still has all the headroom it needs. The math just works.

Enter FPM Resource Limiter

I built a cPanel/WHM plugin that does exactly this. It’s called FPM Resource Limiter and it gives you:

A WHM web interface where you see every domain on the server with its current worker limit, tier classification, and live CPU usage. Change the number, click Apply. Done.

A CLI tool for when you need to make bulk changes or script things:

# See who's consuming what
fpm-limiter status

# Give the flagship store premium resources
fpm-limiter set shop.example.com 15

# Cap the freeloader
fpm-limiter set freeloader.example.com 3

# Apply preset tiers
fpm-limiter tier dev.example.com minimal

Preset tiers so you don’t have to think about numbers:

Persistence — the limits are stored in cPanel’s own YAML source-of-truth files. They survive cPanel updates, PHP version changes, account modifications, and reboots. No external daemon, no database, no cron job.

The before and after

Here’s what my server looked like before and after deploying this:

Before:

44 domains × 15 workers = 660 max workers
Any site can consume all 8 cores
Load average: regularly 15-27
Sites going DOWN multiple times daily

After:

44 domains, proportional allocation = 119 max workers
Premium sites: 15 workers (full headroom)
Standard sites: 10 workers (plenty)
Light/dev sites: 1-2 workers (enough to load, can't starve others)
Capped sites: 3 workers (contained)
Load average: 0.5-2.0
Zero downtime in the weeks since deployment

The flagship WooCommerce store didn’t notice any difference — it still has 15 workers, more than enough for its traffic. But when a bot flood or a broken plugin hits a 2-worker site, it uses at most 2 cores. The server barely notices.

Installation

It’s a one-liner:

curl -sL https://github.com/BeforeMyCompileFails/fpm-resource-limiter-cpanel/archive/main.tar.gz | tar xz
cd fpm-resource-limiter-cpanel-main
bash install.sh

After that you’ll find it in WHM under Plugins → FPM Resource Limiter. The CLI is available as fpm-limiter from any terminal.

To remove it (your limits stay in place):

bash /usr/local/fpm-limiter/uninstall.sh

What this does NOT do

I want to be upfront about the limitations:

• No CPU time limiting — this controls how many PHP processes, not how long each one runs. For hard CPU caps, you’d need cgroups or actual CloudLinux.
• No memory limiting — although you can add php_admin_value[memory_limit] to individual pool configs for PHP-level memory caps.
• No I/O or network limiting — that’s kernel-level (cgroups, tc, iptables).
• No fancy dashboard charts — it’s a table with numbers. It does the job.

This is not a full CloudLinux replacement. It’s the one feature from CloudLinux that prevents 90% of shared hosting crashes, extracted into a free, zero-dependency plugin.

The honest bit

Could I have just bought CloudLinux? Sure. But $30/month forever for a feature that’s essentially sed -i 's/pm_max_children: 15/pm_max_children: 3/' some-yaml-files felt like paying for a sledgehammer to hang a picture frame.

If you’re running a 200-account shared hosting business, CloudLinux is probably worth it for the full package. If you’re running a server with 20-50 accounts and your main problem is “one bad site kills everyone” — this does the job for free.

The plugin is MIT licensed, open source, and I built it while my server was literally on fire. Battle-tested doesn’t begin to cover it.

GitHub: https://github.com/BeforeMyCompileFails/fpm-resource-limiter-cpanel

If it saved you from a 3am wake-up call or from a $360/year CloudLinux subscription, consider buying me a coffee: buymeacoffee.com/beforemycompilefails