How Much Does It Cost to Run a Live-Commerce Video Platform?

Running a live-commerce video platform in production means paying to deliver one seller’s broadcast to every viewer watching it — not paying for a symmetric video call. That single fact shapes the whole cost model: the dominant line is delivery (bandwidth to the audience), and the biggest lever in the entire bill is how you deliver. Over WebRTC you get sub-second latency but pay per participant-minute; over CDN-based delivery you accept added latency — roughly 2–6 seconds with Low-Latency HLS (LL-HLS), 15–30 seconds or more with standard HLS — and pay per delivered minute, which is materially cheaper at broadcast scale. Most “live shopping platform” content compares products to buy. This piece prices what it costs to run your own, component by component, at a stated viewer volume — with a source and a confidence level on every number, because in a cost breakdown an unsourced figure is worse than no figure.

Key takeaways

• Live-commerce is 1-to-many broadcast, so delivery/CDN egress — not per-viewer media routing (the “SFU fan-out” that dominates a symmetric video call) — is the dominant cost line at scale. This is the opposite cost shape from a video call, where relaying each participant’s stream individually dominates.
• The WebRTC-vs-CDN cost gap is real, and the cleanest proof is same-vendor, same-resolution. On Agora’s own pricing, HD video costs $3.99 per 1,000 minutes over its interactive RTC product; over its CDN-based Broadcast Streaming product, the audience Video HD rate is $1.99 per 1,000 minutes — roughly a 2× difference for the same vendor, same resolution, driven purely by transport. (Notably, Broadcast Streaming’s host rate is also $3.99 — the saving is entirely on the audience/viewer side.)
• Pure CDN-based delivery runs roughly $0.0008–$0.001 per delivered minute (≈ $0.048–$0.06 per viewer-hour) across Cloudflare Stream and Mux (720p–1080p) — the cheapest way to reach a large one-to-many audience. Agora’s Broadcast Streaming audience Video HD rate is higher ($0.00199/min), since it’s an interactive-capable product. The trade-off for CDN delivery is added latency — ≈2–6s with LL-HLS, 15–30s+ with standard HLS.
• TURN relay is needed only for the interactive segments — guest hosts, co-streaming, live-bid confirmation — not the broadcast audience. It is billed by data volume and is easy to under-budget: named rates run from $0.05/GB (Cloudflare Realtime, first 1,000 GB free) to $0.40–0.80/GB (Twilio, region-dependent).
• Live adaptive-bitrate (ABR) transcoding is a real, often-underestimated line item that scales with source stream-hours, independent of audience size. On AWS Elemental MediaLive it runs roughly $0.70 per output-hour for HD (AVC), and a full multi-rendition HD live channel runs closer to ~$3.94/hour in AWS’s own worked example.
• Chat/reactions infrastructure at concurrency is a genuine, frequently-omitted cost category. Consumption-based pricing (per message + per connection-minute) means it scales with concurrent viewers, not stream-hours — a spiky, peak-driven cost like TURN.
• Build-vs-buy isn’t only an infra-cost question. It’s infra cost plus the engineering time to build shoppable overlays, chat moderation, and checkout on top of the video layer. The honest comparison prices both sides.

If you’re a product or commercial reader rather than an engineer, skip straight to the worked example and the build-vs-buy section further down — that’s where the dollars and the decision live.

We’ve priced infrastructure this way before, in our breakdown of what it costs to maintain Twitch-scale streaming infrastructure. The discipline is the same here: name the cost driver, source the number, show the range.

What does it actually cost to run a live-commerce video platform, component by component?

A live-commerce stream is a stack of separately-billed services, and the trap is blending them into one “$X per viewer-hour all-in” figure that breaks the moment your bitrate, region, or audience size differs from whoever published it. Price them individually and you get a model you can adapt.

Here is the component reference, with a named source and confidence tier on every figure. All prices are as of August 2026 and cloud/CDN pricing shifts — re-verify against each vendor’s live pricing page before you commit a budget line.

Two things to read off this table before moving on. First, the delivery row scales with your audience, and nothing else on the table does — which is why it dominates at scale and gets its own treatment next. Second, the WebRTC row is roughly 2–5× the delivery row per minute for the same audience size — same viewers, different transport. That gap is the spine of every decision below.

