Shared hosting and a VPS can cost almost the same per month and still be completely different products. On shared hosting, your site lives in one account among many on the same server, and the host caps how much memory, how many processes and how many simultaneous requests each account may use. A VPS, a virtual private server, is a virtual machine of your own, with guaranteed resources, full control and full responsibility. This guide explains both, shows the limits a shared account actually runs into, using our own as the example, and gives a simple rule for when moving to a VPS is worth it.
— Guide
VPS vs shared hosting: what a VPS is, and when you actually need one
Shared hosting rents you a slice of a server with limits you cannot see until you hit them. A VPS gives you a whole virtual machine and all the work that comes with it. Which one fits, measured against the limits we ran into on our own account.
Shared hosting, VPS and managed platforms side by side
| Shared hosting | VPS | Managed platform | |
|---|---|---|---|
| What you get | One account on a server shared with other customers | A virtual machine with its own CPU, memory and disk | Your app deployed on the provider’s infrastructure |
| Limits | Account-wide caps on memory, processes and simultaneous requests | The size of the machine | Per-plan quotas on builds, functions and traffic |
| Root access | No | Yes | No |
| Who updates the operating system | The host | You, unless you pay for a managed VPS | The provider |
| Node.js, Docker, background jobs | Node.js on some plans; no Docker; long jobs get stopped | Anything the machine can run | Depends on the platform |
| Typical fit | WordPress, small PHP or static sites | Web apps, several sites, custom software, your own services | Static and Next.js sites deployed from Git |
| Example | Hostinger web hosting: 1 to 3 GB of memory per plan | Hostinger KVM 1: 1 vCPU, 4 GB of memory, 50 GB NVMe | Vercel, Netlify |
Plan figures from Hostinger’s own pages, checked on 10 October 2026. A managed platform is listed for comparison; it is a third way to host, not a kind of VPS.
The difference in one paragraph
On shared hosting you rent an account, not a machine. The host runs one large server, puts many customers’ accounts on it, and keeps any one of them from taking over by capping what each account may use. The software, the security updates and the control panel are the host’s job. On a VPS you rent a virtual machine: a slice of a physical server with its own operating system and resources reserved for you, which you control completely and therefore also have to look after. Shared hosting is a flat; a VPS is a house on a shared plot.
What shared hosting limits, exactly
Many shared hosts, Hostinger among them, use CloudLinux, which puts each account in its own lightweight container and limits its CPU, memory, disk speed, number of processes and number of entry processes, roughly the requests the account may handle at the same moment. CloudLinux’s own defaults are one CPU core, 1 GB of memory, 100 processes and 20 entry processes per account, and hosts set their own values from there. Hostinger’s current web hosting plans, for example, give an account 1, 2 or 3 GB of memory.
What happens at the limit is simple: requests that do not fit are refused. Hostinger’s help pages say that when a plan reaches its process or memory limit, visitors may see a 503 Service Unavailable error, and that hitting the limit 10 to 20 times in a month is a strong sign the site needs more resources. For a brochure site or a small WordPress install that day may never come. For a shop during a sale, or an application that keeps processes running, it comes sooner than the price suggests.
What we ran into on our own shared account
On shared hosting the limits are invisible until you hit them, and they apply to the whole account, not to one site. Our three websites, levelui.com, .ro and .de, run as Node.js applications on a shared hosting account that also holds three other sites. In July 2026 we redeployed all three domains within two minutes; the account hit its cap of 120 processes, and two of the domains answered with errors until old processes were stopped by hand. Nothing was wrong with either site. They were simply waiting for process slots that the other deploys were holding.
Other limits surfaced the same way, one at a time. A process that grows past about 2 GB of memory is killed, which is why our site can no longer be built on the server and is built on our own machine instead. Background processes are stopped after about an hour, and there is no way to schedule jobs except through the host’s panel. And inside the account, Node.js reports the physical server’s 64 processors and 514 GB of memory, so software that sizes itself from what it sees plans for resources it will never be allowed to use. None of this is a complaint: it is what shared hosting is. We describe the cold starts and the process clean-up in detail in what your server does to PageSpeed.
What a VPS gives you
A VPS removes the account-wide caps and replaces them with the size of the machine. Hostinger’s smallest, KVM 1, has 1 virtual CPU, 4 GB of memory and 50 GB of NVMe storage, and on 10 October 2026 cost $6.49 a month paid upfront, renewing at $11.99; the larger plans double each figure up to 8 CPUs and 32 GB. You get root access, so you can install anything: Node.js, Docker, a database, a queue, scheduled jobs that run as long as they need. Nobody else’s deploy can take your process slots, because there are none to take.
The other side is that a VPS is usually self-managed: Hostinger’s own FAQ describes its VPS plans that way. The operating system, its security updates, the firewall, SSH access, backups that you have actually restored once, and monitoring that tells you the site is down before a customer does are all yours. That is real, recurring work, and on a VPS nobody does it unless you, or someone you pay, does.
When shared hosting is enough
For most small business websites, shared hosting is the right answer and moving would only add work. A WordPress site with steady traffic, a small shop, a static site or a landing page fits comfortably inside a decent plan, and the host’s patching is worth more than root access you would never use. If the site is static, it may not need a server at all: finished pages can be served from a CDN for very little, as we explain in static vs dynamic websites. Before upgrading because the site feels slow, check that the slowness is the server and not the pages, because a heavy theme and unoptimised images will be just as slow on a VPS.
When to move to a VPS
Move to a VPS when you need to run your own processes, or when you hit the shared limits more than occasionally. The first case covers Node.js or Python applications, Docker containers, background workers, scheduled jobs that run longer than a few minutes, and software that has to listen on its own port. The second is measurable: if the host’s resource page shows the account at its memory or process limit several times a month, or visitors see 503 errors under ordinary traffic, the plan is too small.
There are softer reasons too. Several sites on one account slow each other down; a VPS separates them, or lets you give each one its own container. Compliance requirements can ask for an isolated server. And sometimes the trigger is the build: a modern JavaScript site can need more memory to build than a shared account allows, as ours did. Each of those is a reason to move. Raw traffic, on its own, usually is not; a cache or a CDN in front of a shared plan handles more visitors than people expect.
VPS vs cloud hosting
“Cloud hosting” means different things at different companies, which is why the comparison confuses people. At many web hosts it is a larger, managed shared plan: Hostinger’s Cloud Startup, for example, gives an account 4 GB of memory and 4 CPU cores for up to 100 websites, still without root access. At Amazon, Google or Microsoft, a cloud server is a virtual machine, a VPS in everything but name, billed by the hour and able to change size. Read what the plan includes, root access, guaranteed resources, who patches the system, rather than what it is called.
What we use, and what we recommend
Our own sites stay on shared hosting: since we started building them on our own machine and fixed a housekeeping script of ours that kept restarting them, the account handles them well, and we know where its limits are. Client applications on Node.js are a different case, because they need their own processes and room to build, so our Node.js Hosting + Monitoring package puts them on a managed VPS, with daily backups and monitoring included, so the self-managed part is not left to you.
Our recommendation is the order to ask the questions in. Does the site need a server at all, or can it be static? If it needs one, does it run anything besides PHP? If not, a good shared plan is enough until its own resource page says otherwise. If it does, take a VPS and decide on day one who will maintain it, because that decision costs more over a year than the server does. A maintenance retainer is one answer; our hosting and deployment work is another.
Sources
Plan figures and prices from Hostinger’s own pages and the CloudLinux documentation, checked on 10 October 2026. The account limits we describe are from our own production incidents between July and September 2026.
- CloudLinux OS documentation — Limits ↗
The per-account limits shared hosts set: CPU, physical memory, IO, processes and entry processes, with their default values.
- Hostinger — Parameters and limits of hosting plans ↗
Memory, CPU cores and inodes per web and cloud hosting plan.
- Hostinger — What to do if your hosting plan limits are reached ↗
At the process or memory limit visitors may see a 503 error; hitting it 10 to 20 times a month means the site needs more resources.
- Hostinger — VPS hosting ↗
KVM 1 to KVM 8 specifications and prices; full root access; self-managed.
— FAQ
Frequently asked questions
Not sure your site has outgrown its plan?
We read your account’s resource usage, find where the time goes, and tell you whether a VPS would help or whether the fix is in the site.