Unblink

Self-hosted smart surveillance, honestly reviewed. One project, sparse external coverage, limited website — here’s what the README and architecture actually tell you.

TL;DR

• What it is: Open-source (AGPL-3.0) AI camera monitoring application that uses a Vision Language Model (Qwen3-VL) to watch your video feeds, understand what’s happening, and let you search footage in plain English [README].
• Who it’s for: Privacy-conscious founders, homeowners, or small teams who want AI-powered surveillance without paying for cloud camera subscriptions or sending footage to third-party servers [3].
• Cost savings: Commercial AI camera platforms (Verkada, Rhombus, Eagle Eye) run $50–300+/month per camera. Unblink is free software — your cost is the hardware and whatever VPS you use for the relay component.
• Key strength: The relay-node architecture keeps your video stream inside your local network. The node runs on your machine; the public server is a relay for management only, not a video store [README].
• Key weakness: Very early-stage project. 1,349 GitHub stars, minimal public documentation, a website that returned no substantive content at scrape time, and almost no third-party coverage to verify real-world stability [README][3].

---

What is Unblink

Unblink is an AI camera monitoring application built around a Vision Language Model. Instead of the traditional motion-detection approach — pixel diffs and bounding boxes — it feeds frames from your RTSP or MJPEG cameras to Qwen3-VL, an open-weight multimodal model, and asks the model to describe what it sees. The result is semantic understanding rather than just movement: “a person entering through the side door” instead of “motion detected in zone 3” [README][3].

The project comes from Zapdos Labs and sits at 1,349 GitHub stars as of this writing. It’s licensed under AGPL-3.0, which is meaningfully different from MIT — more on that below [README].

Three components make up the system:

• Server: A publicly reachable relay that manages nodes, handles authentication, and stores configuration. This is the bridge between your browser and your local cameras [README].
• Node: A Go binary you run inside your own network. It connects to the relay server and forwards camera traffic locally. Prebuilt binaries are available for Linux x86_64/ARM64 and Windows x86_64/ARM64 [README].
• Frontend: Built with SolidJS, TypeScript, and Vite — served from the relay [README].

The architecture is clever from a privacy standpoint: your video frames are processed by the node on your hardware, not uploaded to the relay. The relay is a coordination layer, not a storage layer. If you’re coming from a cloud camera service where footage leaves your building by definition, this is a meaningful difference [README][3].

One data point worth flagging: the Unblink website returned no useful content at scrape time — empty body text, no H1 headings, no pricing page. This is either a very minimal marketing site or a pre-launch state. The project is primarily documented through its GitHub README.

---

Why People Choose It

Independent coverage of Unblink is sparse. The one substantive third-party mention comes from MEDevel, which describes it as: “a free and open-source smart camera monitoring app that uses AI to watch your video feeds in real time, right on your device. It can spot people, objects, and even understand what’s happening (like ‘someone entering the door’ or ‘a package arriving’). You can search past footage” [3].

That framing surfaces the two genuinely differentiating bets Unblink is making versus traditional self-hosted NVRs:

Natural language search of recorded footage. The ability to type “show me when the delivery arrived” and get a relevant clip back is qualitatively different from scrubbing a timeline. It’s a capability that Verkada and Rhombus sell as a premium feature. Unblink is attempting to ship it as open-source infrastructure [README][3].

Chat interface with live feeds. Asking your camera “is there anyone in the parking lot right now?” as a conversational query is a different paradigm from monitoring dashboards. Whether that paradigm holds up at 2 AM when the model is slow to respond — no third-party data exists to confirm [README].

Privacy as a first-class feature. The relay-node split means footage never leaves your premises. For founders running physical operations, retail spaces, or home offices who’ve been burned by commercial camera cloud subscriptions, this matters [3].

What’s absent from the coverage: any honest accounting of inference speed, accuracy rates, false positive behavior, or what happens when Qwen3-VL misidentifies a shadow as a person at 3 AM. No stress tests, no long-term reliability data, no forum threads to cite. This is a watch-carefully project, not a proven-in-production one.

---

Features

Based on the README and the one third-party mention:

Core monitoring:

• Real-time video processing via RTSP and MJPEG camera streams [README]
• go2rtc for RTSP/WebRTC handling — a well-regarded open-source library [README]
• Frame analysis and summarization using Qwen3-VL [README][3]
• Object and person detection with semantic descriptions, not just bounding boxes [3]

AI and search:

• Natural language video search through recorded frames [README]
• Chat interface for querying live camera feeds in plain English [README][3]
• Vision Language Model inference runs on the node (your hardware), not the relay [README]

