Your own BigBlueButton server for live online classes

What your classes need from the server

BigBlueButton is a whole virtual classroom (audio, webcams, screen sharing, whiteboard and slides, chat, polls, recordings) on one machine, so size that machine for your busiest lesson. The project's production list for 4.0:

• Ubuntu 24.04, 64-bit, freshly installed, with nothing else already using ports 80 and 443. 4.0 is built for this release alone, so the block further down checks it before installing.
• 8 processor cores with good speed per core. The project asks for "high single-thread performance", meaning each core counts, not just how many there are.
• 16 GB of RAM plus swap (disk space the system borrows when memory runs short).
• 500 GB of disk space when lessons are recorded, 50 GB when they never are.
• 250 Mbit/s or more, the same up and down. The FAQ goes further and recommends 1 Gbit/s each way.
• A web address such as classes.yourschool.org, because browsers only allow camera and microphone over HTTPS, plus IPv4 and IPv6 addresses.
• Open ports: TCP 80 and 443, TCP and UDP 3478 for the built-in relay that helps people behind strict networks, and UDP 16384 to 32768 for the audio and video itself.

Coming from 3.0, which ran on Ubuntu 22.04? There is no upgrade on the spot: the documentation says to start a clean 24.04 server and copy your recordings across, which the restore steps below do.

Will the connection keep up with a full class?

For most schools, yes. By the FAQ, a minimum-spec server should carry around 200 people at once, say three classes of fifty, and the FAQ advises keeping any one class under 200. Webcams change this most, because each is sent to every other person in the room; slides and chat barely register. Rough rates:

Our own worked example from those rates: a teacher on a medium webcam in front of 25 students sends about 10 Mbit/s, and a lively screen share to all 26 adds up to 26 Mbit/s. Student cameras push it up fastest, so try your own server with a real group first, as the FAQ recommends.

The server that fits

On our dedicated servers page, look for at least 8 cores and 16 GB of memory. Machines with fewer cores miss the mark: the Opteron X2150 and Xeon E3 cartridges (4 cores each), plus two 6-core boxes, the Xeon L5640 server and the Core i5-9500 desktop. Three more things to check:

1. The processor type. The installer only runs on x86-64, so leave the ARM machines (Ampere Altra and the X-Gene cartridge) aside.
2. The operating system. Pick Ubuntu 24.04 when you order. The widest lines take Ubuntu up to 26.04, but the list differs per machine, so check it on the order page.
3. Speed per core. Several of our Xeon processors are low-power models with modest clock speeds. Compare the GHz figures on the Intel servers page and favour the faster ones.

Why a whole machine: a live class cannot wait while someone else's job uses the processor, and here every core, all the memory and the disks are yours. Nobody meters the port (500 Mbps or 1 Gbps, depending on the line), so a busy term of recorded lessons adds nothing to the invoice. IPv6 is free; check your order includes it. An out-of-band remote console comes with every rack server and blade, and with two cartridge models (m510, m710x): screen and power button, even after a firewall mistake locks you out of SSH. The remaining cartridges offer just a power switch, so prefer a rack server.

A ready server is handed over within 30 minutes of approval. A custom build is slower: 4 to 24 hours when the parts are stock we hold, 5 to 10 working days when they have to be bought in. You manage the server; we keep the hardware and the network running.

Installing it, step by step

1. Add a DNS A record that sends your class address to the server's public IPv4, then give it time to take effect. The installer asks Let's Encrypt for a free certificate for that name.
2. Log in and check the language setting the docs want: cat /etc/default/locale should show only LANG="en_US.UTF-8". If not, install the language-pack-en package, set LANG=en_US.UTF-8 with update-locale, and log in again.
3. Check swap with swapon --show. The documentation requires it without naming a size, and the block below stops if it is missing.
4. Paste the block below. It confirms the Ubuntu release, processor type, DNS and swap, and opens 80 and 443 if a firewall is already on, so the certificate request gets through. Only then does it run the official installer with Greenlight, wait for Greenlight to answer, and create your administrator (skipped when the restore step below has left its /root/.greenlight-restored marker).

