How it works
Sites stand alone. Head office sees them together.
Each site records and analyses its own cameras and keeps its own footage. Sites dial out to the hub over TLS, so no site needs an inbound port. The hub holds the sites’ events, incidents, tracks, thumbnails and health in one store, and asks a site for footage only when someone opens it.
An example estate
The same software at every size
A 150-camera warehouse on five nodes, and a plant and a branch on one node each, all uplinking to one hub.
150 cameras
A warehouse on five nodes: one core, one analysis, three edge
40 cameras
A plant on one all-in-one node
8 cameras
A branch on one all-in-one node
Sites and the hub
Meaning travels up the line, footage stays put
Hubs above hubs
A regional hub can uplink to a national one, so consolidation follows the way the organisation is run rather than the way the network happens to be wired.
Nothing lost on a bad line
Each site’s uplink keeps a 30-day outbox that only moves on when the hub acknowledges. A WAN outage of days loses nothing, and the hub shows the site as stale, not missing.
Footage on demand
Clips and segments are fetched from the site that owns them, over the same uplink, when someone asks. The WAN carries events and metadata, not continuous video.
One view for head office
Management sees the sites at a glance, operators get live view and alerts, and investigators search across sites and keep what they find in cases.
Feeds the systems you run
Video walls and other VMS pull RTSP from Rutba Vision instead of from the cameras. Incidents open tickets over signed webhooks, and building systems get doors, lights and alarms over MQTT.
Footage where it was recorded
Unless your policy says otherwise, recorded video never leaves the site that recorded it. The hub keeps the index and every site’s health, and runs the search.
Inside a site
One pull per camera, three roles
One machine can take all three roles, or a site can spread them over several. Nothing changes but the node count.
Edge nodes hold the cameras
The relay keeps the only connection to each camera stream and fans it out to the recorder, live view, detection and RTSP out. Each edge node’s storage guard enforces its own retention.
Analysis nodes do the heavy work
AI enrichment and codec conversion run here, and you add analysis nodes as the analytics grow.
The core node turns detections into meaning
It runs the Vision Bus, the index, the API and console, the rules that make events and incidents, and the coordinator that assigns cameras to nodes.
Recording
Recording never decodes
The recorder copies the camera’s own stream into self-contained fMP4 segments and hashes each file with SHA-256 as it writes. There is no transcoding on the recording path, so recording costs packet handling, not a GPU.
Segments that play on their own
Each segment file plays by itself, the browser appends segments straight to its player, and an export is the segments joined together, with no re-encoding.
Crash-safe writes
Segments are written to a spool and renamed into place, so a crash never leaves half a segment in the catalogue.
Failover in seconds
The coordinator watches node heartbeats. A node silent for 15 seconds loses its cameras to the others and recording resumes there. Its earlier footage plays again when it returns.
Video takes the direct path
Live and recorded video reaches the browser through the API, which proxies the edge node that owns the camera. Only events and metadata ride the bus.
A fallback only where needed
If a browser cannot decode a camera’s H.265, the console asks for H.264 and a hardware transcode is added for that one viewer. Recording is untouched.
Recording is the floor
Detection, AI, indexing and distribution can all be down, and footage is still written, catalogued and kept.
Configuration
Validate, diff, apply
The file is checked against its schema and its cross-references, the diff shows what changes against the running revision, and apply publishes it to the cluster. Secrets never live in the file: it names environment variables, not passwords.
# vision.yml: the single source of truth
defaults:
user: vision # a viewing user, not admin
password_env: CAMERA_PASSWORD
record: { retain_days: 10 }
detect: { enabled: false }
cameras:
- id: gate_north
ip: 192.168.1.201
detect: { enabled: true }
ai: { enabled: true }
zones:
gate:
polygon: [[0.2, 0.55], [0.8, 0.55], [0.95, 1], [0.05, 1]]
record:
keep: # gate activity
- { zones: [gate], retain_days: 30 }
sub: { retain_days: 30 } # low-res history
- id: loading_bay
ip: 192.168.1.205
record: { audio: true }
- id: corridor
ip: 192.168.1.211 # records onlyThe ten components
Ten parts on one platform
Viewing
Live and recorded playback, the timeline and its activity, saved live views, PTZ, sound and snapshots.
Monitoring
Health of cameras, nodes, services, storage and clocks, retention enforcement, upkeep routines, alerts and metrics.
Detection
Per-camera motion, objects, tracking, zones, masks and filters. What is in the frame.
Aggregating
Rules over tracks in time and space, events, incidents and zone rollups. What it means.
Distribution
RTSP out, webhooks, MQTT, share links and the uplink to the hub.
Codec conversion
Hardware-aware transcoding for browsers that need it, and exports with evidence manifests.
AI analysis
Image embeddings, colour attributes and generated descriptions for the tracks that matter.
Indexing
One writer that turns the event stream into a day-partitioned, searchable store.
Tagging
Automatic and manual tags, cases and evidential holds.
Searching
Structured, keyword, semantic and similar-image search, asked in plain language, across sites.
Sized to the site, not to a box
Recording is cheap. Detection and AI are where the hardware goes, so a site’s node count follows its cameras, its retention and the analytics it runs.