Architecture and deployment:

• Relay-node architecture keeps video local; relay handles auth and config only [README]
• Prebuilt node binaries for Linux (x86_64, ARM64) and Windows (x86_64, ARM64) — no Go toolchain required [README]
• Go install path available for developers: go install github.com/zapdos-labs/unblink/cmd/unblink-node@main [README]
• One-click Render deployment available via “Deploy to Render” button for the server component [README]
• PostgreSQL with pgx as the database [README]
• SolidJS frontend — lighter runtime than React, relevant if you’re running on modest hardware [README]

What’s missing from the data: No mention of multi-camera dashboards, notification/alerting systems, retention policies, or storage management. These are table stakes for any NVR replacement and their absence from the README is either an oversight in documentation or a feature gap. Data not available to confirm either way.

---

Pricing: SaaS vs Self-Hosted Math

Unblink’s website returned no pricing information. The README makes no mention of paid tiers. Based on the AGPL-3.0 license and the project structure, the software itself is free [README].

Your cost breakdown for self-hosting:

What you need to run:

• Hardware for the node: any Linux or Windows machine in your network that can handle VLM inference. Qwen3-VL requires a capable GPU for real-time performance. The README doesn’t specify minimum specs — budget a GPU workstation or a machine with at least 16GB RAM for CPU-only inference.
• A VPS for the relay server: $5–10/month on Hetzner or DigitalOcean is likely sufficient for the relay component since it’s coordination only, not compute.
• Domain + HTTPS setup for the relay.

Commercial alternatives for comparison:

• Verkada: $200–600/year per camera plus hardware. Footage stored in their cloud.
• Rhombus: similar range, cloud-dependent.
• Milestone XProtect / Genetec: enterprise NVR software, $500+/year licensing.
• Frigate (open-source NVR, no VLM): free, but no natural language features.

If you’re running 2–4 cameras and paying a cloud camera subscription, the break-even math works fast — but you need hardware capable of running Qwen3-VL, which is the real cost variable that pricing comparisons need to account for and which Unblink’s documentation doesn’t address.

---

Deployment Reality Check

The README offers a clean install path: download prebuilt binaries, run unblink-node, authorize via browser on first launch [README]. There’s also a “Deploy to Render” button for the server component, which reduces the relay setup to a few clicks [README].

What you actually need:

• A Go binary running on your local machine (node) — no container required
• A relay server: Render one-click deploy or your own VPS with the server component
• PostgreSQL (referenced in README, likely bundled or external)
• RTSP or MJPEG compatible cameras — most IP cameras support at least one

What can go sideways:

• VLM inference hardware is the unknown. Qwen3-VL is not a lightweight model. Real-time frame analysis on a laptop CPU will be slow. The README doesn’t specify hardware requirements, which is a gap for anyone planning a deployment [README].
• The relay dependency. Your node connects to the relay to function. If the relay is Zapdos Labs’ hosted service (the Render deploy button deploys their server, but it’s unclear if there’s a managed relay option), there’s a third-party dependency even in “self-hosted” mode. The README implies you run your own relay server, but clarification is needed.
• AGPL-3.0 license implications. If you embed Unblink in a commercial product or SaaS, AGPL-3.0 requires you to open-source your modifications. For internal use or personal deployment this doesn’t matter, but for founders building on top of it, this is a legal consideration that MIT-licensed alternatives don’t impose.
• Almost zero community resources. 1,349 stars means a small user base. When something breaks, your debugging resources are the README and the GitHub issue tracker — no StackOverflow threads, no r/selfhosted war stories, no YouTube setup guides.

Realistic setup time for a technical user who has Go and can read a README: 1–2 hours for a working single-camera setup. For inference performance tuning (getting Qwen3-VL to run fast enough to be useful): unknown, no benchmarks published.

---

Pros and Cons

Pros

• Semantic video understanding. Natural language queries against recorded footage and live feeds is a genuinely novel capability for self-hosted camera software [README][3].
• Privacy-preserving architecture. The relay-node split means video frames stay on your hardware. The relay is stateless with respect to your footage [README].
• No per-camera subscription fees. Once running, the marginal cost of adding cameras is zero [README].
• Prebuilt binaries for Linux and Windows. No Docker, no Go toolchain required for the node. Lower barrier than most self-hosted projects [README].
• Go2rtc for video handling. go2rtc is a well-maintained library with broad camera compatibility [README].
• Open VLM. Qwen3-VL is an open-weight model — you’re not dependent on OpenAI or Google APIs for vision inference [README].

Cons

