Scrypted: a video integration and NVR platform for cameras you already own

What Scrypted actually solves for a camera owner

Most cameras record to a vendor app that speaks one protocol, and most smart home hubs speak another. Scrypted sits between them. The README describes it as a "high performance home video integration platform and NVR with smart detections" and claims "instant, low latency, streaming" to HomeKit, Google Home and Alexa, with support for "most cameras". That sentence is the whole pitch: the camera stays where it is, and Scrypted republishes its video and events to the assistants you already use.

The second half is the NVR. Scrypted is not only a bridge; it records and runs detection on the stream. The distinction matters when you compare it with a plain HomeKit bridge, because detection events and recording are produced inside Scrypted rather than by the camera firmware. The audience is therefore narrower than "anyone with a camera": it is people who own hardware that the project supports, who want it inside a specific assistant, and who are willing to run a server process rather than accept a vendor cloud.

How the server, plugins and SDK fit together

The repository layout tells you more about the architecture than the README does. Top-level entries include common/, external/, install/, packages/, plugins/, sdk/, server/ and sites/. The README is explicit that the server is not where the interesting logic lives: "the server only provides the hosting and RPC mechanism for plugins", and debugging it "should not be necessary". Video handling, HomeKit exposure, detection and vendor protocols are implemented as plugins that the server hosts and calls over RPC.

That design has a visible consequence in the development workflow. The README states that you "do not need to restart the Scrypted Server if you make changes to a plugin" and that launching the plugin from VS Code deploys the updated build onto the running server. The plugin is the unit of deployment, not the server. The sdk/ and packages/ directories exist to support that model, and developer.scrypted.app is where the plugin API is documented. If you plan to write your own integration, that SDK is the surface you learn; if you only plan to run cameras, the plugin split mostly shows up as a longer list of moving parts to keep current.

Installing Scrypted and onboarding a first camera

The README does not contain installation steps. It says installation and camera onboarding instructions "can be found in the docs" at docs.scrypted.app, and the repository has an install/ directory alongside a .dockerignore, which is consistent with Docker being one of the supported deployment paths. The commands below are the development setup from the README, not an end-user install; they are the only shell steps the README prints.

To work on a plugin, first fetch the repository and its dependencies:

git clone https://github.com/koush/scrypted
cd scrypted
./npm-install.sh

The script name is npm-install.sh and it lives at the repository root. After it completes you have the dependencies for the server and the plugins. The README then opens a specific plugin in an editor:

code plugins/homekit

From there you launch the plugin with the Start Debugging button. If you would rather not use VS Code, the README gives a command-line path from inside a plugin directory:

npm run build && npm run scrypted-deploy 127.0.0.1

That deploys the built plugin to a server listening on 127.0.0.1. For an actual camera install, follow docs.scrypted.app: the repository itself gives no port number, no default credentials and no onboarding sequence, so do not guess them from this README.

Where Scrypted is the wrong tool

The README is thin on failure modes, and that thinness is itself the limitation. There is no documented rollback procedure, no upgrade path between releases, and no compatibility matrix. The repository has SECURITY.md and LICENSE.md at the top level, but the README does not describe what happens when a plugin update breaks a working camera feed. In a system where plugins deploy independently onto a running server, that is the failure mode to plan for: the server keeps running while the plugin that feeds HomeKit misbehaves.

The second limitation is scope. Scrypted is a bridge and an NVR for cameras. If your problem is recording arbitrary IP streams with a large rule engine and no smart home assistant in the loop, a dedicated NVR will fit better. If your camera is not supported by a plugin and you do not want to write one against the SDK, Scrypted gives you nothing. And if you want a hosted service with a support contract, the README points to Discord, Reddit and GitHub for questions, which is community support, not a vendor SLA.

Scrypted vs Frigate: two answers to the same question

The comparison people search for is Scrypted against Frigate, and the difference is in where the output goes. Scrypted's stated purpose is integration: low latency streaming into HomeKit, Google Home and Alexa, with the NVR and detections as part of that delivery. Frigate is an NVR built around detection and recording, with the assistant integration as a downstream concern. If your requirement is "this camera must appear in the Home app and respond quickly", Scrypted's README addresses that directly. If your requirement is "record these streams, run detection, and keep everything in one NVR UI", the integration layer is not the part you are optimizing for.

There is a practical asymmetry too. Scrypted's plugin model means vendor support arrives as plugins, which is how it can claim support for "most cameras" without shipping a driver for each one in the server. That is flexible, but it also means your camera's behaviour depends on a plugin's maintenance, not on the core release cadence. A project with a single detection pipeline has the opposite trade-off: fewer moving parts, less breadth of camera support.

Maintenance, licensing and what the repository does not say

The last push to the default branch was on 2026-09-22, and the most recent release listed is v0.147.0 on 2026-09-13, following v0.145.0 on 2026-09-02. The repository is not archived. On that evidence the project is being worked on, though the gap between v0.143.0 on 2025-10-28 and v0.145.0 on 2026-09-02 shows the release rhythm is not uniform, so pinning a version and reading the release notes before upgrading is the realistic upgrade policy. The README documents no migration steps between versions.

Licensing needs care. The repository metadata reports the license as NOASSERTION, and there is a LICENSE.md at the top level. NOASSERTION means the automated classifier could not match the file to a known licence, not that no licence exists. Read LICENSE.md yourself before shipping Scrypted in a product or a commercial deployment, and check the terms attached to any plugin you install, since plugins are separate packages. Nothing here is legal advice; the point is that the licence is not summarized anywhere in the README.

Editorial conclusion

Adopt Scrypted if you already have cameras or a doorbell that speaks RTSP or a supported vendor protocol and you want them surfaced in HomeKit, Google Home or Alexa with smart detections on your own hardware. Do not adopt it if you expect a single binary with a documented rollback path, or if you want a vendor support contract: the README points at docs.scrypted.app and community channels for installation and onboarding, and the repository carries no install steps of its own. Before committing, verify three things against your own hardware: that your camera model appears in the docs onboarding list, that the NVR storage and pricing terms on scrypted.app match what you need, and that the plugin you depend on builds against the current SDK, since the README treats the server as an RPC host for plugins rather than a monolith.

Frequently asked questions

Official sources

1. Issues
2. koush/scrypted on GitHub
3. Project website
4. README
5. Releases