For the SFU architecture sitting behind that WebRTC row — how the media server actually fans out interactive media — see our comparison of LiveKit vs Mediasoup. And for how this per-participant-minute pricing behaves across WebRTC use cases beyond live-commerce broadcast — Agora vs. LiveKit rates, managed-vs-self-hosted TURN economics — see our WebRTC cost breakdown for CTOs. Here we’re pricing it, not designing it.

How does live-commerce infrastructure cost scale with concurrent viewers and stream-hours?

The components above split into distinct scaling behaviors, and confusing them is the most common modeling mistake teams make. In plain terms: your delivery bill tracks how many people watch, your transcoding bill tracks how much you broadcast, and the two move independently.

Delivery scales with total viewer-hours delivered — concurrent viewers × stream duration, summed across every show and seller in the month. This is the single number that drives the CDN/egress bill. Ten thousand viewer-hours costs roughly ten times what a thousand costs. It’s the one line that grows without limit as you get popular.

Transcoding/encoding scales with source stream-hours — how much content you broadcast — and is independent of audience size. A show with 10 viewers and a show with 10,000 viewers cost exactly the same to transcode, but wildly different amounts to deliver. State this plainly to whoever owns the budget, because it’s the distinction that gets modeled wrong most often: teams size encoding off audience and get a number that’s off by orders of magnitude.

TURN/interactive cost scales with interactive-segment minutes only — guest-host time, co-streaming, live-bid confirmation — not the full broadcast audience. Even in a hybrid architecture, most viewers are pure receivers pulling from the CDN, so they never touch a TURN relay. Budget TURN against the minutes that are genuinely interactive, not against total viewer-hours.

Chat/reactions cost scales with concurrent connections, which tracks concurrent viewers far more closely than total stream-hours. Like TURN, it’s a spiky, peak-driven cost — a flash sale that spikes concurrent viewers spikes your connection-minute bill in the same instant, even if total monthly stream-hours barely move.

Does WebRTC or CDN-based HLS/LL-HLS cost less to run at scale?

CDN-based delivery is cheaper per audience-member at broadcast scale, and the cleanest proof is a same-vendor, same-resolution comparison. On Agora’s own pricing, HD video over its interactive RTC product runs $3.99 per 1,000 minutes billed per participant. On its CDN-based Broadcast Streaming product, the audience Video HD rate is $1.99 per 1,000 minutes — a ~2× difference for the identical company, identical resolution, different transport (Agora RTC pricing; Agora Broadcast Streaming pricing). The sharper detail: Broadcast Streaming charges hosts the same $3.99 as RTC — the discount is entirely on the audience side. You pay the interactive rate for whoever has to be a host or interactive participant either way; the saving materializes only for the broadcast-only audience once they’re served over the CDN product rather than RTC.

The mechanism behind the gap is simple: CDN delivery encodes once and serves every viewer from a shared edge cache — one origin pull, thousands of cache hits, no per-viewer fan-out penalty. WebRTC maintains a per-participant media path and relays or fans out media to each viewer individually, even through an efficient SFU, so its cost compounds as you add viewers. The distinction that matters for budgeting: on the CDN, the unit price per additional viewer stays roughly flat (no fan-out penalty), but your total delivery cost still grows linearly with viewer-hours — it’s a low, flat rate multiplied by a number that climbs without limit as you get popular, not a fixed cost that levels off.

The trade-off you’re buying with that saving is latency, and how much depends on which HLS variant you run. Low-Latency HLS (LL-HLS) lands around 2–6 seconds; standard HLS typically runs 15–30 seconds or more once you account for segment duration, packaging, and player buffer. For a viewer watching a seller demo a product, even the LL-HLS delay is invisible. It becomes material only where the platform needs sub-second interactivity — real-time bidding where a stale price breaks trust, or live Q&A that has to feel instant — and there, plain HLS’s 15–30s is disqualifying, not just noticeable.

That’s why production live-commerce platforms rarely pick one or the other. The pattern that ships is hybrid: CDN/HLS for the broadcast feed to the audience, WebRTC only for the interactive slice — the host-guest link, co-streaming, and bid confirmation. You pay the expensive per-participant rate for the handful of minutes and participants that genuinely need sub-second latency, and the cheap per-delivered-minute rate for everyone else. Getting that boundary right — where the WebRTC layer ends and the CDN layer begins — is the highest-leverage architecture decision in the entire cost model.

