Multi-site camera monitoring is an architecture choice, not a dashboard choice.

It means watching, or having something watch on your behalf, the camera feeds at more than one physical location and routing the alerts that come out of those feeds to the right person at the right site at the right time. The two halves of that sentence are doing more work than they look. Most operators starting out treat it as a dashboard problem, the question of which screen they sit in front of. Almost every real failure mode in the field is the other half: the alert fired at site twelve, the property manager for site twelve was off-call that night, the alert went to the regional inbox, and nobody opened it until Monday. Multi-site camera monitoring is mostly a routing problem layered on top of an inference problem. Pick a stack that solves both and the dashboard takes care of itself.

Cloud-centralized VMS streams every camera feed from every site to a central server. Inference and recording happen in the cloud. Examples in the property-management price band include Verkada, Rhombus, Eagle Eye Networks. Bandwidth scales linearly with cameras: each site needs a continuous upload of every feed it owns. Remote NOC services put humans in front of the feeds. A monitoring company in a central command center watches a wall of monitors, dispatches when something happens. Cost scales linearly with sites and with operator count, and response time degrades as the operator-to-site ratio falls. Edge-distributed puts the inference at the property. A small box at each site (the model Cyrano ships) runs detection, tracking, and threat classification locally, and only the structured events leave the building. The three differ on where the bandwidth goes, where the inference compute lives, and what the per-camera cost curve looks like as you add sites. The dashboard layer sits on top of all three, but it is a thin layer.

Because every camera at every site has to push its feed somewhere, continuously, and that somewhere is rented infrastructure that bills per stream. A single 1080p H.264 feed at a moderate bitrate is around 2 Mbps continuous. A 16-camera property is a 32 Mbps sustained upload, which on a typical small-property internet plan saturates the link before you have run anything else. Cloud VMS vendors paper over this with constrained-resolution proxies, motion-only upload, and tiered storage, but the architectural reality remains that the feed leaves the building. Multiply by 30 sites and you have rented egress bandwidth, ingest infrastructure, and storage that scales linearly with the camera count, and you are paying a per-camera-per-month subscription fee that exists primarily to cover that infrastructure. There is no version of this architecture that costs less per camera at site fifty than at site one.

Because the only lever the operator has against cost is the operator-to-site ratio. A live monitoring company with one operator watching 50 sites has good response time. The same company growing into 500 sites either hires 9 more operators (so cost per site stays flat) or spreads the same 10 operators thinner (so each operator now watches 50 sites in rotation and the average attention any one site gets falls). Most companies do the second, and after the second 200 sites the response time on a real intrusion goes from minutes to tens of minutes. The economics of the model are bounded by the cost of the operator, which is the most expensive line item in security. Operators do not get cheaper as you scale; software does. This is the structural reason the model breaks at scale, not a dig at any specific NOC.

On a Cyrano-style edge-distributed deployment, the only thing that crosses the WAN at each site is the structured event payload and, in the case of a confirmed high-threat event, a 10-second clip. Structured events are JSON lines on the order of 600 to 1200 bytes each. A typical Class C multifamily property emits low double digits of events per camera per day. Ten clips per day at 720p, 10 seconds, H.264 is on the order of 30 megabytes total. Run the math at portfolio scale and a 30-property portfolio with 16 cameras per site uses roughly 100 megabytes per day of upstream bandwidth in normal operation. That is an email inbox, not a video stream. The contrast with cloud-centralized is roughly four orders of magnitude.

It lives in the cloud, but it is a thin layer. It receives the event stream from each site, joins it against the per-property metadata (which property, which camera, which zone, who is on call), and surfaces three views: a live event feed (what is happening across the portfolio right now), a per-property incident history, and a portfolio-level trend report (incident count by site, by category, by week). It does not stream video. When an operator wants to see the clip attached to an event, the dashboard fetches the 10-second clip from that site's local storage on demand. This is the inverse of the cloud VMS flow, where the dashboard is fed by a continuous video pipeline and events are an afterthought.

On any sane multi-site system, alerts route based on three things: which site fired the event, the on-call schedule for that site at the wall-clock moment the event fired, and the threat level the local inference assigned to it. Cyrano's alert router reads the on-call file for each property (a small JSON or CSV maintained per site) and emits an SMS, a phone call, or a queued email depending on the threat level. A LOW THREAT event during business hours queues to email. A HIGH THREAT event after midnight at a residential property phones the on-call manager directly. Mistakes happen at the boundaries: routing a 2 a.m. alert to a person who is not on call, or escalating a known false positive past the silencing rule. The honest description is that this routing is a per-property configuration problem, not a one-size-fits-all dashboard setting. Any vendor who tells you otherwise has not run a 30-property portfolio.

This is the normal state of any multifamily portfolio that grew through acquisitions. Cloud VMS vendors handle it badly because their pricing assumes camera replacement; the per-camera price they quote includes the new hardware. Remote NOC services handle it adequately because the operator does not care which camera the feed came from. Edge-distributed handles it well, by design, because the Cyrano box plugs into the HDMI output of whatever DVR or NVR is already in the closet at each site. The brand and vintage of the cameras stop mattering at the HDMI boundary. This is the single largest practical reason a property manager picks the edge-distributed architecture over a cloud VMS: the cloud VMS pricing assumes you are willing to rip out hardware that is two years old and works fine. The edge-distributed architecture does not.

On a cloud-centralized stack, no. The site is dark until the link comes back. On a remote NOC stack, no. The operator cannot watch what they cannot stream. On an edge-distributed stack, yes, partly. Detection, tracking, and threat classification all keep running locally on the Cyrano box because the inference is local. Recording continues to disk. Alerts queue to a local outbox file and replay in order when the link comes back. The dashboard misses the events for the duration of the outage, but the events are not lost. This is not a marketing claim, it is a consequence of where the inference physically runs. If your portfolio has rural sites or sites with flaky cell-modem WAN links, this property is not optional.

For the price band this guide is written for (property management, 5 to 50 sites), yes. The alternative is to backhaul every feed to a central inference server, which puts you back into the cloud-centralized architecture and its bandwidth bill. The Cyrano box at each site is a one-time $450 hardware cost that handles up to 25 feeds. For a 16-camera property the per-feed amortized hardware cost is $28. The site needs to be capable of running the box (power, ethernet to the network, HDMI cable to the DVR/NVR) and that is the entire site-side install. Installation runs under 30 minutes on every property we have shipped to. The box is the architectural unit, not a dependency you can engineer out without giving up the bandwidth and offline-resilience properties that motivated picking this architecture in the first place.

Live remote video monitoring services work well at small to moderate scale and they have a real role at higher-risk sites where a human in the loop is genuinely needed. The honest comparison is that they answer a different question. They answer 'who watches the feeds tonight,' and the answer is 'one of our operators.' Edge-distributed answers 'what watches the feeds tonight,' and the answer is 'the box at the site, by itself, all night, every night.' The two are stackable: a few of our customers run the Cyrano box for first-line filtering and overnight detection at every site, then route a small filtered subset of HIGH THREAT events to a NOC service for human verification before dispatch. That hybrid is cheaper than either alone at scale, because the NOC operator only spends time on already-filtered events.

It is not a single big-bang deployment. The teams that pick edge-distributed do it one site at a time. A typical rollout: pick three pilot sites, install the box at each (under 30 minutes per site), wire the on-call schedule, run for two to four weeks, look at the event log and the alerts that fired, tune the zone polygons and dwell thresholds at each site to match how the property actually operates, then scale to the rest. The reason for the staged rollout is not the technology, it is the per-property tuning. Every site has its own quirks (a delivery driver that arrives at 4 a.m., a maintenance van that parks in the lot every Wednesday, a stretch of fence that gets touched by tree branches in the wind), and the alert quality at site twelve is a function of how long that site has been running. The staged rollout lets the early sites educate the configuration of the later ones.