ring-mqtt bridges Ring cloud devices to a local MQTT broker

A cloud API bridge dressed as a local integration

Ring sells video doorbells, security cameras, alarm systems and smart lighting devices, all of them cloud devices. ring-mqtt connects to the Ring API, the same one the official apps use, and republishes what those devices report onto an MQTT broker, so that any automation tool able to speak MQTT can act on them. The integration feels local because the protocol is local, but the data path is not. The project is explicit on this point: it uses the cloud API and does not enable local control of Ring devices, because no facility for that is known. It also notes that using the bridge does not technically require a Ring Protect subscription, yet many capabilities are not possible without one, and that the project is not intended as a way around that requirement. The intended users are therefore clear: people who have decided to own cloud devices and want them inside an open protocol home automation setup, rather than people hoping to escape the vendor's cloud.

The broker and the RTSP gateway are both built in

Looking at the dependencies explains how much the bridge takes on. It depends on mqtt for MQTT itself and on aedes, a broker implementation, which is how a local broker is available without a separate service. Video support is provided through an RTSP gateway service, and the dependency list includes werift along with @homebridge/camera-utils for camera work, while device communication sits in @tsightler/ring-client-api, currently pinned at a beta version of 14.3.1-beta.0. Supporting libraries include express for the web side, rxjs for reactive streams, js-yaml, chalk, minimist, write-file-atomic and date-fns. The overall shape is a Node.js ES module, since package.json declares type as module, with the entry point ring-mqtt.js and a start script that runs node ring-mqtt.js. The repository also carries a config.json at the top level, a devices/ directory, a Dockerfile and an init/ directory, which is what the container image uses.

The streaming caveat is not a footnote

The README spends more space on what this project cannot do than on its features, and the streaming paragraph is the reason. The project states it does not turn Ring doorbells or cameras into continuous CCTV cameras, because the devices are designed for event based streaming and recording or for light interactive viewing such as answering a doorbell press or checking a motion event. Even with the bridge, all streaming goes through Ring cloud servers. It then names the consequences of ignoring that: loss of motion and ding events while streaming, since cameras send alerts only when they are not actively streaming or recording, quickly drained batteries, and the risk of overheating or early device failure. It names specific downstream tools as unsupported, including NVR tools like Frigate and Zoneminder, and says questions about tools that require continuous streaming will be locked and deleted. For an engineer scoping this project, that paragraph is the acceptance criteria. Event triggered access to a snapshot or a short clip is the target. Anything that assumes an always-on feed is out of scope by design.

Running it locally and in a container

The project keeps its full documentation in the wiki, and the repository README points there for installation methods and configuration options rather than reproducing them, which is reasonable for something with as many install paths as this. The local route is straightforward once the dependencies are installed, since the start script in package.json is the whole entry point:

node ring-mqtt.js

Configuration lives in config.json at the repository root, and there is a devices/ directory alongside it. The container route is the more interesting one, because the Dockerfile shows what the image actually contains. It builds on node:jod-alpine and installs s6-overlay v3.2.2.0, which is a process supervisor, along with bashio v0.17.5 and go2rtc v1.9.14, and it adds packages including tar, xz, git, bash, curl, jq, tzdata and mosquitto-clients. The image copies the repository into /app/ring-mqtt, then moves the init/s6 scripts into the container's service directories and marks them executable, so the bridge runs as a supervised service. The architecture switch in the build covers x86_64, aarch64 and armv7 and armhf, and any other architecture exits the build with an error.

Where the state lives and what the event flow looks like

The bridge is a state publisher. The Ring API client reports device state, and that state is mapped onto MQTT topics that automation systems subscribe to. Events such as a motion detection or a doorbell press arrive the same way, and the README's warning about losing those events during a stream tells you the bridge is driven by the same notification channel the Ring apps use. The repository layout supports this reading, with lib/ holding the implementation, devices/ holding the per device handling, init/ holding the container service definitions, scripts/ for operational tasks, docs/ for documentation and images/ for assets. The tree also carries a log/ directory, so diagnostic output has a home of its own. For a team integrating this, the practical question is not how the bridge works internally but what topic structure your automation expects, and that mapping is documented in the wiki rather than in the repository README.

Version drift between releases and the repository

The repository is not archived and the last push was on 2026-10-20, so development continues. The published releases tell a different story about cadence: v5.9.3 on 2026-03-09, v5.9.2 on 2025-12-12 and v5.9.1 on 2025-12-04. The version field in package.json reads 5.9.3, matching the most recent release, and the default branch is main while the image build in the Dockerfile references the dev branch in its source URL. Between March and October the commits are therefore ahead of the last tagged release, which is normal for a container-first project but means the image and the release tag can differ. There are no versioned migration notes in the repository README, so upgrading a long lived deployment means reading the changelog yourself. Licensing is MIT, which is the permissive case for a bridge that people tend to self host and modify. One dependency deserves attention during upgrades: the Ring client library is pinned to a beta version, so an upstream change there can alter behaviour in a patch release of the bridge.

The alternative is writing against the Ring API yourself

There is a real alternative, and it is what the project itself is built on: use the Ring API directly from a script, which is what a purpose built automation would do. The difference in approach is scope. A direct script gives you exactly the calls your automation needs, no broker to run, no topic schema to learn and no RTSP gateway to maintain, and it removes the dependency on a community project for a device integration that will outlive any particular bridge. What you give up is the part that is genuinely hard to rebuild. The bridge already handles sign in and the Ring session, the device state model, event delivery and the awkward part of camera access, exposing it over two well known protocols instead of a bespoke one. The middle ground is often the right answer. Run the bridge as the only component that knows about the Ring API, keep your automation talking MQTT, and replace the bridge later if you need to. The reverse order, rewriting the integration inside your automation, is the expensive path and there is little reason to take it unless you are already deep in the Ring API and have a specific reason to avoid the dependency.

Editorial conclusion

Adopt ring-mqtt when you want Ring devices inside a Home Assistant or MQTT driven automation and you accept that every action travels through Ring cloud servers, and when event based camera access is enough for your use. Do not adopt it as a way to get local control, because the project states no such facility is known, or as a source of continuous video for an NVR tool. Verify first that your Ring account can sign in through the bridge, that the embedded broker or your own broker is reachable on the ports you intend to expose, and that you have a Ring Protect subscription if you plan to replay recorded events.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. tsightler/ring-mqtt on GitHub