If you arrived here from the business version, you're in the right place. That piece mapped the three paths — build, buy, embed — and how to tell which one your product needs. This is the companion "how": what each path 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.

Every real-time video product, whoever built it, runs the same handful of components. Build, buy, or embed does not change that architecture — it changes who operates each layer. Understanding the layers is how you predict where each path breaks before you commit to it.

This is the technical companion to the business decision guide. Where that piece weighed speed, economics, and control, this one goes under them: the stack every path has to cover, what you assemble or inherit on each, and the coupling that decides how hard it is to leave. Start with the components themselves.

The stack every path has to cover

Real-time video is not one system; it is six, and every path has to account for each one:

  • Signaling — session setup, SDP negotiation, and presence, usually over WebSocket.
  • SFU / media server — the core that routes RTP between participants without re-encoding (mediasoup, LiveKit, Janus, ion-sfu).
  • STUN / TURN — NAT traversal, with TURN relaying media when peer-to-peer fails (coturn); bandwidth-heavy at scale.
  • Recording — composited or raw capture, with its own concurrency and storage profile.
  • Scaling and orchestration — load balancing, SFU cascading across instances and regions, autoscaling, health checks.
  • Client SDKs — the app-facing layer across web, iOS, and Android.

Build, buy, and embed are three answers to one question: who operates each of these rows? Start with the path where you operate all of them.

Build from open source

Building means you assemble the stack: an SFU like mediasoup or LiveKit at the core, a signaling service you write, coturn for TURN, a recording pipeline, an orchestration layer for scaling, and client SDKs (some open-source SFUs ship their own).

The components are available and well-documented, which makes the demo deceptively quick. The hard part is everything between demo and production. TURN is bandwidth-heavy and must be geo-distributed, so its cost and placement become their own problem. A single SFU caps at a finite participant count, so real concurrency needs cascading and load-balancing across instances and regions. Global p95 latency demands edge presence you have to build and operate. And every codec update, security patch, and scaling incident is yours. The last 20% — hardening, scaling, reliability — is 80% of the work, which is precisely the work a cloud API exists to absorb.

Buy a cloud video API

Buying means you integrate a vendor’s client SDK and a token service on your backend; they run the SFU, TURN, scaling, and edge. You get event webhooks and a bounded set of server-side controls.

Architecturally, the appeal is that five of the six layers become someone else’s operational problem. The constraints are the flip side of that convenience. Media transits the vendor’s infrastructure, so residency is theirs to define, not yours. Customization stops at their API surface — you get what they expose. You pay per participant-minute plus egress, metered forever. And your client and signaling couple to their SDK, which makes leaving expensive. That coupling is the real lock-in: Twilio announced end-of-life for Programmable Video and reversed it in October 2024, and Dyte was acquired by Cloudflare in April 2025 and folded into a new platform — in both cases the vendor’s roadmap became a live dependency in the customer’s. Owning the deployment removes those constraints, at the cost of operating what you deploy.

Embed white-label infrastructure

Embedding means you deploy a complete platform — SFU, signaling, TURN, recording, and SDKs — as one unit that runs in your environment rather than a vendor’s. This is the category Samvyo occupies.

Based on SFU architecture, it delivers the media plane, signaling, and client SDKs as an integrated, white-label system, with an on-premise deployment option that places the entire media path inside infrastructure you control. Architecturally, that is what distinguishes it from the cloud path: residency is resolved at the deployment level — the media never leaves your environment — rather than requested as a configuration from a third party, and the economics are a flat licence instead of a per-participant meter. You own the six layers without assembling them.

The honest cost is integration weight. Deploying and operating a full platform is heavier than dropping in a cloud SDK, even though you are not building the stack from scratch. For a single-product team at low volume with no white-label or residency requirement, that is more operational surface than a cloud API asks for, and the cloud API is the better technical choice. Embedding pays off when you need OEM white-labeling, flat economics at scale, or sovereignty over the media path — requirements that the buy path structurally cannot meet. Which path fits comes down to one more variable that cuts across all three.

The portability question

Underneath the decision is a single technical variable: how tightly is your application coupled to the path you chose? A cloud SDK binds your client and signaling to one vendor, so migrating means rewriting the integration end to end. Building or embedding on standard WebRTC keeps that coupling under your control. The cheapest insurance, on any path, is to abstract the video layer behind your own interface, so the provider sits behind a boundary you own — the design decision that turns the CPaaS roadmap risk above from a rewrite into a swap.

Matching architecture to requirement

The requirements map to paths with little ambiguity once the stack is in view:

  • Sub-second latency, high concurrency, video is the core product, media engineers in-house → build. Operating all six layers is justified when video is the product.
  • Fast integration, standard use case, moderate scale, no residency constraint → buy. Let the vendor run five layers; revisit at scale.
  • White-label / OEM, flat economics at volume, or media that must stay in your jurisdiction → embed. It is the only path delivering an owned, deployable stack without a build.

The architecture is identical across all three — the same six components move the same RTP. What differs is which layers you operate, and therefore which constraints you inherit. Choose by the constraint you cannot move.

For the cost, speed, and ROI framing of this decision, see the business companion: link to the business version.

Frequently Asked Questions

What components make up video infrastructure?

Six: signaling (session setup over WebSocket), an SFU or media server (routing RTP between participants), STUN/TURN (NAT traversal and media relay), recording, scaling and orchestration (SFU cascading, load balancing, autoscaling), and client SDKs. Build, buy, and embed differ only in who operates each. Self-hosted platforms based on SFU architecture, such as Samvyo, deliver all six as one deployable unit.

What is the hardest part of building WebRTC infrastructure?

Not the demo — the production hardening. The difficult layers are TURN (bandwidth-heavy, must be geo-distributed) and SFU scaling (a single instance caps out, so real concurrency needs cascading and load-balancing across regions), plus global latency and continuous maintenance. This is the roughly 20% of the problem that consumes 80% of the effort, and why many teams buy or embed instead.

Does a cloud video API lock me in?

To a degree, yes — your client and signaling couple to the vendor’s SDK, so migrating means rewriting the integration. The vendor’s roadmap also becomes your dependency, as Twilio’s end-of-life reversal and Dyte’s acquisition both showed. The mitigation is to abstract the video layer behind your own interface so a provider can be swapped rather than rebuilt around.

How does self-hosting solve data residency?

Residency is decided by where the media path physically runs. A self-hosted deployment places the SFU, signaling, and recording inside infrastructure you control, so media never crosses into a third party’s environment or another jurisdiction. Samvyo, based on SFU architecture, offers on-premise deployment for exactly this reason — common in BFSI, government, and healthcare, where residency is mandated rather than preferred.

Build versus embed — what is the real technical difference?

Building means you assemble and maintain all six layers yourself from open-source parts — maximum control, maximum ongoing effort. Embedding means you deploy and operate a pre-integrated platform that already includes those layers — you own the stack and its residency without engineering it. Both can be self-hosted; the difference is whether you are constructing the system or running one that is already built.