Library / SDK
node-webrtc/node-webrtc avatar
node-webrtc/node-webrtc

node-webrtc: WebRTC bindings for Node.js, published as @roamhq/wrtc

node-webrtc is a Node.js Native Addon that provides bindings to WebRTC M106

2,804 stars479 forksC++NOASSERTION

At a glance

What is it?
node-webrtc is a Node.js native addon that binds WebRTC M106 into Node, shipped on npm as @roamhq/wrtc with prebuilt binaries for Node 20 and 22. The package works, but its own README points elsewhere when it does not.
Who is it for?
Adopt @roamhq/wrtc if you need a WebRTC peer connection inside a Node process and you are running Node 20 or 22 on linux-x64, darwin-x64, darwin-arm64 or win32-x64, where prebuilt binaries exist.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Activity is slowing. The repository last received commits 6 months ago.
What is it written in?
Mainly C++, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What node-webrtc solves for Node.js processes

Browsers ship a WebRTC implementation. Node does not. If you want a peer connection, an RTP stream or a data channel inside a server process, you either write the ICE, DTLS and SRTP stack yourself or you bind an existing one. node-webrtc takes the second route: it is a Node.js native addon that exposes WebRTC M106 (the branch-heads/5249 line of the Chromium WebRTC source) to JavaScript.

The audience is narrow and specific. It is for people building signalling servers, recording services, media relays or test harnesses in Node who want the browser API surface rather than a different abstraction. The README states the project is aiming for spec-compliance and will eventually be tested using the W3C web-platform-tests project. That word, eventually, is doing real work: it describes intent, not a current conformance claim.

The README also notes that a number of nonstandard APIs for testing are included, documented in docs/nonstandard-apis.md. That matters if you are writing automated tests around media, because the standard API alone gives you little control over what the peer actually sends.

How the binding is put together

The repository layout tells most of the story. src/ holds the C++ side, lib/ holds the JavaScript wrapper that package.json points at with "main": "lib/index.js", and types/ holds the TypeScript declarations at types/index.d.ts. The topics list confirms the mechanism: bindings, n-api, native-addon.

N-API is the reason the supported platform matrix is as short as it is. The README says node-webrtc targets N-API version 3, and adds that because of this there may be additional platforms supported that are not listed. That is a reasonable claim: N-API is ABI-stable across Node versions, so a binary built once can load in later Node releases. The flip side is that the project only confirms what it builds and tests, and the table confirms Node 20 and 22 on linux-x64, darwin-x64, darwin-arm64 and win32-x64, with linux-arm64 marked with a question mark.

Distribution is by optional dependency, not by a postinstall compile. package.json lists @roamhq/wrtc-darwin-arm64, @roamhq/wrtc-darwin-x64, @roamhq/wrtc-linux-arm64, @roamhq/wrtc-linux-x64 and @roamhq/wrtc-win32-x64, all pinned to 0.10.0, plus domexception. npm resolves the one matching your operating system and architecture. There is also a "browser" field pointing at lib/browser.js, which is not a WebRTC implementation for browsers; it is a shim so that code importing the package does not break when bundled.

Installing @roamhq/wrtc and opening a peer connection

The README gives one install command. Note the mismatch that trips people up: the repository is node-webrtc, but the package you install is wrtc, which resolves to @roamhq/wrtc.

bash
npm install wrtc

Installing from npm downloads a prebuilt binary for your operating system and architecture, selected by the optional dependency filters described above. There is no compile step on a supported platform, so the install should be fast and should not need a C++ toolchain. If your platform is not in the table, the README says you may still be able to build from source and points at docs/build-from-source.md.

Once installed, the JavaScript surface is the browser one. package.json's install-example script runs node scripts/install-example.js, which is the route to the worked examples:

bash
npm run install-example

The README points readers at node-webrtc/node-webrtc-examples for full examples rather than shipping one in the repository itself. That is the practical starting point for anything beyond a bare peer connection, and it is where you should look before writing your own signalling layer.

The release history is the biggest thing to check

The package version in package.json is 0.10.0. The most recent release listed for the repository is v0.4.7, dated 2021-01-10. The ones before it are v0.4.6 from 2020-07-19 and v0.4.5 from 2020-05-21. There is a gap of several years between the newest tagged release and the version the package declares, and nothing visible explains it. Either the project stopped tagging releases, or the version field moved without tags, or the tags live somewhere not shown. A reader cannot tell which.

