How to Build a Livestreaming App

TL;DR

• A livestreaming app is six components: broadcaster, ingest, transcode, distribution, viewer, and chat. Everything past the transcoder multiplies by viewer count, which is why scaling is about viewers, not streams.
• Production systems combine protocols rather than picking one: RTMP or WebRTC in for ingest, HLS out for mass audiences, WebRTC egress reserved for products where latency is central.
• Each layer (ingest, transcoding, adaptive playback, chat) is built two ways here: a working vanilla implementation (node-media-server, ffmpeg, hls.js, raw WebSockets) and the equivalent on Stream's Video API, so you can see exactly what a managed platform is doing for you.
• Chat runs on completely different machinery than video, since message fan-out is three to four orders of magnitude lighter than video fan-out at the same viewer count.

Livestreaming doesn't pretend to be simple.

It looks difficult from the outside, and continues to be difficult the deeper you get.

You have to move video from one broadcaster to thousands of viewers basically in real time, across networks you don't control. You have to accept that feed whether it comes from OBS, a browser tab, or a phone, and keep the session alive when the broadcaster's upload connection dips. You have to turn one incoming feed into several so playback doesn't stall on hotel Wi-Fi or cellular, and it also looks great on fiber. Oh, and everyone now expects a chat room that keeps working the first time a streamer gets popular.

For each layer, it covers the decision you're facing and why it matters. We're also doing it two ways: one vanilla React from scratch, and one built on Stream's Video API. By the end, you'll understand exactly what the managed version is doing for you.

The High-Level Architecture of a Livestreaming App

Every livestreaming product, whether it's Twitch, a fitness platform, a live shopping app, or an auction house, is built from the same six components:

• Broadcaster. The app or device capturing video, whether that's a browser with a webcam, a phone camera, or OBS on a streamer's gaming PC. It encodes raw frames into a compressed contribution feed (usually H.264) and pushes it upstream.
• Ingest. The server that accepts that contribution feed. It authenticates the broadcaster (this is what a "stream key" is for), terminates the streaming protocol, and hands the feed to the transcoder.
• Transcode. The compute tier that turns one contribution feed into many. A broadcaster sends a single 1080p stream, but viewers on phones, TVs, and bad networks each need something different. Transcoding produces a "ladder" of renditions (720p, 480p, and 360p, for example) that enables adaptive playback.
• Distribution. The delivery network that moves video from your transcoder to every viewer. For HLS, this is CDN caching at the edge, and for WebRTC, it's a mesh of media servers (SFUs) forwarding packets.
• Viewer. The player. It fetches the stream, monitors the network, and switches between renditions when the viewer's connection changes.
• Chat. A real-time messaging system running alongside the video. It has nothing to do with the video path, since chat is a WebSocket fan-out problem rather than a media problem, but almost every livestream product includes one.

Notice where the arrows fan out. Everything up to the transcoder is a single connection and a single job per broadcaster. After the transcoder, distribution multiplies everything by the viewer count. That asymmetry drives most decisions, and it's why scaling a livestream is about viewers rather than streams.

Choosing Between RTMP, HLS, and WebRTC

The first decision is which streaming protocol to use. Realistically, you aren't just going to pick one. Each protocol was designed for a different part of the path between broadcaster and viewer, and production systems combine them.

The classic architecture is RTMP or WebRTC in, transcoding in the middle, and HLS out, with WebRTC egress reserved for products where latency is central, like auctions, betting, and live shopping.

• Every encoder ever made still supports RTMP, from OBS and Streamlabs to hardware boxes and drone controllers, even though Flash is long gone. That installed base makes it the default contribution protocol, but viewers no longer receive RTMP directly.
• WebRTC delivers sub-500ms latency over UDP with built-in congestion control, and it's the only protocol a browser can publish from, so it's what makes a "go live" button work in a web app without OBS. It has no equivalent of the CDN, though. Connections are stateful peer sessions rather than cacheable files, so scaling WebRTC means running your own fleet of SFU media servers and cascading them as the audience grows.
• HLS cuts the video into 2- to 6-second segments and lists them in a playlist that updates as new segments arrive. Players fetch both over plain HTTP so that any CDN can cache them, and a single origin can serve a million viewers. The tradeoff is latency. A player buffers several segments before it starts playing, which leaves viewers 10 to 30 seconds behind the live edge. Low-latency HLS brings that down to a few seconds by serving partial segments.

