01 — Cloudflare Workers and the Edge Runtime

"Serverless functions, somewhere on the edge" was my working definition of Workers, and "somewhere" was doing all the work. The idea everything else hangs off: a Worker is just JavaScript running in a V8 isolate on a machine sitting next to the user, not on a box I own or provision. [1] The shift is small to say and large in what it implies.

The framing that finally landed is the contrast with the way of thinking I carried from traditional hosting. In the old model, my server lives in one region, every request crosses the world to reach it, and I babysit the machine. In the Workers model, I push code once and Cloudflare runs it on its global network — the request lands at the edge location closest to the user, and my code executes there [2][3]. There is no single origin. The network _is_ the computer.

That diagram is the whole thesis. Before I touch a line of code, the prerequisites and the runtime itself deserve their own section — because the Workers model only makes sense once you know what it's built on.

Prerequisites you actually need

Three things from the reference list are worth naming explicitly, because they kept biting me when I skipped them:

• JavaScript fundamentals. Workers are JavaScript (or TypeScript, which compiles to JS). The non-negotiables are async programming — Promises and async/await — because almost everything a Worker does is an asynchronous I/O call. If fetch() returning a Promise still feels weird, that's the first gap to close [4].
• Basic command-line knowledge. You live in a terminal with Workers — npx wrangler deploy, wrangler dev, wrangler tail. Navigating directories, editing files, running npm scripts. The Wrangler CLI is the primary interface [5].
• HTTP and web protocols. A Worker _is_ an HTTP conversation. Methods (GET/POST), status codes, headers, and caching semantics all matter directly — and modern protocols like HTTP/2 and HTTP/3 are what make the edge fast [6]. TLS/SSL is assumed; everything is encrypted by default.

Git basics show up here too, but mostly because Pages (Cloudflare's static hosting) integrates with a Git repository for deploys [7]. For pure Workers, you can get away with less.

The Workers runtime: V8 isolates, not containers

This is the detail I had to take seriously. A Worker does not run in a container or a VM. It runs in a V8 isolate — the same sandboxing technology Chrome uses to keep one tab from crashing another [1][8].

The practical consequences:

• Cold starts are near-zero. V8 can spin up an isolate in roughly five milliseconds. There's no container image to pull, no OS to boot. Most requests hit a warm isolate anyway.
• No Node.js. The runtime is V8 plus a set of web-standard APIs (Request, Response, fetch, Headers, URL) and a handful of Cloudflare-specific bindings. Things I took for granted in Node — fs, child_process, most of node:* — aren't there. It's a web runtime, not a server runtime.
• Limited CPU time. Workers are designed for short-lived request handling. There's a CPU-time ceiling (50ms on the free plan, higher on paid), which shapes what you can and can't do in a single invocation.

The runtime itself is open-source as workerd, which matters because it means I can run the exact same execution environment locally that runs in production [8].

Edge computing: computation that moves to the data

The phrase that clicked for me: edge computing brings computation closer to the user, minimizing latency [3]. The traditional model forces data to travel to where the compute lives. The edge model inverts that — the compute travels to where the request lands.

This isn't a buzzword when you see the numbers. A user in Singapore hitting a Virginia origin pays ~200ms of network round trip before the server even sees the request. The same user hitting a Singapore edge location pays ~5ms. The compute itself — parsing the request, consulting a cache, calling an upstream — happens in the same few milliseconds either way; the win is purely in the network distance that disappears [3].

What you can _do_ at the edge is whatever fits in the CPU budget: personalize content, filter and rewrite requests, make routing decisions, serve cached responses, call external APIs. Heavy data processing doesn't fit, and that's by design.

Serverless, specifically

Workers are serverless in the precise sense: I don't provision or maintain servers, I deploy code, and Cloudflare handles scaling and infrastructure [9]. The pricing model follows — pay per request and per CPU-time, not per idle box sitting in a rack.

One nuance worth pinning down: serverless on Workers is _stateless_ at the function level. Each invocation gets a fresh isolate (or a warm one reused for a few requests), and nothing persists between invocations by default. State is a separate concern handled by the storage products — KV, D1, Durable Objects — which I'll get to in later notes. The Worker itself is a pure function of its request and its bindings.

How I use this

The way of thinking pays off in two places. First, expectations: when something is slow, I check where the Worker's dependencies live, not the Worker itself — the Worker is already next to the user. A Worker that calls a slow origin re-introduces all the latency the edge removed. Second, scope: I reach for Workers for request-handling, routing, caching, and lightweight compute at the edge, and I don't try to make them do long-running jobs or heavy processing. Those go to a different layer.

References

[1] Cloudflare, "How Workers works," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/workers/reference/how-workers-works/

[2] Cloudflare, "JavaScript · Cloudflare Workers," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/workers/languages/javascript/

[3] Cloudflare, "What is edge computing?," Cloudflare Learning, 2024. [Online]. Available: https://www.cloudflare.com/learning/serverless/glossary/what-is-edge-computing/

[4] MDN, "JavaScript fundamentals," Mozilla Developer Network curriculum. [Online]. Available: https://developer.mozilla.org/en-US/curriculum/core/javascript-fundamentals/

[5] Cloudflare, "Wrangler CLI," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/workers/wrangler/

[6] Cloudflare, "What is HTTP?," Cloudflare Learning, 2024. [Online]. Available: https://www.cloudflare.com/en-gb/learning/ddos/glossary/hypertext-transfer-protocol-http/

[7] Cloudflare, "Git integration - Cloudflare Pages," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/pages/configuration/git-integration/

[8] Cloudflare, "Introducing workerd: the open source Workers runtime," Cloudflare Blog, 2022. [Online]. Available: https://blog.cloudflare.com/workerd-open-source-workers-runtime/

[9] Google Cloud, "What is serverless architecture?," 2024. [Online]. Available: https://cloud.google.com/discover/what-is-serverless-architecture