BigBlueButton

Last reviewed Aug 26, 2026 · 854 words

BigBlueButton wants a whole machine to itself: a clean Ubuntu install, 8 GB of RAM as the floor, a public IP and a real domain name. If your plan was "one more container on the homelab box", stop here and look at Jitsi Meet instead. If you run online classes for a school, a training business or a club that puts 20 to 200 people in a room at once, keep reading, because nothing else you can self-host does breakout rooms, live polls, a multi-user whiteboard and recorded playback in one package.

It is a classroom, not a meeting tool

The video conferencing category is mostly Zoom replacements. BigBlueButton is a teaching replacement, and the difference shows in every screen. There is a presenter role that owns the slide deck, uploaded documents get converted to pages you can annotate, the whiteboard supports multiple cursors, polls return live bar charts, and breakout rooms are timed and pull students back automatically. Recordings replay the slides, chat and webcams in sync rather than as one flat video. Moodle, Canvas and most other learning platforms talk to it over LTI, and a simple API with a shared secret (bbb-conf --secret prints it) lets you script meeting creation. Greenlight, the bundled front end, is what a small organisation uses instead of an LMS: rooms, invite links, recordings list.

Used for a 4-person weekly call, all of this is overhead. Used for a 60-student lecture with a quiz halfway through, it is the reason people put up with the install.

The install is one script, and the script is opinionated

There is no official Docker image. The supported path is bbb-install.sh, which expects a fresh, specific Ubuntu LTS release (22.04 at last check; the project pins one release per major version and refuses others), a hostname that already resolves to the machine, and root. It then installs and wires up FreeSWITCH for audio, a WebRTC media server, nginx, Node services, Redis and the recording pipeline. The pieces are not designed to be picked apart, which is why "Ubuntu-specific installation" is listed as a con: Debian, an LXC container on Proxmox or a Raspberry Pi are all non-starters. A virtual machine is fine as long as it gets the whole RAM budget.

A typical invocation with TLS, the built-in firewall rules, a TURN server and Greenlight looks like this:

wget -qO- https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh \
  | bash -s -- -v jammy-300 -s bbb.example.com -e [email protected] -w -c turn.example.com:secret -g
sudo bbb-conf --check

Check the current branch and version flag in the BigBlueButton docs before copying; the script's flags change between majors. bbb-conf --check at the end tells you which of the dozen services is unhappy, and one of them usually is on first run.

UDP is where audio dies

Web traffic is the easy part: 80 and 443 TCP. Media rides on UDP 16384 through 32768, and every one of those ports has to reach the box from the internet. Behind a home router that means a port-forward range, a static or reliably updated public IP, and an ISP that does not put you behind carrier-grade NAT. Students on corporate or hotel Wi-Fi that blocks UDP entirely need the TURN server (the -c flag above installs coturn) so their media can fall back to TCP 443. Skip TURN and roughly 1 in 10 attendees will report "I can see the slides but nobody can hear me", which is the single most common BigBlueButton support thread.

8 GB is where it boots, not where it teaches

The project's own guidance draws the line at 8 GB and 4 cores for a development or small-group server, and 16 GB with 8 cores for production. Every webcam is a separate stream the media server has to route, so a class of 30 with cameras on is 30 uploads and up to 870 downloads flowing through one machine. Budget about 1 Mbps of bandwidth per participant with video and far less for audio-only. Recording processing runs after the session ends and pegs CPU for a while; disk grows by hundreds of megabytes per recorded hour, so decide on a retention policy on day one.

What I'd do

Rent a 16 GB, 8-core virtual server with a public IP from a provider you already trust, put a subdomain on it, and run the install script with TLS, firewall, TURN and Greenlight in a single pass. Connect the LMS over LTI if there is one, otherwise hand teachers Greenlight rooms. Keep it off the home network entirely unless you have a static IP and a router you control; the UDP range and the RAM budget are both easier to satisfy in a datacentre. And if your honest use case is meetings rather than lessons, install Jitsi Meet in Docker in 15 minutes and give yourself the afternoon back.