# As root (sudo -i) on a new Ubuntu 24.04 x86-64 server. Fill in all four values.
SITE=classes.example.com
LE_MAIL=you@example.com
ADMIN_NAME='Your Name'
ADMIN_MAIL=you@example.com
ADDR=$(getent ahostsv4 "$SITE" | head -n 1 | cut -d' ' -f1)
[ -e /root/.greenlight-restored ] && FIRST=no || FIRST=yes
if case "$SITE $LE_MAIL $ADMIN_MAIL" in *example.com*) true;; *) false;; esac; then echo "STOP - example values left in"
elif [ "$(lsb_release -rs)" != 24.04 ] || [ "$(uname -m)" != x86_64 ]; then echo "STOP - Ubuntu 24.04 x86-64 only"
elif [ -z "$ADDR" ] || ! ip -4 -o addr show scope global | grep -qF " $ADDR/"; then echo "STOP - DNS is elsewhere"
elif ! swapon --show | grep -q .; then echo "STOP - no swap yet"
elif { ufw status | grep -q 'Status: active' && ! ufw allow 80,443/tcp; }; then echo "STOP - 80/443 closed"
elif ! { wget -qO /root/bbb-install.sh https://raw.githubusercontent.com/bigbluebutton/bbb-install/v4.0.x-release/bbb-install.sh &&
  bash /root/bbb-install.sh -v noble-400 -s "$SITE" -e "$LE_MAIL" -g &&
  timeout 600 bash -c 'until curl -s -o /dev/null http://127.0.0.1:5050/; do sleep 5; done'; }; then echo "STOP - install failed"
elif [ "$FIRST" = no ]; then echo "Installed; the restored Greenlight keeps its accounts"
else ADMIN_PASS="Zx9_$(openssl rand -hex 12)" &&
  docker exec greenlight-v3 bundle exec rake "admin:create[$ADMIN_NAME,$ADMIN_MAIL,$ADMIN_PASS]" &&
  echo "Admin sign-in: $ADMIN_MAIL / $ADMIN_PASS (save it now)" || echo "STOP - admin not created"; fi

From the script and the apply-lib.sh it calls: bbb-install.sh adds Docker (which, per the docs, sandboxes the LibreOffice that converts uploads), nginx, the certificate and a relay: coturn answers on 3478, while haproxy, sitting on 443, hands it any relay traffic that comes in over TLS. It then turns on the Ubuntu firewall for SSH, web traffic on 80 and 443, the media range 16384:32768 over UDP and, when the relay is running, 3478. SSH has to be on port 22 for that; on any other port the script halts unless you add -W and manage the firewall on your own.

Afterwards, bbb-conf --check lists any trouble under "Potential problems", while bbb-conf --status shows each part running. If your learning platform starts the classes, bbb-conf --secret gives it the address and shared secret; guard that secret like a password.

Let only your teachers in

Greenlight is the official front page where teachers sign in and open rooms. It appears on your address as soon as the installer finishes, and out of the box anyone can register: its registration method starts as open, set in the Greenlight repository's populate_site_settings.rb. Someone who registers gets no admin rights, but could hold meetings of their own on your server.

So the block makes your administrator as soon as the install succeeds, and never runs rake admin:create bare: that form creates admin@example.com with a default password anyone can read in admin.rake. Your password is generated to Greenlight's rules (capital and small letters, a digit, a symbol, 8 characters or more), so you never type it into your shell history. Other users of the server could glimpse it with ps during that one command, and it is shown once at the end. Sign in, open the administrator panel, switch registration to invite or approval, and look through Manage Users for anyone who slipped in; delete accounts you do not recognise before you share the address.

Keeping your recordings and rooms safe

Recorded lessons live under /var/bigbluebutton: published and unpublished hold the playback, recording/raw the original material. The original material goes 14 days after publishing unless you change published_days= in the file /etc/default/bigbluebutton-cron-config; keep it longer if you may need to rebuild recordings.

The block below saves the small, vital part nightly: BigBlueButton's settings and Greenlight's folder with its users and rooms. Greenlight pauses while it is packed, as in the Greenlight migration guide, so it runs at 02:40, away from lessons.

# Run as root. Every night at 02:40 this saves /etc/bigbluebutton and the whole
# /root/greenlight-v3 folder to /root/bbb-backups and keeps two weeks of them.
install -m 700 /dev/null /usr/local/sbin/bbb-nightly.sh && cat > /usr/local/sbin/bbb-nightly.sh <<'EOF' &&
set -uo pipefail
umask 077
OUT=/root/bbb-backups; ts=$(date +%F-%H%M%S)
COMPOSE=/root/greenlight-v3/docker-compose.yml
mkdir -p -m 700 "$OUT" || exit 1
docker compose -f "$COMPOSE" stop || exit 1
tar -czf "$OUT/greenlight-$ts.tar.gz" -C /root greenlight-v3; rc1=$?
docker compose -f "$COMPOSE" start || rc1=1
tar -czf "$OUT/bbb-etc-$ts.tar.gz" /etc/bigbluebutton; rc2=$?
if [ "$rc1" = 0 ] && [ "$rc2" = 0 ] && tar -tzf "$OUT/greenlight-$ts.tar.gz" >/dev/null && tar -tzf "$OUT/bbb-etc-$ts.tar.gz" >/dev/null
then echo "saved $ts"; find "$OUT" -name '*.tar.gz' -mtime +13 -delete
else echo "BACKUP FAILED $ts" >&2; exit 1; fi
EOF
echo '40 2 * * * root bash /usr/local/sbin/bbb-nightly.sh >> /root/bbb-nightly.log 2>&1' > /etc/cron.d/bbb-nightly

