Video Surveillance: Cloud vs Local Recording | Callaba
More live video workflow notes and product updates.
A remote video-monitoring system needs more than a camera URL. Operators need a stable contribution path, a browser wall that shows the approved feeds, a clear recording destination, access boundaries, and a recovery plan when one source becomes unavailable. This guide compares cloud and local recording within that streaming architecture.
This page owns the architecture and storage-choice procedure. Use the Callaba video-surveillance streaming solution to evaluate the complete product workflow. Callaba is positioned here as a live-video transport, Multiview, routing, recording, storage, access, and failover layer—not as a full video management system.
Start with an explicit capability boundary
Callaba can receive compatible live feeds, arrange approved sources in a browser Multiview, route and record them, attach storage, enforce product access settings, and keep a prepared recovery path. This is useful for remote facilities, venues, construction sites, campuses, industrial locations, and temporary monitoring operations.
Callaba does not claim camera fleet provisioning, ONVIF or PTZ control, motion or incident detection, forensic archive search, physical-access management, a white-label VMS, surveillance regulatory compliance, or a surveillance SLA. If the project requires those functions, keep the VMS, camera-control, security, and compliance systems as named components in the architecture.
Map each feed before deciding where to record
- Identify the camera, encoder, or gateway that provides each compatible live stream.
- Record protocol, addressing, codec, bitrate, frame rate, audio, expected availability, and who owns the source.
- Define who may view, configure, route, and record the feed. Separate operator access from a shareable playback surface.
- Choose whether the feed needs continuous recording, event-window recording, or live monitoring only.
- Document retention, deletion, export, and incident-handling responsibilities outside the streaming configuration.
Cloud recording versus local storage
| Decision area | Cloud or regional deployment | Local or customer-controlled deployment |
|---|---|---|
| Launch | Useful for a fast pilot and sources that already reach the chosen region. | Requires a compatible Linux host, storage, network rules, and operating owner. |
| Network path | Every recorded feed traverses the approved path to the cloud deployment. | The recorder can sit closer to site gateways, existing networks, or local storage. |
| Infrastructure ownership | The team operates the video workflow within the selected cloud service boundary. | The customer or integrator owns host security, capacity, updates, backup, and recovery. |
| Storage control | Attach the storage option selected for the cloud workflow and model transfer and retention costs. | Attach storage controlled by the organization and validate performance, redundancy, backup, and access. |
| Offline behaviour | Depends on continued connectivity between the site and cloud recorder. | Local recording may continue inside the site boundary, depending on the source and host design. |
Neither choice is automatically more secure, compliant, resilient, or inexpensive. Those outcomes depend on the complete design and operating process. Test one representative site at the expected bitrate and retention window, then measure bandwidth, storage growth, playback, recovery, and operator effort.
Build the operator wall around jobs, not camera numbers
Arrange Multiview tiles by site, zone, operational priority, or escalation plan. Use labels that an operator can interpret quickly. A wall with 20 unnamed feeds may technically render video but still fail as an operating surface.
Decide which users can open the management UI and which viewers receive a controlled browser playback surface. Do not expose management credentials or private stream identifiers in a public wall. Test access from a signed-out browser and from the actual operator network.
Keep live monitoring and recording independently diagnosable
A picture in Multiview proves that the operator can currently see the feed. It does not prove that storage is writing, retention is correct, or the file can be played. Monitor recording state and capacity separately, then test the resulting media at the interval required by the operating policy.
Likewise, a valid recording file does not prove that the live operator view is current. Keep input state, connection identity, bitrate, Multiview, recording state, and storage capacity as distinct checks.
Use failover only for a prepared source set
Where a critical view has a primary and backup source, configure both before relying on recovery. Test automatic detection and manual selection with the real feeds. Measure transition behaviour and confirm that the recording and operator wall follow the intended source. Do not describe a second URL as resilient until the failure test passes.
Security-integrator controlled deployment
An integrator can deploy Callaba on infrastructure selected by the customer, define the approved input and output network paths, attach customer-controlled storage, and provide the operator Multiview. This gives the project a controlled streaming and recording layer without pretending that Callaba owns the cameras, door systems, alarms, or VMS functions.
The handoff should state which organization owns the Linux host, updates, certificates, firewall, credentials, storage, backups, monitoring, and recovery. The integrator should also document how the customer revokes access and retrieves recordings at contract end.
API second layer: automate a proven recording path
After the UI workflow and retention process are accepted, use the operator Multiview recipe for repeatable wall configuration and the live capture-to-VOD recipe for the reviewed recording handoff. Automation must preserve access, retention, and rollback rules defined by the organization.
Pilot checklist for one remote site
- The source, protocol, bitrate, access owner, and network path are documented.
- The operator wall uses clear site and job labels.
- Management access and viewer access are tested separately.
- The chosen storage writes at the required rate and a resulting file plays back.
- Retention, deletion, export, and backup have named owners.
- Primary and backup source behaviour is tested where required.
- Every VMS, camera-control, security, and compliance dependency remains explicit.
CCTV cloud storage for multiple sites: size capacity before rollout
Start with the operating workflow, not a storage vendor. The Callaba video surveillance streaming solution owns the product decision: receive approved live feeds, place them in an operator Multiview, record the feeds required by policy, and choose cloud or self-hosted infrastructure. Storage sizing is one planning step inside that workflow.
Calculate a defensible storage baseline
For a constant-bitrate planning estimate, calculate each recording profile separately:
estimated GB = feeds × bitrate in Mbps × recorded hours per day × 0.45 × retention days
The factor 0.45 converts one megabit per second into decimal gigabytes per hour. Add the audio bitrate, container overhead, duplicate copies, temporary processing space, and the operating reserve selected by your infrastructure team. Variable-bitrate sources must be measured with representative motion, lighting, and scene complexity instead of being sized from a nominal encoder setting alone.
| Planning case | Inputs | Calculated media | What remains to add |
|---|---|---|---|
| Small seven-day pilot | 4 feeds × 2 Mbps × 24 hours × 7 days | About 605 GB | Audio, overhead, reserve, and any second copy |
| Twelve-feed continuous archive | 12 feeds × 4 Mbps × 24 hours × 30 days | About 15.6 TB | Growth, transfer staging, backup, and recovery space |
| Scheduled high-motion recording | 32 feeds × 6 Mbps × 12 hours × 30 days | About 31.1 TB | Measured bitrate variance and the organization’s safety margin |
These examples are arithmetic, not capacity promises. Use the Callaba bitrate calculator for an initial profile estimate, then run a representative feed long enough to measure actual file growth. Confirm usable capacity, write throughput, retrieval time, lifecycle rules, egress, backup, and failure recovery with the selected storage provider.
Roll out one site at a time
- Inventory the feed. Record the site owner, source protocol, approved resolution and bitrate, recording schedule, primary path, backup path, and who may view or export the media.
- Prove the live path. Keep the source visible in Callaba Multiview while checking transport health. A visible picture does not by itself prove that the archive is being written.
- Prove the recording path. Create a bounded test with Callaba Live Video Recording, stop or finalize it, and verify that the expected file can be opened and copied.
- Apply retention deliberately. Assign an owner for the retention rule, deletion approval, legal hold, restore test, and storage alarm. Do not infer those policies from the number of cameras.
- Repeat with the next site. Promote a site only after live monitoring, recording, access, restore, and rollback checks pass with its real network and source profile.
Separate operator access from archive access
The operator wall, recording configuration, retained files, and public or internal playback do not need the same audience. Give operators only the approved live views, restrict management and storage credentials to the responsible team, and use Callaba Video on Demand when retained media needs a controlled browser playback path. Document who can change a source, start or stop a recording, retrieve a file, or alter retention.
Rehearse rollback before adding every site
Keep the last accepted source and recording configuration, then test one controlled failure at a time: source disconnect, unavailable backup, stopped recording, full or unreachable storage, and failed file retrieval. The rollback decision should name the configuration to restore, the person authorized to restore it, and the evidence that proves live viewing and recording are healthy again. A successful Multiview check and a successful archive check are separate acceptance results.
Use the API only after the product workflow is accepted
Once operators can run and recover the workflow in the product, use the operator Multiview recipe to reproduce an approved wall, the recording-to-object-storage recipe to automate the reviewed capture and transfer sequence, and the object-storage registration recipe to register a reusable destination. Treat storage credentials as write-only operational secrets and verify transfer completion instead of assuming that an accepted request means a durable archive exists.
Remote video-monitoring architecture FAQ
Is Callaba a full VMS?
No. Callaba provides compatible live-video transport, Multiview, routing, recording, storage integration, access settings, playback, and failover. It does not claim camera fleet management, ONVIF/PTZ control, incident detection, forensic archive search, or physical-access functions.
Should remote feeds be recorded in the cloud or locally?
Choose from the network path, infrastructure ownership, storage and retention requirements, expected outages, and operating capacity. Test one representative site before selecting the wider model.
Can an integrator run Callaba on customer-controlled infrastructure?
Yes. Callaba can be deployed on compatible Linux infrastructure selected by the customer or integrator. The project must explicitly assign host, network, credential, storage, backup, and recovery responsibilities.
Does a live Multiview prove that recording is healthy?
No. The live view and recording are separate checks. Verify recording state, storage capacity, file creation, and playback independently from the live operator wall.
Can the workflow guarantee surveillance compliance?
No. Compliance depends on jurisdiction, organizational policy, system design, access, retention, security, and legal review. Callaba makes no generic surveillance-compliance claim.
