If you arrived here from the business version, you’re in the right place. That piece mapped the three tiers — meeting tools, embeddable video APIs, self-hosted infrastructure — and how to tell which one your use case needs. This is the companion “how”: what each tier actually is at the architecture level, for the engineer who has to build or evaluate it. No re-run of the business case — we go straight to the wiring.
“We’ve outgrown Zoom” is a product statement. “We need to embed video, keep the data in-region, and stop paying per minute” is an enterprise video architecture statement — and the two rarely get translated cleanly between the boardroom and the engineering channel. That translation gap is exactly where bad build-versus-buy decisions get made. So this piece translates: it walks the architecture behind each of the three tiers — what runs, where the media flows, and what you own at each layer — so the technical decision actually matches the business one.
The Three Tiers as Three Enterprise Video Architectures
The business version described the tiers by what they’re for. Underneath, they’re three different enterprise video architectures that differ in one variable: how much of the media path you control, and where the packets physically go.
Meeting tools. A finished SaaS application in front of a closed media backend you never touch. You get an iframe or a client SDK; the servers, routing, and recording are entirely the vendor’s.
Embeddable video APIs. A client SDK in front of the vendor’s cloud SFU. You write against rooms, tracks, and participants; the media still routes through their infrastructure, and you pay per participant-minute.
Self-hosted infrastructure. You run the media server, signaling, TURN, and recording yourself — or a vendor deploys their stack into infrastructure you control. You own the media path and the data end to end.
Here’s the whole comparison in one view. The rest of this piece expands each row — because each row is a decision, and they’re usually made separately when they should be made together.
| Dimension | Meeting tools | Cloud video API | Self-hosted / managed |
|---|---|---|---|
| Who owns the media path | Vendor | Vendor | You |
| UI / white-label | Skin only | Full UI, vendor media | Full, top to bottom |
| Data residency | Vendor's regions | Vendor's regions | Your region or on-prem |
| Cost model | Per seat | Per minute | Flat license |
| Recording location | Vendor cloud | Vendor cloud | Storage you control |
The first fork most teams hit is embedding — putting video inside their own product — so start there.
What “Embed Video in Your Product” Actually Means
“Embedding video” isn’t one thing. It’s a spectrum from “their UI in your page” to “your entire stack on your servers,” and there are three rungs on that ladder.
Meeting SDK / iframe embed. You drop the vendor’s meeting experience into your app — Zoom’s Meeting SDK is the canonical example. Fast to ship, but it’s their interface in an iframe or webview, restyling is limited, and the media backend is entirely theirs.
Client Video SDK. You get camera, microphone, and track primitives and build your own UI on top — Zoom’s Video SDK, Agora, Daily. Full control of the interface; the media still routes through the vendor’s SFU cloud; billing is per participant-minute.
Own the infrastructure. You run the SFU and signaling yourself, so you control the UI, the media path, and the data. Maximum control, maximum operational surface.
The point is that where you land on this ladder sets three things at once — white-label depth, data residency, and cost model — because they’re not independent knobs; they’re consequences of the same architectural choice. And past the shallow end, you’re now responsible for, or renting, the component that makes multi-party video work at all: the SFU.
The SFU: What Running Video Actually Requires
Any video beyond a couple of participants needs a media server, and it helps to know why. Peer-to-peer mesh has every participant send a copy to every other, so it collapses past a handful. An MCU decodes and re-encodes everything into one mixed stream — CPU-heavy and higher latency. An SFU (Selective Forwarding Unit) receives one upstream copy per participant and selectively forwards packets to the others without re-encoding: low latency, far lighter, and the standard for real-time video. mediasoup, LiveKit, and Janus are SFUs.
Which is why “self-host video” sounds like installing an app but isn’t. A production deployment is an SFU (usually clustered), a signaling server, STUN/TURN for NAT traversal, a recording pipeline, and the load balancing and geo-distribution to scale them. You’re not running a program; you’re operating a distributed real-time system. That operational weight is the real cost of the self-hosted tier — and the reason the managed-deployment option exists, which we’ll get to.
The SFU is also where a business requirement quietly becomes a technical one: white-label.
White-Label, Layer by Layer
“Your brand, not theirs” means different things at different layers, and buyers routinely conflate two of them.
At the meeting-embed layer, you can change logos and colours, but the interaction model and any “powered by” surface stay the vendor’s. Shallow branding.
At the Video SDK layer, you build the whole interface, so branding is complete at the pixel level — but the media still traverses the vendor’s cloud, so white-label stops at the interface and doesn’t reach the data.
At the self-hosted layer, it goes all the way down: your UI, your domain, your media servers, no upstream trace anywhere in the path.
So white-label has two dimensions people merge into one: interface branding, which a Video SDK gives you, and infrastructure ownership, which only the self-hosted layer gives you. Regulated and OEM buyers almost always mean the second — which points straight at the thing that most often forces a team down to the infrastructure layer: where the data physically lives.
Deployment and Data Residency: Where the Media Actually Goes
Sort the architectures by data path and the residency picture becomes concrete.
Vendor cloud. Meeting tools and cloud APIs route media through the vendor’s SFUs, frequently in US regions. You don’t choose the jurisdiction, and often can’t prove it to an auditor.
Managed cloud (dedicated). The platform’s stack deployed into a cloud region you specify — AWS, DigitalOcean, or Hetzner, for instance — as a dedicated deployment rather than multi-tenant infrastructure. Media stays in-region and in an environment you control, without you running the hardware. This is the middle path, and it’s where a platform like Samvyo’s managed deployment sits: its stack, your chosen cloud and region, flat-licensed.
On-premise. Media never leaves your own data centre. Maximum control and the strongest residency story; you run the metal.
One honest caveat, the same one the business version makes: choosing the region or going on-prem controls jurisdiction and residency — it does not by itself make you HIPAA- or GDPR-compliant. Those are controls programs regardless of where the SFU runs. What deployment choice changes is whether you can answer “where does the media live, and under whose law” — and a managed dedicated deployment gets you most of that answer without the burden of running the hardware yourself. Residency also reshapes the component nobody budgets for: recording.
Compliant Recording Architecture
Where recording happens matters as much as whether it happens.
Vendor-cloud recording. Recordings are captured and stored in the vendor’s cloud; you inherit their region, retention, and access model. Fine until a compliance officer asks where exactly a given recording lives and who accessed it.
Server-side recording in your deployment. The SFU or a dedicated egress service captures streams into storage you control, with your encryption, retention, and audit trail. This is what regulated records — video KYC, telehealth — generally require.
And recording is never free: it’s a separate service, compute-heavy (often a headless browser or an egress pipeline per session) and storage-heavy. Whether it runs in the vendor’s cloud or your own deployment decides who can actually answer the auditor. Put the layers together — embed depth, the SFU, white-label, residency, recording — and the build-versus-buy question stops being philosophical.
Build, Buy, or Deploy: Choosing an Enterprise Video Architecture
Build on open source. mediasoup, LiveKit, or Janus, assembled and operated by you — SFU, signaling, TURN, recording, scaling. Total control, total operational ownership. Right when video is core to the product and you have the specialists.
Buy a cloud API. Agora, Daily, or Zoom’s Video SDK: an SDK in front of their cloud SFU, billed per minute. Fastest to production, least control over media path and residency. Right when speed outweighs ownership.
Deploy a commercial platform. The whole stack — SFU, signaling, TURN, recording, white-label — delivered as a deployable unit you run on-premise or as a managed cloud deployment on AWS, DigitalOcean, or Hetzner, flat-licensed. Samvyo is one such option. It’s the middle path: infrastructure ownership and residency without assembling the stack yourself. Where it doesn’t fit: if you only need a call button, or vendor-cloud routing is acceptable, this is more than the problem requires.
Three approaches, one underlying axis — how much of the media path you want to own.
The Bottom Line
The three tiers aren’t three products; they’re three architectures separated by a single variable — how much of the media path you own. Meeting tools own all of it and hand you a window. Cloud APIs own the media and hand you an SDK. The self-hosted tier, whether on-premise or a managed cloud deployment, hands you the whole stack and the data. Match the enterprise video architecture to the actual requirement — embed depth, brand, residency, cost — and the decision stops being a build-versus-buy religious war and becomes a specification.
What’s Next?
Want the decision-maker’s version — which tier to pick and what each costs, without the wiring? The companion business piece frames the same three tiers as a buying decision you can forward to a non-engineer stakeholder: link to business version.
Frequently Asked Questions
What’s the difference between Zoom’s Meeting SDK and Video SDK?
The Meeting SDK embeds Zoom’s existing meeting interface inside your app. The Video SDK gives you raw media and track primitives to build a fully custom UI on Zoom’s media stack, billed per participant-minute. One skins a meeting; the other is building blocks for your own product.
What is an SFU, and do I need one?
An SFU (Selective Forwarding Unit) is a media server that forwards one upstream copy of each participant’s stream to the others without re-encoding. Any multi-party video beyond a few participants needs one — either the vendor’s SFU (with a cloud API) or one you run (self-hosted).
Can you self-host video in the cloud, or only on-premise?
Both. “Self-hosted” means a dedicated deployment you control — that can be on-premise in your own data centre, or a managed deployment in a cloud region you choose, such as AWS, DigitalOcean, or Hetzner. What separates it from a cloud API is that it’s dedicated and flat-licensed rather than multi-tenant and per-minute.
Does self-hosting make me HIPAA or GDPR compliant?
No. Self-hosting controls where data physically lives — jurisdiction and residency — which is often a requirement. But compliance itself is a program of controls (access, encryption, audit, retention) that applies regardless of where the media servers run.
Where are recordings stored in embedded video?
It depends on the architecture. With a cloud API, recordings live in the vendor’s cloud and region. With a self-hosted or managed deployment, they’re captured into storage you control, with your own retention and audit trail. For regulated records, the latter is usually required.
What does white-label actually mean, technically?
Two separate layers that buyers often merge: interface branding — your own UI, achievable with a Video SDK — and infrastructure ownership — your media servers and domain with no upstream trace, achievable only at the self-hosted or managed-deployment layer. Enterprise and OEM buyers usually mean both.
