BigBlueButton Certified Service Provider
The full capability list
Everything ZcaleRight does with your BigBlueButton fleet.
The complete list, grouped the way the product is. Every line is something the software does today, in the box — no add-ons, no separate modules, no second product to buy.
01
Dashboard and visibility
One screen for the whole BigBlueButton fleet, refreshing on its own, so nobody has to open a terminal to answer a question.
- Servers in use, live meetings, participants and storage at a glance
- Historical usage, so you can see the shape of a term rather than a moment
- Recording storage totals with a connection check and an export
- System alerts surfaced in the interface, including provider rate limits
- Application logs readable by administrators without shell access
Dashboard
Auto-refreshing
Servers up
14
2 transient
Live meetings
33
across 3 pools
Participants
797
peak today 1,204
Recordings
4.2 TB
S3 · 9,841 items
Participants, last 14 days
Pools
- Classroom 18/24
- Webinar 6/12
- One-to-one 9/30
Example figures. Your own fleet, on one screen.
02
Servers and pools
Permanent servers for baseline capacity, transient ones for peaks, and pools that decide which meetings land where.
- Permanent servers, probed continuously so an unhealthy node leaves rotation in seconds
- Transient servers that register, send heartbeats and disappear when idle
- Pools by use case — one-to-one, webinar, classroom — with servers assigned to each
- A cap per pool and a cluster-wide cap above it
- Enabled and reachable are separate states, so you can drain a server without deleting it
- A test meeting on any server, straight from the interface
Cluster
Live
| Server | Pool | Meetings | People | Load |
|---|---|---|---|---|
| bbb-01.example.edu | lectures | 14 | 312 | 62% |
| bbb-02.example.edu | lectures | 11 | 248 | 48% |
| bbb-03.example.edu | exams | 3 | 96 | 19% |
| bbb-07.example.edu | exams | 0 | 0 | 0% |
| bbb-11.example.edu | overflow | 6 | 141 | 31% |
Example data. Your own cluster, in one view.
03
How a meeting is placed
Placement is a decision made once, at create, and then never revisited — because the most reliable route is the one that never changes underneath a running class.
- Two strategies: one cap for every server, or a cap per pool
- An LMS can ask for a pool by name on create, so a masterclass never lands on a webinar box
- Strict pooling, when a request for a pool must mean that pool and nothing else
- A server that stops answering leaves rotation in seconds, not on the next sweep
- A meeting stays on the server that started it, and every later call — join, end, chat, documents — is routed to that same server
- Create is locked per meeting id, so two retries from the same LMS cannot open two rooms
04
Meetings and live support
Everything running right now, who is in it, and the ability to step into a session that is going wrong.
- Live, all and ended views over the whole fleet
- A live participant summary per meeting
- Join a running meeting as technical support, without asking for credentials
- End a meeting for everyone when it needs to stop
- Advanced search across meetings
- Spreadsheet export for reporting and reconciliation
05
Recordings
One library for every server, with links that keep working after the machine that made the recording is gone — whether the files themselves ever move or not.
- A single catalogue with metadata, whatever produced it
- Recordings can stay on the BigBlueButton servers that produced them: central storage is an option, not a prerequisite, and nothing has to be mounted on every node for the library to work
- Or move them to S3-compatible object storage or SWIFT, with playback links rewritten to your own player
- Publish, unpublish and delete from the interface
- The standard BigBlueButton formats plus commercial ones, with MP4 processing status
- Recordings leave publication, and are deleted, on the schedule you set — so a retention policy holds without anyone remembering to apply it
- Spreadsheet export including playback links
Recordings
Central storage
| Recording | Date | Size | State |
|---|---|---|---|
| LAW-204 · Contract Law | 2026-09-03 | 412 MB | Published |
| MED-118 · Anatomy Lab | 2026-09-03 | 1.1 GB | Published |
| ENG-330 · Seminar | 2026-09-02 | 286 MB | Processing |
| BUS-101 · Intake | 2026-09-01 | 694 MB | Unpublished |
Example rows. One library, whatever the fleet does behind it.
06
Policy you set once, for everything
Rules that used to live in every LMS separately now live in one place, and apply to every meeting the cluster creates.
- Force recording on — or off — across the whole fleet, without touching a single LMS
- Your logo injected into every meeting that is created
- A default presentation dropped into every room
- One welcome message for the whole platform
- The display name your support staff appear under when they join
- Student webcams kept out of recordings for Schoology sessions, for the schools that require it
07
Who can see what
Six roles, drawn around jobs that actually exist on an operations team, so nobody has to be an administrator to do their part of the work.
- Admin, customer, support, recordings reviewer, quality assurance, and an API account for your own automation
- Every action is granted per role — the permission matrix is published, not implied
- A reviewer who can open recordings for compliance and nothing else
- A quality role that joins live sessions to assess them but never sees the library
- A machine account that can only reach the automation endpoints, and never the interface
- Password rules, unique sign-in identities and sessions purged when they expire
08
Tenants and your own name on it
Sell conferencing to your own customers from one cluster, under your brand, with each of them isolated from the others.
- A separate API secret per tenant, checked on every call
- Site name, short name, logo, favicon and primary colour
- Your own terms and privacy links in the footer
- Your powered-by line, not ours
- Each tenant sees only its own meetings and recordings
09
Ways in that are not a BigBlueButton URL
The entry points people ask for once the platform stops being a pilot: one hostname, a phone number, a short guest link.
- Sessions embedded under your own hostname, so nobody sees a server name in the address bar
- Short guest links, for the people who will never have an account
- Telephone dial-in routed to the right server by keypad, through your PBX
- A route to the learning analytics dashboard on whichever server holds the session
- A public join page you can open for a day, for a benchmark or a sales call, that closes itself
10
Capacity that follows demand
Servers appear for the peak and leave when the timetable empties, without anyone watching a dashboard at eight in the morning.
- Capacity on a schedule you build in the interface — dates, weekdays, hours, size
- Or driven by live load, checked every minute
- A minimum per pool, so scaling down can never take the last server with it
- A prepaid credit projection that warns — or refuses — before capacity is added
- A signed event the moment the cluster has no idle capacity left
11
Two APIs and events you can trust
One API for the tools that already speak BigBlueButton, another for your own orchestration, and signed events so your systems hear about capacity before your users do.
- A full BigBlueButton API in front of the fleet — only the address and the shared secret change
- A separate automation API for provisioning, metrics and recordings ingest
- A cluster snapshot endpoint: meetings, participants, servers in use, servers up
- Register a server, send heartbeats, announce an IP, ask whether a node may be torn down
- Register a recording that already lives in your storage, so it survives the server that made it
- Outbound events signed with HMAC, with a delivery id that stays the same across retries
12
Running it day to day
The unglamorous half of a platform: the health endpoint your upstream balancer polls, the jobs that keep the cluster honest, and the alerts that tell you before a customer does.
- A public health endpoint your upstream balancer or uptime monitor can act on, revealing nothing about what is behind it
- Twenty background jobs on one schedule, none of which can ever overlap itself
- Alerts that raise themselves on repeated failure and clear themselves on recovery
- Per-server CPU, RAM, meetings, users, streams and screen shares through Zabbix, collected every minute
- Push a document into a running meeting straight from a Seafile shared link
- The full documentation inside the product, for every signed-in user
Connects to
Server monitoring
Collected every minute
System resources
BigBlueButton usage
- Meetings 33 / 48
- Users 797 / 1,204
- Audio 731 / 1,204
- Video streams 214 / 480
- Screen shares 12 / 48
Example figures. Per server and across the fleet.
Compatibility
Keep the front-end you already use.
ZcaleRight presents your whole fleet as a single BigBlueButton server, so anything that already speaks the BigBlueButton API keeps working exactly as it does today. Your users see no change.
- Greenlight
Product names and marks belong to their owners and appear only to say what ZcaleRight is compatible with.
See it against your own fleet.
Send us your server list and your busiest week, and we will show you exactly what changes.