How Stream Handles the Protocol Decision

This is the first place a managed platform changes the problem rather than just hosting it. A Stream livestream call accepts ingest over RTMP(S), WebRTC, and SRT, and serves every viewer over both WebRTC and HLS simultaneously from the same stream. Instead of picking one protocol, you pick a latency budget for each kind of client. The interactive web app gets WebRTC at around 100ms, while the smart TV app gets HLS.

Building the Ingest Tier

The ingest tier is where a broadcaster's video enters your system. It has to speak a protocol encoders actually support (RTMP, in practice), authenticate every publish attempt before accepting a single frame, and stay stable while the broadcaster's home upload connection varies. If you get the authentication part wrong, strangers can stream whatever they like under your users' names.

The Vanilla Version

The Node ecosystem's workhorse here is node-media-server, an RTMP server implementation. We accept publishes on rtmp://host:1935/live/<streamKey> and treat the last path segment as the stream key, which is exactly the scheme OBS expects when you paste a server URL and key into its settings:

const NodeMediaServer = require('node-media-server');

// In production this table lives in your database, keyed per broadcaster.
const VALID_STREAM_KEYS = new Set(['demo-stream-key']);

const nms = new NodeMediaServer({
  rtmp: {
    port: 1935,
    chunk_size: 60000,
    gop_cache: true, // replay the last GOP to new pullers for instant startup
    ping: 30,
    ping_timeout: 60,
  },
  http: { port: 8001, allow_origin: '*' },
});

// Reject unknown stream keys before a single frame is accepted.
nms.on('prePublish', (id, streamPath) => {
  const key = streamPath.split('/').pop();
  if (!VALID_STREAM_KEYS.has(key)) {
    nms.getSession(id).reject();
  }
});

nms.on('postPublish', (id, streamPath) => {
  startTranscode(streamPath.split('/').pop()); // defined in the transcoding section
});

nms.run();

That's a functional ingest server, and for local development it's genuinely fine. The gap between this and production is everything you can't see in the code.

A production ingest tier also handles:

• TLS termination (RTMPS), so stream keys aren't traveling in plaintext
• Ingest points in multiple regions, so an Australian broadcaster isn't pushing frames to a server in Virginia
• Reconnects that resume a stream instead of ending it when the broadcaster's router blips
• Monitoring that can tell a dead stream from a silent one

There's also a capability gap. With RTMP-only ingest, browsers can't broadcast at all, because there's no way to speak RTMP from JavaScript. If your product wants a "go live" button in a web or mobile app, which in 2026 describes most products, you need WebRTC ingest, and that means running WebRTC infrastructure before your first viewer ever shows up.

The Stream Version

With Stream, the ingest infrastructure already exists, so your backend's job is reduced to creating the livestream and issuing credentials. Using the Node SDK:

import { StreamClient } from '@stream-io/node-sdk';

const client = new StreamClient(apiKey, apiSecret);

app.post('/api/streams', async (req, res) => {
  const { hostId } = req.body;
  const callId = crypto.randomUUID();
  const call = client.video.call('livestream', callId);

  await call.getOrCreate({
    data: {
      created_by_id: hostId,
      members: [{ user_id: hostId, role: 'host' }],
    },
  });

  // Everything an encoder needs to publish into this call over RTMP.
  // The stream key is just a user token scoped to the host.
  const info = await call.get();
  res.json({
    callId,
    rtmpAddress: info.call.ingress.rtmp.address,
    rtmpStreamKey: client.generateUserToken({ user_id: hostId }),
  });
});

Authentication is free. The RTMP stream key is a signed user token, so publish the same identity system authenticates attempts as everything else, and there's no separate stream-key table to build, rotate, and eventually leak.

The livestream call type also starts in backstage mode. The host can join early to check their camera and audio, but viewers are held out until the stream is explicitly flipped live:

