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, 139 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
A jump-to index of every table row in this cheat sheet.
An interactive map of every table and concept in this topic.
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 | ||
npx wrangler dev (runs workerd locally) | • Open-source JavaScript/Wasm runtime powering Workers • also the engine behind wrangler dev local simulation | ||
wrangler init --type typescript | • TypeScript is a first-class language • Wrangler transpiles it at build time • Plain JavaScript (ES modules or Service Worker format) is also natively supported | ||
import mod from './lib.wasm'; const inst = await WebAssembly.instantiate(mod) | • Import a .wasm module and instantiate it inside a Worker• used to run Rust, Go, or C code compiled to Wasm within the JS runtime | ||
const worker = await env.LOADER.create({ code: aiGeneratedCode }) | • (Open beta, March 2026) Programmatically spin up isolated V8 sandboxes at runtime from within a Worker • 100× faster startup than Linux containers, ~2 MB RAM per isolate |