Why Cloudflare is opening up its Workers runtime

Cloudflare has announced that it will open source the runtime behind Cloudflare Workers under the Apache-2.0 license. The company says the move is aimed at addressing two persistent concerns from developers who have been hesitant to build on the platform: vendor lock-in and the lack of a fully local development environment.

Since Workers launched nearly five years ago, Cloudflare says more than 450,000 developers have built on the platform. But the company acknowledges that a meaningful number of developers have held back, not because of the technology’s performance or cost advantages, but because they worry about being tied to a proprietary runtime. Open sourcing the runtime is intended to remove that uncertainty and give developers the freedom to run Workers code wherever they choose.

Cloudflare also points to a second motivation: the web has historically been built in the open. From “View Source” in the browser to the vast ecosystem of frameworks and libraries that developers rely on daily, open source has been a foundational part of how software gets written. The company says it built Workers on top of open source projects like V8 and wants to return the favor by making its own runtime available to the community.

Why Workers couldn’t simply reuse an off-the-shelf runtime

When Cloudflare first set out to build Workers, it wanted to let developers run code across its global network without compromising performance or security. V8 looked promising from a security standpoint, but existing runtimes built on it could not provide the isolation guarantees needed for a large multi-tenant environment without adding a container layer — and containers introduce cold starts.

Cold starts were not acceptable, and there was another constraint: Cloudflare’s data centers are far smaller than the centralized facilities of traditional cloud providers. Even eliminating cold starts would not be enough if the code footprint of an off-the-shelf runtime was too large to give every customer compute access on every node of the network.

So Cloudflare went a different route. Instead of building a new server-side JavaScript model, it turned to an existing web standard: the Service Workers API. Service Workers were designed for the browser, but their Request/Response model mapped well to Cloudflare’s needs. Using a standards-based approach also meant code written for Workers could be portable to other environments — a property that Cloudflare hoped would catch on with future platforms. It did.

At the time, this was a significant gamble. The company did not know whether the approach would work at scale, whether it would take off, or whether developers would embrace a model that diverged from what server-side JavaScript looked like then. But Cloudflare says it was also determined not to build a platform that locked anyone in, and it did not want to open source the runtime until it could do so properly.

What the open source announcement means

With the runtime now being released under Apache-2.0, Cloudflare says developers will be able to build on the platform freely, without worrying about being held hostage by a proprietary implementation. The license choice is deliberately permissive to allow broad use.

The company notes that the code itself is not ready to be shared yet, and more work remains before the actual release. It also flags another announcement coming later today that is meant to complement the open sourcing of the runtime, addressing the other half of the developer concern: the ability to run and test code locally.