OpenIPC
Open-source firmware for IP cameras and surveillance devices
OpenIPC is an open-source firmware project for IP cameras built on common surveillance system-on-chips. It replaces proprietary, often insecure stock firmware with a maintained, self-hostable alternative that streams standard RTSP.
Key features
- Open firmware for IP cameras
- Standard RTSP streaming
- Improved security
- Wide SoC support
Pros & cons
Strengths
- Frees cameras from cloud
- Actively developed
Trade-offs
- Flashing risk
- Hardware-specific
OpenIPC replaces
Last reviewed Sep 13, 2026 · 833 words
OpenIPC is firmware, not a server, and the risk profile is different from anything else on this site: a bad Docker deploy costs you ten minutes, a bad flash costs you a camera. The payoff is a $25 camera that stops phoning home, exposes a standard RTSP stream on port 554, and gets security updates from a project with 2,196 GitHub stars and an active community instead of from a vendor who abandoned the model two years ago. Whether that trade is worth it depends almost entirely on which system-on-chip is inside your camera, so start there.
Check the SoC before you buy or open anything
OpenIPC targets the cheap surveillance SoCs: HiSilicon (Hi3516, Hi3518, Hi3536 families), Goke (GK7205), SigmaStar (SSC335, SSC338Q), Ingenic (T31), and a few others. Consumer cameras from Wyze, Xiaomi, Hikvision clones and most AliExpress bullet cameras use these. The project's supported-hardware list is organised by SoC and then by board, and "the SoC is supported" is not the same as "your camera is supported": the sensor, the flash chip and the WiFi module all need drivers, and a camera with a supported SoC and an unsupported sensor gives you a working Linux box that cannot see.
Find the SoC by opening the camera and reading the largest chip, or by getting a serial console on the stock firmware and reading the boot log. If you are buying specifically to flash, the project recommends particular boards, and following that recommendation is the difference between an afternoon and a week.
Flashing is a UART job the first time
The standard path is a 3.3 V USB-to-serial adapter on the camera's UART pads, interrupting U-Boot at power-on, and loading the OpenIPC images over TFTP from a machine on the same network:
setenv ipaddr 192.168.1.10
setenv serverip 192.168.1.5
run uk # fetch and write the kernel
run ur # fetch and write the rootfs
The exact variables depend on the SoC and the project wiki gives per-family sequences. Before writing anything, dump the stock partitions to TFTP so you can go back. Cameras with a locked bootloader or a signed image chain need a hardware flash programmer instead, and that is where "flashing risk" turns from theoretical to real. Some models can be flashed from the stock web UI or an SD card with the project's coupler tool, which removes the soldering step entirely; check the wiki for yours before reaching for the iron.
Expect 2 to 4 hours the first time including reading and a mistake or two, and 20 minutes after that.
What you get afterwards is a plain RTSP camera
OpenIPC boots a minimal Linux with Majestic, the project's streamer, serving H.264 or H.265 over RTSP at rtsp://camera/stream=0 for the main stream and stream=1 for a lower-resolution substream. There is a web UI on port 80 for exposure, bitrate, night mode, motion detection and audio. ONVIF works well enough for discovery by NVR software. The memory footprint is tiny; these SoCs typically have 64 to 128 MB of RAM in total and OpenIPC leaves most of it free.
This is where the project stops. There is no recording, no cloud, no app. The camera is now an input for whatever NVR you run, and the sensible pairings are Frigate for object detection and recording, or go2rtc if you only want low-latency viewing in Home Assistant. Either treats an OpenIPC camera as a generic RTSP source, which is the entire point.
Two honest caveats. Image quality out of Majestic on a given sensor is usually a little behind the vendor's tuned firmware, because vendors have the sensor datasheets and the project has reverse engineering. And WiFi on the cheaper modules is less reliable than on stock; wire the camera if you can.
Who actually runs this
People with a specific reason: a camera whose vendor has shut down its cloud, a model with a known unpatched vulnerability, a site where no outbound internet is allowed, or FPV drone builders, who use OpenIPC's digital video link on the same SoCs. If none of those apply and you simply want local cameras, buying a camera that already speaks RTSP with a local-only mode is cheaper in hours than flashing one, and the video surveillance category is the place to spend the time instead.
What I'd do
Buy one camera from the project's recommended list (a Goke or SigmaStar board in the $20 to $30 range), flash it on the bench with a UART adapter and a backup of the stock partitions, and point Frigate at it. Judge the image quality and WiFi stability over two weeks before flashing the rest. Never flash a camera you cannot physically reach, and never flash the only camera covering something that matters until the first one has proven itself.
Similar video surveillance apps
MediaMTX
Video SurveillanceReady-to-use media server and RTSP/WebRTC proxy
Replaces Wowza
go2rtc
Video SurveillanceUltimate camera streaming gateway with low latency
Replaces Nest Cam
OpenALPR
Video SurveillanceAutomatic license plate recognition library
Replaces Rekor Scout, Plate Recognizer
CompreFace
Video SurveillanceSelf-hosted face recognition service with REST API
Replaces Amazon Rekognition
OpenCvSharp
Video Surveillance.NET wrapper for OpenCV computer vision
Replaces Commercial vision SDKs
ZoneMinder
Video SurveillanceFull-featured closed-circuit television software suite
Replaces Blue Iris, Milestone XProtect