workerd

The 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.

What it is: Serverless functions (FaaS)
Type: Open source
Made by: Cloudflare, Inc.
License: Apache 2.0
Facts checked: 12 October 2026

What it is

workerd (“worker-dee”, a Unix daemon name) shares most of its code with the runtime that runs Cloudflare Workers. It is server-first: your code does not open sockets, the runtime pushes events such as HTTP requests to it, and its built-in APIs are web standards like fetch(), URL and WebCrypto, implemented in native code so every isolate shares one copy. A single process runs many Workers as nanoservices: each has its own V8 isolate and global scope, but when one calls another, the callee runs in the same thread, more like a function call than a network hop. Because they are so light, the design favors homogeneous deployment: put every service on every machine and load-balance across the whole cluster, as Cloudflare does on its own servers.

Configuration is a Cap’n Proto text file listing services (Workers, disk directories, external servers, the network) and sockets to listen on. A Worker starts with no access to anything; it gets capability bindings, named objects on env that point at specific services, so code calls env.AUTH.fetch() instead of an internal URL, and the global fetch() can be limited to public addresses, which blocks SSRF. Each Worker pins a compatibility date, and the version number of workerd is itself a date, so upgrading never changes how old code behaves. Prebuilt binaries ship on npm (npx workerd serve config.capnp), and Wrangler and Miniflare use it for local development.

Why teams pick it

Bug-for-bug compatible with Cloudflare Workers, so code written for Workers can be self-hosted or tested locally on the same runtime
Nanoservices: many Workers in one process with in-thread calls between them, cheap enough to run hundreds or thousands on one server
Capability bindings make every dependency explicit in config, easy to mock in tests, and immune to SSRF by default
Always backward compatible: a newer workerd emulates the API as it was on each Worker’s compatibility date

Watch out for

Not a hardened sandbox on its own: to run code you don’t trust, wrap it in a VM, because it lacks the extra defenses Cloudflare adds against V8 bugs and Spectre
Not an edge platform: deployment, orchestration and the storage behind KV, R2 or D1 are not included, and Durable Objects in the samples are in-memory only
Developed primarily for Cloudflare’s needs; outside contributions are reviewed after internal work, and internal interfaces can change without notice
Prebuilt binaries need glibc 2.35+ on Linux or macOS 13.5+, and a CPU with SSE4.2 and CLMUL (x86-64) or CRC (arm64)

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.

Cloudflare WorkersCommercialFunctions that run in V8 isolates on Cloudflare’s network, close to the user, with almost no cold start.+1 Wrangler 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.

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 workerd uses

What uses workerd

config.capnp from the repo’s static-files-from-disk sample (trimmed) · text

using Workerd = import "/workerd/workerd.capnp";

const config :Workerd.Config = (
  services = [
    (name = "site-worker", worker = .siteWorker),
    (name = "site-files", disk = "content-dir"),   # read-only directory
  ],
  sockets = [ ( name = "http", address = "*:8080", http = (), service = "site-worker" ) ],
);

const siteWorker :Workerd.Worker = (
  compatibilityDate = "2023-02-28",
  modules = [ (name = "static.js", esModule = embed "static.js") ],
  bindings = [
    (name = "files", service = "site-files"),   # only this Worker can read the files
    (name = "config", json = "{\"hideHtmlExtension\": true}")
  ],
);

# workerd serve config.capnp --directory-path site-files=/path/to/files

See it in a real stack

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

Where it came from2017–2026

Cloudflare Workers had run customer JavaScript on its own runtime, built directly on V8 rather than Node.js, since 2017. That runtime was closed, so developers tested locally with Miniflare, which simulated the Workers API in Node.js and did not always behave the same. Code written for Workers also had no exact way to run anywhere else.

On September 27, 2022, Kenton Varda introduced the first beta of workerd under the Apache 2.0 license: not a new runtime but the Workers runtime itself, made portable, with three intended uses: self-hosting Workers applications, realistic local testing, and programmable forward or reverse proxies. Varda was explicit about what it is not: not a secure sandbox on its own, not an independent community project, and not an off-the-shelf edge platform, since Cloudflare’s service adds security layers, deployment and orchestration that are tied to its network.

Miniflare 3 was rebuilt on workerd that November, and Wrangler v3 made it the default for local development in May 2023. The repository is the canonical source Cloudflare uses for Workers, and in October 2026 Deno’s team, joining Cloudflare, said it would work toward integrating its rusty_v8 library into workerd.

Why it’s built this way

Nanoservices in one process: Microservices pay for every call with a network hop and configuration; running each service in its own isolate but in the same thread keeps independent deployment at close to library-call cost.
Capability bindings instead of global names: If internal services are reachable only through configured bindings, the global fetch() can be restricted to public URLs, which makes SSRF impossible and lets every dependency be listed, swapped or mocked from config.
A compatibility date as the version number: Workers has a hard rule against breaking live code, so each Worker pins the API of a date, and updating workerd itself is always safe.
Built-in APIs in native code: Implementing them in native code rather than JavaScript means isolates share one copy instead of loading their own, keeping the per-service overhead small enough for nanoservices.

Timeline

2017
Cloudflare Workers launches on a closed runtime built on V8
2022
workerd open-sourced in beta under Apache 2.0 on September 27
2022
Miniflare 3 rebuilt on workerd in November
2023
Wrangler v3 runs workerd locally by default from May 17
2026
Deno’s team joins Cloudflare and plans to integrate rusty_v8 into workerd

Sources6 · facts checked 12 October 2026

Improve this page on GitHub