You can record every session your platform runs and still fail the one moment that matters: when a regulator, insurer, or court asks for one specific clip — and proof it was never altered.
That is the gap in how recording gets scoped. On a feature list it is a checkbox; in production it is three problems that break at different scales, and most teams meet the second and third only after shipping the first. Here is what recording actually costs — in engineering, storage, and compliance — once you move past a handful of sessions, starting with the scoping mistake itself.
The recording problem nobody scopes upfront
Scope “recording” and most teams mean one thing: the video gets saved and plays back. That is the demo, and it works on day one with two people and a laptop.
But recording is not one capability. It is three, and they fail independently:
- Concurrency — can you record many sessions at once, or does each tie up a dedicated resource?
- Storage economics — what does it cost to hold footage as long as you are required to, and to get it back out?
- Compliance — can you prove where it lives, how long it is kept, who accessed it, and that it was never altered?
A platform can nail the first, ignore the second, and get destroyed by the third — each breaks at a different point on the growth curve, which is why they are so easy to miss. Take them in the order you will hit them: concurrency first.
Why recording breaks before live streaming does
Your live streaming can run flawlessly while recording quietly fails, because they do not scale the same way. An SFU is cheap: it forwards one stream to many viewers without re-processing it, so the hundredth viewer costs almost nothing. Recording is the opposite — producing one clean file means decoding streams, composing a layout, and encoding output, work that does not get cheaper as sessions grow. Every concurrent recording is its own workload on a far heavier curve than live. And on open-source stacks, that curve hits a hard wall.
The one-recorder-per-session wall
Jibri, the recorder most commonly paired with Jitsi, runs single-use: each instance handles one recording at a time, then recycles. Fine for one meeting; a real problem for a platform. Recording 50 sessions at once means roughly 50 recorder instances standing by, each a full machine running a headless browser. Recording capacity becomes a server fleet you provision and pay for, separate from the calls themselves — a line item, not a feature. Which is why client-side recording looks like the escape hatch.
Server-side versus client-side recording
The tempting shortcut is to record in the participant’s browser and upload afterward, removing the server-side recorder entirely. It also removes your guarantees: client-side recording depends on the user’s device, network, and battery, so a dropped connection loses the footage. Fine for casual use. But for anything you must prove happened — a KYC session, a fleet incident, a monitored site — you cannot stake compliance on whether a phone finished uploading. Which turns the question from architecture into money.
The storage math nobody runs
Recording is the one part of video infrastructure whose cost never stops growing: live sessions end, recordings accumulate, and the bill lands months after the decision that caused it.
Start with a real number. A ten-minute video KYC session runs roughly 500 MB to 1 GB; call it 1 GB. Record 10,000 of them a month and you add 10 TB monthly. At about $0.023 per GB-month, month one costs roughly $230 to store — trivial. But you are not storing one month; you are storing every prior month you are required to keep. By month twelve you hold 120 TB at about $2,700 a month and climbing, for footage nobody has opened since it was recorded. Storage grows every month because retention forbids deleting the old while you keep adding new.
| Storage driver | Figure |
|---|---|
| Session size (10-min vKYC) | ~1 GB |
| Volume | 10,000 sessions / month |
| Added per month | ~10 TB |
| Month-1 storage cost | ~$230 |
| Month-12 (cumulative ~120 TB) | ~$2,700 / month and climbing |
And storing it is the cheap part.
The egress trap
Getting data back out costs far more than keeping it. Egress to the internet runs about $0.09/GB — nearly four times the storage rate per gigabyte — and teams miss it every time. Every audit pull, investigator handoff, or user download is billed, so a platform that lets users retrieve their own recordings can spend more on egress than on storage. Cold-archive tiers make storage nearly free but add retrieval fees and minimums, so the “cheap” tier turns expensive exactly when compliance forces you to produce footage. Every number here assumes you choose how long to keep it. In regulated markets, you do not.
The compliance trap
This is the part treated as an afterthought and the part carrying the real risk: recording for compliance is not about having the file, it is about standing behind it. Retention comes first, and it is set by whoever regulates your customer:
- Banking / video KYC (India): RBI requires vKYC recordings kept a minimum of five years, stored within India.
- Fleet telematics: AIS-140 mandates 90-day retention of tracking data — not video; fleet video retention is insurer- and investigation-driven, typically 30–90 days.
- Surveillance / CCTV: commonly 30–90 days, with banks often held to six months or more.
Retention also has a ceiling: India’s DPDP Act treats recorded video of people as personal data, so you should not keep it longer than the purpose justifies — long enough to satisfy the sector regulator, not so long you breach privacy law. Knowing how long, though, is only half the problem.
Chain of custody
The harder question: when you produce a recording as evidence, can you prove it is the original, untouched? A file in a bucket proves nothing on its own — anyone with access could replace it. To hold up in an inspection, dispute, or court, it needs tamper-evidence: a verifiable creation time, proof it has not changed, and a log of every access. This is what “we save the file” architectures skip, and what decides whether your archive is an asset or an unprovable liability. One question sits underneath it.
Where the recording lives decides jurisdiction
Physically, where does the footage sit? Location determines jurisdiction. RBI’s data-localization rule is explicit — vKYC recordings cannot reside on infrastructure outside permitted borders. Hand footage to a cloud region abroad, or a hosted platform whose storage location you cannot account for, and you may be non-compliant regardless of how good the rest is. For government, defence, and BFSI buyers, “where is the data” is often the first question and the one that ends deals. So before committing to any approach, check the short list.
What to evaluate before you commit
Build, buy, or embed, these questions separate a demo from a production system:
- Concurrency ceiling — how many simultaneous recordings, and what does more cost?
- Storage ownership — do you own it, and can you point to where footage lives?
- Egress terms — what does retrieval cost, routinely and in bulk?
- Tamper-evidence — can it prove originality and log access?
- Data residency — can footage be guaranteed to stay in-jurisdiction?
- Retention automation — is deletion enforced automatically or left manual?
The right answers depend on what you are building — and so does the right approach.
Where each approach fits
There is no universally correct way to record. Three paths, each winning for a different company.
Cloud recording APIs (per-minute plus storage) are the fastest route to a working feature, and at low-to-moderate volume without heavy compliance they are often right. They stop making sense at scale and under regulation: per-minute and egress costs compound, and you are trusting a third party’s storage location to satisfy your regulator.
DIY on open source (Jibri and similar) gives maximum control, zero licensing, and full ownership of where data sits — what some regulated buyers require. The honest cost is operational: you run and scale a recorder fleet and build tamper-evidence, retention, and residency yourself. Worth it with the engineering depth and a reason to own the stack; a larger commitment than it first looks otherwise.
Self-hosted / on-premise (flat licensing, your environment) is where Samvyo sits. It fits organizations for whom residency and retention control are non-negotiable — BFSI, government, defence, healthcare — because footage never leaves infrastructure you control, storage is a flat licence rather than a metered bill, and residency answers itself. It is genuinely not right for a low-volume product with no compliance pressure, where a cloud API is simpler and cheaper. Self-hosting earns its keep when volume is high, retention is long, and “where is the data” is a question you must answer with certainty.
Recording is the hardest part of video infrastructure because getting it right means solving concurrency, storage economics, and compliance at once — and the cost of getting it wrong shows up late, when the footage you need is missing, unaffordable to retrieve, or impossible to prove.
For the architecture behind each approach — how the recording pipeline works from capture to storage to compliance chain — see the technical companion: link to technical version.
Frequently Asked Questions
How much does video recording cost at scale?
Storage is cheap per gigabyte but compounds, because retention forbids deletion — 10,000 ten-minute sessions a month add roughly 10 TB monthly, so by month twelve you are storing 100+ TB continuously. The bigger surprise is egress: retrieval runs about four times the per-GB storage rate, so platforms that frequently produce recordings often spend more retrieving than storing. Flat-licensed self-hosted infrastructure like Samvyo removes per-minute and egress metering, which is why it tends to win at high volume and long retention.
How long must video KYC recordings be retained in India?
RBI requires video KYC (V-CIP) recordings kept a minimum of five years, stored within India. Because footage accumulates without deletion across that span, storage location and retention automation become core architectural decisions — one reason regulated institutions often choose self-hosted or on-premise recording, where residency and retention stay under their control.
What is chain of custody for video evidence?
It is the ability to prove a recording is the original, unaltered since creation, with a log of everyone who accessed it. A raw file in storage provides none of this; it needs tamper-evidence and access logging built into the pipeline. This is usually the missing piece in “we just save the file” setups, and what decides whether a recording holds up in an audit or court.
Can recorded video be tampered with?
A stored file can be replaced or edited by anyone with access unless the system is designed to prevent and detect it. Tamper-evidence — verifiable timestamps, integrity checks, access logs — is what makes footage usable as evidence. Platforms built for regulated use, including Samvyo’s on-premise deployments, treat this as part of the recording layer rather than an add-on.
On-premise or cloud recording — which is better?
Neither universally. Cloud APIs are faster and cheaper at low volume without heavy compliance. On-premise or self-hosted wins when residency is mandated, retention is long, and volume makes metered storage and egress compound — common in BFSI, government, healthcare, and defence. The deciding questions: where footage must legally reside, and how much you will record over how long.
