Secluso: an encrypted Raspberry Pi camera with a relay you do not have to trust

The problem Secluso picks: remote viewing without a vendor holding the footage

A home camera has two jobs that pull in opposite directions. You want to watch the feed when you are away from home, which means the stream has to leave your network. You also want nobody else to watch it, which means the stream should not be readable by whatever carries it. Consumer cameras resolve this by making the vendor the trust anchor: the clip goes to their servers, and their privacy policy is the control. Secluso takes the other position. The README describes it as a private home security camera system for Raspberry Pi where you watch live video, get alerts and open recordings from your phone without handing your footage to a cloud provider. The audience is narrow and specific. You need a Raspberry Pi Zero 2W, a Camera Module V1 or V2 (or any camera built on an OV5647 or IMX219 Sony sensor), a phone running Android or iOS, and a relay. That relay can be your own Linux VPS login, or the project will host one for free during beta if you email them. If you do not have a VPS and do not want to wait on an email, the architecture has no other path, because the relay is a required component rather than an optional convenience.

Untrusted relay, forward secrecy, and what the white paper is doing

The design choice that separates Secluso from a self-hosted NVR is that the relay is treated as hostile. The README points to WHITE_PAPER.md for the full security model and names three properties: an untrusted-relay design, forward secrecy, and post-compromise security. That combination is a deliberate statement about where the trust boundary sits. In a conventional setup, the machine that forwards your video is the machine that can decode it, so running your own VPS protects you from a vendor but not from a compromised VPS. Secluso's claim is that the relay forwards ciphertext it cannot read, so the operator of that box is outside the trust boundary. Forward secrecy and post-compromise security address the time dimension: a key captured today should not decrypt yesterday's recordings, and a device compromise should not permanently expose everything that follows. I cannot verify any of this from the README alone, and the README does not summarize the mechanisms. Anyone evaluating Secluso for a real threat model has to read the white paper and judge the protocol on its own terms, because the repository description saying "advanced end-to-end encryption" is marketing language, not a specification. The honest position is that the architecture is more interesting than the feature list, and the white paper is the document that decides whether it works.

Secluso Deploy builds the image and provisions the relay over SSH

The setup path is a desktop tool rather than a shell script you paste into a terminal. The README's quick start is four steps: download Secluso Deploy from the latest releases, generate a personalized Secluso OS image and camera secret QR code locally, let Secluso Deploy provision your relay over SSH (or email for beta hosting), then boot the Pi and pair it in the mobile app. Two details matter more than the five-minute claim. First, credentials are generated on your machine and injected into a prebuilt Secluso OS image, which is why the project can ship a downloadable image and still argue that your secrets were never generated by them. Second, the relay provisioning happens over SSH from the deploy tool, which means the tool needs login access to your VPS. That is a real grant of authority: the same binary that writes your camera secrets is also the one connecting to your server. The README notes the image must be checked before the deploy tool modifies it, and that you should download from the releases page directly. That instruction exists because verifying a modified image proves nothing about the original. The releases page lists v1.0.2 from May 2026 and v0.1.0 from September 2025, so the project has roughly a year of tagged history behind it.

Reproducible builds cover four artifacts, and the checker order is not optional

Reproducibility is the feature Secluso leans on hardest, and the README is unusually precise about scope. Four things are described as completely reproducible: Secluso OS, the deploy tool, the runtime binaries, and the Android app. Each has its own checker. The repository's releases/README.md holds the checker for the binaries and the deploy tool. The Android app's checker lives in mobile_client/tool/repro/README.md, which is in a separate repository (secluso/mobile_client) rather than this one. Secluso OS has its own repository at secluso/os. The iOS app is not in that list. If you care about verifying what runs on your phone, the Android path is documented and the iOS path is not, which is a meaningful asymmetry for anyone treating reproducibility as a hard requirement rather than a nice property. The sequencing also matters: the README states the image must be checked before the deploy tool modifies it. Run the OS checker first, confirm the hash against the release, and only then let Deploy inject credentials. Reversing that order gives you a verified artifact that is no longer the artifact you downloaded.

