I have a working NethServer 8 module for BigBlueButton 3.0.23, with Greenlight as the front end. It is a development tag and there are still bugs, but the thing runs: you can create a room, join it, talk, turn on your camera, share your screen and draw on the whiteboard. If you like trying new modules, now is a good moment.
Install
add-module ghcr.io/stephdl/bigbluebutton:main 1
main is the development tag, so it moves. One instance per node — BigBlueButton wants the whole node’s media ports.
Then configure it with its own FQDN. Let’s Encrypt is strongly recommended: browsers refuse microphone and camera access on a certificate that does not match the site name.
Signing in
Greenlight migrates its database but never seeds an administrator, so the module creates a bootstrap account for you:
admin@nethserver.org |
|
| Password | Nethesis,1234 |
That password ships with the module, so everyone reading this knows it. Sign in, create your own account, give it the Administrator role, then delete the bootstrap one. The module checks that password on every settings load and keeps nagging in the UI until you change it.
What works
Everything below I have exercised on a live instance:
- Audio. Two-way microphone through FreeSWITCH, with the mediasoup SFU carrying the WebRTC leg. Clients on the LAN and clients from outside both connect without needing a STUN server.
- Webcams. Multiple cameras per meeting, with BigBlueButton’s automatic quality degradation as the room fills up.
- Screen sharing.
- Whiteboard. tldraw over the presentation, with the full toolbar — pen, shapes, arrows, text.
- Shared notes. The Etherpad collaborative editor, one pad per meeting.
- Presentations. Upload your own PDF, or use the default deck the module ships so the whiteboard always has a surface to draw on. Rooms open with the presentation collapsed, so the canvas does not take the screen the moment you join.
- Greenlight rooms. Create rooms, share the join link, manage access, browse the recordings library.
- Backup and restore. Including restoring into a brand-new instance from a Restic snapshot.
Recording is present and off by default. It works, but it is by far the heaviest thing this module can do, so switch it on deliberately rather than by habit.
The rest of the BigBlueButton feature set is there too — chat, polling, breakout rooms, emoji status, multi-user whiteboard, the learning dashboard — since this packages upstream rather than reimplementing it. I simply have not put every one of them through its paces.
What it looks like inside
Seventeen containers under rootless podman. Fourteen share one pod and publish only two TCP ports to the node loopback, behind Traefik. Three run on the host network because they need real media ports: FreeSWITCH for audio mixing, the mediasoup SFU for video, and the raw WebRTC recorder.
The module asks the node for 9216 UDP ports. 8192 go to mediasoup and are the only ones opened publicly; the remaining 1024 carry the SFU-to-FreeSWITCH audio leg and never leave the loopback.
That 8192 is not a participant count. Each WebRTC transport binds one socket per announced address, and the module announces two — the public one and the private one, which is what lets LAN and internet clients work without STUN. So 8192 ports means 4096 concurrent transports, and a transport is per stream, not per person.
For a sense of scale: one meeting with two participants and three cameras held 25 UDP ports. They are allocated per stream and released the moment the meeting ends — between meetings, ss -uanp | grep mediasoup shows nothing at all.
You will run out of memory and CPU long before you run out of ports.
What to expect from a machine
Upstream asks for 8 cores and 16 GB. The stack starts on less, and memory goes first.
Before anybody joins, the containers already hold about 3.2 GB between them — three JVMs, a Hasura engine, a Rails app and a Node SFU run whether there is a meeting or not. On a 7.5 GB node that is 4.5 GB gone at rest.
On 8 vCPU and 7.5 GB with recording off, expect roughly 25 to 40 participants with cameras, or 60 to 80 audio-only. Treat that as an order of magnitude: it is reasoned from the measured idle footprint and from how the components scale, not the result of a load test. Doubling the RAM to 16 GB moves the ceiling from memory to CPU, which is where upstream’s own recommendation puts it.
Bandwidth is the pleasant surprise. BigBlueButton drops every camera to 100 kbps once a meeting reaches 8 participants, then 90, 70, 50, 40 and 30 kbps at 12, 15, 20, 25 and 30. A 20-person meeting showing five cameras each costs about 5 Mbps upstream, plus roughly 40 kbps of mixed audio per participant. Do not tune those thresholds away — an SFU multiplies every extra kbps by the number of receivers.
The failure mode is not a refused connection. It is audio breaking up, cameras freezing and clients reconnecting. Watch memory and load before the meeting that matters, not after.
Backup
The recordings volume, the Greenlight and Hasura databases, and the generated secrets are backed up. Redis and the per-meeting scratch volumes are not — they hold live meeting state, which is meaningless across a restore. So a restore loses any meeting in progress and any recording still queued for processing.
Code, and a README with the architecture notes and the full sizing detail: https://github.com/stephdl/ns8-bigbluebutton
Bug reports very welcome. So are load-test results — I would much rather replace my estimates with somebody’s real numbers.
Nice 
