clearcam runs local detection on your own RTSP cameras, and remote viewing sits behind a premium userID

Notifications are configurable and premium at the same time

The headline sentence lists object detection, tracking, mobile notifications, AI summaries, and search as things this adds to any security camera. Two sections further down say something narrower about the notifications half. One invites you to bring your own, saying you can change the URL notifications are sent to in settings and naming Home Assistant, Pushover, N8N, or any program, with a sample Pushover notification server included in the repository. The premium list then sells notifications on events as one of four paid features, next to remote feeds, remote event clips, and end-to-end encryption. Both can be true at once if the free path is your own webhook and the premium path is the phone app, but the page never draws that line, so a reader has to infer it: the alert target is configurable either way, and what the subscription buys is delivery to the app plus the remote viewing of what was captured.

The free path ends at localhost:8080

The source install is four steps.

pip install -r requirements.txt
python3 clearcam.py

Open localhost:8080 in a browser and the web interface is up on the machine that runs it. The fourth step is optional and is where the boundary sits: enter your Clearcam premium userID in the web UI settings to receive streams and notifications. That userID is described as viewable in the iOS app settings page. So detection, tracking, and the local dashboard work with no account at all, and everything that leaves the machine depends on an identifier tied to a subscription. The premium list also claims end-to-end encryption on all data, which is a claim about a transport path that the open source side never touches, since the local database and the frames on disk sit outside it. Two apps exist for the remote half, one in the App Store and one on Google Play under the package name com.rors.clearcam.

The userID is documented as an iPhone setting and nowhere else

The instruction that unlocks streams and notifications is one clause long: the premium userID is viewable in the iOS app settings page. No other route is given. A desktop user who installed from source and wants remote access has a web interface at localhost and a subscription, and the documentation does not say where to find the string that connects them. An Android user is in the same position, and in a slightly worse one, because the Google Play build exists and is the natural place to look, yet the page points only at the iOS app. The iOS build is the one documented end to end: clone the repository, open the project file, and the app builds.

git clone https://github.com/roryclear/clearcam.git

Its requirements are short as well, iOS 15 or newer, an iPhone SE first generation or newer with older models said to maybe work, and a line that reads dependencies: NONE.

Three dependencies, and one of them is a commit hash

The whole dependency list is three lines long.

git+https://github.com/tinygrad/tinygrad.git@6f87158d77f66a36d5f8bbe915170b24e2acabe8
numpy==2.0.0
opencv-python-headless==4.10.0.84

The numeric libraries are pinned to exact releases, with numpy held at the 2.0.0 line and OpenCV at a 4.10 point release. The interesting entry is the first: tinygrad is installed straight from its repository at one specific commit rather than from a tagged release, so the inference code is reproducible in the way a lockfile is, and pinned to whatever upstream had at that hash. Two consequences follow for anyone running this. There is no release to fall back to, since a deleted branch or a rewritten upstream history changes what pip fetches. And the headless build of OpenCV is the right choice for a machine with no display, which fits a process that serves its interface through a browser rather than a window.

The compute backend is chosen by prefixing the command

There is no configuration file for hardware. Two environment variables, read from the command line, pick the path. Running the script with DEV=AMD or DEV=NV uses the CPU instead of the GPU, in the form DEV=AMD python3 clearcam.py or DEV=NV python3 clearcam.py. A second variable, BEAM=2, asks for extra performance and carries a warning of its own: there is a wait on the first run. That pairing of a vendor prefix and a numeric toggle is a thin surface, and it is also the only hardware documentation on the page. The platform list is equally short: Mac and Linux are named, Windows is struck through with a note that an ffmpeg fix is needed, and ffmpeg itself is a requirement alongside python3.11 or later. The repository tree matches the shape of a single process: one entry script, clearcam.py, alongside detection, models, a tracker directory, an llm directory, and utils.

The headline promises search, and the page never says how

Two of the five things in the one-line description are explained somewhere on the page and one is not. Detection and tracking have a directory each and a tracker by name in the tree. AI summaries arrive as a banner announcing notification summaries built with Qwen3 VL, which is the model named for the newest feature, and the llm directory at the root is where that work would live. Search appears in the headline and in the repository description, and no section on the page describes it: no interface, no index, no configuration. The repository also carries mainview.html at the root, which is the web interface the browser opens, and a test directory. The page offers one way to try the whole thing without hardware, a public tunnel camera feed served as an HLS playlist, for readers who do not own an RTSP camera yet.

Tags are still 0.2.x with a month of commits past the newest one

The release history is three pre-1.0 tags: 0.2.6 on 2026-05-29, 0.2.7 on 2026-07-13, and 0.2.8 on 2026-08-31, spaced between six and eight weeks apart. The last commit on the default branch is dated 2026-10-02, about a month after that tag, so the branch carries work that no release names. There is no package index entry to install from either; the documented route is a clone plus a two-command start, and the version number lives in the tags rather than in a manifest. Licensing is GPL-3.0 with the license text in LICENSE.md rather than a plain LICENSE file. The one older artifact the page keeps is a video demo link on a social account, labeled old, next to the newer feature banner. Taken together the signals describe an actively edited hobby-scale project rather than a finished product, which is consistent with a tree that mixes model code, a tracker, an iOS app, an Android app, and a notification sample server in one repository.

Editorial conclusion

Use it if you already own the cameras and want detection to happen on your own hardware, since the free path is a local process and the notification target is a URL you choose. Two things deserve a decision before you rely on it. The premium boundary sits on remote feeds, event clips, and event notifications, while the marketing line lists mobile notifications among the headline features, so read the pricing page against your actual need. And the only documented way to obtain the userID is the iOS app settings screen, which leaves desktop and Android users without a documented route. Everything else is ordinary: a pinned dependency list, an OC-SORT tracker in the tree, and a repository that is still publishing 0.2.x tags.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. roryclear/clearcam on GitHub