• Hardware requirements undocumented. Qwen3-VL inference needs real compute. The README is silent on minimum specs, which makes deployment planning a guessing game [README].
• AGPL-3.0, not MIT. Commercial embedding or redistribution requires open-sourcing your modifications. Less permissive than what most builders want [README].
• Near-zero third-party validation. One brief mention from a tech blog is the entirety of public third-party coverage [3]. No community forums, no real-world performance data, no failure post-mortems.
• Empty website. The project’s marketing site returned no substantive content at scrape time. First-time evaluators have nowhere to go except GitHub [website scrape].
• Relay dependency is unclear. Whether the relay must be self-hosted or can use a Zapdos Labs-managed relay isn’t explicit in the README. This matters for the “self-hosted” claim’s completeness [README].
• Missing NVR basics. No documented alerting, notification, or storage retention management — standard features in established NVR software that aren’t mentioned [README].
• Early-stage risk. 1,349 stars, a small team, minimal docs, and no third-party stress testing. This is a project to watch, not yet a project to bet your security infrastructure on.

---

Who Should Use This / Who Shouldn’t

Use Unblink if:

• You’re experimenting with VLM-based surveillance on hardware you already own and want a working codebase to build from.
• You run a small physical space and want to replace a cloud camera subscription with something privacy-preserving that you can query in plain English.
• You’re a developer who wants to extend or fork an AGPL-licensed AI camera project — the SolidJS + Go + PostgreSQL stack is clean.
• You’re comfortable running bleeding-edge, minimally-documented software and filing GitHub issues when things break.

Wait and watch if:

• You need production-grade reliability for a business-critical camera setup today. The project’s maturity level doesn’t yet support that bet.
• Your cameras are the only layer of security — you want Frigate (proven, large community, Home Assistant integration) for that use case.

Skip it entirely if:

• You’re a non-technical founder who wants a working AI camera system without debugging VLM inference pipelines. The setup complexity and documentation gaps will frustrate you.
• Your use case requires commercial embedding — AGPL-3.0 is a legal blocker.
• You need alerting, notifications, or retention management out of the box.
• Your compliance team has opinions about AGPL licensing.

---

Alternatives Worth Considering

• Frigate — The established self-hosted NVR with AI object detection. Uses lightweight Coral TPU-optimized models rather than a full VLM. Massive community, Home Assistant integration, proven in production. No natural language search, but it actually works reliably. Start here if you want a camera system today.
• Shinobi — Traditional self-hosted NVR, no AI features. Stable, large user base. Pick this if you want recording and playback without AI complexity.
• ZoneMinder — The veteran open-source NVR. Technically capable, UI hasn’t aged well. Used primarily by homelab enthusiasts who’ve been running it for years.
• Scrypted — Modern self-hosted camera hub with HomeKit and Google Home integration, some AI detection features. Good for smart home use cases.
• MotionEye — Lightweight, minimal, motion-detection only. No AI. Good if you need something simple running on a Raspberry Pi.
• Verkada / Rhombus (commercial) — Cloud AI camera platforms with polished interfaces and reliable alerting. $200–600+/year per camera. Your data goes to their cloud. The economic argument for self-hosting only works if you have the hardware and technical tolerance.

For founders who specifically want VLM-powered natural language search of footage, the realistic comparison is Unblink vs. building your own pipeline with Frigate + a local LLM integration. Unblink at least ships the architecture; the DIY path requires more work but gives you more control.

---

Bottom Line

Unblink is an early-stage bet on a genuinely interesting idea: replace motion-detection surveillance with semantic video understanding via open-weight VLMs. The architecture is thoughtful — keeping video frames local through the relay-node split is the right call for privacy. The natural language search capability, if it works reliably, is a meaningful step forward from what established self-hosted NVRs offer.

But “if it works reliably” is doing a lot of work in that sentence. Third-party coverage is nearly nonexistent. Hardware requirements are undocumented. The website is empty. The project has 1,349 stars — interesting but not yet a proven community. AGPL-3.0 limits commercial use.

If you’re a developer who wants to experiment with VLM-based camera monitoring on your own hardware, Unblink is worth an afternoon. If you’re a non-technical founder who needs a camera system that just works, start with Frigate and revisit Unblink in a year.

---

Sources

1. MEDevel.com — “JavaScript — MEDevel.com | Open-source Apps for Healthcare and Enterprise” (includes brief Unblink mention). https://medevel.com/tag/javascript/

Primary sources:

• GitHub repository and README: https://github.com/zapdos-labs/unblink (1,349 stars, AGPL-3.0 license, Zapdos Labs)
• Official website: https://unblink.net (minimal content at time of scrape)