app.post('/api/streams/:callId/go-live', async (req, res) => {
  const call = client.video.call('livestream', req.params.callId);
  const response = await call.goLive({
    start_hls: true,       // start the HLS egress for at-scale playback
    start_recording: true, // optional VOD capture
  });
  res.json({ hlsPlaylistUrl: response.call.egress.hls?.playlist_url });
});

Because Stream's ingest is WebRTC-native, the browser-broadcast case is just the client SDK joining the call and publishing. It's the same call that accepts OBS over RTMP:

const client = new StreamVideoClient({ apiKey, user: { id: 'host-demo' }, token });
const call = client.call('livestream', callId);

await call.join({ create: true });
await call.camera.enable();
await call.microphone.enable();
// The browser is now the encoder, publishing simulcast layers over WebRTC.

OBS broadcasters and browser broadcasters land in the same call, so nothing downstream has to care which one showed up.

Transcoding One Feed Into Many

The broadcaster sends you a single bitrate, say, 1080p at 4.5 Mbps. A viewer on LTE with two bars can't sustain that; without an alternative, their player stalls, and stalled viewers leave.

Adaptive bitrate (ABR) playback fixes this with a ladder of renditions encoded at different sizes, and producing that ladder is usually the most compute-expensive part of the stack. Every rendition is a full re-encode of every frame in real time for the entire duration of each concurrent stream.

The Vanilla Version

The standard tool is ffmpeg. On postPublish, we spawn one ffmpeg process that pulls the RTMP feed back off the ingest server, splits it three ways, encodes each rendition, and writes HLS segments plus a master playlist that advertises all three:

const RENDITIONS = [
  { name: '720p', width: 1280, height: 720, vBitrate: '2800k', aBitrate: '128k' },
  { name: '480p', width: 854,  height: 480, vBitrate: '1400k', aBitrate: '96k' },
  { name: '360p', width: 640,  height: 360, vBitrate: '800k',  aBitrate: '64k' },
];

function startTranscode(streamKey) {
  const args = [
    '-i', `rtmp://127.0.0.1:1935/live/${streamKey}`,
    '-filter_complex',
    '[0:v]split=3[v0][v1][v2]; ' +
      '[v0]scale=w=1280:h=720:force_original_aspect_ratio=decrease:force_divisible_by=2[v0out]; ' +
      '[v1]scale=w=854:h=480:force_original_aspect_ratio=decrease:force_divisible_by=2[v1out]; ' +
      '[v2]scale=w=640:h=360:force_original_aspect_ratio=decrease:force_divisible_by=2[v2out]',
  ];

  RENDITIONS.forEach((r, i) => {
    args.push(
      '-map', `[v${i}out]`,
      `-c:v:${i}`, 'libx264', `-b:v:${i}`, r.vBitrate,
      '-preset', 'veryfast',
      // A fixed 2-second GOP so every rendition cuts segments at identical
      // points, which is required for clean mid-stream quality switches.
      '-g', '48', '-keyint_min', '48', '-sc_threshold', '0',
      '-map', 'a:0?', `-c:a:${i}`, 'aac', `-b:a:${i}`, r.aBitrate,
    );
  });

  args.push(
    '-f', 'hls',
    '-hls_time', '2',
    '-hls_list_size', '6',
    '-hls_flags', 'delete_segments+independent_segments',
    '-hls_segment_filename', `media/${streamKey}/%v/seg_%05d.ts`,
    '-master_pl_name', 'master.m3u8',
    '-var_stream_map', 'v:0,a:0,name:720p v:1,a:1,name:480p v:2,a:2,name:360p',
    `media/${streamKey}/%v/playlist.m3u8`
  );

  spawn('ffmpeg', args);
}

That's complicated. A few flags worth understanding:

• -g 48 -sc_threshold 0 pins a keyframe every 48 frames (2 seconds at 24fps) and disables scene-cut keyframes. Every rendition must place keyframes at identical timestamps, because a player can only switch quality at a segment boundary, and segments can only start on keyframes. Misalign the GOPs and quality switches glitch or stall.
• force_divisible_by=2 exists because scaling 16:9 content to 480 pixels tall actually gives you a width of 853.33, and libx264 refuses odd frame dimensions. (Our first test run died on exactly this.)
• delete_segments keeps the live window bounded so a 6-hour stream doesn't fill the disk.

But there is a cost. This one stream runs three simultaneous x264 encodes, which is most of the CPU on a modern laptop, and every concurrent broadcaster needs the same. At even 50 concurrent streams you're capacity-planning a transcode farm, scheduling jobs across it, and handling the failure mode where a transcoder dies mid-stream and every viewer's playlist goes stale.

The Stream Version

You've already seen the Stream version of this because it was a single parameter. Calling goLive({ start_hls: true }) starts the transcode, and Stream encodes the ladder, packages HLS, and returns a playlist URL served from its edge network.

The WebRTC path doesn't even need that much. WebRTC handles rendition switching through simulcast, where the broadcaster publishes multiple encodes of the same feed at different bitrates and the SFU forwards whichever layer suits each viewer's measured bandwidth, adjusting per viewer as conditions change.

Playback and Adaptive Bitrate

On the viewer's side, the question is how the player picks a rendition and what happens when the network changes mid-stream. ABR is the difference between a buffering spinner and a barely noticeable quality dip when a viewer walks away from their router. The ladder from the last section only works if the player actually monitors throughput and switches renditions.

The Vanilla Version

Browsers other than Safari won't play HLS natively. hls.js implements HLS on top of Media Source Extensions and ships a real ABR controller:

<video id="video" controls autoplay muted playsinline></video>
<script src="https://cdn.jsdelivr.net/npm/hls.js@1/dist/hls.min.js"></script>
<script>
  const video = document.getElementById('video');
  const src = `/hls/${streamKey}/master.m3u8`;

  if (Hls.isSupported()) {
    const hls = new Hls({
      liveSyncDurationCount: 3, // start near the live edge and stay there
      lowLatencyMode: true,
    });
    hls.loadSource(src);
    hls.attachMedia(video);

    // Populate a manual quality menu from the master playlist.
    hls.on(Hls.Events.MANIFEST_PARSED, (_, data) => {
      data.levels.forEach((level, i) => addQualityOption(i, level.height));
    });
    // -1 restores automatic ABR; any other index pins a rendition.
    qualitySelect.onchange = () => (hls.currentLevel = Number(qualitySelect.value));
  } else if (video.canPlayType('application/vnd.apple.mpegurl')) {
    video.src = src; // Safari: native HLS, ABR is automatic
  }
</script>

hls.js estimates bandwidth from segment download times and automatically moves up or down the ladder. Setting currentLevel = -1 restores auto mode, and pinning a level gives you the manual quality menu viewers expect.

Cache headers can make or break this at scale. Playlists mutate every two seconds, while segments never change once written. Split the cache rules accordingly, and a CDN can absorb almost all of your delivery traffic:

app.use('/hls', express.static(MEDIA_DIR, {
  setHeaders(res, filePath) {
    if (filePath.endsWith('.m3u8')) {
      res.setHeader('Cache-Control', 'no-cache');              // playlists mutate constantly
    } else if (filePath.endsWith('.ts')) {
      res.setHeader('Cache-Control', 'public, max-age=31536000, immutable'); // segments never change
    }
  },
}));

The whole vanilla playback stack ends up being hls.js in the player plus these cache rules in front of the files.

The Stream Version

In Stream, this is just a component. LivestreamPlayer joins the call as a viewer over WebRTC, renders the host's video, and handles quality adaptation through the SFU's per-viewer layer selection, with no manifest handling or buffer tuning on your side:

import { StreamVideo, StreamVideoClient, LivestreamPlayer } from '@stream-io/video-react-sdk';

const client = new StreamVideoClient({ apiKey, user, token });

<StreamVideo client={client}>
  <LivestreamPlayer callType="livestream" callId={callId} />
</StreamVideo>

