Cloudflare Workers is a serverless computing platform that runs code at the network edge, inside Cloudflare data centers located in hundreds of cities worldwide. Instead of starting a container or virtual machine for each function, it executes JavaScript, TypeScript and WebAssembly in lightweight V8 isolates, which gives it near-zero cold start times and makes it one of the best-known examples of edge functions in the serverless and cloud landscape.
A Worker typically intercepts an HTTP request before it reaches an origin server, or serves the whole response itself. Developers deploy code once, and the platform runs it in the location closest to each user, without any choice of region, server size or operating system.
How Cloudflare Workers runs code in isolates
Cloudflare Workers is built on the V8 JavaScript engine, the same engine used in Chromium-based browsers. Each Worker runs in an isolate, a sandboxed V8 context with its own memory heap, and thousands of isolates share a single operating system process. Creating an isolate takes milliseconds or less, compared with the hundreds of milliseconds or seconds a container-based function may need.
The programming model follows web platform APIs rather than a Node.js server. A Worker exports a fetch handler that receives a Request object and returns a Response, and it can also react to scheduled cron triggers and queue messages. A Node.js compatibility layer covers many common modules, but not every Node.js package runs unchanged.
Deployment is global by design. When a developer publishes a new version with Wrangler, the script is distributed to every edge location within seconds, and there is no concept of choosing a region or keeping instances warm. Each request is handled by whichever data center received it through anycast routing, so traffic is spread automatically and capacity planning is largely the provider’s responsibility.
The table below outlines the main building blocks a Worker interacts with.
| Component | Role | Typical use |
|---|---|---|
| Fetch handler | Entry point for HTTP requests | Routing, rewriting, APIs |
| Bindings | Configured links to platform resources | Access to storage and services |
| Workers KV | Eventually consistent key-value storage | Configuration, cached content |
| Durable Objects | Single-instance objects with strong consistency | Counters, chat rooms, coordination |
| R2 and D1 | Object storage and SQLite-based database | Files and relational data |
| Wrangler | Command-line tool for development and deployment | Local testing and publishing |
Execution limits and pricing model
Cloudflare Workers enforces per-request limits on CPU time and memory rather than letting each function choose an instance size. Billing is based mainly on request count and CPU milliseconds, and time spent waiting on network I/O does not count as CPU time, which suits workloads that mostly call other services.
The values below are representative of the published plans and change over time, so they should be confirmed against current plan terms before design decisions.
| Limit | Free plan | Paid plan |
|---|---|---|
| CPU time per request | About 10 ms | Default 30 s, configurable higher |
| Memory per isolate | 128 MB | 128 MB |
| Daily requests | Around 100,000 | Billed per million requests |
| Compressed script size | A few MB | Larger, around 10 MB |
| Wall-clock duration | No fixed cap while the client stays connected | Same, with CPU limits enforced |
The 128 MB memory ceiling is the constraint developers meet most often. Workloads that load large models, process big files in memory or need native binaries usually belong on a container platform instead.
Cloudflare Workers compared with other serverless platforms
Cloudflare Workers differs from AWS Lambda, Azure Functions and Google Cloud Run mainly in where code runs and what isolation model it uses. The comparison below highlights the practical consequences.
| Platform | Isolation model | Placement | Cold start |
|---|---|---|---|
| Cloudflare Workers | V8 isolates | Global edge by default | Typically negligible |
| AWS Lambda | Firecracker microVMs | Chosen cloud region | From about 100 ms to seconds |
| Azure Functions | Managed containers or VMs | Chosen cloud region | Varies by hosting plan |
| Google Cloud Run | Containers | Chosen cloud region | Seconds without minimum instances |
Because isolates start so quickly, Workers rarely needs workarounds such as provisioned concurrency and naturally scales to zero with no idle cost. The trade-off is a narrower runtime: region-based platforms accept almost any language, larger memory sizes and full container images.
When to choose Cloudflare Workers
Cloudflare Workers fits best when latency to users matters and each request does modest computation. It is weaker for long-running, memory-heavy or region-bound workloads.
| Workload | Fit | Reason |
|---|---|---|
| Request routing and A/B tests | Excellent | Runs before the origin with minimal delay |
| Authentication at the edge | Excellent | Rejects bad requests close to the user |
| Lightweight APIs | Good | Fast global responses with KV or D1 |
| Image or video transcoding | Poor | Exceeds CPU and memory limits |
| Data near one central database | Mixed | Edge execution adds round trips to the region |
The last case is a common surprise. A Worker running in Sydney that queries a database in Frankfurt pays the full intercontinental round trip on every query. Smart Placement, which runs the Worker near its backend instead of the user, and regional data replicas reduce this penalty.
Limitations and common pitfalls
Teams adopting Cloudflare Workers typically encounter a predictable set of constraints.
- Global state does not persist reliably between requests, because isolates can be evicted at any time.
- Workers KV is eventually consistent, so a write may take up to about a minute to appear in every location.
- Native Node.js modules and binaries do not run in the isolate sandbox.
- Vendor lock-in grows as code relies on KV, Durable Objects and other bindings.
- Debugging distributed behavior requires logs and tracing rather than a single server console.
Stripped to the essentials
Normally a website’s code runs in one building, perhaps on another continent. Cloudflare Workers places small pieces of code in hundreds of locations at once. Each visitor is answered by the nearest one.
The code starts almost instantly and costs nothing when no one uses it. It is ideal for quick tasks close to the user, such as checking a login or choosing a page version. Heavy, long jobs still belong on ordinary servers.
Where it is applied
A media company serves readers in Europe, North America and Asia from an origin server in one European data center. It wants to show region-specific consent banners and paywall rules without slowing pages or adding servers in each region.
The developers write a Worker of about 200 lines of TypeScript that reads the visitor’s country from the request, checks a subscription token and rewrites the HTML response with the correct banner. Rules are stored in Workers KV, so editors can change them without redeploying code. The logic adds only a few milliseconds per request, cached pages no longer need to vary at the origin, and origin traffic falls noticeably because invalid paywall requests are rejected at the edge.