camera.ui: a self-hosted camera platform with a paid tier behind the asterisks

What camera.ui solves, and who it is actually for

Running cameras without handing footage to a vendor is the problem camera.ui addresses. The README describes it as "a self-hosted platform for your security cameras" with live viewing, recording, on-device AI detection, semantic search, smart-home integration and push notifications, and it states the platform "Runs on hardware you own, no mandatory cloud, your footage stays with you." That last clause is the pitch: the server is yours, not a rented endpoint.

The audience is narrower than the pitch suggests. This is for people who already run a home server or a small rack and are comfortable with Docker, Proxmox or a bare-metal Linux install, because those are the routes the README names. It is also for tinkerers, since the README calls the whole thing "an extensible plugin ecosystem" and the repository ships a shared/ directory alongside server/, service/ and ui/, which is what you would expect if the same types and logic are reused across the backend and the frontend.

If you want a camera app that works out of the box with no server to babysit, this is the wrong shape of product. The README's own Getting Started section does not contain a single command; it says to follow the documentation at docs.cameraui.com instead.

How the monorepo is put together, and where detection runs

The top-level layout tells you most of the architecture. server/, service/, shared/ and ui/ sit next to each other in one repository, with externals/ for bundled third-party pieces and scripts/ for build and release tooling. The root package.json is private and named @camera.ui/monorepo, version 0.0.1, so the published artifacts come from the workspaces rather than from the root.

The scripts reveal a build pipeline rather than a single binary. There is build, bundle, release, setup and update, all driven through tsx, plus check:sensors for a parity check and link:python for Python tooling. A requirements.txt pinning mypy==2.3.1 and ruff==0.16.7 sits at the root, which means some part of the project ships Python alongside the TypeScript. A pyrightconfig.json at the top level points the same way. The README does not explain which component is Python, so treat that as an open question rather than a documented feature.

The README's phrase "on-device AI detection" is the load-bearing claim. It says detection happens on your hardware, not in a cloud service, which is consistent with the local-first framing. What the README does not describe is the model, the acceleration path, or the CPU and GPU requirements that detection implies. Anyone planning a build should assume detection is the expensive part and size the machine accordingly.

Installing camera.ui: the README gives no commands, the docs do

The repository README does not include install steps. It says plainly: "Please follow the documentation at docs.cameraui.com, it covers installation (desktop app, Docker, Proxmox, bare-metal Linux, mobile apps), a guided first run, and everything beyond." So the first real action is opening that page, not running something from the repo.

If you are working from the source tree, the root package.json defines the developer entry points. The setup script is the one that matters, and the npm install step is wired in as a presetup hook, so it runs before setup automatically:

npm install
npm run setup

The README also links a container image at ghcr.io/cameraui/camera.ui and an npm package at @camera.ui/server. Those are the two distribution channels named in the badge links at the top of the README, and the release tags follow the server: server-v2.1.12 corresponds to camera.ui v2.1.12. The README does not give a docker run line or a compose file, so do not guess at port mappings or volume paths; take them from the install page.

For updates after a source install, the root package.json exposes an update script that runs the updates tool across npm, pypi, go, cargo, docker and make, then cupdate, then tsx ./scripts/update.ts. A cupdate.config.txt sits at the repository root, which is the configuration that second tool reads.

npm run update

The README does not document rollback, and neither the root package.json nor the release list shows a downgrade command. If you need to pin a version, that has to come from the container tag or the npm version you install, not from a documented procedure.

The asterisks are the real limitation

The README marks three capabilities with an asterisk and then explains the mark in the license section: "Features marked with * require a camera.ui subscription that funds ongoing development." The asterisks appear on 24/7 recording, semantic search and push notifications. Live viewing and on-device AI detection are not marked.

That split matters more than any technical detail on this page. A self-hosted product whose headline promise is that your footage stays with you still gates continuous recording behind a paid plan. The core is MIT, and the README says so explicitly: "The core of camera.ui is free and open source." But "core" is doing quiet work in that sentence, and the README never enumerates where the core ends. If your plan is a fully free 24/7 NVR, the README does not support that plan.

The second limitation is documentation depth in the repository itself. There is no quickstart, no example configuration, no camera compatibility list, and no docker command in the README. Everything routes to docs.cameraui.com. The live demo is described as "in the works, coming soon," so you cannot evaluate the interface before installing. The issue tracker is also restricted: the README states the issue list is "exclusively for bug reports and feature requests," which pushes questions to Discussions, Discord or Reddit.

camera.ui compared with Frigate and Scrypted

The comparison people search for is camera.ui against Frigate and Scrypted, and the difference is mostly in packaging and licensing rather than in what the cameras do.

Frigate is built around object detection with a local inference pipeline and is typically deployed as a container next to Home Assistant. camera.ui instead presents itself as a full platform: server, service layer, shared types and a UI in one monorepo, with an app for desktop and mobile as named install targets. If you already have Home Assistant and want a detection engine to sit beside it, Frigate's narrower scope is a better fit. If you want one system that owns live view, recording and the interface, camera.ui's scope is the argument for it.

Scrypted is a home-automation hub that exposes cameras into Apple Home, Google Home and Alexa through plugins. camera.ui also claims smart-home integration and runs a plugin ecosystem, so the overlap is real. The distinction visible in the README is the local-first framing and the subscription model: camera.ui keeps the core MIT and charges for recording, semantic search and notifications, while the README gives no equivalent breakdown for alternatives. That is a licensing and funding difference, not a feature one, and it is the part you can verify from this repository alone.

Maintenance, release cadence and what the MIT license does not cover

The last push to the default branch was on 2026-08-28, the same day as the server-v2.1.12 release. The two releases before it, server-v2.1.11 and server-v2.1.10, landed on 2026-08-27 and 2026-08-19. That is a tight cadence across a ten-day window, and the repository is not archived. A CHANGELOG.md and an updates.config.js at the root are consistent with a project that tracks its own dependency updates.

Upgrade cost depends on how you installed it. A container install follows the published tags, and the release naming ties every server tag to a camera.ui version, so pinning is straightforward. A source install runs the update script, which touches npm, pypi, go, cargo, docker and make ecosystems at once; that breadth means an update can move dependencies you did not know the project had, including the Python tooling pinned in requirements.txt. Budget for reading the changelog before running it.

The license is MIT, Copyright (c) 2020-present seydx, per the README and LICENSE.md. MIT covers the code. It does not cover the subscription features, and the README does not state the terms under which those are provided. Nothing here is legal advice; if you are deploying this commercially, read the subscription terms on cameraui.com and the LICENSE.md in the repository rather than assuming MIT applies end to end.

Editorial conclusion

Adopt camera.ui if you want a self-hosted camera platform on hardware you own and you accept that recording, semantic search and notifications sit behind a subscription. Do not adopt it if the README's asterisks are a dealbreaker, or if you need the repository itself to walk you through setup. Before committing, confirm which tier covers 24/7 recording for your camera count, check the install page for your target platform (Docker, Proxmox, bare-metal Linux, desktop app), and read the plugin documentation to see whether your camera brand is already supported.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes