Ever wanted to see what was happening down on the factory floor from a dashboard? Nope, didn't think so! So we made it anyways! Currently undergoing heavy testing, but things have been looking great so far and wanted to share.
Multi‑camera grid — drop the component, pick your cameras, done. Click a tile to expand.
No extra ports. A gateway‑managed media sidecar does RTSP→HLS and everything tunnels through the gateway web port you already expose. Locked‑down‑SCADA‑network friendly.
Self‑contained .modl. No installing anything on the server, no separate services to babysit. Install, done.
Credentials never leave the gateway. Cameras are configured server‑side and referenced by name — the browser never sees a single RTSP URL or password.
Survives a camera wall — a dozen‑plus streams at once, with tiles that flip to OFFLINE (and auto‑recover) when a camera drops.
UniFi Protect friendly — including the rtsps:// endpoint with auto cert‑pinning.
And the part I'm weirdly proud of
A native gateway config page (Connections → RTSP Cameras) to add/edit your cameras — with bulk paste‑import, so you can dump a spreadsheet of Name, rtsp://url and hit go.
I'm interested to find out if anyone else is excited for something like this. What kind of cameras do you use? How many do you have? (We have over 200 on site) What would you use a tool like this for?
I ran some additional testing, this was done from our dev pc. I won't be able to test on our live server until another double down day when we can restart the gateway. We have so many things running ignition its hard to get a window to restart with a 24/7 facility. I hope this explains a bit more, let me know if there are other specific tests anyone wants.
I'm curious how you are achieving a single module file delivery when some of MediaMTX's dependencies (like FFmpeg and GStreamer) are LGPL or GPL. Is the sidecar installed/updated dynamically via the internet?
Edit:
MediaMTX appears to mis-state the license of libcamera. It claims libcamera is MIT licensed, but the libcamera docs state that it is LGPL2. libcamera has numerous LGPL and optional GPL dependencies. If you are embedding the MediaMTX binary in your module file, you are taking a big legal risk, IMNSHO.
On the FFmpeg/GStreamer side, I don't think those actually come into play here. MediaMTX (v1.19.0) is pure Go, statically linked, just the one binary. It does the RTSP to HLS remux itself in Go, it doesn't link or bundle FFmpeg or GStreamer. Those only matter if you point MediaMTX at an external ffmpeg/gstreamer process, which I'm not doing, and it wouldn't ship those binaries anyway, you'd install them yourself. That pure-Go thing is kind of the whole reason I can ship it as a single file.
For delivery, nothing's pulled from the internet. The binary is bundled inside the .modl and just gets extracted to the gateway's working dir on startup. No downloading, no auto-updating.
On libcamera, good catch on the docs being off, but from what I can tell libcamera only gets compiled into MediaMTX's Raspberry Pi (linux/arm64) builds. I'm only shipping linux-amd64 and windows-amd64.
And I'll make sure to provide proper attribution wherever it's needed for licensing.
I'll try to get some stress test numbers too when I can, this is only a side project, my normal job's got me developing other stuff right now, so bear with me lol.
Tossed all my data into Claude to have it make the flow chart while I was on lunch. Then fed it my screen shots for the other stats image. Then confirmed it didn't change any values. Pretty fun tool to use when its right. We have been doing a test runs with it on site, they are testing out the enterprise plan but personally I prefer the none enterprise tiers. It's a lot of double work right now because trust is super low and honestly I don't think that will change ever, not sure it should tbh.
But for now I will enjoy its perks at no cost to me lol.
Looks like we have a planned power outage today, I will be using this chance to get the module loaded on the server. I'll let you guys know more later today how it turns out.
Well we had a huge win for the testing yesterday. Server load was super low. Really the only limitations we were seeing (with our setup) was the viewing devices. All of our older PC's took the streams well with 100-200 feeds.
We naturally had some issues with older Raspberry PI units not loading the streams, but that was expected. They couldn't even handle a couple of camera feeds with this setup.
But the Pi 5's were doing great with 25 feeds at once.
For us, this does so much more than we actually need on any given screen. Made our IT Director very happy. We started transitioning over today. I will post again if we encounter any unforeseen issues, but I'm hoping to have the module out and in the exchange in a month for others to use. I've never uploaded anything there so I'll have to review that process.
Next on my plate is to see about integrating some Unifi commands to restart the camera feeds on low FPS and adding zones / rotations which should be easy enough once I figure out their API.
Multi‑camera grid — drop the component, pick your cameras, done. Click a tile to expand.
No extra ports. A gateway‑managed media sidecar does RTSP→HLS and everything tunnels through the gateway web port you already expose. Locked‑down‑SCADA‑network friendly.
Self‑contained 
Credentials never leave the gateway. Cameras are configured server‑side and referenced by name — the browser never sees a single RTSP URL or password.
Survives a camera wall — a dozen‑plus streams at once, with tiles that flip to OFFLINE (and auto‑recover) when a camera drops.
UniFi Protect friendly — including the 
