Hosting plans are named in a way that suggests a ladder, with shared at the bottom and dedicated at the top, and a cloud somewhere floating above. In practice the differences are less about quality and more about who controls what, and who is affected when something goes wrong. A well run shared server beats a neglected dedicated one every day of the week.
Most of the confusion comes from sales pages that describe each type by its size, when the more useful question is about division of labour. Who patches the operating system? Who notices when the disk is nearly full? Who answers the phone at three in the morning? The answers change a lot between the four types, and they matter more than the number of cores.
This guide takes each type in turn, shows what you actually get and what you take on, and ends with a way of deciding that does not depend on a plan sounding impressive.
Shared hosting
On a shared plan, hundreds of accounts live on one server. The host has configured the operating system, the web server, PHP, the database and the mail system, and you get a slice of it with limits on CPU time, memory, simultaneous processes, disk space and the number of files you may store. You cannot install system software, and you usually cannot change global settings, but you also do not need to, because someone else is patching and monitoring the machine.
What you work with is a control panel, a file manager or SFTP, a database tool and a place to set the PHP version. For a WordPress site, a small shop or a club website, that is everything you need, and the monthly cost reflects that the hardware is split between many customers.
The weak spot is neighbours. Good hosts isolate accounts from each other so one busy site cannot drag down the rest, but the isolation is never perfect. If your site is quiet, you will probably never notice. If your site gets a burst of traffic, you will hit your own limits long before you hurt anyone else, and the usual symptom is a 503 or 508 error rather than a slow page. That is the host protecting the other accounts, and it is the clearest sign you have outgrown the plan, or that something on the site (a bot, a runaway plugin) is using more than it should.
VPS
A virtual private server is a slice of a physical machine that behaves like its own computer. You get root access, a guaranteed share of CPU and memory, and the freedom to install whatever you like. You also get the responsibility: updates, firewall rules, backups, and the 3 a.m. problem when something stops starting.
Under the hood, one physical host runs many virtual machines, each with its own kernel and operating system. Because the resources are allocated rather than shared on a best-effort basis, one neighbour's heavy load affects you much less than on shared hosting. Not zero, though. Disk and network are usually still shared, and a provider that packs too many machines onto a host will show it. Inside the VM, top reports a figure called steal time (shown as st); if it is persistently above a few per cent, the host is handing your CPU to someone else.
Some providers sell managed VPS plans where they handle the operating system side for you. Those sit in an interesting middle ground, with more control than shared hosting and less ongoing effort than a bare VPS. Read exactly what "managed" covers. It might mean security patches and monitoring, or it might mean a control panel pre-installed and nothing else. Take the same care with the question of backups: whether they exist, where they are stored, and who has ever tried restoring one.
Dedicated servers
A whole physical machine, rented to you alone. Nobody shares its CPU, memory or disks. This makes sense when you have steady heavy load, strict compliance needs, or software that wants direct access to hardware. It also means that if a disk fails, you want to have made sure the provider's replacement process and your own backup plan are both real.
Dedicated servers are typically sold with mirrored disks (RAID), a remote console for when the operating system will not boot, and a hardware replacement promise measured in hours. Mirrored disks protect against a single drive failing. They do not protect against deleting a file, a bad update or ransomware, which are copied to both disks instantly. RAID is availability; backups are recovery. The two are often confused.
The step from VPS to dedicated is smaller than it looks if your load is steady, and bigger than it looks if you have never run a server before. Everything you would handle on a VPS is still yours, plus the hardware questions: how fast can the provider replace a failed part, and what does your site do in the hours before they do?
Cloud hosting
"Cloud" is the vaguest word on this list, because it covers everything from a virtual machine you rent by the hour to a function that runs only when a request arrives. The common thread is that resources are pooled and billed by use, so you can add capacity quickly and give it back.
That flexibility is wonderful for traffic that spikes, for applications split into several services, and for teams who automate their infrastructure. It is less wonderful for a small brochure site, where the pricing model and the number of settings can be bigger than the problem you are solving.
Some of the cloud pieces you will meet:
- Virtual machines, billed for the time they exist. These resemble a VPS with more tooling around them.
- Managed databases, where the provider runs the database server and you connect to it.
- Object storage for files and media, billed by the amount stored and the amount fetched.
- Load balancers, which spread requests over several servers and drop failed ones from the rotation.
- Serverless functions, which run your code on demand and charge per execution.
The bill is the part that surprises people. Charges for outbound traffic, storage requests, snapshots and idle resources add up in ways that a flat monthly shared plan never does. Set a budget alert before you launch anything, and look at the bill after the first week.
What the limits look like when you hit them
Each type fails in its own way, and learning to recognise the failure saves a lot of guessing. On shared hosting the typical signs are a 503 Service Unavailable, a 508 Resource Limit Reached page, or admin screens that time out while the front page still loads. They appear in bursts: when a crawler visits, when a backup runs, when a mailing goes out and everyone clicks at once. The panel's resource graphs show the spikes, and the error log often names the limit.
On a VPS, the classic failure is running out of memory. The kernel's out-of-memory killer picks a process, usually the database, and ends it. The site then shows a database connection error until someone restarts the service. You can confirm it with:
journalctl -k | grep -i "out of memory"
dmesg -T | grep -i "killed process"The fix is some mix of a smaller memory footprint (fewer PHP workers, a leaner database configuration) and more memory. Adding swap is a plaster, not a cure, because swap on a busy disk is slow enough to look like an outage.
On a dedicated server the surprises are hardware: a disk reporting errors, a fan failing, a network port renegotiating at a lower speed. Cloud failures are more often configuration than hardware: a security group closed the wrong port, a storage bucket became public, an instance was stopped by a script nobody remembers writing. In every case the first useful step is the same. Find out which resource ran out, or which setting changed, before changing the plan.
Side by side
| Point | Shared | VPS | Dedicated | Cloud |
|---|---|---|---|---|
| Who patches the operating system | Host | You (or host if managed) | You (or host if managed) | You, for virtual machines |
| Root access | No | Yes | Yes | Yes, on virtual machines |
| Resources | Capped slice | Allocated share | Whole machine | Allocated, can be changed quickly |
| Effect of a noisy neighbour | Possible | Smaller | None on CPU and memory | Smaller |
| Cost pattern | Low and flat | Low to moderate, mostly flat | Higher, flat | Varies with use |
| Time needed from you | Minutes a month | Hours a month | Hours a month | Depends on design |
| Typical failure | Hit a limit, get 503 or 508 | Out of memory, service stops | Hardware fault | Surprise bill, mis-set permissions |
Where the real differences show up
Security
On shared hosting the provider handles most of the system security and you handle your site: your passwords, your plugins, your own software updates. On a VPS or dedicated server, the system security is yours too. An unpatched server with an open SSH port gets probed within minutes of going online, which is not a figure of speech. If you take one, the first jobs are key-based login, a firewall, automatic security updates and backups that live somewhere else.
Shared hosting usually includes mail, already configured to send reasonably. On your own server you need to configure sending properly, with SPF, DKIM and DMARC records and a reverse DNS entry, or your messages will land in spam. Many people move websites to a VPS and leave email with a specialist provider, which is a good compromise. The SPF builder and DMARC builder help with the records.
Scaling
Shared plans scale by moving up a tier, which means a short migration. VPS plans often resize with a reboot. Dedicated servers scale by buying a bigger machine and moving. Cloud setups can scale while running, but only if the application was designed to run on more than one server, and many WordPress sites were not.
Support
The kind of help you can expect shifts with the type. A shared host's support team knows its own stack well and can usually look at your account directly, so "my site returns 503" is a question they can answer in minutes from their logs. On an unmanaged VPS or cloud instance the provider will check that the machine and network are up, and will politely decline to debug your application. That is a fair division, but it surprises people who assumed the support came with the hardware. Ask before you buy what is in scope, what the response times are, and whether a human answers out of hours.
What a typical case looks like
Take three examples, all invented. A village cricket club runs a fixtures page and a photo gallery with a few dozen visitors on match days. A shared plan handles this with no effort, and moving it up would add cost and nothing else.
A small online shop with a few hundred orders a month runs WooCommerce and sells mostly in the evenings. It starts on shared hosting, then hits process limits during sales. The step up that fits is a managed WordPress or managed VPS plan, because the owner wants the speed without becoming a system administrator.
A software company runs an application with a web tier, a database and a queue of background jobs, and wants to add servers when load rises. That is what cloud tooling and a team comfortable with automation are for. Putting that on a shared plan would be painful, and putting the cricket club on it would be an expensive hobby.
Who looks after backups and updates
This is where the types differ most in daily life, and where the sales pages say least. On shared hosting the provider usually keeps backups of the whole server, but they are meant for the provider's disasters, and restoring one account's files from them may be a support request, slow, and sometimes chargeable. Keep your own copies of the site and the database as well. The backups guide explains how.
On an unmanaged VPS or dedicated server there is no safety net unless you built one. Some providers offer snapshots as an add-on, which are fine for rolling back a bad upgrade but live on the same infrastructure as the server. A copy stored with a different provider or at a different site protects against the failures that matter, such as account suspension, a billing mix-up or a provider-wide incident.
Updates follow the same split. On shared hosting the operating system, web server and PHP builds are updated for you, though you choose when to move to a new PHP version. On a VPS you decide, which means you have to actually do it. An automatic security update schedule is the cheapest improvement most self-run servers can make. The tasks still on your list in every case are the application: WordPress core, themes and plugins, and the passwords that guard them. A useful test of any plan is to ask what happens if you do nothing for six months. On shared hosting the answer is that the site mostly keeps running, apart from the application. On an unmanaged server the answer is that it slowly becomes a liability.
Moving from one type to another
Moving up or down is a routine job, and it goes smoothly when you treat it as a checklist, not an event. The order that works for most sites:
- Lower the TTL on your DNS records a day or two ahead, so the switch takes minutes and not hours. The TTL planner helps with the timing.
- Build the new environment and copy files and databases across, then test the copy using a hosts file entry or a temporary address before the real domain points at it.
- Freeze changes briefly: put a shop into maintenance mode, or schedule the move for a quiet hour, so orders and comments do not land on the old server after the final copy.
- Change the DNS records, then watch both servers' logs until traffic on the old one has dried up.
- Move email deliberately. Mail is the part most often forgotten, and a changed MX record without a copied mailbox loses messages.
- Keep the old server running for a week or so before cancelling it, with the final backup taken and stored elsewhere.
Avoid doing this on a Friday afternoon, or in the middle of a sale. The casebook has more than one story that starts that way.
Choosing without overthinking it
Most small sites run perfectly well on shared or managed WordPress hosting. Move up when you can name the limit you are actually hitting, not when a plan sounds more impressive. A site that is slow because of unoptimised images will be just as slow on a dedicated server.
When you can name the limit, the right next step usually follows. Running out of memory or processes points at a VPS or a bigger shared tier. Needing software the host will not install points at a VPS. Steady heavy load, with compliance needs, points at dedicated. Traffic that swings by a factor of ten and an application built in pieces points at cloud. If your answer is "I just want it to be faster", measure first, with the uptime calculator and the page weight tool, because the cause may not be the server at all.
It is also fine to move back down. Sites that went to a VPS because it sounded serious, and then went unpatched for two years, are a regular feature of the casebook and of cleanup work. A smaller plan that someone else maintains is a perfectly good outcome.
How to check what you have now
If you have shell access, a few commands tell you how much room there is:
uptime
free -m
df -h
top -b -n 1 | head -15The load averages from uptime should sit below the number of CPU cores most of the time. free -m shows memory and swap; heavy swap use means the machine is short of memory. df -h shows disk space, and df -i shows inodes, which can run out on a mail-heavy or cache-heavy account while space remains. On shared hosting, the control panel usually has a resource usage page that graphs CPU, memory, processes and the times you hit limits. Look there before you decide you need to move.
Things people ask
Is shared hosting less secure?
Not by nature. The provider carries the system layer, and a well isolated shared account is often safer than a neglected VPS. What differs is that your site's own security is still yours on any type.
Can I move between types later?
Yes, and it is common. Files, databases and email can all move, though email and DNS need planning. The DNS cheat sheet covers what to change and when.
Does "unlimited" mean unlimited?
On shared plans it means unmetered on one item, such as bandwidth, while other limits (processes, memory, files) still apply. Read the fair use terms.
What does "managed" actually cover?
It varies by provider. Ask what is patched, what is monitored, what is backed up, and what happens when something breaks outside office hours.
Do I need cloud to handle a traffic spike?
Often a page cache and a CDN handle a spike on a modest plan better than a bigger server would, because most of the requests never reach the application at all.