On this page
You keep seeing “runs on Cloudflare Workers” attached to modern tools, EmDash among them, and you’re nodding along without being totally sure what a Worker actually is. Serverless? Edge? Isolates? Let’s clear it up in plain English, no hand-waving.
By the end you’ll understand what a Worker is, why it’s different from a normal server or a Lambda function, and why it’s a natural foundation for a CMS like EmDash.
The one-sentence version
A Cloudflare Worker is a small piece of code that runs on Cloudflare’s global network, in hundreds of locations close to your users, spinning up instantly when a request arrives and costing nothing when idle.
That’s it. Now let’s unpack the three ideas hiding in that sentence: serverless, edge, and isolates.
Serverless: you don’t manage a server
Traditionally, running a website means renting a server (or a VM, or a container) that sits there 24/7. You patch its OS, you size it for peak traffic, and you pay for it even at 4am when nobody’s visiting.
“Serverless” flips that. You upload just your code, and the platform runs it on demand. There’s still a server somewhere, the word is marketing, but you never see it, size it, or patch it. No SSH, no OS updates, no capacity planning.
The knock-on effect that people love: scale-to-zero. If no requests come in, nothing runs and you pay nothing. When a thousand requests arrive at once, the platform runs your code a thousand times in parallel. You don’t configure any of that.
Edge: your code runs close to the user
Normally your server lives in one place, say, a data center in Virginia. A visitor in Sydney sends every request halfway around the planet and waits for it to come back. That round-trip is latency, and it adds up.
Cloudflare has a network of data centers in hundreds of cities worldwide. “The edge” means running your code in whichever of those is nearest to each visitor. The Sydney user hits a Sydney data center; the London user hits London. Same code, run close to everyone.
For a website, that means the dynamic parts, rendering a page, checking auth, hitting the database, happen near the reader instead of in one distant spot. It’s a big reason edge-served sites feel snappy globally without you setting up a CDN and origin servers by hand.
Isolates: how Workers start instantly
Here’s the clever bit, and the thing that makes Workers different from older serverless like AWS Lambda.
Lambda-style platforms typically spin up a container or micro-VM per function. That’s isolated and safe, but starting one takes time, the dreaded “cold start” of a few hundred milliseconds to seconds while a whole environment boots.
Cloudflare Workers instead use V8 isolates, the same lightweight sandboxing technology that lets your browser run many websites’ JavaScript side by side without one tab reading another’s data. An isolate isn’t a whole virtual machine; it’s a cheap, secure compartment inside a shared runtime. Cloudflare can create one in around a millisecond, and can keep many isolates running in the same process safely.
The practical results:
- Effectively no cold starts. A Worker is ready almost instantly.
- Massive density. One machine runs enormous numbers of isolates, which is how “run my code in hundreds of cities” is even economical.
- Strong isolation. Your code can’t see anyone else’s, by design.
The trade-off: an isolate is not a full Node.js server. Workers run a V8 environment with web-standard APIs (fetch, Request, Response, Web Crypto) plus Cloudflare’s runtime APIs. Not every Node library works unchanged. Modern frameworks, Astro included, target this environment directly, so in practice you mostly don’t notice, but it’s why “runs on Workers” is a real design constraint, not just a hosting choice.
What you pay for: CPU time, not wall-clock time
This surprises people. On a normal server you pay for time the machine exists. With Workers you’re billed largely for CPU time actually spent computing, the milliseconds your code is doing work, not for the time it spends waiting (say, on a slow database or an upstream API).
For request/response web work, which is bursty and full of waiting, this is a genuinely different and often much cheaper cost shape. There’s a generous free tier, and the Workers Paid plan starts at $5/month when you need more (including features like the Dynamic Workers that power sandboxed plugins).
A quick mental model
Put it together:
Request from a user in Tokyo
↓
Hits Cloudflare's Tokyo data center (the edge)
↓
A V8 isolate runs your Worker code instantly (no cold start)
↓
Worker does its work, maybe reads a database, renders a page
↓
Response goes back to Tokyo, milliseconds away
↓
Idle again → you pay nothing until the next requestWhy this is a great foundation for a CMS
This is exactly why EmDash, Cloudflare’s open-source CMS, is built on Workers:
- Global speed by default. Your content renders near every reader, no CDN wrangling.
- Scale-to-zero economics. A low-traffic blog costs almost nothing; a traffic spike is absorbed automatically. Cloudflare’s own blog runs on EmDash and shrugged off a 28,000 RPS DDoS.
- No server to patch. The single biggest source of WordPress security pain, an aging server and PHP stack, simply isn’t there.
- A natural home for sandboxed plugins. Isolates already provide strong, cheap isolation, so EmDash runs each plugin in its own isolate with declared capabilities, safe by construction.
Workers don’t work alone, though. A CMS also needs a database and file storage, and Cloudflare provides both as serverless companions: D1 for the database (see Cloudflare D1 explained) and R2 for files (see R2 vs S3). Together they’re the trio EmDash deploys onto.
Pushing a real site onto Workers takes a couple of wrangler commands, which is the whole appeal: no server to provision, no capacity to plan.
Workers is the network your site runs on if you move to 2emdash: we rebuild ageing websites on Cloudflare and hand the owner a simple panel to run them from. We’re an independent service, not affiliated with Cloudflare or the EmDash project.