Cloudflare Workers is a serverless edge compute platform that runs JavaScript, TypeScript, and WebAssembly directly inside Cloudflare's global network using V8 isolates — the same engine that powers Chrome and Node.js. Unlike traditional serverless functions that spin up containers or virtual machines per invocation, Workers share a single runtime process across thousands of isolated execution contexts, delivering sub-millisecond cold starts and dramatically lower memory overhead. The platform pairs compute with a rich ecosystem of storage and AI primitives — KV, R2, D1, Durable Objects, Queues, Workers AI, Vectorize — all accessible through in-process bindings that eliminate network hops. The key mental model to carry into the tables: Workers are stateless by default (isolates may be evicted or reused across requests), so anything requiring persistence or coordination belongs in Durable Objects, KV, D1, or Queues rather than module-level variables.
What This Cheat Sheet Covers
This topic spans 19 focused tables and 149 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: Runtime Model — V8 Isolates vs Containers vs Lambda
Understanding the isolate model is foundational to everything else in Workers. The execution environment shapes cold-start behavior, memory limits, billing, and how you reason about global state.
| Type | Example | Description |
|---|---|---|
export default { async fetch(req, env, ctx) { return new Response("hi") } } | • Lightweight execution context inside the V8 engine • each isolate has its own private heap but thousands share a single OS process, paying the runtime overhead only once | |
Workers: ~0 ms; Lambda (Node.js): 200–1000 ms | Workers start in under 5 ms (typically 0 ms for warm paths) by creating an isolate inside an existing process instead of booting a container or VM. | |
128 MB heap limit per isolate | • Each isolate is capped at 128 MB covering the JavaScript heap and WebAssembly allocations • the runtime creates a new isolate when this is exceeded | |
// module-level var may be shared across requests | • Cloudflare may reuse or evict isolates at any time • no guarantee two requests hit the same instance — so global mutable state causes cross-request data leaks | |
V8 isolate boundary + Linux namespaces / seccomp | • Layer 1: V8 isolate prevents memory access outside its boundary • Layer 2: OS-level process sandbox blocks all filesystem and network syscalls |