Secluso core: a Raspberry Pi home security camera with an untrusted relay

What Secluso core solves, and for whom

Most consumer cameras send footage to a vendor's servers, and the phone app is a thin client over that account. Secluso takes the opposite position: the camera is a Raspberry Pi you own, the relay that carries remote traffic is treated as untrusted, and the phone app holds the keys. The README states the goal plainly, describing Secluso as "private home security camera system for Raspberry Pi" with live video, alerts, and recordings viewed from a phone "without handing your footage to a cloud provider."

The intended user is a hobbyist who is comfortable with a Linux VPS login and a DIY build. The README requires a Raspberry Pi Zero 2W, a Raspberry Pi Camera Module V1 or V2 (or any camera with an OV5647 or IMX219 Sony sensor), a relay (your own Linux VPS, or free beta relay hosting by email while testing), and an Android or iPhone for pairing, alerts, and playback. That is a narrow hardware list. If you own a Pi 4 or a Pi 5, the README does not say it works there, so treat the Zero 2W requirement as a constraint rather than a suggestion.

The repository is organized as a set of Rust components rather than a single binary: camera_hub, client_lib, client_server_lib, server, server_backbone, motion_ai, config_tool, deploy, update, reset, toggle, and tester. That layout tells you where the boundaries are. Motion detection and the camera pipeline live apart from the server and the client libraries, and the deploy tooling is its own directory.

The untrusted-relay design and where the keys live

The central mechanism is that remote access does not require the relay to be trusted. The README points to WHITE_PAPER.md for "the full security model, including the untrusted-relay design, forward secrecy, and post-compromise security," and ENCRYPTION.md sits at the repository root as a second document on the same subject. The design implication is direct: a relay operator who can see traffic cannot read the video, and the phone is the endpoint that decrypts it.

Secluso Deploy is the piece that makes this practical. According to the README, the tool generates "your personalized Secluso OS image and camera secret QR code locally" and then provisions the relay over SSH. Credentials are created on your machine rather than on a vendor's build server, and the camera secret reaches the phone as a QR code during pairing rather than through an account.

The project claims reproducible builds for the pieces it ships: the README says Secluso OS, the deploy tool, the runtime binaries, and the Android app are "completely reproducible." It also distributes a prebuilt Raspberry Pi image called Secluso OS into which Deploy injects unique credentials. That is a real trade-off rather than a pure win: you get a reproducible prebuilt image, but you are trusting the image until you run the checker, and the README is explicit that "the image must be checked before the deploy tool modifies it (download from our releases directly)." Run the checker after Deploy has touched the image and you have verified the wrong artifact.

The mobile side is not in this repository. The README links to a separate mobile_client repository for the Android reproducibility checker, and the apps are distributed through the App Store and Google Play rather than built from source by the user.

Secluso core setup: image, relay, pairing

The README describes a five-minute path in four steps: download Secluso Deploy from the latest releases, generate the OS image and camera secret QR code locally, let Deploy provision the relay over SSH (or email the project for free beta relay hosting while testing), then boot the Pi and pair it in the mobile app. The commands below are not published in the README. It gives no CLI invocation for the deploy tool, so there is nothing to copy verbatim; what follows is the sequence of actions the README describes, not a command reference.

Start by downloading the Secluso Deploy artifact from the releases page rather than from a mirror, because the reproducibility check only means something against the published artifact:

# Download Secluso Deploy from https://github.com/secluso/secluso/releases
# then run the reproducibility checker described in releases/README.md

Next, use Deploy to generate the Secluso OS image and the camera secret QR code on your own machine. The README says this happens locally. Keep the QR code off any shared screen, since it is the pairing secret for the camera.

Then point Deploy at your relay. It provisions the relay over SSH, so you need a Linux VPS login before this step. If you do not have one, the README offers an alternative: email the project for free beta relay hosting while testing, at [email protected].

Finally, flash the generated image, boot the Pi, and pair it in the mobile app. The README links the iOS app at apps.apple.com/us/app/secluso/id6756543429 and the Android app at play.google.com/store/apps/details?id=com.secluso.mobile. After pairing, the app is where you check in remotely, review recent events, and open encrypted clips.

One thing to plan for: the README's five-minute figure covers the normal path with Deploy handling image building, pairing, and relay setup. It does not include the time to obtain a VPS, install Secluso OS, or debug a camera that the Pi does not detect.

Hardware, dependency and operational limits

