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 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.

Shared hosting, VPS and managed platforms side by side

Shared hostingVPSManaged platform
What you getOne account on a server shared with other customersA virtual machine with its own CPU, memory and diskYour app deployed on the provider’s infrastructure
LimitsAccount-wide caps on memory, processes and simultaneous requestsThe size of the machinePer-plan quotas on builds, functions and traffic
Root accessNoYesNo
Who updates the operating systemThe hostYou, unless you pay for a managed VPSThe provider
Node.js, Docker, background jobsNode.js on some plans; no Docker; long jobs get stoppedAnything the machine can runDepends on the platform
Typical fitWordPress, small PHP or static sitesWeb apps, several sites, custom software, your own servicesStatic and Next.js sites deployed from Git
ExampleHostinger web hosting: 1 to 3 GB of memory per planHostinger KVM 1: 1 vCPU, 4 GB of memory, 50 GB NVMeVercel, 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.

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.