workerd: Cloudflare’s Workers Runtime Goes Open Source
Cloudflare has released the first beta of workerd (pronounced “worker dee”), the open source JavaScript/Wasm runtime that powers Cloudflare Workers. Available under the Apache License 2.0, workerd shares most of its codebase with the production Workers runtime, with modifications aimed at making it portable to other environments. The name follows the Unix convention of appending “-d” (for “daemon”) to program names, and is written in lower case as is traditional for Unix executables. The code is available on GitHub.
Self-hosting and local development
workerd serves multiple use cases. For self-hosting, it is intended to be a production-ready web server for applications that would otherwise run on Cloudflare Workers. The runtime is deliberately unopinionated about hosting environments, so it fits into whatever server, VM, container, or orchestration system you already use.
Since Workers relies on standardized web APIs, applications are not locked into Cloudflare. workerd adds another path for portability: because it uses the same underlying code as the production Workers runtime, self-hosted deployments get exact, “bug-for-bug” compatibility with the platform.
For local development, workerd is designed to provide realistic testing of Workers code. Previously, this was handled by Miniflare, which simulated the Workers API on top of Node.js. While Miniflare worked well, its behavior sometimes diverged from actual Workers on Cloudflare. With workerd, both Miniflare and the Wrangler CLI will be able to offer a more accurate simulation by relying on the same runtime code used in production.
The runtime can also act as an application host, a proxy, or both, supporting forward and reverse proxy modes. In either case, JavaScript code can intercept and process requests before forwarding them. This approach replaces the bespoke configuration languages typical of traditional web servers and proxies, offering more power with configuration that is easier to write and understand.
Server-first architecture
Unlike general-purpose JavaScript and Wasm runtimes that target command-line tools, local applications, and servers alike, workerd focuses exclusively on servers, currently HTTP servers in particular. Applications built on workerd are event-driven at the top level: the runtime pushes events to the application rather than having the application open listen sockets and accept connections. This basic inversion of control underpins several of the runtime’s key features.
Nanoservices
Microservices have gained popularity as a way to split monolithic servers into independently deployable components. However, that independence comes at a price: what was once a fast library call becomes networked communication, adding overhead plus the configuration and administration burden of securing reliable connections. As the codebase is split into more and more services, these costs grow and eventually outweigh the benefits.
workerd introduces a nanoservice model that aims to deliver the benefits of independent deployment with overhead closer to library calls. Many Workers can run in the same process, each in its own isolate with its own code and global scope. When one Worker sends a request to another, the destination actually runs in the same thread with zero added latency, making the interaction closer to a function call than to a network request.
To make nanoservices practical, the runtime had to minimize baseline overhead per service. Two design decisions stand out. First, many nanoservices are run within a single process, sharing basic process overhead and reducing context-switching costs. Second, all built-in APIs are implemented in native code, so every isolate shares the same copy of that code rather than loading JavaScript implementations separately. These choices were the reason Cloudflare built a custom runtime for Workers in the first place, and they would be difficult to retrofit into an existing runtime.
Homogeneous deployment
The nanoservice model enables a different deployment strategy than typical microservices. In the traditional approach, different services are deployed to different containers across a cluster, with manual allocation of capacity and autoscaling per service. workerd supports an alternative: every machine runs every service.
Because nanoservices are far lighter-weight than containers, a single server can host hundreds or even thousands of them. That makes it feasible to deploy every service to every machine in a fleet, eliminating per-service scaling concerns. Requests are simply load balanced across the cluster, and the cluster is scaled as a whole. Cloudflare has used this homogeneous model since its inception, with every edge server running the full software stack so that any server can handle any request independently. This is what lets services, including those using Workers, jump from zero traffic to millions of requests per second instantly.
Secure-by-default capability bindings
The way workerd applications access external resources differs from most runtimes. Typical platforms assume the application can talk to the entire world, leaving it to the application to name resources via global identifiers such as URLs. For example, code talking to an authentication microservice might directly reference that service’s URL:
// Traditional approach without capability bindings.
fetch("https://auth-service.internal-network.example.com/api", {
method: "POST",
body: JSON.stringify(authRequest),
headers: { "Authorization": env.AUTH_SERVICE_TOKEN }
});In workerd, an application starts with no ability to communicate with anything external. It must be explicitly configured with capability bindings that grant access to specific resources. Code that needs the authentication service would instead be configured with a binding called authService:
// Capability-based approach. Hostname doesn't matter; all
// requests to AUTH_SERVICE.fetch() go to the auth service.
env.AUTH_SERVICE.fetch("https://auth/api", {
method: "POST",
body: JSON.stringify(authRequest),
});This difference goes beyond syntax. Because internal services must be reached through bindings, the global fetch() function can be restricted to publicly-routable URLs only, making applications totally immune to SSRF attacks. Internal services can no longer be reached unintentionally through a compromised application. In fact, the global fetch() is itself backed by a binding that can be configured: by default it connects to the public internet, but it can be overridden to permit private addresses, route through a specific proxy, or be blocked entirely.
Restricting access to internal services to configurable bindings yields several practical benefits:
- The complete list of internal services an application uses can be seen at a glance, without reading every line of code.
- These services can always be replaced with mocks for testing.
- Authentication behavior, such as client certificates, or the choice of backend can be changed via configuration, without code modifications.
Services on the receiving end of a binding benefit as well. An authentication service running as another Worker nanoservice need not be bound to a network address at all; it can be reachable only through other Workers’ bindings. In that case, it does not need to verify that a request comes from an authorized client, since only authorized clients can reach it in the first place.
Backwards compatibility guarantees
Cloudflare Workers enforces a hard rule against breaking live production applications, and workerd inherits that commitment. The runtime uses Workers’ compatibility date system to manage breaking changes. Every Worker is configured with a compatibility date, and the runtime guarantees the API behaves exactly as it did on that date. New breaking changes are documented and scheduled for future dates, but updating is always optional: old dates continue to be supported by newer versions of workerd, so it is always safe to upgrade the runtime without touching your code.
Scope of the release
Before diving in, it's worth being explicit about what workerd is not, so expectations stay aligned with reality.
Not a sandbox
workerd alone is not a secure environment for running untrusted code. If you intend to execute code you don't trust, you must wrap workerd in an additional sandboxing layer, such as a purpose-configured virtual machine.
The design of workerd ensures a Worker cannot reach external resources it hasn't been explicitly granted via a capability. But a complete sandbox must also anticipate bugs—both software and hardware. On its own, workerd cannot defend against hardware-level issues like Spectre, nor can it fully mitigate potential vulnerabilities in V8 or in its own codebase.
The Cloudflare Workers service runs the same code found in workerd, but layers substantial additional hardening on top. These measures, which include automated V8 patch deployment, customer risk segmentation, and reliance on non-portable kernel features, are tightly coupled to Cloudflare's specific infrastructure. They are not packaged in a way that can be reused elsewhere.
Not an independent project
workerd is the core of Cloudflare Workers, developed by a dedicated Cloudflare team. The GitHub repository is the canonical source for Cloudflare Workers, and the team will do much of their work directly in that repository. This mirrors how V8 is primarily developed by the Chrome team for Chrome: workerd will be primarily developed by the Cloudflare Workers team for Cloudflare Workers.
As a consequence, external contributions won't necessarily sit on an even footing with internal ones. Review bandwidth is finite, and work required for Cloudflare Workers will take precedence. Not every feature proposal will be accepted, even if fully implemented, because review and maintenance carry a cost. Cloudflare's product management team evaluates feature fit, and many internally generated ideas already don't make the cut.
If you have a substantial feature in mind, the best approach is to open a GitHub issue early and discuss it before writing code. That way you can gauge the likelihood of a PR being accepted and get implementation guidance. Also note that internal interfaces may look clean but can change without warning. Building on workerd internals means accepting churn or pinning to a specific version.
Not an edge platform
The full Cloudflare Workers service extends far beyond workerd, incorporating security layers, orchestration, and deployment machinery. workerd is a slice of the runtime codebase—a small but critical piece of the larger service.
The benefit of this separation is that the code can be released under a permissive open source license.
Beta availability
workerd is currently in beta. To get started, you can find the readme on GitHub.