Because playback is WebRTC, viewers sit around 100ms behind the broadcaster instead of 10 or more seconds, which is close enough for the host to read chat and respond while the moment is still happening. The HLS playlist URL from goLive() is still available for clients where WebRTC isn't the right fit, such as smart TV apps, and the same hls.js code above plays it unchanged.

Live Chat Alongside the Stream

Chat shares no infrastructure with video, so you're building a second real-time system. We covered the general problem in our guide to building a chat app. Livestream chat is a harder variant of it, with one channel holding tens of thousands of concurrent, mostly anonymous participants, plenty of whom are adversarial.

The Vanilla Version

The minimal viable design is one WebSocket per viewer and room-based fan-out, where every message gets rebroadcast to every socket in the room:

const { WebSocketServer } = require('ws');

const rooms = new Map(); // room name -> Set<socket>
const wss = new WebSocketServer({ server });

function broadcast(room, payload, except) {
  const data = JSON.stringify(payload);
  for (const client of rooms.get(room) ?? []) {
    if (client === except || client.readyState !== client.OPEN) continue;
    // Backpressure guard: if a client can't keep up, drop messages for it
    // rather than buffering unbounded memory per slow connection.
    if (client.bufferedAmount > 1024 * 1024) continue;
    client.send(data);
  }
}

wss.on('connection', (ws, req) => {
  const url = new URL(req.url, `http://${req.headers.host}`);
  const room = url.searchParams.get('room');
  rooms.get(room)?.add(ws) ?? rooms.set(room, new Set([ws]));

  ws.on('message', (raw) => {
    if (!takeToken(ws)) {  // token-bucket rate limit: 5 burst, 1 msg/sec sustained
      return ws.send(JSON.stringify({ type: 'error', code: 'rate_limited' }));
    }
    const msg = JSON.parse(raw);
    const text = String(msg.text).slice(0, 500).trim();
    if (text) broadcast(room, { type: 'message', name: ws.name, text, ts: Date.now() });
  });

  ws.on('close', () => rooms.get(room)?.delete(ws));
});

Even this minimal version needed three things that have nothing to do with sending messages:

• A rate limiter, because livestream chat without one fills with spam within minutes
• A backpressure guard, because one viewer on 2G buffering unboundedly will eventually take the process down for everyone
• A ping/pong heartbeat, because mobile viewers vanish without closing their sockets and dead connections otherwise pile up forever

And the feature list has barely started. A real livestream chat also needs:

• Message history, so late joiners see conversation instead of an empty pane
• Moderation, meaning bans, timeouts, slow mode, and profanity and spam filtering, which at livestream scale has to be automated
• Reactions, pinned messages, and user badges and roles
• Threads for Q&A formats
• Reconnection with resume, so a network blip doesn't wipe the chat pane

Each one is a feature built on top of a distributed system you now operate.

The deepest problem, though, is in the broadcast loop itself, which does O(viewers) work per message on a single event loop. The load pattern is the inverse of normal group chat. Livestream chat concentrates everything into a single channel whose member list is the entire audience, so the message rate and the fan-out factor scale with the same viewer count.

Ten thousand viewers producing 50 messages per second means 500,000 socket writes per second from one room. That's beyond what a single Node process handles comfortably, and sharding it means adding a pub/sub backbone like Redis or NATS between chat servers, which introduces a new tier of infrastructure with its own failure modes.

The Stream Version

Stream Chat ships a channel type named livestream with these dynamics already in. Anyone can read and post without being added as a channel member, which matters because tracking membership for 100,000 transient viewers creates load without buying you anything. Slow mode, bans, and AI moderation hooks come out of the box. The client side is a component tree:

import { StreamChat } from 'stream-chat';
import { Chat, Channel, MessageList, MessageInput, Window } from 'stream-chat-react';

const chatClient = new StreamChat(apiKey);
await chatClient.connectUser(user, token);

// One chat channel per stream, keyed by the call ID.
const channel = chatClient.channel('livestream', callId);
await channel.watch();

<Chat client={chatClient} theme="str-chat__theme-dark">
  <Channel channel={channel}>
    <Window>
      <MessageList />
      <MessageInput focus />
    </Window>
  </Channel>
</Chat>