What does it cost to run a live-commerce platform at 300 stream-hours a month? (worked example)

This is a directional model to adapt, not a quote. Every input is a range, so the output is a range too. Here are the assumptions, stated plainly so you can swap in your own numbers:

• Volume: 300 stream-hours/month across multiple sellers — a mid-size platform running several shows a day.
• Audience: an average of 500 concurrent viewers per show, with occasional flash-sale spikes above that (state your own — a niche B2B show may average 50, a celebrity drop 50,000).
• Total viewer-hours delivered: 300 stream-hours × 500 average concurrent viewers = 150,000 viewer-hours/month = 9,000,000 viewer-minutes/month. This is the input to the delivery line.
• Interactive segments: 20 hours/month of guest-host or bid-confirmation time that genuinely needs sub-second WebRTC — a small fraction of total broadcast time.
• Video profile: ~2 Mbps HD broadcast, a standard ABR ladder, one CDN region primary.

Now the two paths, side by side, for the same 9,000,000 viewer-minutes. The point of showing both is to make the transport decision concrete in dollars, not just in concept.

Read those totals as ranges, not headlines. The same 300 stream-hours at 500 average concurrent viewers costs roughly $8,700–$13,500/month all-in over CDN-based HLS (delivery, transcoding, TURN, storage, plus modeled chat and replay egress), versus roughly $19,000–$39,400/month all-in delivered entirely over WebRTC — a 2–5× difference driven almost entirely by transport. Per viewer-hour, the delivery line alone is ≈ $0.048–$0.06 on the CDN path and ≈ $0.12–$0.24 on the WebRTC path.

The practical takeaway isn’t “never use WebRTC.” It’s that a hybrid architecture — CDN broadcast plus WebRTC only for the 20 interactive hours — lands within a few percent of the CDN-only total (those 20 hours involve a handful of hosts and bidders, not the full 500-viewer audience), while a naive “just use WebRTC for everything because it’s real-time” decision multiplies the dominant line by 2–5×. That is the entire economic argument for the hybrid pattern, in dollars.

This is where the architecture choice, not the arithmetic, does the work — and it’s the kind of decision we’ve made in production on both sides. In one live-shopping build, we ran ingest through Wowza with adaptive bitrate over a regional CDN, and the hard part wasn’t cost — it was synchronizing shoppable overlays across viewers whose latency drifted apart, which we solved by embedding timestamp markers in the stream metadata so a flash-sale overlay lands on every screen at the same moment. On a live-auction platform we made the opposite call, running the primary feed over WebRTC to hold glass-to-screen latency under two seconds with WebSocket bid propagation to hundreds of concurrent bidders — because in an auction, a two-second-stale price is a broken product. Same team, opposite transport, because the interactivity requirement was different. The dollar figures above come only from the public vendor pricing cited, not from either engagement.

Sizing these numbers for your own volume is exactly the modeling our WebRTC development team does with clients before a build commitment — you don’t have to read to the end for it.

Real production cost will diverge from this model for reasons you should budget for: your ABR-ladder choices (more renditions, more transcoding), regional CDN pricing, contract-tier volume discounts below pay-as-you-go rates, and — the big one — how much of your show is genuinely interactive versus pure broadcast. Treat the range as a starting frame, then tighten each input with your own traffic.

What infrastructure costs do live-commerce cost estimates usually miss?

A “best platforms” listicle or a vendor’s pricing page never surfaces these, because they’re pricing a finished product, not the infrastructure underneath it. When you build, every one of these becomes your line item.

