Case Study — Production SystemsProduction

BigBlueButton Host

Managed virtual classroom infrastructure, load-balanced across dedicated nodes, for schools, universities, and training academies worldwide.

Overview

What we built

BigBlueButton Host is Bymond's flagship commercial product: managed BigBlueButton hosting for organizations that need virtual classroom infrastructure without running the servers themselves. Customers get a dedicated, isolated BigBlueButton instance, custom domain branding, LMS integration, and automated recording, all of it operated by Bymond.

The Problem

Where single-server BigBlueButton breaks

Organizations running live virtual classrooms hit a real technical ceiling well before they run out of raw hardware. A single BigBlueButton server fails under load not because it runs out of memory, but because WebRTC's stream fan-out math and Node.js's single-threaded event loop saturate long before a modern server's CPU or RAM does. Add background recording transcoding to the same node, and live classes start stuttering. Most schools, training academies, and online learning platforms have no in-house WebRTC and DevOps capacity to solve this themselves, and no reason to build it.

Requirements

What the platform needed to do

Dedicated, isolated capacity per customer, with no noisy-neighbor throttling.

Horizontal scale across multiple BigBlueButton nodes, not a single server.

Low-latency media relay for participants behind restrictive firewalls.

Native LMS integration that drops into an institution's existing workflow.

A recording pipeline that never degrades a live, concurrent session.

Custom domain branding per customer, not a shared white-label subdomain.

Architecture

Client traffic is routed by Scalelite to a dedicated BigBlueButton node; TURN relays keep the media path reachable behind restrictive networks, and recording renders on isolated capacity, off the nodes serving live sessions.

Client (Browser)
Scalelite Load Balancer
Dedicated BBB Node
TURN / STUN Relay
Recording Pipeline
Cloud Storage
Engineering Challenges

What was actually hard

01

WebRTC stream multiplication at scale

A live session's real cost isn't CPU or RAM in the abstract — it's N × (N-1) media routing math. A 50-participant class with cameras on means roughly 2,450 concurrent streams for the media server to route. Node capacity planning has to be driven by concurrent-session math, not just server specs.

02

Recording contention

BigBlueButton renders recordings with background FFmpeg workers after a session ends. Running that transcoding on the same node as live classes competes for the same CPU cores as active WebRTC sessions, which shows up to users as audio stutter. Recording rendering runs on isolated capacity, deliberately kept off the nodes serving live sessions.

03

Multi-tenant isolation

Shared BigBlueButton hosting has a noisy-neighbor problem: one customer's large class can starve another's. Each customer gets a dedicated server instance rather than a slice of a shared pool.

04

Global NAT and firewall traversal

Participants behind restrictive corporate or campus firewalls can't always reach a media server directly. Regional coturn TURN/STUN relays across the US, Europe, and Asia give WebRTC a fallback relay path close to the participant instead of one relay serving the whole world.

05

LMS integration without workflow disruption

Institutions already run Moodle, Canvas, Sakai, or a custom portal, and asking them to adopt a new one isn't realistic. Native LTI 1.3 support means BigBlueButton Host drops into the LMS an institution already has instead of replacing it.

Solution

How it fits together

Scalelite sits in front of the BigBlueButton node pool as an intelligent HTTP API proxy, so the LMS or customer portal integrates against one stable endpoint regardless of which physical node a session lands on. Each customer's sessions run on server capacity isolated from other customers. Regional coturn TURN/STUN relays give WebRTC a nearby fallback path when a direct peer connection isn't possible. Recording rendering is deliberately kept off the nodes serving live traffic, so a session ending and its video being processed never competes with a class still in progress.

Day to day, every customer instance goes through the same operational lifecycle: provisioned on dedicated hardware, configured with custom domain SSL and LMS integration, continuously monitored for CPU, RAM, network, and WebRTC connection health, with recordings automatically rendered and archived after each session.

Technology

What it's built on

BigBlueButtonWebRTCScalelitecoturn (STUN/TURN)FFmpegLTI 1.3LinuxNginx
Production Considerations

Running it, not just building it

  • Reliability: published 99.9% SLA uptime target, backed by dedicated (not shared) node capacity per customer.
  • Security: per-customer server isolation and firewall hardening at provisioning time.
  • Monitoring: continuous CPU, RAM, network, and WebRTC connection-health tracking, part of Bymond's broader production infrastructure capability.
  • Maintenance: proactive OS patching and maintenance updates on a defined support cadence.
Related Solutions

See it in context

Have a similar real-time infrastructure problem?

BigBlueButton, WebRTC, or another real-time media system: tell us what you're running into.