Vuisio vs BigBlueButton: the full 2026 comparison
Vuisio and BigBlueButton are both open source, both run in the browser, and both integrate with Moodle. The similarity ends there. On architecture, performance, sovereignty and the real cost of running them, the two play in different categories. This comparison goes criterion by criterion, with sources.
What Vuisio and BigBlueButton have in common
The two share enough ground to explain why the comparison keeps coming up.
Both are free software: BigBlueButton is published under LGPL 3.0 (official BigBlueButton FAQ), Vuisio under AGPL 3.0 for its core (docs.vuis.io). Both run entirely in the browser over WebRTC, with nothing to install for participants. And both work with Moodle: BigBlueButton has been integrated natively since version 4.0 (Moodle), and Vuisio exposes a compatible API through its compat-api module (docs.vuis.io).
Everything else diverges.
How the architectures differ
Architecture is the structural difference. On its own it explains the gaps in performance, in consumption and in how much administration each one demands.
BigBlueButton: a dozen interlocking components
The architecture page of the official documentation sets out the stack: NGINX (reverse proxy), FreeSWITCH (audio server in MCU mode, which decompresses and mixes streams), Kurento Media Server (video server in SFU mode), Redis (message bus), MongoDB (meeting state), Node.js/Meteor.js (HTML5 client and server), Akka (state management, Scala), bbb-webrtc-sfu (WebRTC bridge to Kurento), Etherpad (shared notes) and LibreOffice (document conversion, running in a Docker container). The customisation documentation recommends three parallel Kurento instances for stability.
A bbb-conf --status lists more than ten active services. If one falls over, the service is degraded or interrupted.
Vuisio: a Rust SFU and an orchestrator
Vuisio comes down to two main parts (docs.vuis.io).
The SFU (core/server/) is a WebRTC relay written in Rust. It receives audio and video packets and redistributes them without ever decoding or re-encoding them, a raw RTP relay. Each thread has its own UDP socket, and participants are spread by hashing (room, client) so the work parallelises. Inter-thread queues are bounded with a time budget, so a busy room cannot block the others.
The orchestrator (bin/vuisio/) starts the SFU, exposes a module registry over gRPC (port 50050) and wires hooks according to the capabilities each module declares. The SFU exposes four generic hooks (on_command, on_media_out, on_media_transform, on_lifecycle) and knows nothing about any module. That is the project’s golden rule: the core stays self-contained and never depends on the SDK or on the modules.
| Criterion | BigBlueButton | Vuisio |
|---|---|---|
| Server components | ~12 (nginx, FreeSWITCH, Kurento, Redis, MongoDB, Meteor, Akka, bbb-webrtc-sfu, Etherpad, LibreOffice, bbb-fsesl-akka, bbb-apps-akka) | 2 (SFU + orchestrator) plus optional modules (lobby, whiteboard, compat-api, anonymizer) |
| Server languages | Java, JavaScript/Node.js, Scala (Akka), C/C++ (FreeSWITCH, Kurento), Ruby (Greenlight) | Rust (core), Next.js (web client) |
| Audio handling | MCU (FreeSWITCH decompresses and mixes) | SFU (raw relay, no mixing) |
| Video handling | SFU through Kurento (in-memory processing) | SFU (raw RTP relay, no decoding) |
| Internal communication | Redis pub/sub, MongoDB, Meteor websockets | gRPC (Protobuf), bounded inter-thread queues |
| Extending it | Change the source code | Rust SDK plus hooks, modules declared over gRPC |
What hardware each one needs
The consequences of that architecture show up directly in capacity and in cost.
| Criterion | BigBlueButton | Vuisio |
|---|---|---|
| Server OS | Ubuntu 22.04 only (BBB install docs) | Debian 11+ or Ubuntu 22.04+ (docs.vuis.io) |
| Minimum RAM in production | 16 GB (BBB install docs) | 1 GB for ten participants, under 2 GB for 450 to 500 |
| Minimum CPU in production | 8 cores, bare metal recommended (BBB install docs) | 2 cores are enough, VM or VPS accepted |
| Minimum storage | 500 GB for recordings (BBB install docs) | Proportional to usage, no document conversion |
| Server bandwidth | 250 Mbit/s symmetric minimum, 1 Gbit/s recommended (BBB FAQ) | Proportional to the number of participants |
| Capacity per server | ~200 simultaneous participants (BBB FAQ) | 450 to 500 participants on 6 vCPU, under 2 GB of RAM |
| CPU load of the media relay | FreeSWITCH: 4.5 to 7 threads; Kurento: 1 to 2.5; Meteor: 2 (Octopuce field report, 167-user test) | “A few percent of the processor” for the media relay (docs.vuis.io) |
| Critical CPU threshold | 70 %, beyond which audio degrades (BBB FAQ) | Memory stable under sustained load, no documented threshold |
| Scaling out | Scalelite cluster (multi-server balancer) | Native multi-threading, parallelised by hashing (room, client) |
Vuisio’s load-testing harness is a contribution in its own right (docs.vuis.io): replay bots use the same str0m library as the server, making them indistinguishable from a real client at the network level, while real Chromium browsers measure what a participant actually experiences (frames per second, jitter, freezes, audio loss). The method is deliberately conservative: the bots emit at a constant rate with no adaptation, which puts the server under a load at least as heavy as real clients would.
Which one protects the data better
| Criterion | BigBlueButton | Vuisio |
|---|---|---|
| Publisher | Blindside Networks, Canada (Wikipedia) | Geezot, France |
| Hosting | Self-hosting only | Sovereign cloud in France, or self-hosted on premise |
| User account required | Yes (through Greenlight or an LMS) | No. A participant is a random numeric identifier, for the duration of the session (docs.vuis.io) |
| Cookies | Yes (Meteor session, Greenlight) | None imposed by the core (docs.vuis.io) |
| Behavioural tracking | Server logs, Learning Dashboard (speaking time, participation) | None. The only fingerprint is the DTLS certificate, a standard cryptographic check (docs.vuis.io) |
| Encryption in transit | Yes (DTLS-SRTP over WebRTC) | Yes (DTLS-SRTP over WebRTC) |
| Encryption at rest | Not documented | AES-256-GCM, key supplied by the operator (docs.vuis.io) |
| Data persistence | MongoDB + Redis + recordings on disk | Optional (Redis). Without Redis, rooms are ephemeral and live in memory only (docs.vuis.io) |
| Automatic cleanup | Recordings deleted after 14 days by default (BBB docs) | Empty room means data erased on close (docs.vuis.io) |
| TLS certificate | Let’s Encrypt (American) | Actalis (European, Italian) by default, or Let’s Encrypt, or your own (docs.vuis.io) |
| Default STUN | Google (stun.l.google.com) | European Nextcloud (stun.nextcloud.com:443) (docs.vuis.io) |
Two details show how far the sovereignty work goes. The default STUN server is European, from Nextcloud, where BigBlueButton points at Google. And the certificate authority offered by default is Actalis, Italian, rather than Let’s Encrypt, American. Neither changes anything for the user, and both change everything about the chain of trust.
What migrating from Moodle looks like
Vuisio implements the BigBlueButton API protocol through its compat-api module (docs.vuis.io). Any platform configured for BBB can point at Vuisio with no change to the integration.
In practice:
- Deploy Vuisio, on the sovereign cloud or with
vuisio-installeron your own server. - Install the compatibility module:
vuisio module add compat-api. - In Moodle (Administration > Plugins > BigBlueButton), replace the URL and the shared secret with Vuisio’s.
- Test. Rooms, roles (teacher and student) and join links behave exactly as before.
On the BigBlueButton side, upgrading is itself a project: moving from BBB 2.x to 3.0 means starting from a fresh Ubuntu 22.04 server and migrating recordings by hand (BBB install docs). On the Vuisio side, vuisio upgrade updates atomically and rolls back automatically if the health checks fail (docs.vuis.io).
What each one really costs
| Criterion | BigBlueButton | Vuisio |
|---|---|---|
| Software licence | Free | Free (AGPL 3.0 core) |
| Infrastructure for 200 users | Dedicated server, ~70 to 140 USD/month (Webhostingzone estimate) | A far more modest server, or the sovereign cloud included |
| Turnkey cloud | Not available | Free (unlimited length and participants) or Pro at €29/month per host |
| Billing | Per server, infrastructure at your expense | Per host, never per participant |
| System administration | Heavy (12 services, Ubuntu only, manual upgrades) | Light (vuisio CLI, atomic upgrades, vuisio doctor) |
| Scaling beyond 200 | Scalelite cluster, more infrastructure | Native multi-threading |
In short
BigBlueButton opened the way for open source video conferencing in education, and it is a respectable project with a large community. But a twelve-component architecture, demanding hardware requirements and no documented encryption at rest place it in a different era against what 2026 asks for. This head-to-head is only a starting point: our comparison of BigBlueButton alternatives situates Vuisio among the other options.
Vuisio keeps what makes BigBlueButton strong (open source, browser-based, Moodle-compatible) and rethinks the rest: a minimal Rust SFU that carries about ten participants on 1 GB of RAM, AES-256-GCM encryption at rest, a sovereign cloud hosted in France with a European STUN server and a European TLS certificate by default, and a migration from BBB that comes down to installing a module and changing a URL. All of it without user accounts, without cookies, and without per-participant billing.
If you run BigBlueButton today, the simplest move is to try Vuisio for free: the migration is reversible, and your users will not notice the difference. Except perhaps how smooth it feels.
Frequently asked questions
Is Vuisio compatible with BigBlueButton?
Yes. Vuisio's compat-api module implements the BigBlueButton API protocol. Platforms that already use BBB (Moodle, Greenlight, API Mate) switch to Vuisio by changing the server URL and the shared secret, nothing else.
How do the two architectures differ?
BigBlueButton rests on about a dozen components (FreeSWITCH, Kurento, Redis, MongoDB, Node.js/Meteor, Akka, Etherpad, LibreOffice). Vuisio uses a single Rust SFU that relays streams without re-encoding them, plus an orchestrator that connects modules over gRPC.
What is the minimum server Vuisio runs on?
About ten participants fit on 1 GB of RAM and 2 cores, measured on an Intel Atom C2338 at 1.74 GHz with no hyper-threading and no L3 cache. It takes 6 vCPU for 450 to 500 participants, with memory never above 2 GB. BigBlueButton asks for at least 16 GB of RAM and 8 CPU cores on a dedicated Ubuntu server.
Is BigBlueButton sovereign?
BigBlueButton is open source and self-hostable, which lets you keep the data in-house. But the project is published in Canada by Blindside Networks, there is no documented encryption at rest, and there is no turnkey sovereign cloud offering.
Is Vuisio free?
Yes. The free sovereign cloud plan has no limit on meeting length or participant count. Pro, at €29 excl. VAT per host per month, adds recording, participation analytics and voice anonymisation.
Can we migrate from BigBlueButton without downtime?
Migration is transparent if you go through Moodle or Greenlight. You change the BBB server URL and the shared secret in the configuration. Rooms, roles and join links keep working.
Complete guide : BigBlueButton alternatives in 2026: the comparison