• TURN relay bandwidth for interactive segments. Why it’s missed: it’s assumed included in a managed platform’s flat price. The moment you self-host or mix vendors for the interactive slice, it’s a separate, metered line — small at broadcast scale, but real, and billed by the gigabyte.
• VOD replay storage + egress. Why it’s missed: estimates stop at the live broadcast. But sellers’ shows get watched again after the stream ends, and replay traffic uses the same delivery-cost logic as live — it’s rarely budgeted as its own line. Routing replay through a CDN rather than serving directly from storage avoids the storage-egress tier (S3→CloudFront same-region transfer is free), which is worth one architecture decision.
• Chat/reactions at peak concurrency. Why it’s missed: WebSockets feel free until the connection-minute bill arrives. Once you have real concurrent viewers, this is a genuinely new cost category that scales with your peak, not your average.
• Observability and stream-health monitoring. Why it’s missed: nobody budgets it until something breaks during a flash sale. Tracking bitrate, rebuffer rate, error rate, and viewer-side quality-of-experience is a real, frequently-deferred category the first time a show degrades in front of 10,000 people.
• DRM / watermarking. Why it’s missed: pricing is often opaque and custom-quoted (Widevine/FairPlay/PlayReady packaging, or third-party forensic watermarking). We won’t invent a number here — it’s a real line item if you license seller content or need anti-piracy protection, and genuinely skippable if you don’t.
• Redundancy and failover. Why it’s missed: first-pass estimates price the happy path. Multi-region origin and a backup ingest path are the cost of not going dark mid-flash-sale — the one time your infrastructure absolutely cannot blink.
• Engineering and ops time. Why it’s missed: it’s not on any vendor’s invoice. The honest total cost of ownership includes the team maintaining ingest, transcoding, delivery, and chat infra — not just the vendor bills. This is where build-vs-buy is actually decided.

What does adding a real-time AI layer cost? (moderation, auto-highlights, product recognition)

A real-time AI layer is optional and adds its own cost line — inference compute, plus the frame-extraction and data-channel delivery mechanics that move video frames to a model and results back to the viewer. It’s a separate budget conversation from the delivery math above, and one we’ve written up in depth rather than re-teaching here. For the architecture of real-time content moderation on a live stream, see our content-moderation pipeline guide; for real-time analytics and auto-highlights aimed specifically at live commerce, see our real-time video analytics guide. GPU/inference pricing is out of scope for this piece — those guides cover the mechanics.

Should you build a custom live-commerce video platform or buy a managed one?

Neutrally: for many teams, buying is the right call, and hedging around that would be dishonest.

Buying a managed provider (Agora, 100ms, Mux, Amazon IVS) or a live-commerce-specific SaaS trades a higher per-viewer-minute rate for zero infrastructure-ops burden. Below a certain scale and complexity threshold, that’s simply the faster, saner path — you reach production without staffing an encoding pipeline, a CDN relationship, a TURN fleet, and an observability stack, and the marginal per-minute premium is cheap next to the engineering time you’d spend replacing it. Time-to-market cuts the same way: buying gets you a working live-shopping demo in weeks, while building the CDN/WebRTC hybrid layer — plus the shoppable-overlay, chat-moderation, and checkout work on top of it — is a multi-month engineering investment before your first show goes live. For most teams weighing this, that gap in time matters as much as the gap in per-minute cost. If you’re evaluating which live-shopping platform to buy rather than build, see our roundup of the best live-stream shopping platforms — that’s the “buy” side of this decision.

Building on your own infrastructure (a CDN-broadcast pipeline, or a WebRTC-native stack, or the hybrid of both) trades lower marginal cost at scale for real engineering investment and every hidden-cost category above. The crossover depends on three things: your viewer volume (does marginal saving ever repay the fixed engineering floor?), how much of the experience is genuinely interactive versus pure broadcast (which decides how much expensive WebRTC you actually need), and whether the shoppable-overlay, chat-moderation, and checkout work on top of the video layer is differentiating enough to justify owning the stack.

The honest heuristic: if live commerce is the product — the core differentiator, not a bolt-on — owning the video-delivery layer buys you control and margin at scale. If it’s a feature added to an existing commerce product, buying a managed provider is usually faster and cheaper until volume or a specific interactivity requirement forces a change.

Whichever way you go, the real-time layer underneath — ingest, ABR transcoding, CDN delivery, and the WebRTC/TURN slice for interactivity — has to be built and operated by someone. That’s the layer Trembit builds and operates: 15+ years of protocol-level WebRTC work across 50+ real-time video and voice implementations, including both the CDN/broadcast side and the WebRTC-native interactive side of live-commerce and live-auction platforms in production. We’re not neutral about whether that layer should be done well — we are neutral about whether you should build it, because for plenty of teams the right answer is “not yet.”

Put your own numbers through the model

The figure worth settling before you commit engineering time is your cost per viewer-hour at your real peak, with your real interactive share — not a blended industry number. Book a free 30-minute call and bring the specifics: your stream-hours, your average and peak concurrency, and how much of a show genuinely has to be sub-second. We will work through the model with an engineer and tell you where the CDN/WebRTC boundary should sit. No deck, no pitch.