VPS vs shared hosting comes down to isolation and control. Shared hosting gives you an account on a server whose CPU, memory and software you share with other customers; a VPS (virtual private server) gives you a virtual machine of your own, with its own operating system, a fixed allocation of RAM and disk, and full root access.
Shared hosting is the simpler choice for a small site; a VPS is the step up when you keep hitting your host’s resource limits, need software the host will not run, or want performance you can predict. A dedicated server gives you a whole physical machine, and a hyperscaler cloud VM (AWS, Google Cloud, Azure) is a virtual machine billed as separate metered parts.
Key takeaways
- Shared hosting is an account inside a shared operating system; a VPS is a virtual machine of your own, with its own operating system, root access and a reserved share of RAM and disk.
- Repeated 508, 500 or 503 errors and slow responses at busy hours are the documented signs that a site is hitting a shared plan's resource limits.
- A VPS is not automatically faster: fix caching and slow queries first, and choose dedicated vCPUs if steal time stays high.
- Entry-level bundled VPS plans in our Index list at $4.00 to $5.00/month with disk and an IPv4 address included; hyperscaler VMs bill disk and IPv4 as separate line items, by the second or minute.
- Move by building the VPS next to the old host, testing it privately, then switching DNS, and keep the shared plan until mail and traffic have moved.
VPS vs shared hosting vs dedicated vs cloud: the comparison table
The table compares the five options on the questions that decide most moves. Shared hosting is often sold simply as “web hosting.” “Managed hosting” is a service level that can sit on top of any of the other four, so its column describes what the provider takes off your plate. If the term VPS is new to you, read what a VPS is and how it works first.
| Factor | Shared hosting | VPS | Dedicated server | Hyperscaler cloud VM | Managed hosting |
|---|---|---|---|---|---|
| What you rent | An account on a server shared with other customers | A virtual machine with its own operating system and reserved RAM and disk on a shared physical host | A whole physical server | A virtual machine assembled from metered parts: compute, disk, IP addresses | A hosted service (often WordPress) where the provider runs the stack |
| Isolation | Per-account limits inside one shared operating system | Own kernel through a hypervisor such as KVM (container VPS share the host kernel); hardware shared | Physical: no other tenants on the machine | Own kernel through a hypervisor; hardware shared | Depends on the platform underneath |
| Root access | No | Yes | Yes | Yes | Usually no |
| Performance predictability | Depends on your account limits and on other accounts | RAM and disk space are reserved for you; CPU time is shared unless the plan has dedicated vCPUs | Highest: no hypervisor, no neighbors | Set by the instance family; shared-core and burstable families vary under load | Depends on the plan; the provider tunes the stack |
| Scaling | Move to a bigger plan, or off the platform | Move to a bigger plan, or add servers | Order new hardware and migrate | Resize by API, add instances, or use autoscaling and managed services | Move up a plan tier |
| Your maintenance work | Your site and its content | OS updates, security, web stack, backups, monitoring | Everything on a VPS, plus coordinating hardware repairs | Everything on a VPS, plus access policies, networking and spend alerts | Your site and its content; the provider patches and backs up |
| Typical billing | Monthly, or prepaid terms of up to several years with a separate renewal price | Monthly; many providers also bill by the hour, minute or second | Usually monthly or longer terms | Post-paid by the second or minute; disk and public IPv4 are separate line items | Monthly or annual plans |
| Who it fits | Brochure sites, blogs, small WordPress installs, first projects | Growing sites, apps, bots, game servers, custom stacks, short projects | Sustained heavy CPU or disk work, large databases, single-tenant requirements | Teams that use managed databases, autoscaling or many regions | Owners who want no server work at all |
One caveat on the VPS column: KVM-based plans, ours included, run their own kernel. Container-based VPS products, such as those built on LXC, aim for an environment close to a standard Linux installation “but without the need for a separate kernel”: they share the host’s kernel.
Quick decision checklist
- Stay on shared hosting if your site runs on PHP and MySQL, never hits its resource limits, and you want the host to handle updates, email and backups.
- Choose a VPS if you need root access, a long-running process (a Node.js app, a bot, a queue worker), software your host does not offer, or limits you set yourself.
- Choose a VPS with dedicated vCPUs before a dedicated server if your problem is CPU contention rather than the size of the machine.
- Choose a dedicated server if one workload keeps many cores or the disks busy around the clock, or a contract requires single-tenant hardware.
- Choose a hyperscaler if you will actually use its managed databases, autoscaling, identity controls or region count.
- Choose managed hosting if nobody on your team wants to patch a server, and you would rather pay for that work than do it.
How shared hosting works, and where its limits come from
On shared hosting, many customer accounts run inside one operating system on one server. You manage files and databases through a control panel such as cPanel, but you cannot install system software or change the server’s configuration.
To stop one busy site from slowing down everyone else, the host caps each account. On servers that run CloudLinux OS, these caps are called LVE limits. The CloudLinux documentation lists them: CPU speed, physical memory, entry processes (concurrent connections), number of processes, disk throughput (IO), disk operations per second (IOPS) and inodes (the number of files and folders you may store).
The same documentation says what happens at each cap: a site limited by CPU or IO “will start responding slower,” and a site limited by memory or process count gets 500 or 503 errors. When concurrent requests go above the entry-process limit, the web server serves a 508 “Resource Limit Reached” page. Those three symptoms are the clearest sign that your site is hitting the plan’s limits; the matrix below sorts out whether a bigger server or leaner code is the fix.
Shared hosting is still the right answer for a lot of sites. If your account never touches its limits, a VPS will not make it noticeably better, and you would take on server maintenance for nothing.
Is a VPS faster than shared hosting?
Often, but not automatically. A VPS is faster when shared hosting was the thing holding you back: your site hit its CPU, memory or entry-process limits, or other accounts kept the server busy. It is not faster when the slowness comes from the site itself, such as uncached pages, a heavy plugin or a slow database query. The same code on a bigger machine stays slow, and a k6 load test from a VPS against a staging copy helps tell the two cases apart before you move.
A VPS has neighbors too, but a hypervisor fences them off. DigitalOcean’s plan documentation is a clear public example: RAM, disk and network bandwidth are always dedicated, while a shared-CPU Droplet’s hyper-thread “may be shared between multiple other Droplets” and dedicated-CPU plans “have guaranteed access to the full hyper-thread at all times.” HourlyVPS draws the same line.
You can measure CPU contention instead of guessing. On a Linux VPS, run top and read the st value in the CPU line. The top manual defines it as “time stolen from this vm by the hypervisor.” If steal time stays high while your app is slow, the physical CPU is busy with other guests: a plan with dedicated vCPUs fixes that, and a code change does not. The VPS benchmark guide shows how to log steal time over a whole test.
Note: HourlyVPS sells both kinds on KVM. Quartz plans use shared vCPUs and suit most workloads; Chrono plans pin dedicated vCPUs for sustained CPU work. The hardware, NVMe storage and DDoS filtering are described on the network and hardware page.
Signs you have outgrown shared hosting
Use this matrix before you buy anything. Each row pairs a symptom with its usual cause, where to check it, and whether a VPS fixes it. On cPanel servers with CloudLinux, the “CPU and Concurrent Connection Usage” page (CloudLinux’s Resource Usage plugin) shows when and how often your account hit each limit.
| Symptom | Likely cause | Where to check | Does a VPS fix it? |
|---|---|---|---|
| 508 “Resource Limit Reached” pages at busy times | Entry-process (concurrent connection) limit | Resource Usage page: entry-process faults | Yes. You set web and PHP worker counts yourself, within the plan’s RAM |
| Random 500 or 503 errors under load | Memory or process-count limit; processes get killed | Resource Usage page: memory and process faults; the error log | Usually. Check plugin memory use first |
| Slow responses without errors, worse at certain hours | CPU or IO throttling, or busy neighbors | Resource Usage page: CPU and IO faults; response times by hour | Often. Choose dedicated vCPUs if the load is CPU-bound |
| Uploads or backups fail while disk space remains | Inode (file count) limit | File usage in the control panel | Yes, but clear caches and old backups first |
| You need Node.js, Python workers, websockets, Redis or Docker | The host does not allow the process or package | The host’s documentation or support | Yes. This is what a VPS is for |
| Mail from your domain lands in spam | A shared sending IP with a poor reputation | Blocklist lookups for the server’s IP | Partly. A VPS has its own IP, but you then own its reputation |
| Pages are slow even when the server is quiet | Uncached pages, heavy plugins or slow queries | An application profiler or query log | No. Fix the application first |
If two or more rows describe your site and the last column says yes, the move is worth planning. If your only symptom is the last row, spend an afternoon on caching before you spend money on a server. If your problem looks like row 6, plan the mail move before you make it: a VPS gives you your own IP address and its reputation, and outbound port 25 starts closed on new HourlyVPS servers and opens only on request, as our acceptable use policy explains.
What you take over when you leave shared hosting
Shared hosting bundles a lot of work into the price, and an unmanaged VPS hands that work to you. At HourlyVPS, for example, you get root access and run the operating system and everything on it; we run the hardware, the hypervisor and the network.
| Job | On shared hosting | On an unmanaged VPS |
|---|---|---|
| Operating system updates | The host | You, including security updates and reboots |
| Web server, PHP and database | Preinstalled and tuned by the host | You install and tune them, or run them in containers |
| HTTPS certificates | Usually a control-panel switch | You configure them, for example with an automatic-HTTPS web server |
| Email mailboxes and sending | Often included | Not included: use a hosted email service, or run and maintain a mail server |
| DNS | Often included | Keep it at your registrar or a DNS provider |
| Backups | Varies by host and plan | You schedule them, keep a copy off the server and test restores; a snapshot is not a backup |
| Firewall and SSH access | The host | You: SSH keys, a firewall, no password or root login |
| Control panel | cPanel, Plesk or similar | None by default; optional |
None of this is hard, but it never ends: updates and backup checks are recurring chores, not one-time steps. Start with connecting to the server over SSH, then work through the security checklist for a new Linux VPS before you expose any port. For the web layer, Caddy as a reverse proxy with automatic HTTPS and Docker on Ubuntu keep the moving parts few. If the Linux command line itself is new, eight hands-on Linux labs on a throwaway VPS teach the basics behind these chores, about two hours per lab.
Managed VPS vs shared hosting: who does the upkeep?
“Managed” describes who does the work in the table above, not a kind of server. On a managed VPS the provider patches the OS and supports the software stack; managed WordPress hosting goes further and runs the whole application platform. That labor is part of the price, while an unmanaged VPS is priced for the server alone because you supply the labor yourself. Our who-does-what table for managed and unmanaged VPS splits the tasks line by line. A self-hosted platform such as Coolify on a VPS sits in between: it automates Git deploys, HTTPS certificates and database backups from a dashboard, while you still patch the server.
VPS vs dedicated server
A dedicated server is a physical machine that only you use; a VPS is one of several virtual machines a hypervisor carves out of a physical machine. With a dedicated server you get every core, all the RAM and the full disk bandwidth, with no hypervisor and no neighbors.
You also take on hardware. A bigger dedicated server means a new order and a migration, and a failed component means a repair window. A VPS is a smaller, more flexible unit: you can add a second server for a week, or delete one the hour a job ends.
When a dedicated server is the right call
- One workload keeps many cores busy around the clock: large databases, build farms, video encoding.
- You need the full throughput of local disks, or more RAM than VPS plans offer.
- A contract, audit or software license requires single-tenant hardware.
- You want to run your own hypervisor and split the machine yourself.
The middle ground: dedicated vCPUs
If steal time is your problem, a VPS with dedicated (pinned) vCPUs removes the CPU sharing without the hardware commitment. At HourlyVPS you still pay by the hour, never more than the plan’s monthly price for a server in a billing period, and you can delete the server when the job ends. Chrono plans are built for this:
Chrono C8
KVM · 25 Gbps port · Istanbul · initial credit $5
- vCPU
- 2 dedicated
- RAM
- 8 GB
- NVMe
- 100 GB
- Traffic
- Istanbul: 6 TB/month
- Per hour$0.07/hour
- Per day (24 h)$1.68/day
- Monthly cap$35.00/month
VPS vs cloud server: is a VPS a cloud server?
Usually, yes. NIST defines cloud computing by five essential characteristics: on-demand self-service, broad network access, resource pooling, rapid elasticity and measured service. A VPS ordered from a web portal, reached over the internet, run on a pooled host and billed by the hour matches most of that list, which is why so many VPS products are sold as “cloud servers.”
Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.
NIST Special Publication 800-145, The NIST Definition of Cloud Computing (September 2011)
The useful difference is between bundled VPS plans and hyperscaler clouds (AWS, Google Cloud, Microsoft Azure, Oracle Cloud). A bundled plan sells one price for CPU, RAM, disk, an IPv4 address and a traffic allowance. A hyperscaler prices each part separately and bills it by the second or minute, which suits autoscaling but makes the monthly total harder to predict.
Does a cloud server run on many machines at once?
Many hosting articles say a cloud server spreads across many physical machines while a VPS sits on one. In practice, one virtual machine runs on one physical host at a time on either platform; the difference is what happens around that host. Google’s Compute Engine documentation describes live-migrating VMs to another host for planned maintenance, and says that if the hardware fails completely, the instance “terminates and restarts automatically.” That is a restart, not zero downtime, so keep backups off the server whichever option you choose.
Bundled vs component pricing, in numbers
The entry sizes below come from our Hourly VPS Fine-Print Index, where every cell links to the provider’s own page. Prices are list prices in USD as checked on October 2, 2026.
| Provider and product | Size | Listed price | Included in that price | Billing unit |
|---|---|---|---|---|
| Vultr Cloud Compute | 1 vCPU, 1 GB RAM, 25 GB SSD, 1 TB transfer | $0.007/hour, $5.00/month | Disk, one IPv4 | Per hour |
| Akamai (Linode) Nanode 1 GB | 1 vCPU, 1 GB RAM, 25 GB storage, 1 TB transfer | $0.0075/hour, $5.00/month | Disk, one IPv4 | Per hour, rounded up |
| DigitalOcean Basic Droplet | 1 vCPU, 512 MiB RAM, 10 GiB SSD, 500 GiB transfer | $0.00595/hour, $4.00/month | Disk, IPv4 on bundled plans | Per second, 60-second or $0.01 minimum |
| AWS Lightsail (with IPv4) | 2 vCPUs, 512 MB RAM, 20 GB SSD, 1 TB transfer | $0.0067/hour, $5/month | Disk, IPv4 | Per hour |
| Google Compute Engine e2-micro (us-central1) | 2 shared vCPUs, 1 GiB RAM | $0.008376428/hour | Compute only: boot disk extra, external IPv4 $0.005/hour | Per second after 1 minute |
| Microsoft Azure B2pts_v2 (East US, Arm) | 2 vCPUs, 1 GiB RAM | $0.0084/hour | Compute only: disk extra, static IPv4 $0.005/hour | Per full minute |
The arithmetic shows where component pricing bites. A Google e2-micro plus one external IPv4 comes to $0.008376428 + $0.005 = about $0.0134 per hour before any disk, or roughly $9.76 for a 730-hour month (our arithmetic from the Index figures). The bundled plans above already include the disk and the address. In fairness, Google’s Free Tier covers one e2-micro instance a month in three US regions, plus 30 GB-months of standard persistent disk, which changes the math for a single tiny VM.
HourlyVPS plans are bundled the same way. Every server comes with one dedicated IPv4 address and IPv6, included in the plan price.
Where hyperscalers are a better fit
Choose AWS, Google Cloud or Azure when you need what sits around the VM: managed databases and queues, autoscaling, fine-grained identity and access controls, or reach. The Index lists 43 Compute Engine regions and 80+ Azure regions. For one website, a bot or a game server, a bundled VPS is simpler to budget. HourlyVPS runs in Istanbul today, with New York coming soon, so check the locations page and our guide to choosing a VPS location by latency before you decide.
Is a VPS more expensive than shared hosting?
At the entry level, list prices overlap more than most comparisons suggest. Hostinger’s web hosting page lists its Premium shared plan at $2.99/month on a 48-month prepaid term, renewing at $10.99/month (as of October 3, 2026). The bundled VPS plans in the Index table above list at $4.00 to $5.00/month (as of October 2, 2026).
They are not equivalent products. The shared price includes the host’s administration work, a control panel and often email; an unmanaged VPS price covers the server alone, and 512 MB or 1 GB of RAM is tight for a database-backed site (the sizing table below starts at 2 GB). How the bill is built differs too:
- Shared hosting: long prepaid terms. The headline monthly price often assumes the longest term: Hostinger’s $2.99/month is billed as $143.52 for the 48 months up front. Compare renewal prices, not introductory ones.
- VPS: monthly, often usage-based too. Many VPS providers also bill by the hour, minute or second. In our Index of 20 hourly-billed providers, 12 bill a stopped server in full until you delete it; the stopped-server billing guide lists who does what. Vultr vs DigitalOcean vs Hetzner billing shows how far the rules differ between three large providers.
- Hyperscaler cloud: post-paid components. Compute, disk and public IPv4 are metered separately and invoiced after the fact; Google bills compute per second after the first minute, Azure per full minute.
At HourlyVPS: there is no term to commit to and no billing mode to pick. Every plan is billed by the hour from prepaid credit, and you never pay more than the plan’s monthly price for a server in a billing period (one month from your order date), so a site that stays online all month costs that monthly price and no more. A stopped server is still billed, because its vCPU, memory, disk and IP addresses stay reserved for you; only deleting the server stops billing.
See every plan on the pricing page, or read hourly vs monthly VPS to see how the monthly cap compares with providers that bill every hour.
How to move from shared hosting to a VPS
Build the new server next to the old one, copy everything, test it privately, and only then switch DNS; keep the shared plan until the move is proven. The steps assume a PHP and MySQL site such as WordPress, SSH access to both machines, and an Ubuntu 24.04 LTS VPS with a web server, PHP and the same database family as the old host (MySQL or MariaDB, same or newer version) so the dump imports cleanly. Our guide to install WordPress on a VPS builds that stack with Caddy, PHP-FPM and MariaDB.
- Deploy and secure the VPS. Log in with an SSH key, enable the firewall, install updates and disable root login, as in the VPS security checklist.
- Lower the DNS TTL and check your mail records. At your DNS provider, set the TTL of the domain’s A and AAAA records to a few minutes, at least one old-TTL period before the switch, so resolvers drop the old address sooner. If the MX record points at the bare domain, mail follows the A record, so move mail or give it its own host name first.
- Export the database on the old host (command below).
- Copy the files and the dump to the VPS with rsync (command below).
- Import the database into an empty database on the VPS, and update the app’s config if the database name, user or host changed (for WordPress,
wp-config.php). - Test privately with
curl --resolveand a hosts-file entry, before any visitor sees the new server. - Cut over. Pause edits on the old site, run rsync and the database export once more, import again, then point the A and AAAA records at the VPS.
- Finish up. Watch HTTPS right after the switch: Let’s Encrypt’s HTTP-01 challenge fetches a file from your domain on port 80, so it succeeds only once the domain resolves to the VPS (the DNS-01 challenge is the alternative if you need a certificate earlier). Then watch the logs, move DNS hosting if it lived on the shared plan, and only then cancel it.
Export the database
Run this on the old host over SSH, from your home directory; it prompts for the database password. Per the MySQL manual, --single-transaction dumps a consistent state of InnoDB tables “without blocking any applications.” The manual also lists the PROCESS privilege as required unless you pass --no-tablespaces; a shared-hosting database user may lack that privilege, so the command includes the flag. On MariaDB hosts the tool is also named mariadb-dump and takes the same options.
mysqldump --single-transaction --no-tablespaces -u DB_USER -p DB_NAME > site.sqlWarning: never write the dump inside public_html. Anyone who guesses the file name could download your whole database. Delete site.sql from both machines after the move.
Copy the files with rsync
Run these on the VPS as your sudo user, with your domain in place of example.com; the first two lines create the web root and make you its owner. The trailing slash on public_html/ copies the folder’s contents, not the folder. At cutover, run the rsync lines again: its delta-transfer algorithm sends only what changed. rsync must be installed on both ends; if your host offers only FTP, download a full backup from the control panel instead.
sudo mkdir -p /var/www/example.com
sudo chown "$USER": /var/www/example.com
rsync -avz [email protected]:public_html/ /var/www/example.com/
rsync -avz [email protected]:site.sql ~/Import the database and test privately
Create an empty database and user on the VPS first, then load the dump:
mysql -u DB_USER -p DB_NAME < ~/site.sqlPoint the web server’s site configuration at /var/www/example.com, then request the site from your own machine with the VPS address forced. The curl manual calls --resolve “a sort of /etc/hosts alternative provided on the command line.” Replace 203.0.113.10 with the VPS IP address:
curl -sI --resolve example.com:80:203.0.113.10 http://example.com/A 200 or a redirect shows that the VPS answers, but a default welcome page also returns 200. For the real check, add a temporary hosts-file entry on your computer and click through old pages, log in and submit a form; if the site forces HTTPS, expect certificate errors until the VPS has its own certificate.
For WordPress, the official migration guide confirms that if the database and URL stay the same, you can move by copying the files and database alone. If the URL changes, use a serialization-aware tool such as WP-CLI’s search-replace, not a raw find-and-replace.
Tip: rehearse the whole move on a throwaway server first. Eight hours on a Quartz Q2 costs $0.16; delete the server afterward and billing stops. The pre-delete checklist covers what to wipe first.
Which VPS size should you start with after shared hosting?
There is no official RAM figure for “a WordPress site,” so treat this as reasoning, not a benchmark. On a VPS the operating system, the database server and every PHP worker share the plan’s RAM, and the database usually wants the biggest slice. Start here, then check memory use after a week of real traffic.
| Your site | Starting plan | Reasoning |
|---|---|---|
| One small WordPress or PHP site leaving shared hosting | Quartz Q2: 1 vCPU, 2 GB RAM, 50 GB NVMe | Room for the OS, a database and a few PHP workers without swapping |
| A WooCommerce shop, or several sites on one server | Quartz Q4: 2 vCPUs, 4 GB RAM, 80 GB NVMe | Uncached cart and checkout pages need more PHP workers at once |
| CPU-bound app, or high steal time on a shared-vCPU plan | Chrono C8: 2 dedicated vCPUs, 8 GB RAM, 100 GB NVMe | Pinned vCPUs remove CPU contention; the extra RAM fits a larger database cache |
What the move costs depends on how long each server runs: a rehearsal server you delete after a few hours, then a production server that stays online. The table shows what a Quartz Q2 costs for each duration on hourly billing; a server left on for the whole month stops at the monthly cap:
| Duration | Hours on the meter | Cost $0.02 | Note |
|---|---|---|---|
| 8 hours | 8 | $0.16 | |
| 1 day | 24 | $0.48 | |
| 7 days | 168 | $3.36 | |
| 30 days | 720 | $10.00 | Capped at the monthly price |
The rehearsal server bills only the hours it exists. A test copy you keep for a few days costs 24 hours of hourly billing per day, which is all a daily VPS is here. The production site stays online every day, so its bill stops at the monthly cap each billing period: that is what a monthly VPS means here, with no contract and nothing to renew. To compare totals across providers, try the VPS cost calculator, and for a wider view of prices read how much a VPS costs.
Deploy this setup
Host a site that outgrew shared hosting
Quartz Q2 · 1 shared vCPU · 2 GB RAM · 50 GB NVMe · Istanbul
- Per hour$0.02/hour
- Per day (24 h)$0.48/day
- Monthly cap$10.00/monthFor this job
Starts with a $5 initial credit, which goes into the server’s balance and pays for its hours.
Billed by the hour, never more than $10.00 per billing period. Delete the server and billing stops.



