Use the current Kerberos Agent container on ZimaOS, not the old archived kerberos/kerberos image. The current project uses kerberos/agent, supports AMD64 Docker, and is designed around one Agent instance per camera.
If recordings should live on a Synology NAS, first mount the Synology share reliably on ZimaOS, confirm the actual host mount path, then bind that path into the Agent recording directory. Do not point Kerberos at a network path that disappears whenever the NAS reconnects.
The Old Kerberos Docker Repository Is Archived
The original Kerberos Open Source Docker repository now points users to the new Kerberos Agent project repository.
Start with the Current Agent Image
docker run -p 8080:80 --name camera1 -d --restart=always kerberos/agent:latestUsing host port 8080 avoids taking over port 80 on the ZimaOS host.
Persist Configuration and Recordings
docker run -p 8080:80 --name camera1 -v /DATA/AppData/kerberos/camera1/config:/home/agent/data/config -v /DATA/AppData/kerberos/camera1/recordings:/home/agent/data/recordings -d --restart=always kerberos/agent:latestThe current Agent docs explicitly recommend persistent volumes for config and recordings.
One Agent per Camera
Kerberos Agent is architected as an isolated camera-processing instance. For multiple cameras, create separate containers with unique names, web ports, and persistent directories.
Use Synology as the Recording Destination Carefully
Mount the Synology SMB/NFS share in ZimaOS first, confirm it stays mounted after reboot, then inspect the actual host mount path with findmnt. Bind that stable host path to /home/agent/data/recordings.
Do Not Store Config Only on the Synology Share
Keeping Agent configuration local on ZimaOS and recordings on the Synology can make startup more resilient. If the Synology is temporarily unavailable, the Agent can still start and report the storage problem cleanly.
Change the Default Login
Current Kerberos Agent documentation still notes default credentials for a fresh Agent. Change them immediately before using the deployment beyond a local test.
Use RTSP for IP Cameras
Kerberos Agent expects an RTSP H264/H265 camera feed for normal IP-camera use. Verify the stream independently before blaming the container.
The custom Docker guide covers the general custom-app workflow.
Test the Synology Mount Before Recording
findmnt
touch /path/to/synology/test-write
rm /path/to/synology/test-writeConfirm the ZimaOS host can write to the mounted share with the intended permissions before mapping it into Kerberos Agent. A camera app cannot fix an SMB/NFS permission problem underneath it.
Plan for Synology Downtime
If the Synology reboots or the network share drops, Agent recordings can fail even though the camera stream remains healthy. Decide whether you want a small local recording buffer or whether missed recordings during NAS downtime are acceptable.
Watch Free Space and Retention
Video fills storage quickly. Set retention/auto-clean rules deliberately and monitor the Synology destination. Do not rely on an unlimited recording directory on a shared NAS volume.
FAQ
Which Kerberos image should I use now?
Use the current kerberos/agent image. The old kerberos/kerberos project is archived.
Can recordings live on Synology?
Yes, if the Synology share is mounted reliably on the ZimaOS host and that host path is bind-mounted into the Agent recordings directory.
Can one container manage many cameras?
The current Agent model is designed around one Agent instance per camera.
What port does the Agent UI use?
The container listens on port 80; map it to a free ZimaOS host port such as 8080.
