Kerberos Agent: an MIT licensed surveillance agent that runs on a Pi, a NUC or a cluster

What the agent is, and why the licence changed

Kerberos Agent is described as an isolated and scalable video surveillance management agent, made available as open source under the MIT License. The project description is the video surveillance system for anyone making this world a better and more peaceful place, and the homepage is kerberos.io with the documentation at doc.kerberos.io.

The licence paragraph is the most consequential thing in the README, and the point it makes is about history rather than about the present. All the source code is available for you or your company, and you can use, transform and distribute it as long as you keep a reference of the original licence. And Kerberos Agent can be used for commercial usage, which was not the case for v2.

That sentence is a direct answer to a common objection about open source components of commercial surveillance products. The v2 licensing restricted commercial use of the agent, and that restriction is gone. The MIT licence means you can embed the agent in a product you sell, which is a materially different proposition from the previous terms.

The scope is also stated in a way that is worth heeding. The repository discusses one of the components of the Kerberos.io stack, the Kerberos Agent, in depth, and if you are looking for an end to end deployment guide there is a link to a separate deployment repository. So this is the agent, not the whole product, and the distinction matters when you plan an installation.

The primary language is Go, and the repository layout matches the two halves of the project. There is a machinery/ directory, which is the Go service and which is published as a Go module on pkg.go.dev, and a ui/ directory for the front end, which is built separately with its own workflow. The ui directory plus a React workflow badge tells you the interface is a React application, and the CodeQL workflow badge tells you the project runs CodeQL analysis over the code.

The repository is not archived, the last push was on 2026-10-10, and the recent releases are v3.12.9 on 2026-10-10, v3.12.8 on 2026-10-08 and v3.12.7 on 2026-10-02, so this is a project shipping patch releases weekly.

The prerequisites, and the question of whether your camera will work

Two prerequisites are listed, and the second one is unusually broad.

The first is an IP camera which supports an RTSP H264 or H265 encoded stream. The alternative is a USB camera, a Raspberry Pi camera or other camera that you can transform into a valid RTSP H264 or H265 stream, with a link to a separate camera-to-rtsp project for that purpose. So a non RTSP camera is not a dead end, but it is a conversion rather than a direct connection, and the conversion is a separate container or program you have to run.

The second is any hardware that can run a binary or a container, and the list given is ARMv6, ARMv7, ARM64 and AMD64, with the examples being a Raspberry Pi, an Nvidia Jetson, an Intel NUC, a VM, a bare metal machine or a full blown Kubernetes cluster. That range is the scalability claim in concrete terms. The same agent artefact runs from a Pi Zero class board to a Kubernetes deployment, and the Docker image is multi architecture, which is why the build script has per-architecture build tag logic.

The third prerequisite is the one people forget. There is a section asking whether your camera is working, and it acknowledges that there are a myriad of cameras out there, USB, IP and others, and that it might be daunting to know whether Kerberos Agent will work for your camera. Because of that, the project maintains a list of all the camera models acknowledged by the community, in a GitHub issue, and invites people to add their own.

That is a much better approach than a compatibility matrix in the documentation, because camera firmware changes and the community list stays current. It is also a real admission that the agent does not work with every camera, and the honest framing of that is worth taking seriously before you commit to a deployment.

The codec matters too. There is a section on H264 versus H265 in the documentation outline, and the two are treated as different enough to deserve their own page, which is a hint that the choice affects the processing cost rather than just the file size.

Running it: Docker, Balena and Snap

Three quickstarts are offered, and the Docker one is a single command.

The easiest way to get a Kerberos Agent running is the public image on Docker Hub, and running the docker command opens the web interface of the agent on port 80:

docker run -p 80:80 --name mycamera -d --restart=always kerberos/agent:latest

The flags carry the usual production instincts. The name is set so the container is addressable, -d detaches, and --restart=always means the agent comes back after a reboot or a crash, which matters for a device that is supposed to be watching something.

The second Docker command handles the USB and Raspberry Pi camera case. You need the side car container, camera-to-rtsp, which proxies the camera to an RTSP stream, and in that case you configure the agent container to run in the host network so it can reach the sidecar directly:

docker run --network=host --name mycamera -d --restart=always kerberos/agent:latest

That is the mechanism that makes a USB camera work, and the reason it needs host networking is that the two containers have to find each other. The camera-to-rtsp project is a separate repository, and pulling it in means running two containers rather than one, which is worth knowing before you plan the deployment.

The Balena route is for fleets. The application on Balena Hub is called video-surveillance, and the description lists what it gives you: monitoring of your Kerberos Agent with seamless remote access, over the air updates, an encrypted public https endpoint, and creating your first or a fleet of Kerberos Agents. Balena is the managed IoT platform approach, where the device management is handled for you.

The Snap route is the shortest of the three:

snap install kerberosio

And the Snapcraft package is published as kerberosio.

So there are three deployment models, and they map onto three different operational situations: a single machine you administer yourself with Docker, a fleet of devices you manage centrally with Balena, and a Linux desktop or appliance with Snap. The rest of the documentation covers the running and automation material, including how to access the agent, how to configure and persist it with volume mounts, and how to configure it with environment variables.

The Dockerfile, and what the build tags reveal about the architecture

