Cloudflare Workers run on V8 isolates instead of containers or VMs, and that architectural choice is why cold starts on Workers are measured in single-digit milliseconds instead of the hundreds of milliseconds typical of container-based serverless.
Cloudflare Workers is a serverless platform running JavaScript/TypeScript (and WASM) directly on Cloudflare's global edge network, across hundreds of locations worldwide. Because Workers use V8 isolates — the same lightweight execution sandboxing that powers browser tabs — rather than spinning up a container or VM per request, they start almost instantly, making them well suited for latency-sensitive edge logic.
Why Cloudflare Workers Matter (and When to Skip Them)
Traditional serverless functions run in one or a few regions, meaning requests from distant users pay real round-trip latency to reach the function. Workers run in the Cloudflare location closest to the request by default, and their isolate-based cold start is fast enough that "cold start latency" is a much smaller concern than with container-based serverless platforms.
Skip Workers for workloads needing full Node.js API compatibility, heavy computational work, or large memory/CPU allowances — the isolate model imposes real constraints (limited CPU time per request, a restricted subset of Node.js APIs, though this has expanded significantly) that don't fit every workload.
Getting Started with Cloudflare Workers
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const url = new URL(request.url);
if (url.pathname === "/api/hello") {
return Response.json({ message: "Hello from the edge" });
}
return new Response("Not Found", { status: 404 });
},
};
npx wrangler deploy
A wrangler.toml configures bindings to other Cloudflare services:
name = "my-worker"
main = "src/index.ts"
compatibility_date = "2026-01-01"
[[kv_namespaces]]
binding = "CACHE"
id = "abc123"
[[d1_databases]]
binding = "DB"
database_name = "my-app-db"
Core Cloudflare Workers Concepts Every Developer Should Know
Bindings connect Workers to other Cloudflare services directly, without separate network calls or SDKs — KV for key-value storage, D1 for SQLite-based relational data, R2 for object storage, and Durable Objects for stateful coordination, all accessed as typed bindings in your Worker's environment:
export default {
async fetch(request: Request, env: Env) {
const cached = await env.CACHE.get("some-key");
const { results } = await env.DB.prepare("SELECT * FROM users WHERE id = ?").bind(userId).all();
return Response.json({ cached, results });
},
};
Durable Objects provide strongly consistent, stateful coordination at the edge — useful for use cases like real-time collaboration or rate limiting that need a single source of truth, something stateless Workers alone can't provide.
CPU time limits, not wall-clock time, constrain execution. A Worker can wait on network I/O (like a fetch to an external API) for a long time without that counting heavily against its CPU budget — the constraint is actual compute time, which matters for understanding what kinds of workloads fit the platform.
The Workers runtime is not full Node.js, though compatibility has expanded substantially via nodejs_compat. Some Node-specific APIs and native modules still don't work — worth checking compatibility before porting an existing Node.js codebase directly.
Common Cloudflare Workers Mistakes and How to Fix Them
Mistake 1: assuming full Node.js compatibility without checking. Porting an existing Node.js app directly can hit unsupported APIs or native dependencies. Fix: check nodejs_compat coverage for your specific dependencies before committing to a migration, or design new Workers projects with the runtime's actual capabilities in mind from the start.
Mistake 2: using Workers for CPU-heavy, long-running computation. The platform is optimized for fast, edge-distributed request handling, not sustained heavy compute. Fix: offload genuinely CPU-intensive work to a different compute platform, using Workers for the edge-facing logic in front of it.
Mistake 3: not using bindings, instead making network calls to external services for data that could live in KV, D1, or R2 directly. This adds latency the edge architecture was specifically designed to avoid. Fix: use Cloudflare's own storage primitives via bindings wherever they fit, keeping data access as close to the Worker as the platform allows.
When Should You Use Cloudflare Workers Instead of Vercel Functions or AWS Lambda?
Use Workers when edge-distributed, low-latency execution across many global locations is the priority, and your workload fits within the isolate model's constraints (fast, I/O-bound, moderate CPU needs). Use Vercel Functions or AWS Lambda when you need fuller Node.js compatibility, heavier compute allowances, or deeper integration with those platforms' broader ecosystems.
Cloudflare Workers in Production
Design around the platform's actual execution model (fast, distributed, I/O-bound) rather than treating it as a drop-in replacement for a traditional server — workloads that fit this model see genuinely excellent latency; ones that don't will fight the constraints. Also use Durable Objects deliberately for the specific cases needing strong consistency, rather than as a default state solution for every Worker.
If your app has genuinely global users and latency-sensitive edge logic (auth checks, redirects, A/B test routing, API proxying), Cloudflare Workers is worth evaluating specifically for how much of that logic it can absorb at the edge.