Cloudflare Workers

Functions that run in V8 isolates on Cloudflare’s network, close to the user, with almost no cold start.

What it is: Serverless functions (FaaS)
Type: Commercial product
Made by: Cloudflare, Inc.
License: Proprietary (the workerd runtime is Apache 2.0)
Facts checked: 5 October 2026

What it is

Workers don’t use containers or VMs per function. Each Cloudflare machine runs the V8 JavaScript engine (the one in Chrome and Node.js) once, and every Worker runs inside it as an isolate: a sandboxed context with its own memory. One process can hold hundreds or thousands of isolates and switch between them. Cloudflare says an isolate starts about a hundred times faster than a Node process in a container or VM and uses an order of magnitude less memory, so there’s no real cold start to design around.

Your code runs in Cloudflare data centres around the world, in whichever one is nearest the user. JavaScript, TypeScript, Python and Rust are supported directly, and other languages can compile to WebAssembly. Workers talk to Cloudflare’s storage (R2, KV, D1, Durable Objects) through bindings rather than network credentials. The paid plan starts at $5 a month with 10 million requests and 30 million CPU milliseconds included; you’re billed for CPU time, not time spent waiting on the network.

Why teams pick it

Starts in a fraction of a container’s time, so scale-from-zero is effectively free
Runs near every user by default, with no regions to pick
Billing counts CPU time only, so a Worker that waits on slow APIs stays cheap
The runtime, workerd, is open source, so you can run the same code locally or self-host it

Watch out for

Not a full Node.js or Linux environment: no arbitrary binaries, and some npm packages won’t run
128 MB of memory per isolate, and CPU time is capped (10 ms on the Free plan, up to 5 minutes on Paid)
A Worker’s code is capped at 64 MiB uncompressed, which rules out large dependencies or bundled models
Running near users helps little if your database is in one region far away

The Cloudflare Workers family

1 technologies built from or on Cloudflare Workers

Tools

WranglerOpen sourceThe command-line tool for Cloudflare Workers: it reads `wrangler.jsonc`, runs your Worker locally on the real runtime, deploys it, and manages the D1, KV, R2 and other resources it binds to.

Alternatives

What all serverless functions (faas) have in common →

AWS LambdaAWSAWS’s functions service: upload a handler, connect a trigger, and pay per request and per millisecond.

Beta9Open sourceThe open-source engine behind Beam’s cloud: decorate a Python function and it runs as an autoscaling GPU endpoint, task queue or sandbox, on Beam or on your own Kubernetes cluster.

Cloudflare Browser RunRenamedCommercialHeadless Chrome on demand in Cloudflare’s network, called Browser Rendering until April 2026: one HTTP call for a screenshot, PDF, Markdown or crawl, or a full browser session driven by Puppeteer, Playwright, CDP or an AI agent.FissionOpen sourceOpen-source functions on Kubernetes: a pool of warm, generic pods takes your code on the first call, so cold starts stay around 100 ms.

workerdOpen sourceThe open-source JavaScript and WebAssembly server runtime behind Cloudflare Workers, which you can run yourself as an application server, a local dev server or a programmable HTTP proxy.

Workers AICommercialServerless inference on GPUs in Cloudflare’s network: call one of 50+ open models by name from a Worker binding or a REST API, and pay per unit of GPU work instead of renting GPUs.

How it fits with other technologies

What Cloudflare Workers uses

What uses Cloudflare Workers

A Worker that serves files from an R2 bucket · ts

export default {
  async fetch(request, env): Promise<Response> {
    const key = new URL(request.url).pathname.slice(1);
    const object = await env.FILES.get(key); // R2 binding from wrangler config
    if (object === null) return new Response("Not found", { status: 404 });

    const headers = new Headers();
    object.writeHttpMetadata(headers);
    headers.set("etag", object.httpEtag);
    return new Response(object.body, { headers });
  },
} satisfies ExportedHandler<Env>;

See it in a real stack

No architecture uses Cloudflare Workers yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from2017–2025

In 2017 Cloudflare was, at its core, an HTTP cache running in 117 locations, and customers kept asking for behaviour its settings didn’t cover: their own cache rules, custom load balancing, bespoke security checks. Each answer meant building another product feature. As the launch post put it, “We can keep adding features forever, but we’ll never cover every possible use case this way.” The alternative was to let customers run their own code on Cloudflare’s servers.

Kenton Varda, who wrote most of Google’s open-source Protocol Buffers v2 and co-founded Sandstorm.io, led the work and announced Workers on September 29, 2017. Giving every customer a VM or container in every location was out of the question: VMs needed hundreds of megabytes of RAM and typically took tens of seconds to boot. So Workers ran JavaScript in V8 isolates, many to a process. It became available to everyone on March 13, 2018, at $0.50 per million requests with a $5 monthly minimum.

Workers grew from small scripts that rewrite requests into a full platform: Durable Objects added consistent state in 2020, the workerd runtime was open-sourced in 2022, and Containers arrived in beta in 2025 for code that doesn’t fit in an isolate.

Why it’s built this way

V8 isolates instead of containers or VMs: Code has to run in every data centre, on demand, for every customer. Isolates share one runtime process, start in milliseconds and use a few megabytes, so Cloudflare can afford to keep almost anyone’s code ready almost everywhere.
JavaScript first: Varda called V8 “arguably the most scrutinized code sandbox in the history of computing”, backed by Chrome’s security team, and web developers already knew the language.
The browser’s Service Worker API: Instead of inventing request hooks, Workers adopted an existing web standard. Its asynchronous model lets one script make several subrequests in series or in parallel and combine the results.

Timeline

2017
Kenton Varda announces Workers on September 29
2018
Generally available on March 13; isolates explained in “Cloud Computing without Containers”
2020
Durable Objects bring strongly consistent state to the edge
2022
The workerd runtime is open-sourced under Apache 2.0
2023
Workers AI runs models on GPUs in Cloudflare’s network
2025
Cloudflare Containers enter public beta in June, alongside Workers

Sources7 · facts checked 5 October 2026

Improve this page on GitHub