Same question, different address.
Every video analytics system has to run its models somewhere. That location shapes how quickly alerts arrive, how much bandwidth the site needs, where footage travels and what happens when the internet drops.
Edge video analytics process video on site: inside the camera, on an NVR or appliance, or on the monitoring workstation itself. Video stays local and only results or selected clips leave the building. Our guide on how object detection works on security cameras explains the models that typically run there.
Cloud video analytics send video, or frames from it, to remote servers for processing. That unlocks large models and central management, at the cost of bandwidth, a dependency on the connection and footage leaving the site.
Side-by-side comparison.
| Edge analytics | Cloud analytics | |
|---|---|---|
| Where models run | Camera, appliance or local workstation | Remote data center |
| Latency | Low; no round trip | Depends on upload and queueing |
| Bandwidth | Minimal; results only | Significant for continuous streams |
| Internet outage | Keeps working | Analysis stops or degrades |
| Footage leaving site | Little or none | Streams or frames by design |
| Model size | Limited by local hardware | Large models on demand |
| Updates and management | Per device unless centrally managed | Central, one place |
| Cost shape | Upfront hardware | Ongoing compute and storage |
The case for the edge.
Security alerts are time-sensitive, and a person at a gate does not wait for an upload. Edge detection answers immediately and keeps working when the site’s connection is poor, which is common at construction sites, yards, solar farms and rural facilities. It also keeps footage where it belongs. Many clients are uncomfortable with continuous video streaming to someone else’s servers, and many sites simply do not have the upstream bandwidth for it.
The limit is horsepower. Compact detectors that find people and vehicles run comfortably on local hardware. Large models that can read a scene and describe it in words are heavier and may need a GPU the site does not have.
The case for the cloud.
Cloud processing brings those heavier models within reach without buying hardware for every site. It centralizes updates and makes it easy to add capabilities. It fits well when a system needs occasional deep analysis rather than constant processing, and when the data sent is small and well protected.
The risk is sending everything. Continuous cloud streaming turns every quiet hour of footage into upload, storage and exposure. The smarter pattern is hybrid: detect at the edge, send only the frames that matter, and protect the transfer properly.
What “protect the transfer properly” means.
If frames leave the site, the connection they travel over deserves the same scrutiny as the door to the server room. Ask any vendor four questions. Is the connection encrypted, and does the client actually verify the server’s certificate and hostname, or will it quietly accept anything? Is every request authenticated with a credential that can be revoked per installation? Can the client prove its own identity too, with mutual TLS, when your security team requires it? And when the connection fails, does the system fall back to plain text or a different provider, or does it fail safely and tell the operator?
The right answers are yes, yes, yes and “fail safely.” A monitoring station that declares a scene clear because the cloud did not answer is worse than one with no cloud at all.
When to choose each.
Lean on the edge when…
- Bandwidth is limited or the connection is unreliable.
- Clients restrict footage leaving the site.
- Alerts must arrive with no round-trip delay.
- Detection of people and vehicles is the core need.
Lean on the cloud when…
- You need large models that local hardware cannot run.
- Analysis is occasional, event-driven and small in volume.
- You want central updates without touching each site.
- Transfers are encrypted and authenticated end to end.
Where Semaphor fits.
Semaphor takes the hybrid path, with the edge doing the constant work. It works from the monitoring screen on the monitoring station itself, and person and vehicle detection runs locally. Pixel-change checks, duplicate suppression and cooldowns also run on site. The preliminary alert publishes locally and immediately, so a slow connection never delays the guard.
The heavier step, a vision-language model that writes the scene report, can run locally on suitable hardware or on hosted inference. When it is hosted, Semaphor sends only selected event stills, never a raw video stream, over verified HTTPS with an authentication credential and optional mutual TLS. If the hosted review fails, the preliminary alert stays visible and the review is marked unavailable; nothing is declared safe. See security and privacy for the details.
Detection on site. Deep review only when an event earns it. Footage stays where you want it.
Want to see the split on your own layouts? Book a live demo on your own camera screens, or start a pilot with local or hosted review.
Frequently asked questions.
Does Semaphor stream my video to the cloud?
No. Detection runs locally. Only when hosted review is configured are selected event stills sent, encrypted and authenticated, for a scene report.
Can Semaphor run fully on site?
Yes. Detection is always local, and the vision-language model can also run locally on suitable hardware.
What is mutual TLS?
Both sides of the connection prove their identity with certificates, not just the server. The glossary covers it and related terms.