VM, Container Platform, Serverless or PaaS: Choosing a Deployment Target

Four ways to run the same application, with very different operational and cost profiles. The choice is more consequential than the code.

23 June 2026 Updated 6 September 2026 3 min read

The same application can run on a virtual machine, a managed container platform, a serverless function or a platform-as-a-service. All four work. They differ in what you operate, what you pay for, and how quickly things move.

The comparison

	VM	Managed containers	Serverless	PaaS
You operate	OS and up	The container	The function	The code
Scale to zero	No	Often yes	Yes	Sometimes
Cold starts	No	Possible	Yes	Possible
Billing	Per hour	Per request or per hour	Per invocation	Per plan
Control	Complete	High	Limited	Limited
Long-running work	Yes	Yes	Time limited	Usually
Best at	Anything, cheaply	Containerised services	Spiky, event-driven work	Getting started fast

Virtual machines

Complete control, lowest unit cost, and you own everything above the hypervisor. A VPS instance running Docker Compose behind a reverse proxy is an extremely capable and cheap production setup.

Choose it when cost matters, when you need specific system-level control, when the workload runs continuously, or when the team is comfortable operating servers. The cost is patching, monitoring and backups being your responsibility.

Managed container platforms

Cloud Run, ECS Fargate, Azure Container Apps and App Platform run your container without you managing hosts. Most scale to zero and bill per request or per second of execution.

This is the sweet spot for a large share of web services: containers keep the application portable, scaling is automatic, and there is almost no operational surface. Cold starts on scale-to-zero and higher per-unit cost at sustained load are the trade-offs.

Serverless functions

Lambda, Cloud Functions and Azure Functions run individual functions in response to events. Zero traffic genuinely costs nothing.

Excellent for event handling, scheduled jobs, webhooks and glue between services.
Excellent for genuinely spiky workloads with low average volume.
Poor for sustained high volume, where a server is cheaper.
Poor for long-running work, given execution time limits.
Cold starts add latency on the first request after idle, which matters for user-facing paths.
Always set concurrency limits, or a loop bills without bound.

Platform as a service

App Service, App Engine, App Platform and similar take your code and run it. Fastest path from nothing to a deployed application, with the least to learn.

Good for small teams, prototypes and applications that fit the platform’s assumptions. Constraining when you need something the platform does not support, and more expensive per unit of compute than a VM.

Choosing

Steady traffic and cost sensitivity, with someone comfortable operating servers — VM.
Containerised service, variable traffic, small team — managed container platform.
Event-driven, spiky or scheduled work — serverless.
Small team, standard stack, speed matters most — PaaS.
Many services and a platform team — Kubernetes.

Mixing is normal and usually correct: the main application on a container platform, background jobs on serverless, the database managed, static assets on object storage with a CDN.

Portability

A container runs anywhere a container runs, so moving between VM, managed containers and Kubernetes is mostly a deployment change. Serverless functions are more tied to their platform’s event model and runtime conventions.

That is not a reason to avoid serverless — it is a reason to keep business logic in ordinary functions and let the handler be a thin adapter. Then portability is a matter of replacing the adapter.

Common questions

Is serverless cheaper?

For low or spiky volume, dramatically. Above a moderate sustained request rate, a small always-on server is usually cheaper. Calculate the crossover with your own numbers.

How bad are cold starts?

Tens of milliseconds to a few seconds depending on runtime and package size. Provisioned concurrency removes them at a cost that partly defeats the pricing model.

Can I start on PaaS and move later?

Yes, and it is a sensible path. Keep the application containerisable and avoid platform-specific APIs where a standard alternative exists.

What about static sites?

Object storage with a CDN, or a static hosting platform. There is no reason to run a server for static files.

Where to go next

See Kubernetes: when and why and cloud pricing models compared.

DigitalOcean Google Cloud Microsoft Azure