Choosing hosting: shared, VPS or cloud — and what each is for
Hosting is not decided by comparing monthly prices. The real difference between shared, VPS and cloud, the hidden line items, and when you actually need to scale up.
Hosting almost always gets decided on the wrong axis: monthly prices go into a table and the cheapest one wins. But the real difference between the tiers isn’t price, it’s where responsibility ends.
What you are actually buying is the answer to “who deals with this when it breaks.”
Three tiers, three boundaries
Shared hosting. You share one physical server with hundreds of other sites. Updates, security patches and server maintenance belong to the provider. It’s cheap, and for most corporate brochure sites it is more than enough.
Its weakness is the noisy neighbour: if another site on the same machine gets traffic or runs bad code, your site slows down too. Resource limits are also hard — past a certain number of concurrent visitors, requests queue.
VPS. A guaranteed slice of a physical server. Resources are yours, so is root access, and you install what you like. In exchange, maintaining the server becomes your job: OS updates, firewall, SSL renewal, service monitoring.
The hidden cost here isn’t money, it’s time. “Managed VPS” plans hand that load back to the provider and are usually worth paying for.
Cloud. AWS, Google Cloud, Azure, Hetzner, Cloudflare. The difference is that they sell elasticity, not servers: capacity grows when traffic rises and shrinks when it falls, and you pay for what you use.
The advantage shows up with unpredictable traffic — a campaign day, press coverage, seasonal peaks. The disadvantage is that the invoice isn’t knowable in advance.
When you need none of the three
For brochure sites, blogs and landing pages, the modern answer is usually none of the above: static hosting on a CDN.
If the site compiles to finished HTML at build time, nothing needs computing per visit. Files are distributed to edge locations worldwide and served from the one nearest the visitor. No database, no PHP version, no server to patch, no scaling problem — and often close to zero cost.
It’s how this site is published. We covered the architecture behind that choice in what a headless CMS is and the site speed guide.
Servers become genuinely necessary where content varies per request: accounts, carts, dashboards, APIs.
The line items the price table doesn’t show
When comparing, ask about these six — the difference usually lives here:
- Renewal price. $29 the first year, $120 the second. Standard practice across the industry. Compare on the renewal price.
- Backups. Automatic? How often? Retained how long? And is restoring chargeable? Some providers take backups free and bill you to bring one back.
- Traffic limits. There is always a fair-use threshold under the word “unlimited.” What happens when you cross it — throttling, overage charges, suspension?
- Email. Same plan or separate? Keeping site and email on one server means that when the server IP hits a blocklist, your invoices stop reaching customers.
- Migration and exit. Will they hand over a full backup when you leave? On cloud, egress fees are the surprise line on the invoice.
- Support. How long until a real person answers, and at what hour? When the site is down, this is the only feature that matters.
Backups: an untested backup is not a backup
The most expensive infrastructure incidents we see don’t involve companies without backups. They involve companies that believed they had one.
If you can’t answer three questions, assume you don’t:
- Is the backup stored somewhere else? A backup on the same server leaves with the server.
- How far back can you go? If the corruption started three weeks ago and you keep seven days, there is no clean point to return to.
- Has the restore been rehearsed? Once a year, actually bring a copy up. You don’t want to learn an untested restore procedure during the crisis.
We covered the security side in full in website security.
When to scale up
That decision comes from measurement, not from the feeling that the site got slower. If two of these three appear together, it is time to change tier:
- Server response time (TTFB) goes above 600 ms at peak hours and is normal when quiet.
- 5xx errors show up during traffic spikes.
- The provider has started sending resource limit warnings.
Moving to an expensive plan while none of these are true will not make the site faster. In most “slow site” cases the problem is in images and client-side code, not the server — and upgrading hardware puts the money in the wrong place.
The short answer
- Brochure site, blog, landing pages → static hosting + CDN.
- WordPress, small ecommerce → good managed shared hosting.
- Mid-size ecommerce, custom application → managed VPS.
- Variable traffic, multiple services, a team → cloud with a real deployment pipeline.
On that last one, what matters isn’t the vendor’s name — it’s that deployment and rollback are automated. Our cloud and DevOps service builds exactly that pipeline, rollback drill included.