The last push to the repository was on 2026-03-26, so work is happening. But a commit stream is not a release stream. If your dependency policy requires tagged, published versions with changelogs, you are relying on a release process that the visible history does not demonstrate. CHANGELOG.md exists in the repository root, which is something, but you will want to read it before assuming 0.10.0 corresponds to anything you can pin with confidence.

The README also does not document rollback, deprecation policy or a support window for older Node versions. Node 18 does not appear in the supported table at all. If you are on an older runtime, the README is silent on whether it works.

Where the licence story gets confusing

package.json declares "license": "BSD-2-Clause". The repository metadata carries NOASSERTION, which is what GitHub reports when it cannot classify the licence file automatically. LICENSE.md sits in the repository root, and THIRD_PARTY_LICENSES.md sits beside it.

That third file is the one people skip and should not. Binding WebRTC M106 means shipping a large amount of Chromium-derived C++ inside your node_modules. THIRD_PARTY_LICENSES.md exists precisely because the dependency tree is not a single licence. The BSD-2-Clause declaration covers the addon's own code; it does not describe everything in the prebuilt binary.

This is not legal advice, and the repository does not enumerate what is in that third-party file. The concrete step is to open THIRD_PARTY_LICENSES.md and LICENSE.md and read them against your own distribution model, particularly if you ship the prebuilt binary inside a product rather than installing it at build time on a server you control.

node-datachannel and werift as alternatives

The README names two alternatives directly, which is unusually honest for a project page: node-datachannel and werift.

The difference in approach is worth understanding before you pick. node-webrtc binds the Chromium WebRTC implementation, the same C++ that Chrome runs. You get M106 behaviour, including the codec set and the quirks, because you are running that code. The cost is a native addon with a platform matrix, prebuilt binaries and a C++ build path for anything unsupported.

werift is a WebRTC implementation written in TypeScript. There is no native addon and no prebuilt binary, so it installs anywhere Node runs and you can read the implementation. The trade-off runs the other way: it is a reimplementation, not the reference stack, so behaviour will not track Chromium release for release.

node-datachannel is a native binding too, but it is built around libdatachannel rather than the Chromium stack, which makes it a smaller dependency to carry. If your use case is data channels rather than media, that narrower scope is usually the better fit. node-webrtc's own README frames both as things to try if this package does not work for you, which is a fair summary of when to switch.

Frequently asked questions about node-webrtc

The questions below cover the practical points a new user hits: what the package name actually is, which platforms have binaries, and what to do when yours does not. The README answers some of these directly and is silent on others, and the silence is noted where it applies. For anything about media quality, codec tuning or audio processing, the repository does not provide guidance, so those are not answered here.

Editorial conclusion

Adopt @roamhq/wrtc if you need a WebRTC peer connection inside a Node process and you are running Node 20 or 22 on linux-x64, darwin-x64, darwin-arm64 or win32-x64, where prebuilt binaries exist. Do not adopt it if you need a documented build-from-source path, a maintained release history, or a licence you have not read: package.json declares BSD-2-Clause but the repository carries NOASSERTION, and the newest release listed is v0.4.7 from 2021-01-10 while the package version is 0.10.0. Before committing, run npm install wrtc on your target machine and confirm the optional dependency for your platform resolves, then check the repository's docs/build-from-source.md if it does not.

Frequently asked questions

How do I install node-webrtc?

Run npm install wrtc. The install downloads a prebuilt binary for your operating system and architecture, chosen by the optional dependency filters, so no compiler is needed on a supported platform.

Which platforms does node-webrtc support with prebuilt binaries?

The README confirms Node 20 and 22 on linux-x64, darwin-x64, darwin-arm64 and win32-x64. linux-arm64 is marked with a question mark, and the README notes that other platforms may work because the addon targets N-API version 3.

What is the npm package name for node-webrtc?

The package is published as @roamhq/wrtc, and the README's install command is npm install wrtc. The repository name and the package name do not match, which is a common source of confusion.

What can I do if my platform is not supported?

The README says you may still be able to build from source and links to docs/build-from-source.md. It also states that a debug build or cross-compile requires building from source rather than installing from npm.

Does node-webrtc handle signalling for me?

No. The library exposes the peer connection, offers, answers and ICE candidates, but the README does not describe any signalling transport. You pass the SDP and candidates over your own channel and feed the remote side back in through setRemoteDescription and addIceCandidate.

Official sources

  1. Issues
  2. node-webrtc/node-webrtc on GitHub
  3. README
  4. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/node-webrtc-node-webrtc.svg)](https://hysenlabs.com/projects/node-webrtc-node-webrtc)