Matterbridge turns one Matter pairing into all your smart home plugins

A bridge device that loads plugins

Matterbridge creates a Matter device, of type bridge, that can be paired with any ecosystem, and the list given is Apple Home, Google Home, Amazon Alexa, SmartThings, Home Assistant, Gladys Assistant or any other platform supporting Matter. The stated benefit is that you do not need a hub or a dedicated new machine, and that all your Matter devices can be up and running in a couple of minutes without dealing with the pairing process for each individual device. That last part is the actual design idea. Pairing a Matter device with a controller is the tedious part of the protocol, and a bridge collapses all of it into one commissioning step. After that, the bridge loads all your registered plugins and presents their devices to whichever controller you paired with. The project is built on top of matter.js, and the credits single out the foundational work on that library, the library the whole plugin system depends on.

Installation is a pasted script

The setup story is deliberately short. The README says there is no complex setup, and that you just copy and paste the installation scripts, which are available for Docker, Nginx, Linux systemctl, Windows Task Scheduler and macOS launchctl. That list covers the five ways people actually run a background service, and the existence of a Task Scheduler script and a launchctl script tells you the author expects Windows and macOS users, not only Linux servers. The prerequisites are either a Node.js environment or Docker installed, with the recommendation to use Docker for its simplicity. On the memory side the claim is that Matterbridge is lightweight and also runs on slow Linux machines with as little as 512MB of memory, which is the constraint that decides where the bridge can live. It is fully supported on Linux, macOS and Windows, and the project publishes a Docker image as well as npm packages.

The Node version rules are unusually strict

The Node requirements are worth reading carefully, because the wording is specific about what is supported and what is not. The minimum supported version of Node.js is 22.13.0. The supported versions are greater than or equal to 22.13.0 within Node.js 22, Node.js 24 and Node.js 26, and Node.js 20 is no longer supported. The advice is to install Node.js 24 LTS and not to use Node.js Current, always the LTS releases. Odd-numbered versions such as 21, 23, 25 and 27 are not supported. The package manifest encodes the same thing, and the engines field is the machine readable version of the policy:

  "engines": {
    "node": ">=22.13.0 <23.0.0 || >=24.0.0 <25.0.0 || >=26.0.0 <27.0.0"
  },

One more warning appears for people arriving from the Homebridge world. Nvm is a development tool and is not supported for production. If you plan to run the bridge on a server, install Node from the distribution packages on Debian or use Docker instead of a version manager, because a version manager is exactly the kind of thing that quietly changes versions under a service.

IPv6 is a prerequisite, not a preference

The global prerequisites section exists because Matter itself is defined that way. Since Matter is designed as a universal IPv6-based communication protocol for smart home devices, per the Matter specifications, IPv6 must be enabled on your local network. The documentation marks this as important. It is the kind of requirement that is easy to miss and hard to diagnose, because on a home network with a modern router IPv6 is usually already on, and on a network where it is not, the symptom is that pairing fails or that the controller never sees the bridge, with no obvious cause. The other global point is that you only need one bridge device per ecosystem you want to control, which is the operational simplification behind the whole project. If you already run a Matter controller, you add the bridge once and it exposes the devices that your plugins provide.

Plugins, and the Homebridge lineage

Two things are said about extending the project. Developers can focus solely on device development by extending the provided classes, and the project aims to enable porting Homebridge plugins to Matterbridge plugins without having to recode everything. That second point is the interesting one, because porting an existing Homebridge plugin is far less work than rewriting it from scratch. A bridge that can host a ported plugin turns a Homebridge installation into something a Matter controller can see. The documented way to start is to clone the Matterbridge Plugin Template, which has dev container support for an instant development environment with all the tools and extensions already loaded and configured, including Node.js or Bun, TypeScript Native, Vitest and the shared Oxc and oxlint and oxfmt configurations. The project is also built to be extended by people who write plugin code rather than infrastructure code, and the repository keeps the development notes in a separate README-DEV.md.

The binaries tell you what the project exposes

The package manifest lists the executables, and the names are a map of the internals. The main one is matterbridge, and alongside it there are three helper binaries with both dashed and underscored aliases, so the same tool answers to either convention:

  "bin": {
    "matterbridge": "bin/matterbridge.js",
    "mb-mdns": "bin/mb_mdns.js",

The rest are mb-coap for the CoAP side of the protocol, and mb-health for health checks, with the same dashed and underscored pairs. A dedicated mDNS binary and a CoAP binary as separate entry points is a sign that the protocol work is exposed rather than hidden, which matters because mDNS discovery is the step that fails first on a network with unusual settings. The repository itself is a workspace with eight packages under packages/, named types, jest-utils, vitest-utils, test-utils, utils, dgram, thread and core, which is a conventional layout for a TypeScript project that keeps the shared test helpers in their own packages.

A fast moving project with formal conformance testing

The release cadence is the last thing to weigh, and it is fast. The listed releases are 3.10.14 published on 2026-10-16, 3.10.13 on 2026-10-09 and 3.10.12 on 2026-10-02, so a patch release roughly every week, and the last push was on 2026-10-19. That is a project in active work, with a CHANGELOG.md at the root and the version in the package file matching the npm release. The quality signals are more interesting than the cadence. There is a Chip tests workflow badge, and the root of the repository holds chipTests.json, chipTests.md and a series of chip test summary logs, alongside the Matter specification notes for versions 1.5.1, 1.6.0 and 1.6.1 and the matter.js release notes for 0.17 and 0.18 with a diff document between them. That is a maintainer who tracks the specification and the upstream library closely. The licence is Apache-2.0, the code is TypeScript compiled natively, the packages are ESM for both Node.js and Bun, the tests run under Vitest, and there is a CodeQL workflow as well as the build one.

Editorial conclusion

Matterbridge fits a household or a developer who has a pile of smart home devices behind several different protocols and wants them visible in one Matter controller, since the whole point of the bridge is that you pair once and every plugin appears. It does not fit a network without IPv6, because the Matter specification assumes it and the documentation calls it out as a global prerequisite, and it does not fit a team that wants a stable plugin API, since the version numbers move weekly and the project explicitly aims to let Homebridge plugins be ported rather than freezing the surface. Before you install it, enable IPv6 on the LAN, decide between Node and Docker with Docker recommended, and check the Node version rules, since the engines field allows only 22.13 and up, 24 and 26.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Luligu/matterbridge on GitHub
3. Project website
4. README
5. Releases