The Dockerfile is a multi stage build with the toolchain in one stage and a slim runtime in the other, and it is worth reading because the details encode decisions.

The base images are build arguments. The Go image is golang:1.25-trixie and the runtime is debian:trixie-slim, both with the Debian codename as a build argument so the base can be moved without editing the file. A VERSION argument defaults to 0.0.0, and the comment explains the mechanics that catch people out: arguments declared before the first FROM are not visible inside build stages, so VERSION is re-declared inside the build stage to make the value passed via --build-arg VERSION=... available below.

The build stage installs a specific dependency set, and reading it tells you what the agent actually links against. Beyond the usual git, build-essential, cmake, pkg-config and unzip, there is libgtk2.0-dev, which is a graphics toolkit dependency and tells you the machinery links a GUI library, and then the media stack: libavcodec-dev, libavutil-dev, libswscale-dev and libjpeg62-turbo-dev, which are the FFmpeg development libraries for codec and scaling work. libcurl4-openssl-dev and libssl-dev give TLS, and curl and ca-certificates give the download machinery.

So the agent decodes video in process through FFmpeg's libraries rather than shelling out to ffmpeg, and does its rendering against GTK. That is a real dependency footprint, and it is why the runtime image is debian-slim rather than something smaller, and why the Docker image is not as tiny as a static Go binary would be.

The build tags are the other interesting part. The build sets BUILD_TAGS to timetzdata,netgo,osusergo, which is a standard set for reproducible containers: embedding the timezone database so the container does not depend on the host's tzdata, the pure Go resolver so DNS is not tied to libc, and osusergo so the user lookup does not depend on cgo.

Then the case statement on TARGETARCH adds the moq tag for amd64 and arm64 only. moq is a mock generator, and the tag is presumably a build constraint that excludes mock code from the binary on those architectures. Which is a reminder that the build is doing something deliberate per architecture rather than just cross compiling.

The version is stamped into the binary with ldflags, setting the VERSION variable in the machinery's utils package, and the build also writes the resolved version to a file named version. The dependency caching is done properly, by copying the go.mod and go.sum first, running go mod download, and only then copying the source, so that a source change does not invalidate the module cache layer.

There is also a GOSUMDB=off environment variable in the build stage, which disables the checksum database lookup for module verification. In a build image that is sometimes set to work around a network restriction, and it is worth noting as a supply chain consideration, since it means the build trusts go.sum alone rather than cross-checking against the public checksum database.

The parts you have to find elsewhere, and the open questions

Some of the answers to the questions you will have are not in this repository, and knowing which ones are not is worth as much as knowing the ones that are.

The end to end deployment is elsewhere. The documentation outline in this repository covers running and automation, insights, and contributing, and the intro points you to a separate deployment repository for a full deployment guide. So if you are installing a complete Kerberos.io stack with its cloud side, that is a separate project and a separate set of decisions.

The camera compatibility list is elsewhere too, in a GitHub issue rather than in the documentation, and the encryption section is in the documentation outline but its content is not in this README. There is also a separate README-RTSPS-TLS.md file at the repository root, which suggests the RTSP over TLS configuration is documented separately because it is a distinct setup path from plain RTSP.

The contributing section is a good place to look for the project's own priorities. It lists security vulnerability reporting first, then contributing with Codespaces, develop and build, building from source, and building for Docker. The presence of a SECURITY.md at the root and a CodeQL workflow badge means the project takes the security side seriously, which for software that handles camera credentials and video streams is a reasonable expectation rather than a bonus.

The open question that the documentation does not answer, and that you will have to measure, is throughput. Nothing in the README states how many streams one agent handles, and the answer will depend on the codec, the resolution, the frame rate and the hardware. The FFmpeg based in-process decoding, the motion detection work and the web interface all compete for the same CPU, and the difference between an Intel NUC and a Raspberry Pi is exactly the kind of thing that has to be tested on your hardware rather than read from a table.

The second open question is the boundary between this repository and the rest of the stack. The topics list motiondetection and motiondetector, so the motion detection lives here, and the ipcamera topic says the camera handling lives here too. But the cloud side, the account management and the multi-tenant viewing experience are not in this repository, and that is where the licensing question for a commercial deployment really lives.

The last practical point is packaging. Docker Hub, Balena Hub and Snapcraft all carry the project, and the Snap is the easiest to try, so if you want to know whether the motion detection and the interface meet your needs, installing the Snap on a spare machine with a test camera is the lowest cost way to find out.

Editorial conclusion

Kerberos Agent fits a team that wants self hosted video surveillance with an open source core, can run an RTSP H264 or H265 camera or convert a USB camera into one, and wants the agent to run on cheap ARM hardware as easily as on a Kubernetes node. It is the wrong tool if you need a finished end to end product, since the documentation sends you to a separate deployment repository for that, and it is the wrong tool if you need commercial use terms that the MIT licence does not cover. Before deploying, work out how many streams one agent is expected to handle, since motion detection is CPU bound, and check the camera compatibility list, because the project asks you to check that your camera is already acknowledged before assuming it will work.

Frequently asked questions

Official sources

1. kerberos-io/agent on GitHub
2. License: MIT
3. Project website
4. README
5. Releases