watch() delivers recent history to late joiners and subscribes to new events, while reconnection, gap recovery, rate limiting, and fan-out are the platform's problem.

The video call and the chat channel are glued together by nothing more than a shared ID, which is the right amount of coupling for two systems that share no infrastructure.

Scaling to Thousands of Viewers

Livestreaming scales differently from most real-time systems.

Broadcaster count barely matters. Each new streamer costs one ingest connection and one transcode job, and that cost grows linearly and predictably.

Viewer count is what matters, because every viewer is a full-bandwidth video consumer. Put 10,000 viewers on the 2.8 Mbps 720p rendition, and you're sustaining 28 Gbps of egress for one moderately popular stream. The same 10,000 viewers generate maybe a few MB/s of chat JSON. Video fan-out runs three to four orders of magnitude heavier than message fan-out, which is why the two paths scale with completely different machinery.

How you deliver that egress depends on the protocol choice from earlier:

• HLS scales through a CDN. Because segments are immutable HTTP resources, the CDN absorbs the fan-out: your origin serves each segment once per edge location, and the edge serves it ten thousand times. This is why HLS remains the default for big audiences. The viewer-count problem turns into a CDN bill rather than an engineering program, and latency is what you give up.
• WebRTC scales through your own servers. Every viewer maintains a stateful connection to an SFU, and each SFU can support up to a few thousand subscribers. Past that, you cascade, with the broadcaster's SFU relaying to other SFUs, which relay to viewers, forming a distribution tree that must grow and rebalance in real time as viewers pile in.

Cascading SFUs well is an infrastructure challenge, which is the strongest argument for not building this tier yourself. It's also measurable. Stream has published benchmarks of a single livestream scaled to 100,000 concurrent WebRTC viewers with stable frame rates and zero packet loss.

That load pushed over 200 Gbps of egress for one 1080p stream, absorbed by stepped SFU auto-scaling that doubles or triples capacity when saturation spikes. Those are the numbers to plan for the moment a streamer goes viral, whether you build the tier or buy it.

Chat has its own version of the scaling problem. Connection sharding and pub/sub backbones from the chat architecture guide carry over, but livestream chat is the worst-case for channel management.

Sharding by channel does nothing if one channel accounts for 95 percent of your traffic, so the fan-out for a single channel must be spread across many nodes. At extreme scale, platforms stop delivering every message to every viewer and instead sample messages per client, since nobody can read 500 messages a second anyway.

Build vs. Buy

Building means at least:

• An RTMP and WebRTC ingest fleet
• A transcode farm
• A CDN contract or an SFU cascade
• ABR players for every platform you support
• A chat system with its own scaling work

Add the operational load of running all of it at four nines while browsers and codecs shift underneath you. Our build vs. buy analysis for video shows that building production-grade video infrastructure typically runs $2 - 4M over three years with a dedicated team of 4 - 8 engineers, against roughly a third of that all-in with a managed API and almost no engineers dedicated to plumbing.

The question is never whether you can build it; we've shown that. The question is which layer differentiates your product. UX, content, and community mechanics all live above this infrastructure. If sub-second latency at six figures of concurrency is genuinely what sets your product apart, you might be the exception. For most products, the pipeline is just that, a pipeline, and buying it makes more sense.

Build With Your Stack

Everything in this guide's Stream implementation was React and Node, but the same livestream call and chat channel are addressable from every major platform SDK:

Backend SDKs for token minting and stream lifecycle (the /api/streams endpoints above) are available for Node, Python, Go, and more.

Shipping the Production Version

Strip away the acronyms and a livestreaming app comes down to three systems:

• A contribution path that has to be reliable for one person
• A distribution path that has to be cheap for ten thousand people
• A chat system that has to survive both

The vanilla implementations in this guide really work, and they're the same moving parts Twitch runs, just at a tiny fraction of the scale. Building them is the fastest way to understand why the production versions look the way they do.

When you're ready to ship the production version, the livestreaming tutorial gets a broadcaster and viewers connected in about fifteen minutes. The free tier is enough to start building a robust livestream app that serves thousands of viewers.