Runtime Keys

Draft Community Group Report,

This version:


A proposal defining standard identifier keys for various runtime environments

Status of this document

This specification was published by the Web-interoperable Runtimes Community Group. It is not a W3C Standard nor is it on the W3C Standards Track. Please note that under the W3C Community Contributor License Agreement (CLA) there is a limited opt-out and other conditions apply. Learn more about W3C Community and Business Groups.

1. Introduction

This proposal defines a list of keys that represent various runtime environments.

These keys can be used in a variety of ways, and should be considered a reliable representation of the given runtime.

For example, they may be used in a project configuration file to indicate the given project supports the specified runtime.

This specification does not detail how the keys can be used; that is left up to community developed tools.

The point of this proposal is to only define what the keys are in order to prevent conflicts, and provide users a reliable list of platforms they can build tooling around.

Inclusion in this registry does not imply that the specified runtime is conformant with the WinterCG Minimum Common API.

Inclusing in this registry does not imply endorsement of any kind.

1.1. Example Usage

One example of how these keys may be used (remember, this proposal does not specify how the keys are to be used) is within package.json files for projects hosted on npm.

The following package.json file demonstrates a library that exports separate outputs for Node.js and Deno, as well as specifies which versions of each runtime it supports.

    "name": "the-library",
    "version": "1.0.0",
    "exports": {
        "node": "./dist/node/index.js",
        "deno": "./dist/deno/index.js"
    "engines": {
        "node": ">=16",
        "deno": ">=1.10"

2. Keys

2.1. Alibaba Cloud - edge-routine

The JavaScript/Webassembly runtime that powers Alibaba Cloud edge-routine.

Key: edge-routine


2.2. Cloudflare - workerd

The JavaScript / WebAssembly runtime that powers Cloudflare Workers.

Key: workerd



2.3. Deno Land - Deno

A modern runtime for JavaScript and TypeScript.

Key: deno



2.4. Lagon - Lagon Runtime

Lagon is an open-source runtime and platform that allows developers to run TypeScript and JavaScript Functions at the Edge.

Key: lagon



2.5. Meta - React Native

A framework for building native apps using React. This key represents supported React Native JS runtimes on native platforms (excludes react-native-web).

Key: react-native



2.6. Netlify - Edge Functions

Edge Functions connect the Netlify platform and workflow with an open runtime standard at the network edge.

Key: netlify



2.7. OpenJS Foundation - Electron

Build cross-platform desktop apps with JavaScript, HTML, and CSS.

Key: electron



2.8. OpenJS Foundation - Node.js

Node.js is an open-source, cross-platform JavaScript runtime environment.

Key: node



2.9. Oven - Bun

Incredibly fast JavaScript runtime, bundler, transpiler and package manager - all in one.

Key: bun



2.10. Vercel - Edge Light

Developing, testing, and defining the runtime Web APIs for Edge infrastructure.

Key: edge-light



3. Key Management

3.1. Adding a key

All JavaScript runtimes are welcome to create a key and add it to this list. New keys must not conflict with another existing key. Runtime entries on this list are encouraged, but not required, to participate in the community group.

To propose a new key, create a pull request in runtime-keys repository that adds the desired key to the file using the following format:

## <Runtime Organization> - <Runtime Name> ## {#<Runtime Key>}

<Runtime Description>

Key: `<Runtime Key>`

Website: [<Runtime Website>](<Runtime Website>)

Repository: [<Runtime Repository>](<Runtime Repository>)

The key should be inserted in alphabetical order based on the first character of the Runtime Organization.

Keys should meaningfully represent the relative runtime and be a simple, string-like value so it can be used in common configuration formats such as JSON and YAML.

Keys should also not conflict with existing Browserlist entries.

Entry pull requests must be approved by at least two active members of the community group that are not directly affiliated with the proposed runtime.

3.2. Modifying a key

Modifying an entry requires opening a pull request and recieving two approvals from active community group members not affiliated with the relative runtime project.

Modifications can be made to aspects such as the Organization, Name, Description, Website, and Repository.

Aside from extraordinary circumstances, to prevent breaking tools built around this list, Keys are not modifiable.

Keys may be deprecated to indicate inactive runtime projects.

Deprecated Keys may be undeprecated and claimed by another runtime.

To deprecate or undeprecate a key, open a pull request adding or removing <b>[Deprecated]</b> from the Name:

+ ## <b>[Deprecated]</b> <Runtime Organization> - <Runtime Name> ## {#<Runtime Key>}
- ## <Runtime Organization> - <Runtime Name> ## {#<Runtime Key>}


Document conventions

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.


Normative References

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: