BigBlueButton server on a dedicated machine

Production minimums for 4.0

Each figure is the project's; the last column names the document. For a server at these minimums the FAQ estimates about 200 simultaneous users (3 sessions of 50, say), recommends no single session above 200, and urges a stress test of your own.

The installer refuses less: check_cpus and check_mem in bbb-install.sh stop below 4 cores or roughly 4 GB (-j overrides them), need_x64 stops a non-x86-64 CPU, the -v value must be a noble-4 line, and check_ipv6 only looks for /proc/net/if_inet6, i.e. kernel support, not a public address. If ip addr | grep inet6 shows no ::1/128 line, the install page says to disable IPv6 in FreeSWITCH afterwards. Docker is required: it keeps LibreOffice, which converts documents, in a sandbox.

The script does not test the running Ubuntu release on this path (only the -v value), so the block below checks lsb_release itself. Ubuntu 22.04 was the 3.0 base. Moving 2.6, 2.7 or 3.0 to 4.0 in place is not supported; the docs say to build a clean 24.04 server and transfer the recordings.

Bandwidth per class, from the FAQ figures

Media is the load that grows with the class. The FAQ gives rough per-stream rates and the formula: a room with U users and W webcams at rate Y sends W×(U−1)×Y out of the server.

Our arithmetic, not a project number: one lecturer at 640×480 to 39 students is about 15.6 Mbit/s out, a busy screen share to all 40 adds up to 40 Mbit/s, audio about 1.6 Mbit/s. Student webcams are what multiply it. Slides and chat cost almost nothing, per the FAQ.

Which of our machines fit

Read the dedicated server range with four filters. It is x86-64 only, so the Ampere Altra and X-Gene ARM lines are out. It needs Ubuntu 24.04: the widest lines install Ubuntu from 14.04 to 26.04, but the list depends on the line, so check the configurator's OS menu. It needs 8 or more cores and 16 GB or more: that leaves out the 4-core cartridges (Opteron X2150 and the Xeon E3 models), the 6-core Xeon L5640 and the 6-core Core i5-9500 desktop, while the Xeon D-1587 and E-2286M cartridges, the Atom lines, the other single-socket rack lines and every dual- and quad-socket rack server meet the numbers. The Atom cores are slow ones, though. And it wants single-thread speed: many of our Xeon lines are low-power L parts at 1.7 to 1.8 GHz, so compare the clocks on the Intel Xeon lines before you pick one.

• Port. Unmetered, 1 Gbps on most lines and 500 Mbps on some; the Port column on the range page gives each line's speed. Both clear the 250 Mbit/s floor; 1 Gbps matches the FAQ. No transfer allowance and no overage fee.
• IPv6. It is in no default build. Add it at checkout, at no charge, as individual addresses rather than a routed prefix.
• Disk. Recordings live in /var/bigbluebutton. Size for the 500 GB figure, or pass -m /mnt/recordings to the installer to symlink that folder onto a separate volume.
• Console. Every racked single-, dual- and quad-socket server has an out-of-band console (HPE iLO, Dell iDRAC or a Supermicro BMC), which matters when a firewall rule locks you out. Of the cartridges, only the m510 and m710x have a console; the rest have power control only.
• Delivery. A racked machine is live about 30 minutes after the order is approved; a build to order takes 4 to 24 hours; the custom build page prices each part.

Install with bbb-install.sh

1. Point an A record for your hostname at the server's IPv4 and wait until it resolves. The script requests a Let's Encrypt certificate for it; browsers refuse webcam and microphone access without HTTPS.
2. Check the locale the docs ask for: cat /etc/default/locale should print only LANG="en_US.UTF-8". If not, run apt-get install -y language-pack-en and update-locale LANG=en_US.UTF-8, then log out and back in.
3. Make sure swap is on (swapon --show). The docs require it but give no size; the block below stops without it.
4. Paste the block. It checks the Ubuntu release, the architecture, DNS, swap and, if ufw is already active, opens 80 and 443 before the certificate request. Then it runs the installer with Greenlight (-g), waits for Greenlight to answer on 127.0.0.1:5050 and creates your administrator, unless /root/.greenlight-restored exists, the marker the restore step below leaves.

# As root on a fresh Ubuntu 24.04 x86-64 server. Replace all four values (no commas).
BBB_HOST=bbb.example.com
BBB_EMAIL=you@example.com
GL_NAME='Your Name'
GL_MAIL=you@example.com
IP=$(getent ahostsv4 "$BBB_HOST" | head -n 1 | cut -d' ' -f1)
[ -e /root/.greenlight-restored ] && GL_NEW=0 || GL_NEW=1
if case "$BBB_HOST $BBB_EMAIL $GL_MAIL" in *example.com*) true;; *) false;; esac; then echo "STOP - example values"
elif [ "$(lsb_release -rs)" != 24.04 ] || [ "$(uname -m)" != x86_64 ]; then echo "STOP - needs Ubuntu 24.04, x86-64"
elif [ -z "$IP" ] || ! ip -4 -o addr show scope global | grep -qF " $IP/"; then echo "STOP - DNS is not this server"
elif ! swapon --show | grep -q .; then echo "STOP - no swap"
elif { ufw status | grep -q 'Status: active' && ! ufw allow 80,443/tcp; }; then echo "STOP - 80/443 not opened"
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 "$BBB_HOST" -e "$BBB_EMAIL" -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 [ "$GL_NEW" = 0 ]; then echo "installed; the restored Greenlight keeps its accounts"
else GL_PASS="Aa1-$(openssl rand -hex 12)" &&
  docker exec greenlight-v3 bundle exec rake "admin:create[$GL_NAME,$GL_MAIL,$GL_PASS]" &&
  echo "Greenlight admin: $GL_MAIL / $GL_PASS (store it now)" || echo "STOP - admin not created"; fi

Per bbb-install.sh and apply-lib.sh, the script installs Docker, nginx, coturn (the built-in TURN, listening on 3478) and haproxy on 443, which hands TURN-over-TLS connections to coturn by ALPN, and writes /etc/bigbluebutton/bbb-conf/apply-config.sh, whose enableUFWRules allows the OpenSSH profile, the "Nginx Full" profile (80 and 443), UDP 16384:32768 and, while haproxy runs, port 3478, then runs ufw --force enable. The rules assume SSH on port 22: if sshd listens elsewhere, the script stops unless you pass -W and run the firewall yourself. -b adds stronger SSH ciphers.

Then run bbb-conf --check (read anything under "Potential problems") and bbb-conf --status. bbb-conf --secret prints the API URL and shared secret an LMS needs; treat the secret like a password.

Greenlight's first administrator

Greenlight v3 is the official room manager, served at your hostname once -g is used; its container listens only on 127.0.0.1:5050 behind nginx. It goes public the moment the script finishes, and its registration method ships as open (populate_site_settings.rb in the Greenlight repository). A stranger who signs up gets an ordinary account, not admin rights, but can still create rooms on your server.

That is why the install block creates the administrator straight after the script succeeds, with rake admin:create, and never uses the no-argument form: that one creates admin@example.com with a published default password (admin.rake). The generated password meets Greenlight's rule (upper and lower case, a digit, a symbol, 8 or more characters) and stays out of shell history, but ps can see it while the command runs, and it is printed once. Sign in, set the registration method to invite or approval in the administrator panel, then open Manage Users and delete any account you did not create, before you announce the address.

Recordings, backups and a restore

Recordings sit in /var/bigbluebutton/published, unpublished and recording/raw. Raw data is deleted 14 days after a recording is published by default; it is what bbb-record --rebuild works from, so raise published_days in /etc/default/bigbluebutton-cron-config to keep it longer.

The nightly job archives the config overrides and the Greenlight folder, stopping Greenlight meanwhile, as the Greenlight migration page does.

# As root. Nightly at 03:15: /etc/bigbluebutton and the whole Greenlight folder
# (compose file, .env, database, uploads), kept 14 days in /root/bbb-backups.
install -m 700 /dev/null /root/bbb-backup.sh && cat > /root/bbb-backup.sh <<'EOF' &&
set -uo pipefail
umask 077
B=/root/bbb-backups; GL=/root/greenlight-v3; ts=$(date +%F-%H%M%S)
mkdir -p -m 700 "$B" || exit 1
docker compose -f "$GL/docker-compose.yml" stop || exit 1
tar -czf "$B/greenlight-$ts.tar.gz" -C /root greenlight-v3; g=$?
docker compose -f "$GL/docker-compose.yml" start || g=1
tar -czf "$B/bbb-etc-$ts.tar.gz" /etc/bigbluebutton; e=$?
if [ "$g" = 0 ] && [ "$e" = 0 ] && tar -tzf "$B/greenlight-$ts.tar.gz" >/dev/null && tar -tzf "$B/bbb-etc-$ts.tar.gz" >/dev/null
then echo "ok $ts"; find "$B" -name '*.tar.gz' -mtime +13 -delete
else echo "FAILED $ts" >&2; exit 1; fi
EOF
echo '15 3 * * * root bash /root/bbb-backup.sh >> /root/bbb-backup.log 2>&1' > /etc/cron.d/bbb-backup

Recordings are too large to re-archive every night. Pull them from a second machine with a key authorised for root on the server: rsync -a root@bbb.example.com:/var/bigbluebutton/published/ ./published/, then unpublished/ into ./unpublished/ and recording/raw/ into ./raw/, and /root/bbb-backups/ into ./bbb-backups/. Never add --delete: a wiped server would wipe the copy.

A restore onto a new server, same hostname and DNS already moved, keeps the docs' migration order. Copy bbb-backups to /root/bbb-backups and the published, unpublished and raw folders to /root/bbb-recordings. Unpack Greenlight before installing: G=$(ls -1 /root/bbb-backups/greenlight-*.tar.gz | tail -n 1); [ ! -e /root/greenlight-v3 ] && tar -tzf "$G" >/dev/null && tar -xzpf "$G" -C /root && touch /root/.greenlight-restored && echo ok must print ok. Then paste the install block, checks included; the installer keeps that database and only rewrites the BigBlueButton URL and secret. Last, the block below puts the recordings back, owned by bigbluebutton, setting the empty new folders aside.

# As root on the NEW server, after the install block. Needs the folders published,
# unpublished and raw from your recordings copy inside /root/bbb-recordings.
S=/root/bbb-recordings; R=/var/bigbluebutton; t=$(date +%F-%H%M%S)
if ! command -v bbb-conf >/dev/null; then echo "STOP - BigBlueButton is not installed"
elif [ ! -d "$S/published" ] || [ ! -d "$S/unpublished" ] || [ ! -d "$S/raw" ]; then echo "STOP - recordings copy incomplete"
elif bbb-conf --stop && mkdir -p "$R/published" "$R/unpublished" "$R/recording/raw" &&
  mkdir -m 700 "$R/pre-restore-$t" &&
  mv "$R/published" "$R/unpublished" "$R/recording/raw" "$R/pre-restore-$t/" &&
  cp -a "$S/published" "$S/unpublished" "$R/" && cp -a "$S/raw" "$R/recording/" &&
  chown -R bigbluebutton:bigbluebutton "$R/published" "$R/unpublished" "$R/recording/raw"
then bbb-conf --restart; echo "restored; the new server's empty folders are in $R/pre-restore-$t"
else echo "STOP - a step failed; look in $R and $R/pre-restore-$t before running it again"; fi

Our choice, not a documented step: the archived /etc/bigbluebutton is not copied back, since the installer generates one for this machine; diff it and port your overrides by hand. Rollback: bbb-conf --stop, take the three restored folders out, return those in the pre-restore folder, bbb-conf --restart. If the recordings block stops mid-move or mid-copy, inspect /var/bigbluebutton and the pre-restore folder before a second run.

Upgrades

Within 4.0, re-run your original bbb-install.sh command: it takes BigBlueButton and Greenlight to the latest noble-400 release, and a newer line is a different -v. Watch the bigbluebutton-dev list for releases. A new Ubuntu release means a new server plus the restore above.

Licence and limits

BigBlueButton is licensed under the GNU LGPL, version 3.0 (the FAQ, the repository's LICENSE file); the headers of bbb-install.sh and Greenlight's files add "or (at your option) any later version". Our general reading, not legal advice: running it for your own classes, over the internet included, carries no duty to publish source, because the LGPL has no network clause like the AGPL's. Distributing copies, modified or not, obliges you to supply the licence text and the corresponding source for the LGPL-covered code. Bundled projects such as FreeSWITCH keep their own licences.

• It is not a box to share. The docs want a clean, dedicated server with nothing else on 80 and 443; put your LMS or website on another machine and connect it through the API.
• One server is one server. For many concurrent classes the docs point at Scalelite across several servers.
• For small meetings without the classroom tools, Jitsi Meet on its own server is lighter. For courses taught as recorded video rather than live, see video hosting for online courses.