Add workerd (Cloudflare Workers open-source runtime) as a server runtime in BCD

[joesepi]

What would you like to see added to BCD?

Add workerd (Cloudflare Workers runtime) as a server runtime in BCD.

workerd is Cloudflare's open-source JavaScript/WebAssembly runtime that powers Cloudflare Workers. It fits BCD's server-runtime model alongside Node.js, Deno, and Bun.

• Open-sourced: September 27, 2022
• Engine: V8
• Runtime type: server

Cloudflare is a co-founder and active leader of WinterTC (TC55), the Ecma International technical committee working to standardize web API interoperability across server-side JavaScript runtimes (see also WinterTC55 on GitHub). workerd's API surface is designed with this interoperability goal in mind, making compatibility data especially relevant for developers targeting multiple runtimes.

Addressing the data guidelines

The addition of browsers guidelines require the following. Here is how we'd propose to meet each one:

• Machine-readable release information: workerd publishes version metadata to npm (registry.npmjs.org/workerd), and its GitHub repo contains machine-readable release dates (src/workerd/io/release-version.txt), maximum compatibility dates, and compatibility flag default dates. We have a working release updater script that follows the same pattern as the Bun updater.

• Compelling downstream-consumer story: Cloudflare Workers has a large developer base. As part of WinterTC (TC55)'s web-interoperable runtimes effort, having workerd compat data alongside Node.js, Deno, and Bun in BCD would give developers a single place to compare API availability across the runtimes they target. We'd welcome input from MDN, caniuse, or other consumers on whether this data would be useful to them.

• Compelling data-automation story: workerd is already tracked by runtime-compat, the same collector infrastructure used for Bun, Deno, and Node.js. We also have a release updater script ready to contribute (modeled on the existing Bun updater), as well as a diagnostic script that maps workerd npm packages to their pinned V8 versions, giving reviewers a verifiable evidence trail for JavaScript built-in support claims.

• Reviewer capacity: Cloudflare is committed to providing reviewers for workerd-related data changes. We can provide at least one reviewer acting on behalf of the vendor, and are happy to discuss what level of involvement the maintainers would need.

• Documentation: workerd's compatibility flags and supported APIs are documented at https://developers.cloudflare.com/workers/configuration/compatibility-flags/. The runtime itself is open source at https://github.com/cloudflare/workerd.

---

How impactful do you think this enhancement will be?

Cloudflare Workers has a large and growing developer base. With workerd in BCD, developers would be able to compare API availability across all four major server-side JavaScript runtimes (Node.js, Deno, Bun, and workerd) in one place -- on MDN and anywhere else that consumes BCD data.

This is especially relevant given Cloudflare's active role in WinterTC (TC55), which is working to standardize web API interoperability across runtimes. As that effort progresses, having accurate, up-to-date compatibility data for workerd alongside the other runtimes becomes increasingly useful for the developer community.

---

Do you have anything more you want to share?

Prior attempts

We've tried to add workerd to BCD before, and want to acknowledge that history and what we've learned from it:

1. January 2022 -- PR #14629 by @jkup, with a companion discussion issue on mdn/content (mdn/content#12742). Closed because maintainers did not have the resources to support additional server runtimes at the time.
2. April 2026 -- PR #29544 by @irvinebroque. Closed because it was submitted as a large implementation PR without prior discussion, which did not follow the data guidelines for adding browsers.

We're opening this issue to restart the conversation on the right foot and discuss the benefit to the community of including workerd in BCD.

Versioning model -- open question

One topic we'd like the maintainers' input on: workerd's developer-facing compatibility axis is compatibilityDate (e.g., 2026-04-26) rather than a semver package version. We'd propose modeling versions as dotted-date checkpoints (2026.04.26), since BCD accepts dotted-numeric version strings and this maps directly to what developers configure. But we're open to alternatives if the maintainers prefer a different approach.

Proposed plan if accepted

Following the precedent set by Bun's addition (PR #23440):

1. Agree on approach in this issue
2. Submit a small PR adding browsers/workerd.json and the schema change
3. Submit the release updater script as a separate PR
4. Submit initial compat data in manageable, reviewable chunks -- not a single large diff

We're happy to adapt this plan based on maintainer feedback.

[joesepi]

I recognize this isn't a "brief issue" as requested when PR #29544 was closed. I wanted to make sure there's sufficient context for the discussion -- particularly around how we'd meet the data guidelines and what we've learned from prior attempts. Happy to answer any questions.

[ddbeck]

Hi @joesepi, this issue came up for discussion on this week's BCD call. The two big things that came out of this were:

• For a consumer story, a parallel track to start here would be an issue on mdn/content, to ask about adding workerd to compat tables if the data were in BCD (i.e., a do over of Content suggestion: Add browser compat support for Cloudflare Workers content#12742). @Rumyra would be the point person for a decision on that. If you have any plans to use this data yourselves, that would also be helpful context.

• A question that came up was about runtime-compat. Since you mentioned that workerd is already tracked there, what do you expect to be different or better about tracking it in BCD too?