cloudflare/workerd

What it is

workerd is the JavaScript/Wasm server runtime built on the same code that powers Cloudflare Workers. It is not a CLI or GUI tool; it targets server deployments, and it can be used as an application server for Workers-style apps, as a local development runtime for Workers code, or as a forward/reverse HTTP proxy that intercepts and routes requests.

The runtime follows a few design choices that shape how it is used: built-in APIs follow web platform standards such as fetch(), applications can be split into nanoservices that run in the same thread and process, and configuration connects services and external resources through capability bindings rather than global namespaces. Version numbers are dates that correspond to the maximum supported compatibility date, so older Workers code can continue to run against the API behavior of a past date.

Quick start

The repository's build path uses Bazel. Linux builds download their own LLVM toolchain and Debian sysroot; macOS requires an Xcode 26.6 installation (macOS 26 or newer); Windows requires the winget-based dependency installer and two Bazel setup steps described in the build section. With those prerequisites in place, build the server from the repository root:

bazel build //src/workerd/server:workerd

Add --config=release for a release build, or --config=thin-lto for a more performant build if a recent clang is installed. The binary lands at bazel-bin/src/workerd/server/workerd.

Next, create a Cap'n Proto config that declares a worker and an HTTP socket, plus a hello.js worker script. A minimal worker responds with fetch:

addEventListener("fetch", event => {
  event.respondWith(new Response("Hello World"));
});

The config points at that script with serviceWorkerScript = embed "hello.js", sets a compatibilityDate, and binds a socket named http on *:8080. Then serve it:

workerd serve my-config.capnp

workerd serve wrangler.jsonc is also accepted for simple Wrangler-style projects; main is bundled with esbuild, and only the listed fields (name, main, compatibility_date, compatibility_flags, vars, durable_objects, exports, migrations, no_bundle, $schema) are supported. Prebuilt binaries are available through npm via npx workerd ....

Local development and deployment

To use a locally built binary with Wrangler (v3 or greater) and Miniflare, set MINIFLARE_WORKERD_PATH to the built binary and run wrangler dev. For production, the README shows a systemd setup: a socket unit opens ports 80 and 443, and the service unit runs workerd serve as an unprivileged user with --socket-fd http=3 --socket-fd https=4 to inherit those sockets.

Constraints

workerd isolates each Worker's access to configured resources, but the project states it is not a hardened sandbox: running possibly malicious code with it requires an outer secure sandbox such as a virtual machine. Cloudflare's hosted Workers service adds its own defense layers.

Tested platforms are Linux and macOS on x86-64 and arm64, and Windows on x86-64. Prebuilt npm binaries require glibc 2.35+ on Linux, macOS 13.5+ with Xcode command line tools on macOS, and x86-64 CPUs with SSE4.2 and CLMUL, or arm64 CPUs with CRC. The project is Apache-2.0 licensed. The configuration format is Cap'n Proto, with reference documentation in the workerd.capnp comments and sample configs in the samples directory.

HotRepo's take

The repository had a single recorded daily snapshot for the C++ list on 2026-11-04, when it ranked 9th with 9 stars gained. That one record does not establish a trend, but the 2022 Hacker News thread about open-sourcing the Workers runtime drew 27 points and 2 comments, with one commenter calling it a duplicate of a prior post linking the blog context. The more useful observation for readers is that the project has spent years as the open implementation behind Workers; this snapshot alone says little about how it is being used today.

Project source and documentation