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 customers. On an unmanaged 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 allocation and guarantees depend on the plan. 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 for many sites. If your site needs a program that keeps running while nobody is visiting, check whether your shared host supports persistent services before choosing 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, and some hosts also offer a shell prompt. You do not get root, but some providers allow software installed in your home directory, permitted ports and background services.

Many shared hosts run CloudLinux, which puts each account in its own lightweight container with caps on processor time, memory, disk I/O, the number of processes and the number of entry processes. Each cap fails in its own way. Hitting the processor or I/O cap makes your site respond more slowly; it does not break it. Hitting the memory cap or the process cap usually shows up as 500 and 503 errors. With Apache, the error page titled 508 Resource Limit Reached comes from the entry-process cap; LiteSpeed handles entry processes differently. In every case that 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 and maintains the supported software; certificate renewal and backup schedules depend on the plan. 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, your instance boots its own kernel and holds its own IP address, its own firewall and its own init system. On an unmanaged Linux VPS with root access, sudo works. On a Debian or Ubuntu installation, apt install works. A program you start through systemd keeps running after you log out, and with the appropriate restart and boot configuration it restarts after a crash 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 gives you control over the operating system. 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, the panel is not always the limit: alwaysdata supports installing additional PHP extensions with ad_install_pecl.

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

ss -ltnp

Each socket row shows a TCP listener; process details depend on your permissions, so a service expected to listen on TCP that failed to start shows up as a missing line. On shared hosting, access to socket information and permission to run your own listeners depend on the provider, even though the host controls ports 80 and 443.

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. On CloudLinux, hitting the physical-memory limit kills processes and visitors can get a 500 or a 503.

On a VPS, free -m reports the memory visible to your guest, not proof of an irrevocable physical-memory reservation. A host can reclaim guest memory through ballooning; the provider's resource guarantees determine whether that is allowed for your plan.

Processor time is another shared resource on shared-CPU VPS plans, and you can measure steal time 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. There is no universal normal percentage or threshold that proves oversubscription; sustained steal time is a figure you can quote in a support ticket. vmstat needs access to the relevant /proc files, not root for its ordinary readings, and a shared host can restrict that visibility. Storage is also a resource to check, 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 manages the operating system, the web server and the supported PHP builds; certificate and backup coverage depend on the plan. When the machine stops answering you open a ticket; the response depends on the host's support arrangements. The cost of that is the other side of the same rule: software outside the supported environment must fit the host's installation and service policies.

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 traffic within the plan's resource limits. No background jobs. No unusual runtime. Nothing that has to stay in memory between requests. Shared hosting serves that site well and hands the server maintenance to people who do it full time; compare prices because it does not cost less than every VPS. 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 rules differ: DreamHost prohibits persistent processes on shared plans, while alwaysdata offers supervised custom services on paid plans.

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 the panel does not offer (cPanel covers MySQL and, where the host switches it on, PostgreSQL), check the provider's installation rules. Installing software in your home directory does not universally need root: DreamHost documents compiling zlib and a custom Python version on shared servers.

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 the host may set a minimum interval of its own. On CloudLinux, a job that hits the account's processor limit is slowed down rather than killed, so a long job can still be running when the next one is due, and if the account is already at its process cap the job cannot start new processes at all. You can see some of this: cPanel's Cron Email setting mails you each job's output, and on CloudLinux hosts that offer it, the Resource Usage page in the panel names the limit the account hit and counts the faults. Access to system logs and authority to raise limits remain with the host, but some providers expose task logs with start and end times.

On a VPS crontab -e accepts schedules supported by the installed cron implementation, and a systemd timer is better still:

systemctl list-timers
journalctl -u cron -n 20

list-timers prints the next and last trigger times for timers currently in memory, not their services' exit results; the cron journal depends on the installed cron service and logging configuration. When a job does not happen, inspect its service status and logs to 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, that shows consistent timing, not whether the cause sits in the server, code or database. If they are steady at 3am and swing by several hundred milliseconds at peak hours, compare account resource usage, request volume and server logs before blaming neighbouring accounts. These timings include connection setup and server processing, so they do not establish the cause by themselves.

What the move actually costs

These are advertised examples checked on November 4, 2026, not category-wide averages or the smallest available plans. The shared, 4 GB VPS and managed examples are DreamHost's Web Hosting Launch, Stack 4 and Managed VPS Business on annual billing; the 1 GiB VPS is DigitalOcean's regular Basic Droplet at its monthly cap. Check the current price before you buy.

[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

The headline gap runs from 2.89 to 6 US dollars a month, and it is not the number that decides anything. The shared example requires paying a year up front and renews at 10.99 dollars a month. Compare renewal against renewal and the picture changes: 10.99 dollars for the shared account against 6 dollars for an entry VPS. DigitalOcean's two figures are equal because this example has no introductory discount.

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 2 vCPU, 4 GB example renews at 11.99 dollars a month, but shared-account limits and VPS capacity are not directly interchangeable. In these examples its renewal premium over shared hosting is one dollar a month.

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, and allow the previous TTL to expire before switching; local caches can still take longer to update.
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 using DNS validation or an existing valid certificate before changing 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 of InnoDB tables without locking them; nontransactional tables and concurrent schema changes need separate care, and later orders are not included in that snapshot. 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. The provider handles the agreed maintenance, but root access and management coverage depend on the plan; DreamHost's managed VPS does not include root access. The chart above puts its 2 GB managed example at 31.99 dollars against 11.99 for the 4 GB unmanaged example, so this is not a comparison of equal sizes. 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. Assigned memory does not eliminate CPU contention: on a shared-CPU VPS, neighbouring instances can still affect response time, and memory guarantees depend on the provider. If your pages are slow at 3am as well as at 7pm, check code, database queries and hosting resource limits; the time of day does not establish the cause.

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

Sometimes, within the provider's limits. Some panels start an application for you through Passenger, and it runs when a request arrives. The host's ownership of ports 80 and 443 does not prevent other permitted listeners: alwaysdata allows custom services on ports 8300 to 8499 over IPv6 on its Public Cloud. Persistent-process rules also differ by host, so a bot, queue worker or websocket server needs a plan that explicitly supports it, not universally 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 hands the agreed 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?

Lowering the DNS TTL and keeping both accounts running helps avoid downtime, but it does not guarantee a seamless move. Set the TTL to 300 seconds a day ahead and let the previous TTL expire, copy the files and the database, test the new server through your laptop's hosts file, then change the A record. During the change some visitors reach the old server and some reach the new one, and caches can take longer than five minutes to update, so keep the shared account alive for a week. Pause writes for the final database dump and restore, and keep the old site read-only or send its requests to the new server so later writes are not lost.