Shared Hosting vs VPS in 2026: Where the Real Breakpoint Is

Almost every shared-hosting-versus-VPS guide ends the same way: move up "when you grow". That advice is useless because it never says what to measure. This article gives you the two numbers that actually decide it — peak concurrency and workload — with the limits documented by the platforms themselves, a worked example you can reproduce, and a decision table.

The short version: the breakpoint is almost never a monthly-visits figure. A site with 200,000 monthly visits spread evenly can sit happily on shared hosting, while a site with 20,000 visits that all arrive in a five-minute window, or that needs a background worker, cannot. Concurrency and workload are the axes that matter.

Why monthly visits is the wrong metric

Shared hosting providers do not cap your account by pageviews. They cap it by resource limits enforced per account. On the majority of cPanel-based shared platforms those limits are enforced by CloudLinux LVE (Lightweight Virtual Environment), which isolates each account into its own resource cage. The limit that decides whether your visitors see your site or an error page is not bandwidth — it is entry processes.

Per CloudLinux's own documentation, the EP (Entry Processes) limit is the “max number of concurrent connections to Apache dynamic scripts”, and its default value is 20. When an account exceeds it, the server returns HTTP 508 (Resource Limit Reached). A separate limit, NPROC (total processes and threads, default 100), triggers 500 or 503 errors when hit. So the ceiling on a shared account is the number of dynamic requests you can have in flight at the same instant — not how many you serve over a month.

The documented shared-hosting limits

These are the reference default and recommended values published in CloudLinux's Limits documentation. Individual hosts raise or lower them, so treat them as the baseline, not a universal law — check your own account's limits in cPanel under "Resource Usage".

Note that CloudLinux's own knowledge base lists a lower PMEM default (512 MB) for a typical account than its main documentation (1024 MB); the two pages disagree, which is a useful reminder that the exact number is set by your host, not by a single fixed standard.

Turning the EP limit into a real traffic figure

Here is where the concrete number comes from — and I am going to show the arithmetic so you can check it against your own site rather than trust a figure I made up.

