Shared hosting vs VPS: which do you need?

Shared hosting vs VPS: the short answer

Shared hosting vs VPS is not a speed question. On shared hosting you rent an account on a machine that somebody else configures, patches and shares between hundreds of customers. On a VPS (virtual private server) you rent a whole operating system with root access, so you install what you want and you also repair what you break.

Three things really differ. You either have root or you do not. Your memory is either assigned to you or borrowed from a pool. And when the server stops answering at midnight, either the host fixes it or you do. Everything on a feature grid follows from those three.

If your site is pages, images and a contact form, shared hosting is the correct answer and it costs less. If your site needs a program that keeps running while nobody is visiting, you need a VPS.

What shared hosting actually gives you

One Linux server runs many customer accounts at once. Each account is a home directory with a document root, a database and a mailbox, and a single web server, usually Apache or LiteSpeed, serves every site on the box. You get a control panel in place of a shell prompt. You do not get root, so you cannot install a package, open a port or start a background service.

Most shared hosts run CloudLinux, which puts each account in its own container with a hard cap on processor time and on the number of processes you may run at once. Crossing the process cap does not make your site slow. It makes the server return an error page reading 508 Resource Limit Is Reached. That page is your own account hitting its ceiling, not a neighbour taking your share.

The trade is deliberate. You give up control, and in return the host patches the kernel, updates PHP, renews the certificate and keeps a nightly backup. For a great many sites that is a good trade.

What a VPS actually gives you

A VPS is a virtual machine running on a host server. Under KVM, the hypervisor behind most Linux VPS plans, your instance boots its own kernel and holds its own IP address, its own firewall and its own init system. sudo works. apt install works. A program you start through systemd keeps running after you log out, restarts after it crashes, and comes back after a reboot.

That same root access is why the security of the machine becomes your job. Nobody else is watching it. The range of things people run on a VPS is wide for exactly this reason: the box does whatever a Linux server can do.

Difference 1: root access, and what it unlocks

Root is the difference that produces all the others. With it you install any package from the distribution, bind any port, write a systemd unit, read every log on the machine and change kernel settings with sysctl. Without it you get the list the panel offers: a PHP version selector, a fixed set of extensions and a form for cron jobs.

On a VPS you can always ask the machine what is listening:

ss -ltnp

Every line is one open socket with the process that owns it, so a service that failed to start shows up as a missing line. On shared hosting the question has no answer, because ports 80 and 443 belong to the host's web server and nothing you write can take one.

Difference 2: assigned memory against borrowed memory

Shared hosting is sold on the assumption that few accounts are busy at the same moment. The memory in the machine is a pool, and your account's share of it is a limit rather than a reservation. When your share runs out, PHP processes are killed and visitors get a 500 or a 508.

On a VPS the memory in your plan belongs to your instance. free -m reports it, and no process outside your virtual machine can take it away.

Processor time is the honest exception. Most VPS plans share physical cores between guests, and you can measure that yourself:

vmstat 1 5

The st column is steal time: the share of time your virtual processor was ready to run while the physical core was handed to another guest. A steady value of a few percent is normal. A sustained double-digit number means the host is oversubscribed, and it is a figure you can quote in a support ticket. On shared hosting there is no equivalent reading, because every tool that would show it needs root. Storage behaves the same way, which is why the disk type behind a VPS plan matters, and why it is worth measuring a new VPS yourself in the first week rather than trusting the sales page.

Difference 3: who is responsible when it breaks

On shared hosting the host owns the operating system, the web server, the PHP build, the certificates and the nightly backup. When the machine stops answering you open a ticket, and somebody is already working on it. The cost of that is the other side of the same rule: you cannot ask them to install something they do not support.

On an unmanaged VPS the provider owns the hypervisor, the network and the power. Everything from the kernel upwards is yours. Security updates, the firewall, backups, certificate renewal and monitoring are all your work, and support will not log in to debug your web server config. Plan for that on day one: the first ten minutes on a new VPS, then a firewall you understand, automatic security updates and backups you have restored at least once.

When shared hosting is the right answer

A brochure site is the clearest case: some pages, images, a contact form, perhaps WordPress with a caching plugin, and a few thousand visits a day. No background jobs. No unusual runtime. Nothing that has to stay in memory between requests. Shared hosting serves that site well, costs less than any VPS, and hands the maintenance to people who do it full time. Moving it to a VPS buys nothing and adds a job you did not have.

There is a second case that gets less attention. If nobody on your side wants to read a log file or run apt upgrade, shared hosting is the safer choice. An unpatched VPS with an open database port is a worse outcome than a shared account that a professional keeps current. Control is only an advantage when somebody uses it.

Sign 1: you need a program that keeps running

A daemon is a program that stays in memory and waits for work: an API, a chat bot, a queue worker, a game server. Shared hosting runs your code only when a request arrives, and anything you leave running from an SSH (secure shell) session is killed, because a long-lived process counts against the account's process cap.

On a VPS the same program becomes a systemd unit:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status should print Active: active (running) with a process ID. If it prints Active: failed (Result: exit-code), the reason is in journalctl -u myapp -n 50, which shows the program's own output at the moment it stopped. Restart=always in the unit file brings it back after a crash, and enable brings it back after a reboot. Writing systemd services and timers is the first VPS skill worth learning properly.

Sign 2: you need a runtime the panel does not offer

The panel gives you a list. If your application needs a language version outside that list, a library that has to be compiled, ffmpeg, a headless browser or a database that is not MySQL, shared hosting has nowhere to put it. Installing software needs root, and the account has no compiler and no development headers, so a build fails before it produces anything.

