Architecture · Reference
Choosing a deployment model, without the hype
Static, server-rendered, serverless functions, containers, virtual machines and managed PaaS are six different answers to one question: where does your code actually run, and what does that cost you in cold starts, scaling behaviour and ongoing ops? The ledger below sorts and filters on the columns that matter; the prose around it explains the trade-offs a bare table can't.
Once you know which model fits, describe the app and the blueprint generator will scaffold it for that choice.
Where logic and rendering happen
Static and SSR are a rendering choice, not a hosting choice
Before serverless-vs-containers even comes up, most apps first decide whether a page's HTML is built once at deploy time or rebuilt on every request.
Static rendering generates a separate HTML file per URL at build time, so every visitor gets an identical, already-finished response straight from a CDN edge node — nothing runs on a server when the request arrives. Server-side rendering (SSR) instead builds the HTML fresh for each request, which is slower per request but lets the page reflect data that's different for every visitor. Google's web.dev engineering team frames this as the core rendering decision underneath every other architecture choice, and is explicit that the two approaches have different, not simply better-or-worse, performance profiles: static rendering gets a consistently fast time-to-first-byte because nothing is computed on demand, while SSR can pull in live or personalised data that static pages structurally cannot.
The practical rule: if the same URL should show the same content to everyone, render it statically and let a CDN do the work for free at request time. If the content depends on who's asking — a logged-in dashboard, a cart, a personalised feed — you need SSR, a serverless function, or a full backend, because static output has no way to differ per visitor.
The ledger
Six models, sorted your way
Click any column to sort; type in the box to filter by model, use-case or keyword. No row is "best" — each is a default for a real, common situation.
| Model | What it suits | Cold-start behaviour | Scaling shape | Typical cost driver | When it's the wrong choice |
|---|---|---|---|---|---|
| Static | Marketing pages, docs, blogs — content identical for every visitor | None — a CDN edge node returns a file it already has; no execution happens | Scales by serving more cached copies from more edge locations, essentially flat per request | Bandwidth/requests to the CDN and build frequency, not runtime compute | Any page whose content must differ per visitor — a dashboard, a cart, personalised results |
| Server-rendered (SSR) | Pages that need fresh or personalised data on every load, but still want fast first paint | Usually low if the server process is already running; a fresh cold instance still has to boot the app first | Scales by running more server processes/instances behind a load balancer or platform autoscaler | Server compute time per request, since every request re-renders | High-traffic pages whose content barely changes — you're paying to regenerate the same output repeatedly |
| Serverless functions | Spiky or infrequent traffic, thin endpoints (webhooks, forms, small APIs) that shouldn't need a server managed 24/7 | Provider-dependent and the single biggest differentiator in this row — see the sources ledger for AWS's and Cloudflare's own documented behaviour | Scales per request automatically, typically to zero when idle and up to provider concurrency limits under load | Invocation count plus compute time actually used (e.g. requests and CPU/duration), not idle capacity | Long-running jobs, heavy startup dependencies, or workloads needing a persistent in-memory connection pool |
| Containers | Custom runtimes, long-running processes, or teams standardising on one packaging format across environments | Depends on the platform: container platforms that scale to zero (e.g. request-driven container services) pay a startup cost on the first request after idle; container platforms kept always-on avoid it entirely | Scales by starting more container instances, either automatically (managed platforms) or manually/via an orchestrator (Kubernetes) | Reserved or metered compute time (CPU/memory) the container occupies, plus orchestration overhead at scale | A small, simple app where a full container/orchestrator adds operational weight with no matching payoff |
| Virtual machines | Workloads needing full OS-level control, specific kernel/driver access, or legacy software that assumes a persistent server | None during operation — a running VM has no per-request cold start; only a full reboot or new instance has boot time | Scales by adding more VM instances behind a load balancer (horizontal) or resizing an instance (vertical); rarely scales to zero | Reserved instance-hours, billed whether or not the VM is handling traffic | Spiky or low-traffic workloads — you pay for capacity around the clock even while idle |
| Managed PaaS | Teams that want to push code and get a running app without managing servers, containers or orchestration themselves | Varies by platform and plan; entry-level tiers on some platforms sleep idle apps, which then pay a wake-up cost on the next request | Scales by adding platform-managed instances/dynos, usually via a dashboard slider or simple config, not custom orchestration | Per-instance or per-dyno pricing tiers, plus add-ons (databases, background workers) billed separately | Workloads with unusual resource needs (GPUs, specific OS packages) the platform's managed environment doesn't expose |
"Typical cost driver" names the usage dimension you're billed on, not a rate — published rates change too often to print here honestly; see each provider's own pricing page for current numbers.
The honest part
Cold starts are a real cost, and providers document them differently
This is the one row in the ledger where "it depends on the provider" isn't a dodge — it's the actual answer, and it's worth reading a primary source rather than a rule of thumb.
AWS documents its own Lambda cold starts directly: an execution environment is created by downloading the function's code, starting the runtime, and running any initialization code outside the handler, and AWS states that this "typically" happens in under 1% of invocations, with the added latency ranging from under 100 milliseconds to over a second depending on runtime, package size and memory configuration. Reused ("warm") environments skip all of that and finish faster. Cloudflare, by contrast, documents Workers as billing on requests and CPU time with no separate charge for idle capacity, running each request in an isolated V8 context rather than a full container — a structurally different execution model, not just a faster version of the same one. Google Cloud Run's own documentation focuses less on cold starts and more on concurrency: a single instance can be configured to handle up to hundreds of simultaneous requests, and minimum-instance settings exist specifically to keep instances warm when a cold start would be unacceptable.
The honest takeaway: don't repeat a specific millisecond figure you read somewhere as if it applies to your stack. Cold-start duration depends on your runtime, package size, memory allocation and how long the platform keeps environments warm — read the provider's own current documentation (linked in the sources ledger) for the workload you're actually deploying, and if the number matters to your product, measure it yourself in a staging environment before you commit.
Sources
- Addy Osmani & Jason Miller, "Rendering on the Web," web.dev (Google Chrome team). web.dev/articles/rendering-on-the-web. Accessed 26 Jul 2026.
- AWS, "Understanding the Lambda execution environment lifecycle" — Init/Invoke/Shutdown phases and the documented cold-start frequency and duration range. docs.aws.amazon.com/lambda/latest/dg/lambda-runtime-environment.html. Accessed 26 Jul 2026.
- Cloudflare, "Pricing · Cloudflare Workers docs" — request- and CPU-time-based billing with no separate egress/bandwidth charge. developers.cloudflare.com/workers/platform/pricing/. Accessed 26 Jul 2026.
- Google Cloud, "Maximum concurrent requests for services · Cloud Run" — per-instance concurrency and its relationship to instance count and cost. docs.cloud.google.com/run/docs/about-concurrency. Accessed 26 Jul 2026.
- DeployCloud, "Serverless or containers — choose without regret" (this site) — a narrower, FAQ-style companion focused specifically on the serverless-vs-containers decision. deploycloud.allfrontierglobal.com/serverless-vs-containers-guide.
FAQ