# mrlt8/docker-wyze-bridge: local RTSP, WebRTC and HLS from Wyze cameras

> The bridge turns Wyze cameras into local RTSP, RTMP, WebRTC and LL-HLS streams inside a Docker container. It is aimed at people running Home Assistant or an NVR who want a standard stream without flashing firmware.

**mrlt8/docker-wyze-bridge** — WebRTC/RTSP/RTMP/LL-HLS bridge for Wyze cams in a docker container

- Repository: https://github.com/mrlt8/docker-wyze-bridge
- Stars: 3,267 · Forks: 295
- Language: Python
- License: AGPL-3.0
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/mrlt8-docker-wyze-bridge

## What docker-wyze-bridge replaces

Wyze cameras are cheap, but they are not designed to hand you a standard video stream. The bridge exists to close that gap. According to the README, it creates a local WebRTC, RTSP, RTMP, or HLS/Low-Latency HLS stream for most Wyze cameras, including the outdoor, doorbell, and 2K models, with no modifications or special firmware. The intended user is someone who already has an NVR, a Home Assistant instance, or a media player that speaks RTSP and does not want to depend on the Wyze app for live viewing. The repository ships a home_assistant/ directory and a docker-compose.sample.yml, which tells you the maintainers expect the container to sit next to other services rather than run standalone. The trade-off is architectural: the bridge is a translator, so every stream depends on both the camera and the Wyze cloud account staying reachable.

## How the bridge talks to a Wyze camera

The README states that it uses the same SDK as the app to communicate directly with the cameras, and points at kroo/wyzecam for details. That means the container authenticates against Wyze as a client would, then republishes the camera feed locally. The README also says streaming does not use internet bandwidth in most cases, because the bridge attempts to stream locally and falls back to streaming over the internet when you are remote or using a shared camera. Recording and restreaming are handled by MediaMTX, which the release notes for v2.10.0 describe as the new recording backend. The practical consequence is that the container holds your Wyze credentials and the session state, so restarting it re-establishes every camera connection. The v2.10.3 notes mention a fix to restore user data on bridge restart, which suggests that state handling has been a recurring source of bugs rather than a solved problem.

## Installing docker-wyze-bridge and opening the WebUI

Install Docker first, then run the container. The README gives this exact command, which publishes RTSP on 8554, the WebUI and API on 8888, maps container port 5000 to host 5050, and disables authentication:

```bash
docker run -p 8554:8554 -p 8888:8888 -p 5050:5000 -e WB_AUTH=false mrlt8/wyze-bridge
```

After it starts, the README says the web interface is at http://localhost:5050, where localhost is the hostname or IP of the machine running the bridge. You should see the WebUI load and begin listing your cameras once the bridge has authenticated. Since May 2024 the README states you need an API Key and API ID from Wyze support, so a container that starts but shows no cameras usually means those credentials are missing rather than a networking fault. For a compose-based setup, the repository includes docker-compose.sample.yml, docker-compose.tailscale.yml, and docker-compose.ovpn.yml as starting points.

## STREAM_AUTH, RECORD_KEEP and the options that matter

Two option groups do most of the work in a real deployment. The first is stream access. The README describes STREAM_AUTH, which takes users separated by |, a username and password joined by :, an optional IP address after a second :, and paths after @. Its own example is:

```text
STREAM_AUTH=user:pass@cam-1,other-cam|second-user:password@just-one-cam|user3:pass
```

The README notes that the IP restriction does not work with Docker Desktop, which rules it out for many desktop users. The second group is recording, handled through MediaMTX. RECORD_ALL or RECORD_CAM_NAME enables it, RECORD_PATH accepts %path or {cam_name} plus strftime variables, RECORD_LENGTH defaults to 60s, and RECORD_KEEP deletes older clips with 0s disabling deletion. The v2.10.3 notes add SNAPSHOT_KEEP for timelapse-style snapshots, with values such as 180s, 3m, 72h, or 3w. The unit suffixes are not interchangeable with plain numbers in every field, so read each option's own example before copying it.

## Where docker-wyze-bridge breaks or is the wrong tool

