CloudLinux is the operating system most cPanel hosts run under the control panel, and its Lightweight Virtual Environment (LVE) is the reason a shared account has a CPU figure, a memory figure and a process count instead of an "unlimited" promise. This guide explains what each LVE limit caps, what you see when a site hits one, how to read the Resource Usage screen in cPanel, and how to choose a plan from the numbers a host publishes. The limit definitions below are taken from the CloudLinux documentation as read on 1 November 2026.
What CloudLinux adds to a cPanel server
A plain cPanel server runs every account on one Linux kernel with no wall between them. One site that loops a PHP script or gets hit by a scraper can take the CPU and memory every other account on the box needs. CloudLinux replaces that kernel with one that puts each account in its own LVE, a container with its own CPU, memory, disk-throughput and process ceilings, and adds three things on top:
- CageFS: a virtualised file system that shows each account only its own files, so a compromised neighbour cannot read your configuration files or see which other sites share the server.
- PHP Selector: a per-account choice of PHP version and extensions, which is what the Select PHP Version icon in cPanel drives.
- LVE Manager: the WHM interface where the host sets the limits per package, and the Resource Usage screen in cPanel that shows you how close you are to them.
The result is that a shared account behaves like a very small virtual server for resource purposes while still being managed through cPanel. It is also why the better cPanel hosts publish CPU cores and RAM per plan: those figures are LVE limits, and a plan with "0.5 cores and 512 MB" is telling you exactly what it will enforce. MassiveGRID's cPanel reseller plans run CloudLinux with CageFS, and the cPanel hosting plans publish a CPU-core and RAM allocation for each of the ten tiers, from half a core and 512 MB on Starter to 16 cores and 32 GB on Ultimate.
The LVE limits, one by one
CloudLinux documents eight limits. The table gives each limit, what it caps and what the documentation says happens when it is reached.
| Limit | What it caps | What you see when it is reached |
|---|---|---|
| SPEED | CPU, "in terms of % of a single core, or as a fixed number of Hz" | Nothing breaks; the documentation says "the site will start responding slower". CloudLinux recommends hosts set it "not less than 100%", because smaller limits cause context switching that wastes CPU. |
| PMEM | Physical memory "actually used by end customer's processes" | CloudLinux first reclaims disk cache, then "will kill some of the processes within that LVE", which usually surfaces as 500 or 503 errors. |
| VMEM | Virtual memory processes may allocate | Allocations fail and the process dies; the documentation now calls VMEM deprecated and recommends setting it to 0, so most hosts no longer use it. |
| IO | Disk throughput in KB/s | Processes are throttled: "they just work slower when the limit is reached". |
| IOPS | Read and write operations per second | "The read/write operations stop until current second expires". |
| EP | Entry processes, the number of concurrent requests entering the LVE (PHP, CGI, SSH sessions, cron jobs) | The web server cannot place the request in the LVE and "will return error code 508". This is the limit behind almost every "508 Resource Limit Is Reached" page. |
| NPROC | Total processes and threads inside the LVE | "No new process can be created (until another one dies)"; the web server may return 500 or 503. |
| Inodes | The number of files and folders, enforced through disk quotas | A soft limit "can be exceeded for a period of time"; a hard limit "prevents a user from writing data to disk", so uploads, caches and email delivery start failing. |
Two of these matter far more than the others for a normal website. EP decides whether visitors get a page or a 508 when traffic arrives in a burst, and PMEM decides whether a heavy page builder or a WooCommerce checkout finishes rendering. SPEED only makes things slower, and IO and IOPS rarely bite unless a backup plugin or an import is running.
How to read the Resource Usage screen in cPanel
Open Metrics > Resource Usage in cPanel. The summary tells you whether the account has hit a limit in the last 24 hours; Details shows a graph per limit with the current value, the limit and a fault counter. Faults are what you care about: a CPU graph that sits at 100% for an hour is a site that is slow, while an EP fault counter above zero is a site that returned 508 pages to real visitors.
- CPU at the ceiling with no faults: the site is CPU-bound. Server-level caching (LiteSpeed Cache on a LiteSpeed host, otherwise a page cache plugin) removes most of it, because a cached page costs almost no CPU.
- EP faults: too many requests arriving at once. Bots and uncached wp-admin or cart pages are the usual cause; caching, blocking bad bots in
.htaccessor Imunify360, and moving cron jobs off peak hours fix most cases. If faults persist with a clean site, the plan is too small. - PMEM faults: single requests that need more memory than the limit allows. Raise
memory_limitonly if the plan has headroom; otherwise find the plugin or import that needs it. - IO or IOPS at the ceiling: almost always a backup plugin, a media import or a log file being written every request. Schedule the first two at night and switch off debug logging.
The cPanel settings for WordPress performance guide covers the caching and PHP settings that cut CPU and entry-process usage on a typical site.
Why sites return 508 errors, and what fixes them
A 508 does not mean the server is down. It means your account reached its entry-process limit at that second, so the web server refused the request rather than let it slow everyone else. The host's other customers are unaffected, which is the point of CloudLinux, but your visitor saw an error page. In order of how often they are the cause:
- Uncached dynamic pages under load. Each uncached request holds an entry process for as long as PHP takes to build the page. With caching, most requests never reach PHP and never count.
- Crawlers and scrapers. A badly behaved bot can open twenty connections at once. Rate limiting in the firewall or a robots rule for the worst offenders removes the spikes.
- Slow external calls. A plugin that waits on a payment gateway, a licence server or an API keeps its entry process open for the whole wait. Timeouts and background queues fix it.
- Cron jobs and backups at peak time. They count as entry processes too. Move them to the quiet hours.
- Too small a plan. If the site is cached, the bots are blocked and faults still appear at your normal traffic, you need more entry processes and CPU, which on a well-run host means the next plan rather than a VPS.
Sizing a plan by its published limits
Because LVE limits are what a host actually enforces, the useful way to compare shared plans is by the numbers, not by adjectives. A host that writes "unlimited" is still enforcing an LVE; it has simply chosen not to tell you the figure. A host that publishes cores and RAM is telling you.
As a rule of thumb for a cached WordPress site: half a core and 512 MB serve a brochure site or a blog with light traffic; one core and 1 GB serve a business site with a page builder; two cores and 2 GB serve a busy site with forms and search; and a WooCommerce shop should start at three cores and 6 GB because cart, checkout and search pages cannot be cached and each one holds an entry process while PHP runs. Those four steps are, not by accident, the Starter, Pro, Ultra and Business tiers of MassiveGRID's cloud cPanel hosting, which start at $2.42 a month and run on a high-availability cluster rather than a single server; the plans page has a picker that maps a site type to a tier.
When the published CPU and RAM are the same on two hosts, the next things to compare are the web server (LiteSpeed serves cached pages without touching PHP at all, which is why it matters so much under an EP limit), the storage (NVMe keeps IO limits from being the bottleneck) and whether the server itself has any failover. The noisy neighbour guide explains what isolation can and cannot do, and the cheap cPanel hosting comparison lists what each budget host publishes.
What CloudLinux does not fix
CloudLinux protects you from your neighbours and tells you honestly what your account may use. It does nothing about the server underneath. If the host's hardware fails, every LVE on it goes offline together, and a kernel update still needs a reboot. That is a separate question from resource limits, and it is answered by the infrastructure: whether the cPanel server is one machine with a refund policy or a node in a cluster that can restart it elsewhere. The two questions, how much may I use and what happens when the machine dies, are the two things to settle before paying for any shared plan.
Frequently Asked Questions
What is CloudLinux in cPanel hosting?
CloudLinux is a Linux operating system built for shared hosting that runs underneath cPanel. Its LVE kernel feature gives every account its own CPU, memory, disk-throughput and process limits, CageFS hides other accounts' files, and PHP Selector lets each account pick its PHP version. Most cPanel hosts run it; the Resource Usage screen in cPanel is the visible part.
What does "508 Resource Limit Is Reached" mean?
The account hit its entry-process (EP) limit, which caps how many requests may run inside the LVE at the same moment, so the web server returned 508 instead of starting another PHP process. Other accounts on the server are unaffected. Caching, blocking aggressive bots, fixing slow external calls and moving cron jobs off peak hours remove most 508s; if they persist on a clean, cached site, the plan is too small.
Does CloudLinux make a website faster?
Not by itself. It stops a neighbour from slowing you down and enforces the CPU and memory your plan promises, but your own speed depends on the web server, caching and the plan's limits. A site that hits its CPU (SPEED) limit simply runs slower; server-level caching such as LiteSpeed Cache is what cuts the CPU a page needs.
How do I know which plan I need?
Open Resource Usage in cPanel on your current host and look at the fault counters over a normal week. EP or PMEM faults on a cached site mean the next tier up. As a starting point, half a core and 512 MB suit a brochure site, one core and 1 GB a business WordPress site, two cores and 2 GB a busy site, and three cores and 6 GB a WooCommerce shop, which are the Starter, Pro, Ultra and Business tiers of MassiveGRID's cPanel hosting.
cPanel hosting with published CPU and RAM per plan
MassiveGRID cPanel hosting lists the CPU cores, RAM, NVMe storage and traffic of each of its ten plans, from half a core and 512 MB at $2.42 a month to 16 cores and 32 GB, and runs every account on a high-availability cluster with LiteSpeed, free SSL, daily backups, Imunify360 and a 100% uptime SLA.
Compare the cPanel Plans