Overview
workerd (pronounced “worker-dee”) is the open-source JavaScript and WebAssembly runtime built from the same code that powers Cloudflare Workers. It lets you run Workers-style applications on your own servers, test them locally with production fidelity, or use the runtime as a programmable HTTP proxy.
What You Can Use It For
- Application server: self-host applications written for Cloudflare Workers
- Local development: run and test Workers code with the real runtime (Wrangler and Miniflare use it under the hood)
- Programmable proxy: intercept, modify, and route HTTP traffic as a forward or reverse proxy
Design Principles
- Server-first: built for long-running servers, not CLIs or GUIs
- Standards-based APIs: built-ins follow web platform standards such as
fetch() - Nanoservices: split an app into independently deployable components that call each other with the performance of a local function call
- Capability bindings: services connect through explicitly granted capabilities instead of global namespaces, which makes code more composable and resistant to SSRF
- Always backwards compatible: versions are dated “compatibility dates”, and pinning an older date keeps your code running exactly as it did
Getting Started
Prebuilt binaries are distributed through npm, so you can run the runtime without compiling it:
npx workerd serve my-config.capnpConfiguration is written in Cap’n Proto text format and describes your services, sockets, and bindings. For day-to-day Workers development, wrangler dev already runs your code on workerd.
Security Note
workerd isolates Workers from each other, but it is not a hardened sandbox on its own. If you run untrusted code, place it inside an additional security boundary such as a virtual machine — the hosted Cloudflare Workers platform adds several more layers of defense.
Platforms
Tested on Linux and macOS (x86-64 and arm64) and Windows (x86-64). Building from source uses Bazel and a recent Clang/LLVM toolchain.
License
Apache License 2.0.
