If you arrived here from the business version, you're in the right place. That piece mapped the three failure modes — concurrency, storage economics, and compliance — and what recording at scale costs a business. This is the companion "how": what each of those looks like at the architecture level, for the engineer who has to build or evaluate the pipeline. No re-run of the cost case — we go straight to the wiring.

An SFU forwards a stream to a hundred viewers without ever decoding it. A recorder cannot. That single asymmetry makes recording the most expensive workload in your video stack — and the architecture you pick for it sets your ceiling on concurrency, your storage bill, and whether the footage survives a regulator’s scrutiny.

This is the technical companion to the business overview. We go under the pipeline: the three recording architectures, how the recorder tier scales, how footage moves to and from storage, and how compliance is built into the pipeline rather than bolted on — using real API surfaces, because the trade-offs only surface at that level. Start with why recording is a different kind of work.

Why recording is a different workload than forwarding

A Selective Forwarding Unit is cheap because it never touches the media: it receives RTP from a producer and forwards it unmodified to each consumer — no decode, no composition, no re-encode. Adding a viewer costs bandwidth and almost no CPU.

Recording breaks that the moment you want one playable file of a multi-party session. A composed output means decoding each stream, laying them into a frame, and encoding the result — in real time, for the session’s duration. Real-time encode is recording’s cost floor, and unlike forwarding it does not amortize across sessions; every concurrent recording is its own decode-compose-encode pipeline. That is the fork, and it splits into three architectures.

Three recording architectures

Three ways to capture a session, differing in one thing that matters: how much media processing happens, and where.

Composited recording — the headless-client model

This is Jibri. An instance launches a headless Chrome, driven by Selenium, that joins as an ordinary participant, renders the layout a human would see, and encodes that window to one file. The output is excellent — clean, laid out, ready to play. The cost is structural: each recorder is a full browser doing real-time decode, layout, and encode of the whole session, and Jibri is single-use — one session per instance before recycling. Recording N sessions means roughly N instances: a browser-running fleet scaled and paid for apart from your media plane. The lighter path captures earlier in the stack.

Server-side track recording — raw RTP capture

Capture the media as raw RTP at the SFU, before anything renders it. In mediasoup: create a plain transport with router.createPlainTransport({ comedia: false, rtcpMux: false }), consume(producerId) each producer, and point the RTP at FFmpeg or GStreamer to write to disk. The defining property is that the media is never re-encoded — packets are stored essentially as-is, which is why this is far lighter than compositing. The trade: you get per-track, per-participant files, not a composed session, so composition becomes an offline job on your schedule, or is skipped if per-track playback is fine. There are edges — FFmpeg has no RTCP-mux, so you run explicit RTCP ports, and codecs pair to containers (VP8 to WebM, H.264 to MP4) — but one worker captures many concurrent sessions, because none pay the encode tax. The third option pushes capture all the way to the edge.

Client-side recording

Recording in the participant’s browser via MediaRecorder yields a Blob that uploads after the session, removing the server-side recorder — and every guarantee with it. It depends on the user’s device, CPU, and network, so a dropped connection or closed tab loses the footage. Fine for ephemeral use; unusable for anything you must prove happened, where you cannot anchor compliance to whether a device finished uploading. For regulated work the choice is between the two server-side models — and that choice is really about how you scale.

Scaling the recorder tier

Server-side recording is its own tier with its own scaling, and it does not scale like the media plane.

The single-use lifecycle and the recorder pool

Composited recording forces a pool: each recorder handles one session then recycles, so you keep a warm pool sized to peak concurrency, with a dispatcher assigning idle recorders. Pool exhaustion is a hard failure — no idle recorder, no recording, exactly when demand spiked. Sizing, warming, and recycling the pool is the operational core. Raw capture changes the shape.

Autoscaling recording independently of media

The recorder tier must autoscale on concurrent-recording demand, not call volume — the two diverge. Raw capture softens this: capture is cheap and encode is deferred, so a worker absorbs far more concurrent sessions before you add capacity, and composition runs as a batch queue you scale on backlog rather than in real time. You trade real-time provisioning for schedulable offline compute. Either way, encode is where the cost concentrates.

Encode as the bottleneck

For compositing, real-time H.264/VP8 encode of a composed frame is CPU-heavy, and GPU/NVENC acceleration is what separates a recorder holding a handful of sessions from one holding many. For raw capture there is no live encode, so the bottleneck shifts downstream — disk-write throughput during capture, batch encode during composition. Once capture is solved, the footage has to land somewhere durable.

The storage pipeline

A recording is done when it is durably stored, correctly tiered, and retrievable — three decisions, each with a cost.

Recorder to object store

The write path moves the file from local disk to object storage, usually via multipart upload so large files upload in parallel and resume on failure. Upload in segments during the recording or once on completion — segmenting shrinks the blast radius of a recorder crash but multiplies requests and complicates assembly. It is also the natural seam to compute an integrity hash, before the bytes leave your control.

Lifecycle tiering

Access is front-loaded — heavy in the days after capture, then almost never — and lifecycle rules automate the transitions: hot (S3 Standard, about $0.023/GB-month) for recent footage, an infrequent-access tier after weeks, cold archive (Glacier Deep Archive, about $0.00099/GB-month) for footage kept only to meet retention. The catch: cold tiers charge retrieval fees plus minimum-duration commitments, so aggressive archiving bets you will rarely retrieve — a bet compliance can force you to lose when an audit demands bulk footage back.

The retrieval and egress path

