Deployment models — server, serverless, edge

Where your code actually runs matters as much as the framework. Three dominant models today — each optimizes for different things and imposes different constraints on your code.

Long-running server (VM, container on Kubernetes/ECS/Heroku): one process starts, serves requests for hours or days, holds warm caches and connection pools. Traditional, predictable, great for WebSockets and background work. Operational overhead: you provision, monitor, scale.

Serverless functions (AWS Lambda, Vercel Functions, Google Cloud Functions): your code runs per-request or per-event. No provisioning — the platform handles scale from zero to thousands. Pay-per-use. Costs: cold starts (first request after idle — 100 ms to several seconds), no persistent in-memory state, hard time limits (~15 min AWS, ~5 min Vercel Pro).

Edge runtimes (Cloudflare Workers, Vercel Edge Functions, Deno Deploy): like serverless but runs in 200+ data centers worldwide. Ultra-low latency for users near any PoP. Restricted runtime: V8 isolates only — no Node APIs, no native modules, tight memory and CPU-time budgets. Great for auth, rewrites, personalization; wrong for heavy computation.

The trade-off in one line: long-running = predictable + full capabilities + ops overhead. Serverless = scale-to-zero + pay-per-use + cold starts + ephemeral. Edge = global low latency + restricted capabilities. Match your workload to the model — don't let a hype choice drive the architecture.