Hosting models side by side
The same eight models, compared on the attributes that actually differ. Cost is relative: no figures, because hosting prices change faster than a reference page can track them.
| Model | Isolation | Root / OS access | Who patches the OS | How you scale | Relative cost |
|---|---|---|---|---|---|
| Static / edge hosting | Not applicable — files only | None | Platform | Automatic, at the CDN edge | Lowest (often free tiers) |
| Shared hosting | Weak — one OS, many accounts | None (control panel only) | Host | Move to a bigger plan | Low |
| Managed WordPress | Varies — containers or shared | None | Host, including WordPress itself | Plan tiers, usually by visits | Low to moderate |
| Reseller hosting | Same as shared, resold | None (panel admin only) | Host | Buy more quota | Low to moderate |
| VPS | Strong — your own kernel (KVM) | Full | You, unless managed | Resize the instance; add more | Moderate |
| Cloud / IaaS | Strong — virtual machines | Full | You, for anything above the hypervisor | API-driven, horizontal, often automatic | Moderate to high, metered |
| Dedicated server | Total — the whole machine | Full, plus hardware console | You | Order another machine | High |
| Colocation | Total — your own hardware | Full, and you own the box | You, down to the disks | Buy and rack more hardware | Highest up front, lowest per unit at scale |
What the columns mean
- Isolation
- How well your workload is separated from other customers'. It governs both performance consistency and the blast radius of somebody else's mistake.
- Root / OS access
- Whether you can install arbitrary software. In practice this is the single most decisive column: a project that needs a package the host does not offer has already chosen a VPS or above.
- Who patches the OS
- The recurring work. Moving up a tier for control always means moving this column onto yourself unless you pay for management.
- How you scale
- Whether growth is a plan change, a reboot, an API call or a purchase order — and therefore how quickly you can respond to load you did not predict.
- Relative cost
- Ordering only. The crossover points move with utilisation: steady load favours rented machines, bursty load favours metered capacity.
What the table cannot tell you
- Availability is not a row. No single machine is highly available, however good. Redundancy is a count of independent failure domains, so two modest instances in different zones beat one excellent server.
- Specs are not comparable across providers. Two vCPU on two platforms are different quantities, because oversubscription ratios are never published. Benchmark before migrating.
- Support quality dominates everything at the lower tiers. On shared and managed plans you cannot fix the server yourself, so the response time of the people who can is the product.
If the table has narrowed it to two candidates, how to choose works through the decision by use case.