--- title: "01 — Cloudflare Workers and the Edge Runtime" uid: workers-and-edge-runtime tags: ["workers", "cloudflare", "v8", "roadmap:cloudflare", "serverless", "edge-computing", "javascript"] excerpt: "A Worker is JavaScript running in a V8 isolate on a machine next to the user — not on a box you own or provision. Small to say, large in what it implies." date: 2026-08-13T03:28:19+0000 source: https://www.aveshina.my.id/en/blog/workers-and-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. ```figure ``` 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/](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/](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/](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/](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/](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/](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/](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/](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](https://cloud.google.com/discover/what-is-serverless-architecture) ```quiz Q: A Cloudflare Worker runs inside what kind of execution environment? - A Docker container, like a typical Lambda function - A V8 isolate — the same sandboxing tech Chrome uses per tab - A full Node.js process with access to the fs module correct: 1 explain: Workers run in V8 isolates, not containers or VMs. That's what gives them near-zero cold starts, and it's also why most Node built-ins aren't available — it's a web runtime, not a server runtime. Q: Why does running code at the edge reduce latency? - Edge machines have faster CPUs than origin servers - The request lands at a location near the user, so network distance shrinks - The edge caches every response automatically without code correct: 1 explain: The compute time is roughly the same either way; the win is purely network. The request no longer crosses continents to reach a single origin — it lands at the nearest edge city. Q: Which of these is NOT available by default in the Workers runtime? - The Fetch API - The Node.js `fs` (file system) module - `Request` and `Response` objects correct: 1 explain: Workers is a web-standard runtime, not Node.js. `fetch`, `Request`, `Response`, `Headers` are all there; `fs` and most `node:*` modules are not. Q: Workers are stateless at the function level. Where does persistent state live? - In global variables that survive between requests - In separate storage products like KV, D1, or Durable Objects - Nowhere — Workers can never have state correct: 1 explain: Each invocation is effectively a fresh (or briefly reused) isolate. Persistence is a separate concern handled by the storage bindings, not by the Worker's own memory. Q: What shapes what you can realistically do in a single Worker invocation? - The per-request CPU-time ceiling - The size of the deploy bundle only - Whether the user is on HTTP/2 or HTTP/3 correct: 0 explain: Workers are designed for short-lived request handling with a CPU-time budget (50ms on free, more on paid). That's why heavy data processing doesn't fit and belongs in a different layer. ```