Recordings are too big for that. Pull them from a second computer with a root key for the server: rsync -a root@classes.example.com:/var/bigbluebutton/published/ published/, then likewise unpublished/, and recording/raw/ into a folder named raw/; fetch /root/bbb-backups/ as bbb-backups/ too. Leave out --delete, or an emptied server would empty your copy too.

A restore follows the documentation's migration order. Point the old hostname at the new machine; put bbb-backups in /root/bbb-backups and published, unpublished, raw in /root/rec. Before installing anything, unpack Greenlight with cd /root && ARC=$(ls -t bbb-backups/greenlight-*.tar.gz | head -n 1) && test ! -d greenlight-v3 && tar -tzf "$ARC" > /dev/null && tar -xzpf "$ARC" && touch .greenlight-restored && echo ok, and continue only on ok. Then paste the install block above, checks and all; it reuses that database, refreshing only the BigBlueButton address and secret. Finally the block below copies the recordings in for the bigbluebutton user, keeping the fresh install's empty folders to one side.

# Run as root on the NEW server once the install block has finished. Expects the
# published, unpublished and raw folders of your recordings copy in /root/rec.
IN=/root/rec; V=/var/bigbluebutton; ts=$(date +%F-%H%M%S)
if ! command -v bbb-conf >/dev/null; then echo "STOP - install BigBlueButton first"
elif [ ! -d "$IN/published" ] || [ ! -d "$IN/unpublished" ] || [ ! -d "$IN/raw" ]; then echo "STOP - recordings missing from $IN"
elif bbb-conf --stop && mkdir -p "$V/published" "$V/unpublished" "$V/recording/raw" &&
  mkdir -m 700 "$V/set-aside-$ts" &&
  mv "$V/published" "$V/unpublished" "$V/recording/raw" "$V/set-aside-$ts/" &&
  cp -a "$IN/published" "$IN/unpublished" "$V/" && cp -a "$IN/raw" "$V/recording/" &&
  chown -R bigbluebutton:bigbluebutton "$V/published" "$V/unpublished" "$V/recording/raw"
then bbb-conf --restart; echo "Done. The empty folders it replaced are in $V/set-aside-$ts"
else echo "STOP - a step failed; check $V and $V/set-aside-$ts before trying again"; fi

Our advice, not documented steps: leave the saved /etc/bigbluebutton out, since the new install makes its own, and redo your changes by comparing the two. To undo the recordings part, stop with bbb-conf --stop, swap the restored folders for the ones kept in the set-aside folder, and start with bbb-conf --restart. If the recordings block halts partway, check /var/bigbluebutton and the set-aside folder and tidy up before running it again.

Staying up to date

To update, run your install command again: BigBlueButton and Greenlight move to the newest 4.0 release (-v noble-400), and a later line needs a new -v. The bigbluebutton-dev mailing list carries release news. A newer Ubuntu always means a new server and a restore.

Is it the right tool for you?

BigBlueButton's licence is the GNU Lesser General Public License, version 3.0, per its FAQ and LICENSE file; the script and Greenlight headers add "or any later version". As we read it (a general reading, not legal advice): teaching your own classes with it, online included, asks nothing of you, since, unlike the AGPL, the LGPL has no clause about use over a network. Give copies to others, changed or unchanged, and they must get the licence and the source of the LGPL-covered code with them. The other open-source projects inside it keep their own licences.

• Give it the server to itself. Your website and learning platform go elsewhere; the platform reaches BigBlueButton through its API.
• For many classes at once, the documentation suggests Scalelite to spread meetings over several servers.
• If you only need plain video meetings, a Jitsi Meet server is simpler. If your course is recorded video rather than live teaching, hosting video for online courses fits better.

Questions people ask

Can I put version 4.0 on Ubuntu 22.04?

No. Version 4.0 is built and supported for Ubuntu 24.04 only. The installer itself does not check which Ubuntu it is running on, which is why our install block does. Ubuntu 22.04 belongs to BigBlueButton 3.0, which is a different release with its own installer branch.

How many students can join one server?

About two hundred at once on a minimum-spec server, the FAQ estimates, however you split them into classes, with none larger than 200. Many webcams lower that, so test with real users before term starts.

Do some students need a TURN server to connect?

Usually not. Since version 2.6 the standard install includes coturn, a relay for people on networks that block the media ports, which answers on port 3478; relay traffic over TLS reaches it through haproxy on 443. The installer's README only suggests a separate relay when your users' networks block UDP.