Cloudflare Workers Cheat Sheet

Updated 2026-05-21

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 LambdaTable 2: Wrangler CLI — Core WorkflowsTable 3: wrangler.toml ConfigurationTable 4: Request / Response and Web APIsTable 5: Workers KV — Distributed Key-Value StoreTable 6: Durable Objects — Stateful CoordinationTable 7: R2 Object StorageTable 8: D1 — Serverless SQLite DatabaseTable 9: Queues — Async Message ProcessingTable 10: Workers AI — Inference at the EdgeTable 11: Vectorize — Vector DatabaseTable 12: Hyperdrive — Database Connection AccelerationTable 13: Routing — Custom Domains, Routes, and ZonesTable 14: Observability — Logs, Traces, and MetricsTable 15: Smart Placement and Worker PlacementTable 16: Workers for Platforms and Service BindingsTable 17: Workflows — Durable Multi-Step ExecutionTable 18: Pricing, Limits, and Billing ModelTable 19: Common Pitfalls and Best Practices

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
V8 Isolate	`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.
Cold start time	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.
Memory per isolate	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.
Isolate reuse	`// 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.
Two-layer sandbox	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.

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
V8 Isolate	`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.
Cold start time	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.
Memory per isolate	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.
Isolate reuse	`// 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.
Two-layer sandbox	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.