Video surveillance systems often bundle multiple camera streams into a single monolithic process, which can complicate scaling and fault tolerance. Kerberos Agent takes a different approach: it spins up one isolated agent per camera stream, each running as a standalone Go process or container. This pattern naturally isolates failures and enables horizontal scaling by simply adding more agents. But it also means managing many lightweight agents, which shifts complexity to orchestration and resource planning.
What Kerberos Agent does and how it works
Kerberos Agent is an open-source video surveillance management system written in Go, designed for edge deployment across a wide range of hardware platforms. Its core responsibility is to process RTSP streams encoded in H264 or H265 from IP cameras or proxied USB/Raspberry Pi cameras. Each camera gets its own dedicated agent instance, which handles motion detection recording or continuous recording based on configuration.
The architecture is deliberately simple but effective: a single-agent-per-camera model. This agent consumes the video stream, applies motion detection algorithms, and records video conditionally — with pre- and post-motion buffers — to optimize storage usage. Recordings are saved as fragmented MP4 files, supporting HLS streaming for live or near-live playback.
Kerberos Agent supports multi-architecture builds targeting ARMv6, ARMv7, ARM64, and AMD64, making it suitable for devices ranging from Raspberry Pis and NVidia Jetsons to Intel NUCs and Kubernetes clusters. This versatility is a big plus for edge deployments where hardware diversity is the norm.
Security is baked in with end-to-end encryption: MQTT communication uses RSA/AES, and recordings are encrypted at rest with AES-256-CBC. Integration with external systems is possible through Webhooks, MQTT, and a REST API. For cloud storage, Kerberos Agent connects to its own Kerberos Hub and Vault backends, as well as Dropbox.
Under the hood, the Go codebase handles RTSP stream decoding, motion detection, encryption, and recording logic. The system keeps a low resource footprint, which is critical for edge devices with limited CPU and memory.
What makes Kerberos Agent’s design interesting
The single-agent-per-camera architecture is a deliberate design choice that shapes everything about the system. Instead of a centralized VMS managing all streams, each camera runs an independent agent. This offers natural horizontal scaling: when you add a new camera, you just deploy another agent instance.
This model isolates faults: if one camera or agent crashes, it doesn’t bring down the entire system. That’s a strong advantage in production environments where uptime matters.
The tradeoff is the overhead of running many agents. Each agent is lightweight, but at scale, resource management and orchestration become more complex. You need a robust way to deploy, monitor, and update potentially dozens or hundreds of independent processes or containers.
Code quality is solid for a system-level Go project. The repo uses idiomatic Go with a clear separation of concerns: streaming, detection, encryption, and storage modules are cleanly organized. The use of multi-architecture containers shows attention to real-world deployment constraints.
Kerberos Agent also balances features with minimal dependencies. The entire system is distributed as a single binary or container image, simplifying installation. The project supports both motion-triggered and continuous recording with configurable buffer sizes, which is practical for storage optimization.
However, the system doesn’t natively provide multi-agent coordination or a unified management UI beyond the individual agent’s web interface. This means that users running multiple cameras will need to build or integrate higher-level orchestration tooling or rely on Kerberos Hub for cloud management.
Quick start with Docker, Balena, and Snap
Getting Kerberos Agent running is straightforward thanks to official container images and packages. Here are the exact commands from the project README:
# Run with Docker (web interface on port 80)
docker run -p 80:80 --name mycamera -d --restart=always kerberos/agent:latest
# For USB or Raspberry Pi cameras using RTSP proxy sidecar
# Run container in host network mode
docker run --network=host --name mycamera -d --restart=always kerberos/agent:latest
# Install with Snap
snap install kerberosio
# Run the agent with Snap
sudo kerberosio.agent -action=run -port=80
The Docker images cover most deployment needs, from single-board computers to full Kubernetes clusters. Balena Cloud support adds fleet management, OTA updates, and encrypted HTTPS endpoints, which is useful for managing multiple agents remotely.
The Snap package is a convenient option for Linux users who prefer traditional package management.
Verdict: who should consider Kerberos Agent?
Kerberos Agent is well-suited for practitioners who need a lightweight, scalable video surveillance system at the edge, especially when hardware diversity and resource constraints are factors. Its single-agent-per-camera design is a solid pattern for fault isolation and horizontal scaling, although at scale it requires external orchestration tooling.
The Go implementation and multi-architecture support demonstrate real attention to deployment realities. The encryption features and integration options make it production-ready for secure environments.
On the downside, users looking for a turnkey multi-camera management UI or built-in orchestration will find the system limited. It’s more of a building block for custom surveillance solutions rather than a full-fledged VMS out of the box.
If you want a system that can run close to the camera, handle motion detection efficiently, and scale horizontally without a heavy centralized server, Kerberos Agent is worth checking out. Just be prepared to invest in your own orchestration and monitoring layer as your camera fleet grows.
→ GitHub Repo: kerberos-io/agent ⭐ 1,021 · Go