Concurrency, throughput and response time are related by a simple queueing identity (Little's Law): throughput = concurrency ÷ average response time. The EP limit is your concurrency ceiling for dynamic pages. So:

1. If a PHP page takes 200 ms to generate, an EP limit of 20 allows roughly 20 ÷ 0.2 = 100 dynamic requests per second before requests start queueing and eventually returning 508.
2. If your pages are slow — say 1 second each, common on an untuned WordPress install with no page cache — the same limit allows only about 20 requests per second.

Two things fall out of this. First, the figures above are peak capacity, not monthly totals: 100 dynamic requests/second sustained would be an enormous site, but a marketing email or a news spike can push a small site past its EP ceiling for a few minutes and cause visible 508s. Second, your response time matters more than your traffic. Adding full-page caching (so most visitors are served static HTML that never consumes an entry process) can multiply your effective capacity without touching the plan — which is exactly why "just upgrade to a VPS" is often the wrong first move.

This refines the rule of thumb in our own shared vs VPS vs dedicated comparison ("under ~10k visits/month, shared hosting is fine"): that holds for an average site, but a cached brochure site can go far higher, and a heavy, uncached, logged-in application can hit the wall well below it.

The workload breakpoint: things shared hosting simply cannot do

The concurrency limit is a matter of degree — you can tune around it. The second breakpoint is binary. Some workloads are not slow on shared hosting; they are impossible, because you have no root access and long-running processes are disallowed.

1. Persistent daemons. Redis, Memcached (as your own instance), Elasticsearch, or a Node.js service need a process that stays resident. Shared platforms are built around short-lived request handling; as 20i's support documentation states plainly, you cannot run daemons or long-running server programs on their shared hosting.
2. Background queue workers. A Laravel queue:work process, a Celery worker, or any always-on job runner is a persistent process — the same restriction applies, and each one you did manage to start would consume an entry process and NPROC slot.
3. Reliable, fine-grained cron. Shared hosts impose minimum intervals, runtime caps and I/O throttling on cron jobs, and when many accounts run jobs at once the scheduler queues can delay or truncate them. If your app depends on a job firing every minute, on time, shared cron is the wrong tool.
4. Custom system software and extensions. A specific PHP extension, a particular Python/Node runtime version, a system library, or your own Nginx config all require root you do not have on shared hosting.

If any of these is a hard requirement, the traffic question is moot — you have already crossed the breakpoint, regardless of how small your site is. Our guide on how to choose the right VPS plan covers sizing once you are on the other side of that line.

What a VPS actually costs you

Because Karizanta sells VPS plans, it is worth being blunt about the tradeoff a VPS introduces rather than only its benefits. On a VPS the resource ceiling becomes your own RAM and CPU rather than a per-account cage — but nothing tunes itself. You now own updates, security hardening, and capacity planning.

Concurrency on a VPS is governed by how you size your PHP-FPM pool. The standard formula, as documented in hosting knowledge bases such as Kinamo's, is:

pm.max_children = (Total RAM − RAM for OS/database/cache − ~10% buffer) ÷ average memory per PHP process

The one number you must not guess here is average memory per PHP process — it varies from tens of megabytes to well over a hundred depending on the application, so measure it on your own server (ps -ylC php-fpm --sort:rss) rather than copying a figure from an article. Set pm.max_children too high and heavy traffic swaps the box to death; too low and you throttle yourself. A VPS gives you the room to get this right, and the responsibility to actually do it. If that responsibility is unwelcome, a well-tuned shared plan or managed hosting is the honest recommendation. Our initial VPS setup checklist is the starting point if you do make the move.

Decision table

The decision rule

Before you upgrade for performance, do one thing: add full-page caching and re-measure. A large share of "we outgrew shared hosting" cases are really "we never cached anything", and moving an uncached app to a VPS just relocates the same slow pages onto hardware you now have to babysit. Upgrade when you are still hitting concurrency limits with caching in place, or the moment you need a workload — a daemon, a worker, root — that shared hosting structurally cannot provide. That second test, not any visit count, is the real breakpoint.

Sources

1. Limits — CloudLinux OS Product Documentation (EP, NPROC, PMEM, SPEED defaults and error codes) (unknown)
2. Determining the correct number of child processes for PHP-FPM — Kinamo knowledge base (unknown)
3. Can I run daemons on the shared hosting platform? — 20i Support Database (unknown)
4. Why cron jobs are unreliable with shared hosting — webhosting.de (unknown)

{"@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [{"@type": "Question", "name": "How many visitors can shared hosting handle before I need a VPS?", "acceptedAnswer": {"@type": "Answer", "text": "There is no fixed visitor number, because shared hosting is limited by concurrent dynamic requests, not monthly visits. On CloudLinux-based hosts the default entry-process (EP) limit is 20 simultaneous PHP requests. With 200 ms pages that is roughly 100 requests per second at peak; with slow 1-second pages, only about 20. Add caching before assuming you have outgrown it."}}, {"@type": "Question", "name": "What error means I have hit my shared hosting limit?", "acceptedAnswer": {"@type": "Answer", "text": "An HTTP 508 \"Resource Limit Reached\" error means your account hit its entry-process (EP) limit — too many dynamic requests at once. 500 or 503 errors can indicate the NPROC (total process) limit. Seeing 508s during traffic spikes, after caching is already enabled, is a clear signal to move to a VPS."}}, {"@type": "Question", "name": "Can I run Redis, a queue worker, or Node.js on shared hosting?", "acceptedAnswer": {"@type": "Answer", "text": "Generally no. These need persistent, long-running processes and often root access, which shared hosting does not provide. Providers such as 20i state you cannot run daemons or long-running server programs on shared plans. If your application requires them, you need a VPS regardless of how little traffic you have."}}, {"@type": "Question", "name": "Is a VPS always faster than shared hosting?", "acceptedAnswer": {"@type": "Answer", "text": "Not automatically. A VPS gives you dedicated resources and root access, but you must tune it yourself — for example sizing PHP-FPM's pm.max_children to your RAM. An uncached, badly configured app can run no faster on a VPS than on shared hosting, and you also take on OS updates and security. Managed VPS or optimised shared hosting can be the better choice if you do not want that responsibility."}}, {"@type": "Question", "name": "Does upgrading to a VPS fix slow pages?", "acceptedAnswer": {"@type": "Answer", "text": "Only if the slowness is caused by resource limits. If pages are slow because nothing is cached or the code is inefficient, a VPS moves the same slow pages onto hardware you now have to manage. Add full-page caching and re-measure first; upgrade when you are still constrained after that."}}]}