Single site and distributed processing
A small deployment can place the required components on a site server if resources allow. The reference distributed design separates a master node from compute nodes. Select the topology using source count, model workload, storage, network and operating requirements.
Deployment package
Use the approved installation directory, domain configuration, environment files and container definitions supplied for the release. Image names, registries, credentials and private addresses come from the delivery package. Public documentation does not invent replacement download locations.
Infrastructure preparation
- Confirm the supported host OS, Docker/runtime and GPU drivers.
- Check source access, network routes, DNS and time synchronisation.
- Prepare metadata and media volumes, capacity and permissions.
- Set certificates and protected credentials.
- Record enabled domains and service versions.
Bring up and verify
Check dependencies and service health, then validate camera acquisition, inference, Kafka delivery, event storage and operator access. A running container is not an end-to-end acceptance result.
Additional modules
Archive, WebRTC, offline/body-worn video, specialised sources and integrations may add domains, ports, storage or processing needs. Confirm compatibility and resources before enabling them.
Operations and rollback
Prepare monitoring, backups, restore validation and a release manifest. Retain the previous package and assess database migration compatibility before using rollback procedures.
One central cluster or a cluster at each site
The reference model inside each BOX 3.x environment is one master node and 1…N compute nodes in Docker Swarm. Compute scales horizontally; master-node and storage redundancy must be specified separately. Choose the cross-site topology using autonomy, latency, bandwidth, retention, consolidated reporting and support requirements.
| Criterion | One shared cluster | A cluster at each site |
|---|---|---|
| Management | One interface, configuration and reference-data set | Local management; rules and settings need synchronization |
| Cross-site network | Critical for transporting streams and continued central processing | Core video analytics runs locally when the external link is lost |
| Failure scope | Resources can be redistributed within the shared cluster | A site failure does not stop the other site clusters |
| Data and reports | A common event store and analytics | Consolidated reporting needs an aggregation layer or BI |
| Maintenance | Fewer environments to update | More versions and monitoring points |
| Typical reason to choose | Reliable high-capacity links and a central operating team | Site autonomy and limited connectivity |
Local processing still depends on local camera access and local services. Verify the promised functions during an external disconnect and the recovery path afterward. Early deployment sizing figures are not universal: measure the actual camera/model/runtime workload.