Cloudflare Workers
Serverless that runs at the network edge in V8 isolates, not containers — near-zero cold starts and global-by-default, with a distinct execution model to design around.
What is Cloudflare Workers?
Cloudflare Workers runs serverless code at Cloudflare’s edge — hundreds of locations worldwide — and does it with a fundamentally different execution model than Lambda or Cloud Run. Instead of spinning up a container or microVM per function, Workers uses V8 isolates: lightweight sandboxes within a shared runtime (the same isolation Chrome uses between browser tabs). The result is near-zero cold starts (sub-millisecond — there’s no VM to boot) and code that runs close to users by default, since every edge location can execute it.
Why the isolate model changes the tradeoffs
V8 isolates are the whole story. Because there’s no per-request VM, Workers sidesteps the cold-start tax that shapes traditional serverless architecture — a decisive advantage for latency-critical, globally-distributed workloads (auth at the edge, API routing, personalization, A/B logic, request transformation). The cost of that model is constraints: Workers run JavaScript/TypeScript and WebAssembly, not arbitrary binaries or containers, within tight CPU-time limits per request, and without full Node.js APIs (a Web-standards runtime, though Node compatibility has grown). You design for the edge — small, fast, stateless-per-request — rather than lifting a container onto it.
The platform, not just the function
Workers is the center of a coherent edge stack that’s much of its appeal: KV (eventually-consistent edge key-value), Durable Objects (strongly-consistent stateful coordination at the edge — genuinely novel for things like collaborative state and rate limiting), R2 (S3-compatible object storage with zero egress fees — a direct shot at S3 egress economics), and D1 (edge SQL). This bundle is why teams choose Workers for latency-sensitive global apps over centralized serverless. The trade against AWS/GCP is ecosystem breadth and the constraint of the edge programming model.
What people get wrong
- Porting a Node.js container to Workers and hitting runtime/API and CPU-limit walls — it’s a Web-standards isolate runtime, not container FaaS.
- Ignoring Durable Objects/R2 and rebuilding state and storage that the platform provides natively (and R2 without egress fees).
- Heavy compute at the edge: strict per-request CPU limits mean Workers routes and transforms brilliantly but isn’t the place for long CPU-bound jobs.
Primary source: Cloudflare Workers documentation
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.