The most visible failure mode is authentication. The README's May 2024 notice makes an API Key and API ID mandatory, and the v2.10.0 notes record a bug where WB_AUTH could not be disabled if WB_API was set. Credentials are therefore a moving part, not a one-time setup step. The second limitation is the cloud dependency: the bridge uses the same SDK as the Wyze app, so it is tied to an account and to Wyze's service. If you want a camera that never touches a vendor account, this is the wrong project. The third is security posture. The README warns in capitals not to forward ports or enable DMZ access to the bridge unless you know what you are doing, which is a direct statement that the container is not meant to be exposed. Finally, the default WebUI password is derived from the username part of the Wyze email address, so john123@doe.com yields john123. That is convenient and also guessable, and the README says this default does not affect users who set their own WB_PASSWORD and WB_API.

## docker-wyze-bridge against go2rtc and Frigate

The natural alternative for the same job is a general-purpose streaming server such as go2rtc, often paired with Frigate for detection. The difference is where the vendor logic lives. docker-wyze-bridge contains Wyze-specific code: it speaks the Wyze SDK, handles the account, and exposes the result as RTSP, RTMP, WebRTC, or LL-HLS. A generic restreamer does none of that. It expects a working RTSP or WebRTC source and focuses on transcoding, relaying, and client compatibility. If your cameras already publish a standard stream, the generic tool is the smaller dependency. If they are Wyze cameras that publish nothing standard, the bridge is doing work the generic tool cannot do, and you would still need something like it upstream. The two are not mutually exclusive: the bridge can produce the RTSP stream that a restreamer or NVR then consumes.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-21, so the project is being touched. The releases tell a more mixed story: v2.10.3, v2.10.2, and v2.10.1 were published in 2024, while the code has moved since. Upgrades are container pulls rather than package upgrades, and the release notes show why that matters. v2.10.3 changed MTX_WRITEQUEUESIZE to handle higher bitrates and restarted RTMP livestreams on failure; v2.10.0 changed how authentication defaults are derived. Anyone pinning an older tag will not get those fixes. The licence is AGPL-3.0, which is a strong copyleft licence and carries obligations if you modify the code and let users interact with it over a network. That is a question for your own legal review, not something this article can settle. The README also links a wiki for authentication and Home Assistant details, and the README itself does not document rollback, so keep the previous image tag before you pull.

## Conclusion

Adopt it if you already run Docker and want Wyze cameras feeding Home Assistant or an NVR over RTSP without changing firmware, and accept that a Wyze API key and ID are now mandatory. Do not adopt it if you need a vendor-supported path or cannot run a container next to your cameras. First verify that your camera model appears in the supported list, that the ports you need are free, and that your Wyze account can issue the API key and ID the bridge requires.

## FAQ

### Does docker-wyze-bridge still work?

The repository is not archived and the last push was on 2026-09-21, and the README states that as of May 2024 you need an API Key and API ID from Wyze support. So the bridge still exists, but it now depends on those credentials being issued for your account.

### How to set up docker-wyze-bridge?

Install Docker, run the container with the ports from the README, then open the WebUI at http://localhost:5050. The README gives the command docker run -p 8554:8554 -p 8888:8888 -p 5050:5000 -e WB_AUTH=false mrlt8/wyze-bridge, and notes that a Wyze API Key and API ID are required.

### What is docker-wyze-bridge?

It is a Docker container that creates a local WebRTC, RTSP, RTMP, or HLS/Low-Latency HLS stream for most Wyze cameras, including outdoor, doorbell, and 2K models, with no firmware modification. The README says it uses the same SDK as the Wyze app to talk to the cameras directly.

### What are the docker-wyze-bridge username and password?

The README states that the default WB_PASSWORD is derived from the username part of the Wyze email address, so john123@doe.com gives john123. Users who set their own WB_PASSWORD and WB_API are not affected by that default.

### Is there a docker-wyze-bridge alternative?

A general-purpose restreamer such as go2rtc is the usual alternative, but it expects an existing RTSP or WebRTC source rather than speaking the Wyze SDK itself. For Wyze cameras that publish no standard stream, the bridge is the piece that produces one.

## Sources

- [Issues](https://github.com/mrlt8/docker-wyze-bridge/issues)
- [License: AGPL-3.0](https://github.com/mrlt8/docker-wyze-bridge/blob/main/LICENSE)
- [mrlt8/docker-wyze-bridge on GitHub](https://github.com/mrlt8/docker-wyze-bridge)
- [README](https://github.com/mrlt8/docker-wyze-bridge/blob/main/README.md)
- [Releases](https://github.com/mrlt8/docker-wyze-bridge/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mrlt8-docker-wyze-bridge