Playback and export run through short-lived signed URLs, ideally fronted by a CDN so repeat reads hit the edge, not the origin. Egress is the dominant variable cost — data out runs about $0.09/GB, roughly four times the hot-storage rate — and CDN fronting is the standard lever to cut it. Model retrieval as a first-class cost: a platform letting users pull their own recordings can spend more moving footage than storing it. And write, tier, and retrieve are each where compliance is enforced or lost.

Implementing compliance in the pipeline

Compliance is not a document attached to a recording — it is a set of pipeline properties, each mapping to a mechanism.

Tamper-evidence

Hash each file (SHA-256) at write time and store it separately in an append-only log; any later change alters the hash and is detectable. For a stronger guarantee, chain the hashes or sign the manifest so the log itself cannot be quietly rewritten. Pair with object immutability — WORM via object-lock in compliance mode with a retention period — so even an admin cannot overwrite or delete a locked object before retention expires. Hashing plus WORM is what turns a file into evidence.

Encryption in transit and at rest

Media is encrypted on the wire (SRTP to the SFU, TLS on upload and retrieval) and at rest (AES-256), with keys in a managed KMS. For regulated data the deciding question is who controls the keys — which sharpens when the storage is someone else’s infrastructure.

Access logging and retention automation

Every read is logged — who, when, which object — for the access trail an inspection expects. Lifecycle policies delete footage when its mandated period expires, with a legal-hold override for objects under investigation. DPDP lives here too: automated end-of-purpose deletion is not just cost hygiene, it is how you avoid holding personal data longer than the law allows.

Data residency at the architecture level

Residency is decided by where the object store physically sits. In cloud, pin buckets to a permitted region and confirm no replication, CDN edge, or backup crosses the border. On-premise, the question dissolves — storage is infrastructure the operator controls, in-jurisdiction, with no third party in the chain. For RBI-regulated vKYC, where recordings must stay in India, this often decides the architecture. And it is where build, buy, and embed truly diverge.

Build, buy, or embed — at the architecture level

The business version framed this strategically. Technically, it is a choice of which mechanisms above you own.

Buy a cloud recording API: composited recording as a managed service — no pool, no encode farm. In exchange, storage location, key control, and tamper-evidence are the vendor’s defaults, and egress plus per-minute are metered. Fine when residency is unconstrained and volume moderate; limiting when a regulator asks where footage lives and who could alter it.

Build on open source: Jibri gives you a composited single-use fleet; mediasoup’s plain-transport path gives you raw capture with deferred composition. Either way you also own — and implement — hashing, WORM, access logging, retention, and residency. Maximum control, correct when a buyer demands you own every link, but a standing engineering commitment.

Embed self-hosted infrastructure: the category Samvyo occupies. Based on SFU architecture, the raw-RTP capture path — cheap concurrent capture, deferred composition — is available at the architecture level, no browser-recorder fleet required. Deployed on-premise, the object store sits inside infrastructure the operator controls, making residency and retention control properties of the deployment and licensing flat rather than metered. The compliance mechanisms above — tamper-evidence, WORM, hash-chained audit logs — are patterns this self-hosted model lets you implement in your own environment; which ship built-in versus are integrated per deployment is worth confirming directly. And the boundary holds: for a low-volume, low-compliance product, self-hosting is over-engineering — a managed API is simpler and cheaper. It earns its complexity when concurrency is high, retention long, and residency non-negotiable.

Recording is the hardest part of video infrastructure because it is the one workload where media processing, storage economics, and cryptographic compliance are solved in the same pipeline — and the architecture you pick decides which you own and which you inherit.

This is the recording-specific view of a larger decision. For the full build-vs-buy-vs-embed analysis across the whole video stack, see link.

For the cost and compliance overview aimed at decision-makers, see the business companion: link to the business version.

Frequently Asked Questions

How do you record video without re-encoding it?

Capture the media as raw RTP at the SFU before it is rendered. In mediasoup, a plain transport (createPlainTransport with comedia: false, rtcpMux: false) consumes each producer and forwards RTP to FFmpeg or GStreamer, which writes it essentially as-is. With no real-time encode, this is far lighter than compositing and lets one worker capture many concurrent sessions — the model available in self-hosted, SFU-based infrastructure such as Samvyo.

Why can’t a single server record unlimited sessions?

In the composited model, each recording is a full real-time decode-compose-encode pipeline, and recorders like Jibri are single-use — one session per instance — so concurrency scales linearly with machines. Raw-track capture avoids the live encode and defers composition, raising per-worker concurrency, but the encode cost does not vanish — it moves to an offline farm you schedule.

How do you make a video recording tamper-evident?

Hash each file (SHA-256) at write time into an append-only — ideally hash-chained or signed — log, so any later change is detectable. Combine with WORM storage — object-lock in compliance mode with a retention period — so the object cannot be overwritten or deleted before retention expires. Hashing proves integrity; WORM enforces immutability.

How do you guarantee data residency for recordings?

In cloud, pin the object store to a permitted region and confirm no replication, CDN, or backup crosses the border. On-premise, the question largely dissolves — storage sits inside infrastructure the operator controls, in-jurisdiction — one reason RBI-regulated workloads, which require vKYC recordings to stay in India, often favor self-hosted infrastructure like Samvyo where residency is a property of the deployment.

Composited versus raw-track recording — which should I use?

Composited when you need a single laid-out file immediately and concurrency is modest — you pay real-time encode per session for a ready-to-play output. Raw-track when concurrency is high and you can compose offline or accept per-track files — cheap capture now, heavy encode deferred to a batch queue. The decision is where to spend the encode cost: in real time, or later.

Subscribe to VidBlogs