Understand the Workers runtime

A Cloudflare Worker is not a server. It’s a small piece of JavaScript or TypeScript that runs inside a V8 isolate, the same sandbox Chrome uses to keep browser tabs apart. Cloudflare runs those isolates on machines all over its network, and the closest one handles each request.

There is no virtual machine to boot and no container to start. That’s why a Worker starts in a few milliseconds, and why it behaves differently from the Node.js server you may be used to.

The APIs are the browser’s APIs

Inside a Worker you write code against web standards: Request, Response, URL, fetch(), streams, and Web Crypto. If you have used fetch() in the browser, you already know most of it.

There is no http.createServer(), no fs, no process.env. Node.js built-ins exist only behind the nodejs_compat compatibility flag, and they are a compatibility layer, not the real thing. Code that sticks to web standards ports with zero effort.

An isolate is not your process

This is the mental shift I want you to make. A Node.js server has one process whose memory lives as long as the server runs. You can keep a counter in a variable and it just works.

A Worker isolate can serve many requests, and it can disappear at any moment. The next request may land in a fresh isolate, on a different machine, in a different city.

So module-level constants are fine. A lookup table you never change is fine. But an in-memory counter, a cache, or a login session in a global is a bug waiting to happen. It’s not durable, and it’s not private to one user. Concurrent requests can share an isolate, so global mutable state gives you race conditions, not coordination.

Where the state goes instead

There is no local disk. Anything that must survive the request goes into a binding, a named connection to a Cloudflare resource: D1 for relational data, KV for cached values, R2 for files, Durable Objects for coordinated state.

Execution is bounded too. Every request has a CPU time budget, and a slow external API eats into wall-clock limits. If a job cannot finish inside one request, move it to a Queue or a Durable Object.

Which workloads fit

Workers shine for request-driven work: APIs, HTML rendering, redirects, auth checks, webhooks. They are a poor fit for anything that expects a long-lived process, a local filesystem, or a heavy native dependency.

Before we build, go through the Books API from the Web APIs course file by file. Write down which parts are portable web-standard code and which depend on Node.js or local files. That list is the work ahead of us.