Hosting models compared: VPS, PaaS, containers and serverless
Shared and VPS hosting, platform as a service, container hosts and serverless functions, the real limits of each, and how to match a model to a workload.
The four models
| Model | You manage | Provider manages | Scales to zero | Typical failure mode |
|---|---|---|---|---|
| Shared hosting | Files and database content | Everything else | No | Noisy neighbours; no control over versions |
| VPS | OS, runtime, patches, backups | Virtualisation and network | No | You forget to patch or the disk fills |
| PaaS | Application code and config | Runtime, deploy, TLS, scaling | Usually not | Platform limits on build time or process model |
| Containers | Image, orchestration config | Nodes and scheduling | Yes | Misconfigured probes and resource limits |
| Serverless | Function code and triggers | Everything including idle | Yes | Cold starts and per-invocation limits |
The question is not which model is best but how much operational work you are willing to own. A VPS is the cheapest way to run a long-lived process and the most expensive way to spend a weekend, because every patch and every backup is your problem.
- Shared hosting still wins for a brochure site with a CMS that a non-technical person updates.
- A VPS is right when you need a specific kernel, a daemon, or a version nobody else offers - and when you will actually maintain it.
- PaaS is right when the application fits its build and process model. Fighting the platform is a sign the fit is wrong.
- Containers are right when you need a reproducible runtime and horizontal scale, and you accept owning an image pipeline.
- Serverless is right for spiky, event-driven work and wrong for a stateful long-running process.
Matching a model to a workload
Decision sketch
Always idle, low traffic, one runtime?
-> shared hosting or a small PaaS plan
A long-running process with a specific runtime version?
-> VPS or a container with a persistent service
Requests that arrive in bursts and can be 30 seconds late?
-> serverless functions behind a queue
An HTTP API with steady traffic and a database?
-> container host or PaaS, with a managed database
Needs a GPU, a custom kernel, or a licensed binary?
-> VPS or dedicated hardware
Compliance requires a specific region and audit trail?
-> check the provider's region list before the architecture| Constraint | Rules out |
|---|---|
| Requests longer than the platform timeout | Most serverless platforms |
| A persistent WebSocket per user | Serverless without a managed gateway |
| Local disk that survives a restart | Serverless; containers only with an attached volume |
| A cron job every minute | Serverless schedulers with coarser granularity |
| A fixed outbound IP | Most serverless platforms without a NAT gateway |
| Sub-50 ms cold start | Serverless with a large runtime |
Estimate the cost of both the invoice and the attention. A platform that saves a few hundred a year but needs an engineer half a day a week is not cheaper - it is a worse use of a scarce resource.
Mixing models deliberately
A common, defensible hybrid
static assets object storage plus a CDN cheap, fast, no scaling story
HTTP API container host, 2+ replicas steady traffic, predictable
image processing queue plus worker functions spiky, latency-tolerant
scheduled reports a cron job on a small worker long running, infrequent
database managed service with backups the part you least want to run
Rule: put each workload where its cost curve is flattest.- Every additional model is another thing to monitor and another place credentials live. Two is usually enough; four needs a reason.
- Keep the boundary explicit: a queue or an HTTP interface between models, not a shared filesystem.
- Write down which model owns each workload in the repository README. The next person will otherwise guess.
💡
Start with the simplest model that meets the requirement, and move when a measured limit is reached - not when a hypothetical scale arrives. Most projects never reach the scale that justified the complexity they adopted on day one.
FAQ
Is a VPS cheaper than a PaaS?
The invoice often is, and the total cost usually is not. Add patching, monitoring, backups, TLS renewal, deploy scripts and your own time, then compare.
Can I move between models later?
Yes, if the application is a container or a plain process with configuration supplied by environment variables. Migration pain comes almost entirely from coupling to a platform's proprietary runtime or storage API.
Related
Static versus dynamic hosting Choosing a host: cost, lock-in and support
Last refreshed 2026-09-18.