Manage camera Agents on your own Kubernetes cluster

Understand the boundary between cameras and workloads

Factory creates a Kerberos Agent deployment, service, and configuration for each camera. Agent connects to the camera and handles live video, local recording, and forwarding. Factory operates the Agent fleet; it is not replacement camera firmware or a promise to manage every vendor-specific camera setting.

Your Kubernetes cluster supplies the compute and scheduling environment. Plan node capacity, camera-network reachability, storage access, and the resources each Agent needs. The number of cameras that fit on a node depends on stream settings, recording behavior, and hardware, so validate capacity with your own footage instead of relying on a universal camera-per-node figure.

Onboard cameras with RTSP or ONVIF

Add a camera using its RTSP stream, or discover supported cameras through ONVIF. Factory turns the camera configuration into an Agent workload rather than requiring operators to assemble a new deployment by hand for every device. Verify stream compatibility and credentials before repeating the process across a site.

Discovery and capture depend on the network path between the cluster and the cameras. Include representative subnets, firewalls, and credentials in the pilot. A Kubernetes workload being healthy does not, by itself, prove that the camera is reachable or that recordings are arriving at their destination.

Define shared settings and retain camera-specific overrides

Factory provides fleet-level settings for concerns such as timezone, MQTT, STUN/TURN, encryption, Hub, and Vault persistence. Agents inherit these settings, with overrides where an individual camera needs different behavior. This makes the common configuration explicit without pretending that every location has identical network or recording requirements.

Decide which values belong in the shared configuration and which belong to a camera before onboarding a large batch. Review the intended destination for recordings and events, and test the resulting Agent configuration against the systems it must reach.

Roll out versions and inspect the running fleet

Factory can apply an Agent version to an individual camera or the fleet; Agents already on that version are left untouched. Start a version change with representative cameras and confirm the behavior that matters to your operation before expanding it. Fleet-wide control is not a substitute for validating a new capture or forwarding configuration.

Operators can inspect logs, open a terminal, reboot an Agent, and adjust its memory limit from the camera list. Node and pod CPU and memory visibility comes through the Kubernetes metrics API. Ensure that the relevant cluster services are available if those resource views are part of your operational process.

Keep fleet management separate from storage and video operations

Factory manages the Agent workloads. Vault receives recordings and stores them in the object storage you choose. Hub brings live viewing, recording search, alerts, cases, and AI workflows into a shared workspace. Keeping those roles clear helps teams investigate whether a problem belongs to capture, workload scheduling, storage delivery, or processing.

A useful rollout checklist covers a disconnected camera, an interrupted uplink, an Agent restart, and a recording reaching its final destination. Document what operators should inspect at each step and measure capacity and recovery behavior on the actual deployment. Use the implementation documentation for setup details and the UUG.AI team for deployment planning.

Products and implementation resources

• Factory: Kubernetes camera fleet management
• Agent: the camera-facing service
• Vault: recording storage and delivery
• Hub: live viewing, search, and workflows
• Factory setup documentation
• Connecting RTSP cameras to AI workflows