Video conferencing in Moodle: beyond BigBlueButton

BigBlueButton is the standard for video conferencing in Moodle. Built in natively since version 4.0, used by the French higher education ministry and deployed in hundreds of universities, it made the virtual classroom accessible at scale. But “native in Moodle” does not mean “the only option”. The BigBlueButton API is an open protocol, and other solutions can implement it to plug into the same plugin, with nothing to change on the Moodle side. This guide explains how that works, why you might look beyond BBB, and how to migrate. For a wider view of what is available, see our comparison of BigBlueButton alternatives.

How the BBB integration works in Moodle

Understanding the mechanism is the key to understanding why BBB can be replaced without touching Moodle.

Since Moodle 4.0, the BigBlueButton plugin ships in Moodle core (you enable it in Administration > Plugins > Manage activities) (Moodle). For earlier versions, the BigBlueButtonBN plugin installs from the Moodle plugin directory (Moodle Plugins).

The plugin talks to the video conferencing server through two pieces of information configured by the Moodle administrator.

1. The API URL of the BigBlueButton server (for example https://bbb.example.com/bigbluebutton/api/).
2. The shared secret, used to sign every request with a SHA-256 checksum.

When a teacher creates a BigBlueButton activity in their course, Moodle sends a create request to the API with the room identifier, the meeting name and the configuration parameters. When a participant clicks to join, Moodle sends a join request with the name, the role (moderator or participant) and a redirect link. The video server checks the signature, creates the room if needed, and redirects the user to the meeting interface.

It is a standard HTTP protocol, with XML responses. The Moodle plugin knows nothing about the server’s implementation: it knows only the URL and the secret.

That abstraction is what makes substitution possible. Any server implementing the same endpoints with the same signature format can plug in where BigBlueButton was, without modifying the Moodle plugin.

Why look beyond BigBlueButton?

BBB opened the way, and it is a respectable project. But three limits come up consistently in feedback from technical teams.

The infrastructure is heavy

BigBlueButton 3.0 requires a dedicated Ubuntu 22.04 server with at least 16 GB of RAM, 8 CPU cores and 500 GB of storage (BBB documentation). The project recommends bare metal rather than a virtual machine, because FreeSWITCH copes badly with shared CPU. For an institution running Moodle on a modest VPS, deploying a BBB server that matches the recommendations means significant cost and complexity.

The free server shipped with Moodle is very limited

By default, the BBB plugin in Moodle points at a test server run by Blindside Networks. That free server imposes serious restrictions: sessions capped at 60 minutes, 25 simultaneous participants maximum, recordings that expire after 7 days and cannot be downloaded, and student webcams visible only to the moderator (BigBlueButton Host). To go beyond those limits you have to deploy your own BBB server or subscribe to a third-party provider.

Day-to-day administration is complex

A BBB server in production runs more than ten services at once (nginx, FreeSWITCH, Kurento, Redis, MongoDB, Meteor, Akka, Etherpad, LibreOffice in Docker, and more) (BBB architecture documentation). Each has its own logs, its own failure modes and its own update needs. Moving from BBB 2.x to 3.0 even requires starting again from a fresh Ubuntu 22.04 server (BBB install documentation).

What are the alternatives for video in Moodle?

LTI integration (Jitsi, Zoom, Teams)

LTI (Learning Tools Interoperability) is a standard for embedding external tools in an LMS. Jitsi, Zoom and Teams can integrate with Moodle through LTI. But LTI integration is less native than the BigBlueButton API: it opens the external tool in an iframe or a new window, with no automatic handling of teacher and student roles, no room creation tied to the course, and no recordings coming back into Moodle. The experience works, but it is less smooth.

On top of that, Zoom and Teams raise the sovereignty problems already documented (CLOUD Act, the French data protection authority, the 2025 decree), and Jitsi is controlled by 8x8, an American company (TechTarget).

The BigBlueButton API implemented by another server

This is the most transparent approach: a server that speaks the same protocol as BigBlueButton, with a different implementation underneath. The Moodle plugin sees no difference, and neither do teachers or students. Only the URL and the secret change in the configuration.

That is exactly what Vuisio does with its compat-api module.

How Vuisio integrates with Moodle

Vuisio’s compat-api module exposes a BigBlueButton-compatible HTTP API under /bigbluebutton/api/ (docs.vuis.io). It uses the same SHA-256 checksum authentication (or SHA-1 depending on the length supplied) and returns responses in the same XML format.

Installation in three steps

1. Install the compat-api module on your Vuisio instance:

vuisio module add compat-api

The module is free and needs no token. It works in a Docker runtime as well as natively (docs.vuis.io).

2. Retrieve the shared secret:

vuisio secrets show --reveal COMPAT_API_SHARED_SECRET

3. Configure Moodle:

In Moodle, go to Site administration > Plugins > BigBlueButton (or BigBlueButtonBN for versions before 4.0). Replace the two fields:

Moodle field	BigBlueButton value	Vuisio value
BigBlueButton Server URL	https://bbb.example.com/bigbluebutton/api/	https://your-domain.vuisio.com/bigbluebutton/api/
BigBlueButton Shared Secret	The BBB server’s secret	Vuisio’s COMPAT_API_SHARED_SECRET

Save. Test by creating a BigBlueButton activity in a course and joining it. The teacher enters as moderator, the student as participant, exactly as with BBB.

What the LMS can do through the API

The compat-api module implements the following BigBlueButton API endpoints (docs.vuis.io):

Endpoint	Function
create	Create a room with an identifier, a name and parameters
join	Let a participant in with their name and role (moderator/participant)
end	End a meeting
isMeetingRunning	Check whether a meeting is running
getMeetingInfo	Get a meeting’s details (participants, duration and so on)
getMeetings	List every running meeting
getRecordings	List available recordings
Webhooks (callbacks)	Notify the LMS of events (participants joining or leaving)

Authentication works exactly as with BigBlueButton: every request carries a checksum parameter computed from the action name, the parameters and the shared secret. An LMS, or a tool such as API Mate, computes that checksum automatically.

What Vuisio adds over BBB inside Moodle

API compatibility is the way in, but under the hood everything changes.

Criterion	BigBlueButton	Vuisio (through compat-api)
Moodle plugin	Native (same plugin)	Native (same plugin)
Change on the Moodle side	None	None (URL plus secret)
Minimum server	16 GB RAM, 8 cores, dedicated Ubuntu	1 GB of RAM, 2 cores for ten participants
Server components	~12 (FreeSWITCH, Kurento, Redis, MongoDB, Meteor and others)	2 plus modules (Rust SFU and orchestrator)
Capacity per server	~200 participants (BBB FAQ)	450 to 500 (6 vCPU, under 2 GB of RAM)
Transcoding	Yes (FreeSWITCH mixes audio)	No (raw RTP relay)
Recording	Proprietary BBB format (conversion needed)	Native MP4
Encryption at rest	Not documented	AES-256-GCM (docs.vuis.io)
Server user account	Yes (Greenlight)	No (ephemeral identifier)
Turnkey sovereign cloud	No	Yes (free or Pro, France)
Sovereignty	Open source, self-hosted, Canadian vendor	Open source, self-hosted or French cloud, French vendor
Whiteboard	Yes (native to BBB)	Yes (module) (docs.vuis.io)
Voice anonymisation	No	Yes (docs.vuis.io)
Server updates	Ubuntu reinstall between major versions	Atomic vuisio upgrade with rollback (docs.vuis.io)

Can the Vuisio cloud be used with Moodle?

Yes. If you would rather not run a server at all, the Vuisio sovereign cloud exposes the same BigBlueButton-compatible API. It comes with the API key: one included in the Team plan, at €149 excl. VAT per month for five hosts, and an unlimited number on the Sovereign plan. The Pro plan does not open it. You then configure Moodle with the URL and secret of your cloud instance, and that is it: no server to administer, no updates to manage, hosting in France. When self-hosting, the compat-api module stays free, as noted above.

It is the simplest option for institutions with no IT department, or whose technical team is already stretched running Moodle itself.

Migration, step by step

1. If you do not have Vuisio yet: create a free cloud account or deploy an instance with vuisio-installer (docs.vuis.io).
2. Add the compat-api module: vuisio module add compat-api.
3. Retrieve the secret: vuisio secrets show --reveal COMPAT_API_SHARED_SECRET.
4. Change the Moodle configuration: Administration > Plugins > BigBlueButton > URL and secret.
5. Test: create a BBB activity in a course, join as a teacher and then as a student.
6. Check recordings: if you use the Pro plan, start a recording and check it appears in Moodle.

The migration is reversible: to go back to BBB, put your old server’s URL and secret back.

In summary

BigBlueButton established an integration standard in Moodle that other solutions can now implement. Vuisio is one of them: the compat-api module speaks the same protocol, uses the same plugin, and is configured by changing two fields. Under the hood, though, everything is different: a Rust SFU with no transcoding instead of twelve Java and JavaScript components, AES-256-GCM encryption at rest, a sovereign cloud hosted in France, and a server that runs on 1 GB of RAM.

If you are happy with BigBlueButton, there is no reason to change. But if you are after less maintenance, a lighter footprint, stronger sovereignty or simply a turnkey cloud so you never run a video server again, try Vuisio free: the migration takes five minutes and it is reversible.