The hardware list is the first real constraint. A Raspberry Pi Zero 2W is required, and the supported cameras are the Camera Module V1 and V2 or any camera built on the OV5647 or IMX219 sensor. A USB webcam is not mentioned. A Pi 4 or Pi 5 is not mentioned. If your plan depends on either, the README does not support it.

The second constraint is the relay. You supply a Linux VPS login, or you depend on free beta relay hosting that the README describes as available "while testing." Beta hosting is a temporary arrangement by definition, and the README gives no commitment about its duration or terms. Anyone building on this should assume they will eventually run their own relay.

The third is that the mobile client is a separate repository and a store-distributed app. You can verify the Android build against source using the checker the README links, but the iOS app is not described as reproducible anywhere in the README. If your threat model requires that every component be auditable, that asymmetry matters.

The fourth is legal and practical rather than technical. The README carries a disclaimer that the project "uses cryptography" and tells you to check your local laws before use, and a second disclaimer that the authors "provide no guarantees of privacy or home security." That is an unusually blunt statement from a security project, and it should be read literally. Secluso is a DIY system with no support contract, no uptime guarantee, and no warranty that a camera will record the event you care about.

Finally, the README does not document rollback, migration between releases, or what happens to existing recordings when you upgrade. The update directory exists in the repository, but the README describes no upgrade procedure. Treat upgrades as an area to test on a spare SD card first.

How Secluso differs from Frigate and general NVR software

The obvious comparison is Frigate, which also runs on a Raspberry Pi and also does local detection, but the two solve different problems. Frigate is an NVR: it ingests camera streams, typically over RTSP, runs detection on them, and exposes a web interface, and it expects you to bring your own cameras and storage. Its value is in recording, retention, and integration with home automation.

Secluso is not an NVR in that sense. It is a complete stack from camera hardware to phone app, and its distinguishing claim is the encrypted remote path through a relay that does not need to be trusted. The README does not describe an RTSP output, a web UI, or storage retention policy, so you cannot point Frigate at a Secluso camera and get the same result. The two are not substitutes.

Privastead is the closer relative, and it is a name people search alongside Secluso. Both are privacy-focused camera systems built around end-to-end encryption, and the repositories share a naming vocabulary. The README here does not compare the two, so the honest statement is that Secluso's own documentation is the only source for what Secluso does, and anyone choosing between them should read both white papers rather than assume equivalence.

If what you want is a camera that plugs into an existing NVR, home automation, or a NAS with retention rules, Secluso is the wrong tool. If what you want is a phone app that shows your front door without a vendor account, and you accept a fixed hardware list, it is aimed at exactly that.

Licence, maintenance and the cost of upgrading

Secluso core is licensed GPL-3.0, and the README states that contributions are made under the project license in LICENSE. The practical consequence of GPL-3.0 for a self-hoster is minimal: you can run it, modify it, and redistribute modified versions, provided you meet the licence's source-availability terms. If you intend to ship a product built on this code, that obligation is the thing to examine, and THIRD_PARTY_LICENSES at the repository root is where the dependency licences are collected. This is a description of the licence, not legal advice.

The repository is not archived, and the last push was on 2026-08-24, which is under a month before the date of this article. The release history is short and uneven: v0.1.0 arrived on 2025-09-14, and v1.0.2 on 2026-05-21. Two tagged releases in roughly a year, with nothing between them, suggests a project that ships in larger steps rather than continuously. The commit activity and the release cadence tell different stories, and the release cadence is the one that affects you, because that is what you pin your deployment to.

Upgrade cost is the open question. The repository contains an update directory and a reset directory, so the mechanism for updating a deployed device exists in the codebase, but the README documents no upgrade path, no version compatibility statement, and no way to roll back a bad image. The reproducibility checkers help here in a specific way: they let you confirm that a new release binary matches its source before you flash it. That is the closest thing to a safety net the documentation offers.

Budget for the hardware as well. A Pi Zero 2W, a supported camera module, an SD card, and a VPS add up to more than the sticker price of a consumer camera, and the README's free relay option is explicitly a testing arrangement.

Editorial conclusion

Adopt Secluso if you have a Raspberry Pi Zero 2W, a Camera Module V1 or V2, and a Linux VPS you are willing to use as a relay, and you want a phone app for alerts and playback without a cloud account. Do not adopt it if you need a wired camera, a board other than the Zero 2W, or an RTSP stream that existing NVR software can ingest; the README lists no such output. Before buying anything, verify the reproducibility checker in releases/README.md and the untrusted-relay claims in WHITE_PAPER.md, and confirm the mobile app is still listed on the iOS and Android stores.

Frequently asked questions

Official sources

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