On a VPS you install it with apt install, or you run it in a container and keep the host clean. Docker Compose on a VPS is the usual path once the application has more than one moving part.

Sign 3: your cron job has to run on time

Shared hosts accept cron jobs through a form and set a minimum interval, commonly five or fifteen minutes. A job that runs past the account's processor limit is killed part way through, and it fails quietly, because nothing writes to a log you are allowed to read.

On a VPS crontab -e accepts any schedule you write, and a systemd timer is better still:

systemctl list-timers
journalctl -u cron -n 20

list-timers prints the next run and the last result for every timer, and the cron log shows each command as it fires. When a job does not happen, you can tell whether it never started or started and failed. That distinction is most of what debugging a scheduled task involves.

Sign 4: your neighbours are costing you response time

The symptom is specific. The same page, with no change to your code, answers quickly at night and slowly at seven in the evening. Measure it from your own machine before you blame anyone:

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer is the time to the first byte of the response, in seconds. If the twenty numbers sit close together, the server is not your problem and the fix is in your code or your database queries. If they are steady at 3am and swing by several hundred milliseconds at peak hours, you are sharing a busy machine with accounts you cannot see. That is the one trigger you cannot fix with better code, because the cause sits on the other side of the account boundary.

What the move actually costs

These are typical advertised prices as of August 2026 for the smallest plan in each category. Treat them as a shape rather than a quote, and check the current price before you buy.

[
  {
    "plan": "Shared hosting",
    "first_term_usd": 3,
    "renewal_usd": 12
  },
  {
    "plan": "VPS, 1 vCPU 1 GB",
    "first_term_usd": 5,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB",
    "first_term_usd": 12,
    "renewal_usd": 15
  },
  {
    "plan": "Managed VPS, 2 vCPU 4 GB",
    "first_term_usd": 25,
    "renewal_usd": 30
  }
]

The headline gap runs from 3 to 5 US dollars a month, and it is not the number that decides anything. Shared hosting advertises a first-term rate that normally requires paying one to three years up front, and it renews near 12 dollars. Compare renewal against renewal and the picture changes: 12 dollars for the shared account against 6 dollars for an entry VPS.

Be careful with that comparison, because the sizes are not equal. A 1 vCPU, 1 GB VPS runs the web server and the database on one small box, which is tight for WordPress once real traffic arrives. The honest like-for-like against a renewed shared plan is the 2 vCPU, 4 GB line at roughly 15 dollars. So the true premium is a few dollars a month, not a multiple.

The larger cost never appears on the invoice. A VPS adds an hour of setup, a few minutes each month for updates, and the evening you will spend the first time something breaks. Price that at your own hourly rate and the gap closes fast. What a VPS costs in practice works through the sizes in more detail.

Moving a site off shared hosting without losing traffic

1. A day ahead, lower the DNS (domain name system) TTL (time to live) for the domain to 300 seconds, so the switch takes effect in minutes rather than hours.
2. Build the new server and get the site working on its IP address before you touch DNS.
3. Copy the files, then dump the database and restore it on the new box.
4. Test through your laptop's hosts file, which points the domain at the new IP for your machine only.
5. Issue the TLS (transport layer security) certificate on the new server, change the A record, and keep the shared account alive for a week.

dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig prints the TTL in the second column of its answer, so you can confirm the lower value is live before you switch anything. --single-transaction takes a consistent snapshot without locking the tables, which matters if the old site is still taking orders while you work. On the new server, get certificates working the same day: Let's Encrypt on Ubuntu with nginx takes a few minutes once the DNS record points at the box.

Resources without the responsibility

If the four signs describe your site but the maintenance does not appeal, the middle option is a managed VPS. You keep the assigned memory and the root-level capability, and the provider keeps the patching, the monitoring and usually a panel. The chart above puts that at about 30 dollars against 15 for the same size unmanaged. The difference buys somebody else's attention when the box stops answering at night.

The managed against unmanaged VPS decision is the right next read if that sounds like you. If instead you already run a busy VPS and the steal time is still bad at peak hours, the step after that is a dedicated server with no neighbours at all.

FAQ

Is a VPS faster than shared hosting?

Not automatically. A quiet shared server can beat a 1 vCPU VPS on a single WordPress page. What a VPS gives you is consistency: the memory in your plan is yours, so response time depends on your code instead of on the busiest account on the machine. If your pages are slow at 3am as well as at 7pm, the cause is your code or your database queries, and moving the same code to a VPS moves the problem with it.

Can I run a Node.js or Python app on shared hosting?

Sometimes, and only inside narrow limits. Some panels start an application for you through Passenger, and it runs when a request arrives. You cannot bind your own port, because the host's web server owns 80 and 443. You cannot keep a worker in memory between requests, because the account's process cap ends anything long-lived. A bot, a queue worker or a websocket server needs a VPS.

Do I need to know Linux to run a VPS?

For an unmanaged VPS, yes. You need SSH keys, a firewall, updates, backups and the habit of reading logs. Budget an hour for the initial setup and a few minutes each month after that. If that is not work you want, a managed plan keeps the assigned resources and hands the maintenance back to the provider, which is the trade covered in managed against unmanaged VPS hosting.

Will my site go down while I move from shared hosting to a VPS?

Not if you lower the DNS TTL first and keep both accounts running. Set the TTL to 300 seconds a day ahead, copy the files and the database, test the new server through your laptop's hosts file, then change the A record. For a few minutes some visitors reach the old server and some reach the new one, so keep the shared account alive for a week. Put the site in read-only mode during the final database dump, or accept losing anything written in that gap.