Short answer: Record in the building where the cameras are, and give operators one app that connects to every site. Sending live streams across a WAN to a central recorder costs more bandwidth than most links have, makes one outage take down every site, and moves footage away from the people who answer for it.
The two designs
Central recording. Every camera at every site streams across the WAN or VPN to one server at head office. One box to manage, one place to look.
One server per site. Each building has its own recorder on its own LAN. Operators use one client that connects to each server as needed. Footage stays put; only the pictures someone is actually watching cross the WAN.
Most multi-site deployments that start central end up per-site once the link bill arrives. Here is the arithmetic.
The bandwidth maths
A 1080p camera at a typical H.264 bitrate runs at about 4 Mbps, all day, whether anyone is watching or not. Recording is continuous, so the link load is continuous:
| Cameras per site | Continuous upload needed |
|---|---|
| 10 | 40 Mbps |
| 20 | 80 Mbps |
| 50 | 200 Mbps |
That is the upload from the branch, which on most business broadband is the small number. A site with 20 cameras on a 100/20 Mbps line cannot do central recording at all. Even on a leased line, 80 Mbps of video competes with everything else the branch does, 24 hours a day.
H.265 roughly halves this. Recording on motion only helps in quiet areas and does nothing at a busy entrance. Neither changes the conclusion.
Compare per-site recording: with nobody watching, WAN traffic from video is zero. When an operator at head office opens a 3×3 grid of a branch, the branch sends nine substreams of perhaps 0.5 Mbps each, so about 5 Mbps, and only while the grid is open. Playback of one camera is one stream.
Use the storage calculator to size each site’s disks; the same bitrate figures drive both sums.
Failure domains
With central recording, every link is a single point of failure for the site at the far end of it. A branch’s internet going down for an hour means an hour with no footage of that branch, which is exactly the hour someone will ask about. A failure at the central server, or a power cut at head office, stops recording everywhere.
With a server per site, a WAN outage means head office cannot watch the branch live for an hour. The branch keeps recording. When the link returns, the footage is there. A dead server affects one building.
Health monitoring should match: each site’s server checks its own cameras, and the central view shows which servers and cameras are up.
Who sees what
Multi-site brings the permissions question into focus. A branch manager should see their branch. A regional security lead sees their region. The head-office team sees everything, and auditors see playback and exports but cannot change cameras.
This is easier to get right when each site is its own server with its own user list, with roles tied to a directory group where one exists. It is harder on a central server where every camera lives in one tree and one mis-ticked box gives a branch manager the whole estate.
Why footage should stay where it was recorded
- Legal and policy. Data protection rules, works council agreements and customer contracts often say where footage may be stored. “In the building it was captured in” is the answer that satisfies nearly all of them.
- Chain of custody. When footage is requested for an incident, the people who answer for it are usually on site. Export from the site server, with an audit log entry, is a shorter chain than retrieving it from head office.
- Retention. Different sites may need different retention: 30 days at a warehouse, 90 at a cash office. Per-site servers make that a per-site setting.
- Decommissioning. When a site closes, its server and its footage can be handled under that site’s retention policy and wiped. On a central server, one site’s footage is interleaved with everyone else’s.
When central recording still makes sense
- Sites on the same campus, connected by fibre you own.
- Very small sites (two or three cameras) where a server is overkill and the link is comfortably larger than the camera load.
- A data centre design where the “central” server is in the same building as the cameras anyway.
Where Supervision fits
Supervision’s multi-site design is one server per site and one desktop app. Each server is a single Go binary with its own SQLite database, its own roles from owner to viewer, and its own audit log of camera changes, exports and user changes. The desktop app connects to every server you are allowed to see, pins each one’s certificate on first connect, and shows live grids over WebRTC with only the streams you are watching crossing the WAN. The layout is described on the enterprise page.
Supervision is self-hosted video management software for any camera brand. If this is the kind of problem you're solving, tell us about your cameras and we'll talk it through, or email hello@bipolarfactory.com.