Reading a cPanel hosting plan in India: websites, inodes, databases, backups and the limits that actually bite
Most cPanel plan tables lead with storage and the number of websites, but those are rarely what stops a small site. The limits that actually bite are file count (inodes), concurrent PHP requests (entry processes), databa
Most cPanel plan tables lead with storage and the number of websites, but those are rarely what stops a small site. The limits that actually bite are file count (inodes), concurrent PHP requests (entry processes), database connections and how far back your backups go, and they usually sit in the terms of service rather than the pricing table. Measure your current site against those four numbers before you compare prices.
This post walks through each line on a typical Indian cPanel plan, what it means in practice, and how to measure your own site so you compare real numbers rather than marketing ones.
1. "Websites": what counts as one
A "website" on a cPanel plan is normally a domain attached to the account: the primary domain plus addon domains. Subdomains and parked (alias) domains usually do not count, but read the plan wording.
The trap is not the count itself. It is that every site on the account shares one pool of CPU, RAM, inodes and entry processes. A "100 websites" plan with 4 CPU and 4 GB RAM does not give each site 4 CPU; it gives 100 sites the same 4 CPU. If one client's WooCommerce store gets busy, the brochure sites next to it slow down too.
Rule of thumb: the website count tells you what the panel will allow. The CPU, RAM and process limits tell you what will actually run well.
2. Storage: almost never the first wall
Storage is the most advertised number and the least likely to hurt. A brochure site of around 40 pages sits comfortably under 1 GB. A WordPress blog with years of uploads is typically 3β8 GB. A WooCommerce store with product photography can reach 15β40 GB, mostly in wp-content/uploads and its generated thumbnail sizes.
Check what you actually use. Over SSH (many hosts enable it on request for shared plans):
# Total size of your web root
du -sh ~/public_html
# Biggest directories one level down, largest last
du -h --max-depth=1 ~/public_html | sort -h | tail -n 15
If you only have the cPanel UI, Disk Usage shows the same breakdown. Local backups, old staging copies and email in ~/mail count against the same quota.
3. Inodes: the limit people discover the hard way
An inode is one file or directory. Most shared hosts cap the number per account, and "unlimited storage" plans almost always carry an inode cap in the fair-use clause, commonly somewhere in the low hundreds of thousands.
WordPress is inode-hungry. Each image upload produces several resized copies, cache plugins write thousands of small files, and a forgotten node_modules or old backup folder can hold more files than the rest of the site combined. Mail counts too: every message in a Maildir is its own file.
Measure it:
# Total inodes used under your home directory (GNU coreutils 8.22+)
du --inodes -s ~
# Which directories hold the most files
du --inodes --max-depth=2 ~ 2>/dev/null | sort -n | tail -n 15
# Portable fallback if --inodes is not supported
find ~ -xdev | wc -l
The usual culprits, roughly in order: page-cache directories, thumbnails in wp-content/uploads, mailboxes nobody cleans, session files in a custom tmp folder, and node_modules or vendor directories uploaded by mistake. Fixing these is usually a cleanup job, not an upgrade.
4. Entry processes: the "508" limit
On shared servers that isolate resources per account (CloudLinux LVE is the common implementation), "entry processes" caps how many requests can be inside your PHP or CGI code at the same moment. It is not visitors per day. A limit of 20 means 20 requests executing simultaneously; the 21st gets an error, typically 508 Resource Limit Is Reached or a 503.
Two things make this tighter than it looks:
- Slow pages hold slots longer. A page that takes 4 seconds to generate occupies a slot ten times longer than one that takes 400 ms. Halving page generation time roughly doubles the traffic that fits under the same cap.
-
Only uncached traffic counts. Requests served from a full-page cache (LiteSpeed's LSCache, for example) never enter PHP, so they don't use entry processes. Logged-in users, cart and checkout pages,
wp-admin,admin-ajax.phpand XML-RPC all bypass page cache.
On CloudLinux hosts, cPanel's Resource Usage page shows entry-process, CPU and memory faults over time. Any non-zero fault count is worth reading. From outside, you can get a rough idea of page generation time:
# Time to first byte, five runs; the query string usually bypasses page cache
for i in 1 2 3 4 5; do
curl -s -o /dev/null -w "%{time_starttransfer}\n" "https://example.com/?nocache=$i"
done
If uncached TTFB is consistently above a second, fix the slow plugin or query before you buy a bigger plan.
5. Databases: count, size and connections
The database line on a plan ("3 databases", "unlimited") is about how many you can create. A WordPress site normally needs one. The limits that matter more:
- Concurrent MySQL connections per account, often in the 20β30 range on shared hosting. A traffic spike that runs into the entry-process cap is usually close to this one as well; "Too many connections" in your error log is the symptom.
-
Database bloat. Oversized
wp_optionsautoload data, years of post revisions and tables left by uninstalled plugins slow every uncached request.
Check sizes in phpMyAdmin's SQL tab:
SELECT table_schema AS db,
ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;
For WordPress, the size of autoloaded options (read on every request):
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');
Adjust the wp_ prefix if yours differs. (WordPress 6.6 added the on/auto values; older sites only use yes.) A few hundred KB is normal; several MB usually means a plugin is storing logs or caches in options.
6. Backups: frequency, retention and who can restore
"Daily backups" is half the story. Ask three questions:
- Retention. How many days back can you go? Malware or a bad plugin update is often noticed days later. One restore point is not enough; two to four weeks is a sensible floor.
- Self-service restore. Can you restore a single file or a single database yourself (JetBackup in cPanel does this), or do you open a ticket and wait?
- Off the server? A backup on the same disk as the site does not survive that disk failing.
Keep your own copy as well. cPanel's Backup page lets you download a full home directory and individual database dumps. Do it before every major update and store one copy outside the host.
7. The other quiet limits
- Outbound email per hour. Often a few hundred messages per account. Order emails plus a newsletter plugin can hit it; use a transactional mail service for bulk sending.
- PHP versions. Check the plan offers current PHP 8.x and lets you choose per domain, so you can upgrade one site at a time.
- SSH and cron. Some plans give SSH only on request. Cron jobs should use absolute paths.
- Renewal price. Many Indian plans headline a 3-year rate. Work out the total over three to four years at the renewal rate, not the first-term rate.
Checklist: measure first, then choose
| Item | How to check your current site | What to look for in the new plan |
|---|---|---|
| Inodes | du --inodes -s ~ |
Published inode cap, ideally 2x your count |
| Peak concurrency | Resource Usage faults; uncached TTFB | Entry-process limit, CPU/RAM per account |
| DB connections | "Too many connections" in error logs | Per-account connection limit |
| Disk |
du -sh ~ including mail and backups |
Storage type (NVMe/SSD) and quota |
| Backups | When did you last test a restore? | Retention days, self-restore, off-server copy |
| Messages sent per hour at peak | Outbound per-hour cap | |
| Cost | Your current renewal price | 3β4 year total at the renewal rate |
If what you measure is close to a plan's limits, pick the next tier or look at a VPS. Shared hosting stops being the right answer when you need root access, need a system package you can't install yourself, or keep hitting CPU and process limits after caching is in place.
Where we fit
Disclosure: this was written by the Bigdomainhost team. We are a small Indian host founded in 2024, and not connected with the US company Big Domain Host LLC.
Our cPanel plans run on LiteSpeed with LSCache, Imunify360 and JetBackup (daily restore points, 30 days), and we publish the fair-use numbers on our docs page rather than burying them: 250,000 inodes, 20 entry processes and 25 concurrent MySQL connections per account, with outbound mail capped at 250 messages an hour. Plan sizes are on the cPanel hosting page. If your site is WordPress and you want staging and caching set up for you, the managed WordPress plans fit better; if you host sites for clients, reseller hosting with WHM gives each client a separate cPanel account with its own limits. For a wider comparison of Indian hosts on renewal price, server location and backups, see our web hosting buying guide.
Originally published by Dev.to WebDev. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.