One overloaded cPanel account can drag down every other site on the same box. A runaway WordPress plugin, a badly written cron script, or a spam-happy contact form can eat CPU, I/O, and memory that other tenants are paying for.
WHM package restrictions exist for exactly this problem. Yet most admins either skip them entirely or set values so aggressive that legitimate customers get throttled during normal traffic spikes.
This tutorial walks through setting realistic WHM package restrictions on a shared or reseller cPanel server. That means CPU and I/O caps via CloudLinux LVE, entry process limits, email sending caps, and MySQL connection limits.
The goal is a config that protects the server without flooding your inbox with tickets from users who did nothing wrong.
Why Default cPanel Limits Aren't Enough
Out of the box, a fresh WHM package usually caps disk space and bandwidth and calls it done. That covers storage abuse. It does nothing for CPU hogging, database connection floods, or an account sending 50,000 emails an hour through a compromised script.
If you're running reseller hosting or managing shared plans, resource isolation matters more than raw specs. A dedicated server with 32 cores can still choke if three accounts run unthrottled PHP loops at the same time.
Quick diagnostic: run top or htop during a slow period. If one or two cPanel usernames keep showing up as top CPU consumers in WHM > Show Current Resource Usage, you have an isolation problem — not necessarily a hardware problem.
Step 1: Enable CloudLinux LVE (or Verify It's Active)
Hard per-account CPU and I/O limits require CloudLinux with LVE Manager. Stock AlmaLinux or CentOS Stream with cPanel won't give you true kernel-level containment — just soft limits.
Check LVE status:
lvectl --lves
If that command doesn't exist, you're on stock RHEL-family cPanel. You can still apply the entry-process and email restrictions below, but per-account CPU/I/O throttling won't be enforced at the kernel level.
Migrating to CloudLinux is worth it for any multi-tenant box. It's a drop-in replacement kernel, not a full OS reinstall.
Step 2: Create or Edit a Hosting Package
Go to WHM > Packages > Edit a Package (or Add a Package for new plans) and scroll to the resource limits section. Here's a sane starting point for a shared hosting tier serving small business sites:
- Disk Quota: 10240 MB
- Bandwidth: 100 GB
- Max Email Accounts: 50
- Max Databases: 10
- Max FTP Accounts: 5
- Max Subdomains: 25
- Entry Processes: 20
Entry Processes controls how many PHP-FPM or CGI processes an account can run at once. Twenty is generous for a low-traffic WordPress site. It also stops a single account from spawning hundreds of workers during a bot attack or crawler storm.
Step 3: Set CPU and I/O Limits via LVE
If CloudLinux is active, go to WHM > LVE Manager > Limits by Package. This is where the real containment happens.
| Plan Tier | vCPU % | I/O (MB/s) | IOPS | Memory (MB) |
|---|---|---|---|---|
| Starter shared | 25% | 10 | 1024 | 768 |
| Business shared | 50% | 20 | 2048 | 1536 |
| Reseller premium | 100% | 40 | 4096 | 3072 |
These numbers assume a modern NVMe-backed VPS or dedicated box. Still on spinning disks? Drop the I/O and IOPS columns by roughly 40 percent. Mechanical drives choke faster under concurrent random reads.
Apply the limits, then monitor for 48 hours with lveinfo --list --fields=uid,cpu,mem,ep to confirm real accounts aren't hitting the ceiling during normal traffic.
If a legitimate WooCommerce store maxes out CPU during a flash sale, that's a package tier problem, not a security issue. Upsell them to a higher plan instead of raising the shared-tier limit for everyone else.
Step 4: Cap Email Sending Per Hour
Runaway contact forms and compromised WordPress installs are the most common source of outbound spam floods. They'll tank your server's IP reputation fast.
Set this at WHM > Edit Package > Max Hourly Email by Domain, or globally at WHM > Tweak Settings > Mail.
A reasonable default for a shared account is 200-300 emails per hour. Legitimate transactional email — order confirmations, password resets — rarely exceeds that unless the site is genuinely high-volume. Those accounts belong on a plan with a raised limit and, ideally, their own dedicated sending IP.
Already chasing deliverability problems? It's worth reviewing the email bounce troubleshooting tutorial alongside these limits. Bounce spikes and hourly caps are often symptoms of the same root cause: a compromised account.
Step 5: Limit MySQL Connections Per User
A single poorly optimized WordPress plugin can open dozens of persistent database connections and starve MySQL for everyone else on the server. Set per-user connection caps in /etc/my.cnf:
[mysqld] max_user_connections = 15 max_connections = 500
Restart MySQL after editing:
systemctl restart mysql
Fifteen connections per cPanel user is plenty for typical WordPress or PHP apps using connection pooling correctly. If a client's app genuinely needs more, that's a conversation about query efficiency — not a reason to raise the ceiling server-wide.
Step 6: Watch for False Positives
Aggressive limits create support tickets. Before rolling changes to production, check these common false-positive triggers:
- WooCommerce during sales — spikes in entry processes and CPU are normal during checkout rushes, not abuse.
- Backup jobs — I/O limits can make nightly backups crawl if scheduled during business hours. Stagger cron-based backups across off-peak windows.
- Image-heavy sites without caching — high entry-process counts often mean missing page caching, not malicious activity. Pair limits with a caching layer rather than raising the cap.
- Cron-triggered plugins — WP-Cron running on every page load under heavy traffic can spike CPU. Moving to a real system cron job usually fixes this; see the cPanel cron job setup tutorial for the exact steps.
Step 7: Alert on Repeat Offenders
One-off spikes are normal. Repeated hits against the same account's limits over days or weeks usually mean malware, a compromised plugin, or a genuinely undersized plan.
Set up a simple check:
lveinfo --list --fields=uid,cpu_hits,mem_hits --sort=cpu_hits
Run this daily via cron and pipe the output somewhere you'll actually see it — a Slack webhook, email digest, or lightweight dashboard. No alerting in place yet? The server monitoring tutorial covers setting up resource alerts that pair well with LVE data.
For accounts that repeatedly hit limits, run a quick malware scan before assuming it's just heavy legitimate usage:
find /home/username/public_html -name "*.php" -mtime -7 -exec grep -l "eval(base64" {} \;
Checklist Before You Deploy Package Changes
- Confirm CloudLinux LVE is active if you need hard CPU/I/O caps
- Set entry process limits per package tier, not globally
- Cap hourly email sending per domain, not just per account
- Set MySQL max_user_connections in my.cnf
- Test on a staging package before applying to live accounts
- Monitor for 48-72 hours and log false positives
- Document your tier structure so upgrades are a simple package change, not a manual limit edit
Building out reseller-ready plans from scratch? Pair this with proper package sizing. The WHM account package setup tutorial covers disk and bandwidth allocation in more depth, so your tiers don't oversell resources you can't actually deliver.
Resource isolation only works as well as the hardware underneath it. If your current node is already maxed out at idle, no amount of LVE tuning will fix that. HostMyCode's managed VPS hosting and reseller hosting plans run on NVMe storage with CloudLinux available out of the box, so package restrictions actually have room to work.
FAQ
Do I need CloudLinux for WHM package restrictions to work?
You can set entry process, email, and database limits without it. But hard CPU and I/O throttling per account requires CloudLinux's LVE kernel. Without it, cPanel's built-in limits are advisory at best.
Will strict limits slow down legitimate WordPress sites?
Only if set too aggressively for the traffic tier. Pair reasonable limits with page caching and real visitors rarely hit a ceiling — most limit violations trace back to bots, malware, or missing caching.
How often should I review package limits?
Check LVE hit logs weekly and revisit tier definitions every six months, or immediately after adding a new hardware node with different specs.
Can I apply different limits to existing accounts without rebuilding packages?
Yes. Use WHM > Manage User's Features or LVE Manager's per-account override to adjust individual accounts without touching the whole package definition.
What's a safe entry process limit for a busy WooCommerce store?
Start at 30-40 for stores with real traffic, and pair it with object caching. If checkout pages still spike processes near the limit during sales, move the account to a higher tier or a dedicated resource pool.