The hardware list is short, and that is a limitation, not a feature

Secluso supports exactly one board: the Raspberry Pi Zero 2W. The camera options are the Raspberry Pi Camera Module V1 and V2, or any camera using an OV5647 or IMX219 Sony sensor. There is no mention of the Pi 4 or Pi 5, no CSI camera beyond those two sensors, and no USB or IP camera path. If you already own a Pi 4 and a USB webcam, this project does not meet you where you are. The Zero 2W is a low-power, single-board device with a modest CPU, and the README does not describe on-device processing beyond capture and encryption, so I cannot say what headroom exists for anything heavier. The topics list includes local-ai, but nothing in the README describes an inference pipeline, a model, or what would run it. Treat that topic tag as unverified until you find it in the white paper or the source. There is also no stated weather rating, no battery option, and no mention of PoE. This is an indoor, mains-powered, single-camera design, and the hardware constraints are the first thing that will rule Secluso out for a given deployment.

Where Secluso is the wrong tool, and what to run instead

If your goal is a general NVR with many cameras, motion zones and long retention on local disk, Secluso is the wrong shape. Frigate is the obvious alternative and the difference is architectural rather than cosmetic. Frigate expects to sit in front of cameras that already speak RTSP, including cheap ONVIF IP cameras, and it does detection and recording on a host you control, typically with a Coral or GPU accelerator. Its trust model is a local network boundary: keep the cameras on a VLAN, keep the NVR off the internet. Secluso inverts that. It builds the camera itself on a Pi, and it assumes the video will traverse a relay you do not control, so it spends its complexity budget on end-to-end encryption and forward secrecy instead of detection hardware. If you want object detection across six cameras with a web UI, Frigate is the better fit and Secluso will not get there. If you want one camera, remote viewing from a phone, and a relay operator who cannot see the feed, Frigate gives you nothing for that problem and Secluso is built for it. The two projects are not competing on the same axis, and picking wrong means fighting the design rather than using it.

Licence, maintenance, and what a GPL-3.0 camera stack costs you

Secluso is GPL-3.0. For a self-hoster that changes nothing practical: you run the software, you read the source, and if you modify and distribute it you inherit the licence obligations. If you are a company considering embedding this in a product you ship, GPL-3.0 is a copyleft licence and the compliance analysis is yours to do; this is not legal advice and the project does not offer an alternative licence. The development company is Secluso, Inc., co-founded by Ardalan Amiri Sani, a UC Irvine professor in computer security and privacy, and John Kaczman. Releases are sparse: v0.1.0 in September 2025 and v1.0.2 in May 2026, with the last push to main in August 2026. Sparse tags are normal for a project at this stage, but they do mean you should read commit history rather than release notes if you want to know what changed recently. The upgrade cost is concentrated in the image and the phone app. Because credentials are injected into a prebuilt OS image, a new Secluso OS release likely means regenerating the image and re-pairing, and the mobile app updates on the store's schedule rather than yours. The README's disclaimers are worth reading literally: the project authors provide no guarantees of privacy or home security, and it advises checking local cryptography laws before use.

Editorial conclusion

Adopt Secluso if you already run a Linux VPS and you accept a Raspberry Pi Zero 2W with an OV5647 or IMX219 sensor as your whole camera budget, and if you want the relay operator to be unable to watch your footage. Do not adopt it if you need a battery camera, an outdoor rating, ONVIF integration with an existing NVR, or a desktop web client, because none of those appear in the requirements. Before you buy anything, read WHITE_PAPER.md and confirm the forward secrecy and post-compromise security claims match the threat you actually care about, then verify the Secluso OS image hash against the releases page before Secluso Deploy touches it.

Official sources

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