Which Zoom alternative for online teaching fits FERPA and COPPA duties?
A school, university or training team that runs classes on Zoom needs to know who holds student and child data during a session before choosing a replacement. FERPA (34 CFR Part 99) applies to educational agencies and institutions that receive funds from a program administered by the US Secretary of Education, and it requires the institution to control access to education records and to log disclosures. *COPPA* (16 CFR Part 312) applies to operators that collect personal information from children under 13, including the written security program and retention rules that come with it. Institutions in the Title IV federal student aid programs also agreed to the GLBA Safeguards Rule (16 CFR Part 314) in their Program Participation Agreement, which adds a written information security program and multi-factor authentication for anyone accessing an information system. Ask counsel or your compliance lead which of these apply to your institution and to each class population before you go further.
In short, self-hosted BigBlueButton fits classes, structured sessions and training that need a whiteboard, polling, breakout rooms and LMS integration, and it keeps recordings and chat on servers you run. Jitsi Meet fits lighter meetings and ad hoc sessions where those teaching tools are not required. Whichever you choose, the controls that matter are concrete: who may create rooms and view recordings, how external contractors who operate the servers are placed under your direct control, how access to records is limited to the staff with a legitimate educational interest, and how retention and deletion periods are written down. Confirm with BigBlueButton and your identity provider how each role and login is configured in your own environment, since these are decisions you make, not defaults you inherit.
DeployOpen plans, implements, hardens and documents these environments and prepares the access controls, retention settings, logs and other evidence that a compliance review will ask for. DeployOpen does not issue audit reports, attestations or certifications, so any FERPA, COPPA or GLBA conclusion about your institution remains a decision for your counsel, your compliance function and, where required, an independent assessor. Ask any implementation partner to put the scope of controls, evidence and deliverables in writing before work begins, so you can see what is covered and what your own staff still have to decide.
What FERPA, COPPA and the Safeguards Rule require from a teaching platform
Schools, universities and training providers that move classes to a self-hosted platform inherit obligations for student and child data. The cards below cover the access, disclosure, retention and authentication duties that a virtual classroom must support, and they point to the regulation text your compliance lead should confirm against your own data flows.
Outside parties as school officials
A hosting partner, integrator or support contractor can see education records only if it performs a service the institution would otherwise staff internally, stays under the institution's direct control for how records are used and maintained, and respects the redisclosure limits. For a self-hosted classroom, put these terms in the contract and confirm who holds administrator access to recordings, chat logs and attendance data. Review the rule at 34 CFR 99.31(a)(1)(i)(B).
Access limited to legitimate interests
The institution must use reasonable methods, such as role-based permissions and technological access controls, so that school officials see only the education records tied to their legitimate educational interest. In BigBlueButton, map instructor, teaching assistant and administrator roles to what each needs, and test that a course recording from one class cannot be reached from another. Confirm how Greenlight room permissions and LMS roles interact before go-live.
Disclosure record for each request
FERPA requires a record of each request for access to, and each disclosure of, personally identifiable information from a student's education record, including who received it and their legitimate interest. Recordings, transcripts and exported attendance files all count. Self-hosted platforms do not produce this log automatically, so decide whether your web server, LMS or document store will keep it and for how long the records are kept.
COPPA security program and retention
Operators that collect personal information from children under 13 must maintain a written information security program with a designated coordinator and at least annual risk assessments, and they may keep that information only as long as reasonably necessary under a written retention policy with a deletion timeframe. Younger learners in virtual classrooms trigger these duties. Ask your vendor or integrator who the coordinator is and set automatic deletion for recordings and chat logs. See 16 CFR 312.8 and 312.10.
Safeguards Rule written program
Institutions participating in Title IV federal student aid agree to comply with the GLBA Safeguards Rule, which requires a written information security program covering the systems that hold student financial and personal data. A video platform that stores recordings or account data falls inside the perimeter you document. Record the platform in your risk assessment, its data flows and its patch and backup procedures, and keep the evidence ready for the annual compliance audit.
Multi-factor authentication for all access
The Safeguards Rule requires multi-factor authentication for anyone accessing any information system, which means administrators, instructors and support staff on the BigBlueButton server, Greenlight, the LMS plugin and the host operating system. Configure MFA on the identity provider that fronts Greenlight, for example through the Keycloak route the docs describe, and confirm that server SSH access uses it too. Ask your auditor how they will test this control.
Where Zoom's controls meet teaching requirements and where to confirm them
The first thing to settle is whether Zoom's controls cover your teaching obligations, and the supplied facts do not settle that on their own. Zoom Node runs on premises but is managed from the Zoom cloud, hosting modules such as Zoom Meetings Hybrid and Recording Hybrid, so meeting traffic may stay local while management, updates and some processing still depend on Zoom's cloud. Zoom saves recordings as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files, and these can be downloaded from the recordings page. Those files are useful for an exit, but a downloadable file does not show who could access a student's recording or how long Zoom keeps it.
Under FERPA, a vendor that receives education records as a school official must be under the institution's direct control for their use and maintenance. Under COPPA, operators that collect personal information from children under 13 must keep a written data retention policy with a deletion timeframe. Put these questions to Zoom in writing: where meeting, recording and transcript data is stored, how student data is processed, which retention settings apply to each file type, whether deletion can be enforced on request, and whether the contract limits access by outside parties. Ask for the data processing terms and the sub-processor list, not a verbal assurance.
Your own compliance lead or counsel should review the answers against 34 CFR Part 99 and 16 CFR Part 312, because neither the vendor's documentation nor this page can confirm FERPA or COPPA compliance for your account. The same review applies to a self-hosted option, where you would also need to document access controls, logging and retention yourself. Treat the written answers as a checklist for the migration decision: a platform that cannot answer them clearly is a platform you cannot yet approve for student data.
BigBlueButton, Jitsi Meet and Element Call compared for teaching use
This table compares three self-hosted options for teaching on access control, data location, logging and operating trade-offs. Read each row as a question to put to the vendor or your own test environment, because several capabilities depend on configuration and version. The main takeaway is that BigBlueButton is the closest fit for classes, while Jitsi is the lighter meeting tool and Element Call is best judged on whether your organization already runs Matrix.
| Criterion | BigBlueButton | Jitsi Meet | Element Call |
|---|---|---|---|
| License | LGPL-3.0, maintained by BigBlueButton Inc. with community contributors | Apache-2.0, maintained by 8x8, Inc., which also sells hosted JaaS | AGPL, delivered as part of Element Server Suite Community with Synapse |
| Core teaching tools | Slides with annotations, multi-user whiteboard, shared notes, polling and breakout rooms | Rooms-first meetings with screen sharing and chat; teaching tools such as polling and whiteboard are not a core focus, so confirm before relying on them | Voice and video within Matrix rooms; confirm whether whiteboard, polling and breakout equivalents exist in your version |
| LMS embedding | Built-in integration with Canvas, Moodle, Sakai, D2L and Schoology; confirm the connector version for your LMS | Embeds through the web app and common web integrations; LMS-specific connectors need to be built or sourced | No established LMS connector identified; treat LMS integration as a custom project |
| Access control | Greenlight can use external login through OpenID Connect, and Keycloak can add Google, Microsoft or SAML; API calls require checksums | Supports JWT tokens (recommended), internal XMPP accounts, LDAP and Matrix verification, configured in the .env file | Access follows Matrix room membership and Synapse accounts; confirm how moderator roles map to teacher and student roles |
| Data location and logging | Runs on your servers; recordings sit on the 500 GB disk you provision; verify log retention and where logs are written | Runs on your servers; recording through Jibri is per instance; verify the logs your Prosody and Jicofo stack keeps | Messages and media metadata are stored in your Synapse homeserver; confirm what call data is retained and for how long |
| Hardware needs | At least 16 GB RAM with swap, 8 CPU cores, 500 GB disk for recordings and 250 Mbit/s symmetrical bandwidth for BigBlueButton 4.0 | Central server suggested at 4 CPU and 8 GB; each videobridge 4 or 8 CPU with 8 GB, scaled horizontally | Depends on Synapse and call infrastructure sizing; confirm current requirements with Element before planning |
| Install and upgrade path | BigBlueButton 4.0 needs a clean Ubuntu 24.04 install because direct upgrades from 2.6, 2.7 or 3.0 are not supported | Debian 12 or Ubuntu 24.04 packages or Docker; HTTPS with a valid certificate is required for audio and video | Requires running Matrix services; this is a larger platform choice than a standalone classroom tool |
| Best fit | Structured classes, training and sessions that need whiteboard, polling and LMS embedding | Small teaching meetings, tutoring and quick sessions where a lighter stack matters more than classroom tools | Organizations already standardizing on Matrix for messaging who want voice and video in the same stack |
Choosing BigBlueButton or Jitsi by teaching situation
For courses run inside a learning management system, BigBlueButton is usually the better fit. It is embedded in LMSs including Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology, so instructors join sessions from the course page and keep their existing gradebook and access rules. Its whiteboard, shared notes, polling and breakout rooms match the way lecturers run seminars and group work.
- LMS integration: Confirm the LMS version and the integration method (LTI or a native plugin) with your LMS administrator before you choose a server layout.
- Server layout: BigBlueButton 4.0 installs on Ubuntu 24.04 with bbb-install.sh, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so plan a clean server rather than an in-place upgrade.
- Hardware: The install docs list at least 16 GB of RAM with swap, 8 CPU cores and 250 Mbit/s symmetrical bandwidth per server, with 500 GB of disk if you record.
- Network: Open TCP 80 and 443 and UDP 16384 to 32768, and plan a TURN server for students behind restrictive firewalls.
- Constraint: Choose BigBlueButton when breakout rooms and LMS-embedded access are required by the course design.
Check the installation and LMS steps against the current BigBlueButton documentation before you commit to a timetable.
For small tutoring sessions, office hours and staff meetings, Jitsi Meet is often the lighter choice. A self-hosted Jitsi deployment needs a web front end, Prosody, Jicofo and Jitsi Videobridge, and it can be started with Docker containers or Debian and Ubuntu packages. Participants join from a browser link without an LMS, which suits ad hoc sessions that do not need a gradebook or course structure.
- Deployment: The Debian and Ubuntu quick start supports Debian 12 or newer and Ubuntu 24.04 or newer, with OpenJDK 17, or the Docker setup can be used.
- Ports: Open 80/TCP, 443/TCP and 10000/UDP, with 5349/TCP for TCP fallback and 3478/UDP for STUN as optional items.
- HTTPS: Use a certificate for a proper domain, because the Jitsi handbook says self-signed certificates cause problems, especially with mobile clients.
- Authentication: Use JWT token authentication for staff and a separate anonymous domain for students as guests, since the secure domain method is deprecated for new installations.
- Constraint: Choose Jitsi when sessions are short, ad hoc and do not depend on whiteboard, polling or LMS integration.
Confirm with your IT team whether a single Jitsi server covers your peak number of concurrent meetings.
For lectures and town halls with large audiences, the choice depends on how the session is recorded and how many servers you can run. Jitsi scales videobridges horizontally by adding more, and its scalable setup guide suggests a 4 CPU, 8 GB machine for the central server and 4 or 8 CPU with 8 GB RAM for each videobridge. Recording and streaming run through Jibri, which the project describes as one recording per Jibri instance. BigBlueButton can also run large sessions, and Scalelite can pool several servers.
- Jitsi capacity: Plan one videobridge per group of participants and add bridges as load grows, since the default install is already set up for horizontal scaling.
- Recording: Jibri needs its own host resources, so budget one instance for each concurrent recording.
- BigBlueButton pooling: Use Scalelite to distribute meetings across several BigBlueButton servers, each built to the 4.0 specification.
- Bandwidth: Size outbound bandwidth from the number of viewers and the stream quality, and ask your provider to confirm symmetrical capacity.
- Constraint: Choose Jitsi with Jibri when the lecture must be streamed or recorded and the team is comfortable running several bridges and recorders.
Test a full-size session before the term starts, because audience size changes the server count more than any single setting.
What a BigBlueButton 4.0 server needs before classes start
Plan the server before anything else, because BigBlueButton 4.0 has a fixed hardware floor and a clean install requirement. The BigBlueButton install documentation calls for at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 250 Mbit/s of symmetrical bandwidth. Disk depends on whether sessions are recorded: 500 GB covers recordings, while 50 GB is the figure given for a server that will not record. Confirm these numbers against the current BigBlueButton install documentation before you order hardware, since the requirements can change between releases.
Network and name settings are where most first installs fail. The server needs TCP 80 and 443 reachable, UDP 16384 to 32768 open for media, a valid hostname with a certificate that browsers trust, and Docker, which the installer uses to run LibreOffice document conversion in a sandbox. Students on school or campus networks often sit behind restrictive firewalls that block UDP, so plan a TURN server for them. Ask your network team to confirm the UDP range is not blocked at the perimeter and that the hostname resolves from both inside and outside the campus.
Two decisions shape the rollout. First, BigBlueButton 4.0 cannot be reached by upgrading from 2.6, 2.7 or 3.0, so existing installs need a fresh server and a migration of rooms and recordings. Second, one server has a concurrency ceiling, and Scalelite can pool several BigBlueButton servers behind a single entry point when a school or training provider needs more simultaneous classes. Decide early whether one server will cover the expected peak, because adding a pool later means re-testing bandwidth and TURN for every node.
How to deploy BigBlueButton for classes under FERPA and COPPA controls
This sequence takes an institution from data classification to a tested, documented BigBlueButton service for classes, with access controls, retention rules and disclosure records that its own staff can show to auditors and parents.
Classify data and set retention with counsel
Legal counsel and the registrar or privacy officer decide which data classes the classroom service will hold: attendance, chat, polls, shared notes, recordings and any under-13 personal information. They confirm whether FERPA applies to the institution, whether COPPA reaches any student population, and how long each class of data may be kept. The output is a signed data inventory and retention schedule that the server configuration will follow. DeployOpen can prepare the technical mapping to that schedule, but the legal determinations stay with the institution.
Provision a clean server in the institution network
The institution's infrastructure team provisions a new server, or confirms a new virtual machine, on Ubuntu 24.04 inside its own network or data center. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so the host must be a clean install. Check the published minimums before ordering hardware: at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. The step is done when the host passes a baseline hardening review and its location and administrators are recorded in the asset inventory.
Install BigBlueButton with Greenlight or LTI
Staff run the bbb-install.sh script with the options that match the design, typically Greenlight for room management or LTI support for LMS launches, or both on one server. DeployOpen can run the installation under a written scope and document each option chosen. The host needs a valid hostname for SSL, TCP ports 80 and 443 reachable, UDP ports 16384 to 32768 open and Docker available for sandboxed document conversion. The step is complete when the service loads over HTTPS with a valid certificate and a test room starts with audio, video and a shared whiteboard.
Configure OpenID Connect sign-in with MFA
Greenlight v3 supports external authentication through OpenID Connect, configured with environment variables. The docs suggest Keycloak as a broker, which can add Google, Microsoft, SAML and other login methods, and it is the place to enforce multi-factor authentication for staff and instructor accounts. Identity staff register the client, map roles to instructor and student groups and disable local accounts that are not needed. The step is done when a test instructor and a test student each sign in through the identity provider, MFA is prompted for staff accounts, and an unlisted account is refused.
Store the API shared secret outside web pages
Every BigBlueButton API call carries a checksum computed with a secret shared with the server, using SHA-256 by default, and SHA-384 or SHA-512 is supported since version 2.5. The docs warn never to embed this secret in a web page. Administrators keep it in the server configuration file and in the LMS or integration vault, restrict read access to the people who run the service, and rotate it after any staff change. The step is complete when a scan of the LMS templates and public pages finds no secret and the team has recorded where the secret is held.
Connect the LMS and test classroom paths
Instructional technology staff register the BigBlueButton tool in the learning management system, such as Canvas, Moodle, Sakai, D2L or Schoology, and check that launches create the right room for the right course section. Before any live class, run a pilot with a small group of staff and volunteer students. Test the TURN server for users behind restrictive firewalls and confirm that UDP traffic reaches the media ports from the networks students actually use. The step is done when the pilot completes a full session with audio, video, polling, breakout rooms and a recording, and the network results are logged.
Set recording retention and deletion
Administrators apply the retention schedule from the first step to recordings, shared notes, chat exports and logs. Because COPPA requires a written data retention policy with a deletion timeframe for personal information from children under 13, the deletion job and its owner must be written down and tested with a sample record. Staff also confirm that backups follow the same schedule, which matters because deleted recordings may remain in backup sets. The step is done when a test recording is removed on schedule from the server and from backups, and the outcome is in the change record.
Document access logs and disclosure records
FERPA requires a record of each request for access to and each disclosure of personally identifiable information from education records, kept for as long as those records are kept. Institution staff define which access events the server and LMS log, how logs are retained and who reviews them, and they set up the disclosure register for any third party such as DeployOpen, which may act as a school official only under the conditions in the regulations. Staff also keep the written information security program, the access control list and the evidence from the pilot in one controlled folder. The output is a documented access and disclosure process that the institution can present to an auditor or parent request, and DeployOpen prepares the technical evidence without issuing any audit opinion.
What auditors and regulators will ask to see
Regulators and assessors judge a virtual classroom by the paperwork and access records around it, not only by how the video works. The cards below cover the artifacts that tie a BigBlueButton or Jitsi deployment to FERPA, COPPA, GLBA and MFA obligations. DeployOpen prepares these artifacts, while independent auditors and regulators assess them.
Written information security program
This is the document that describes how the institution protects student and customer information, who owns the program and how it is reviewed. The GLBA Safeguards Rule requires one, and the COPPA Rule requires a written information security program with a designated coordinator for operators collecting data from children under 13. For a self-hosted classroom, check that the program names the BigBlueButton or Jitsi servers, their hosting location, the people who administer them and the backup and patch process for each.
Users with legitimate educational interest
FERPA requires institutions to use reasonable access controls so that school officials see only the education records in which they have a legitimate educational interest. Keep a current list of staff, instructors, contractors and administrators with access to recordings, chat logs and transcripts. Confirm that a contractor who administers the servers is under the institution's direct control and bound by the redisclosure limits.
Disclosure and access record
FERPA requires a record of each request for access to and each disclosure of personally identifiable information from education records, kept for as long as those records are kept. Recordings, transcripts and chat exports from a virtual classroom can contain student names and statements, so they count. Ask whether the chosen platform and recording storage can log who downloaded or shared a file, and where those logs are kept and for how long.
COPPA data retention policy
Operators that collect personal information from children under 13 must keep it only as long as reasonably necessary for the purpose collected and maintain a written retention policy with a deletion timeframe. For a K-8 class or a youth training program, this policy has to cover recordings, chat history, transcripts, room metadata and server logs. Set the deletion timeframe in the policy, then confirm that the BigBlueButton recording cleanup and the storage lifecycle actually enforce it.
Annual risk assessment
COPPA requires at least annual risk assessments for operators handling children's personal information. Use the assessment to cover the video path, the TURN relay, the recording disks, the LMS integration, the administrator accounts and the backup copies. Record each finding, its owner and the fix date, because assessors ask for the trail of decisions as much as the document itself. DeployOpen can prepare the assessment inputs, while the institution or an independent assessor signs off on the results.
MFA configuration for administrators
The Safeguards Rule requires multi-factor authentication for anyone accessing any information system that holds customer information. For a virtual classroom, that covers server SSH access, the Greenlight or LTI administrator console, the backup system and the identity provider. Export the MFA settings from the identity provider and the server access policy, and keep a dated list of accounts that have MFA enrolled. Confirm which login methods the chosen Greenlight setup supports before writing the control.
What does a Zoom replacement for teaching cost and require?
What are the main cost drivers for a self-hosted BigBlueButton classroom?
The largest costs are servers, bandwidth, storage and the people who install and run them, because BigBlueButton has no license fee under LGPL-3.0. The BigBlueButton install documentation lists the minimum 4.0 server as at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk for recordings (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Add a TURN server for students behind restrictive firewalls, a valid hostname for SSL, and Docker for document conversion. Ask any quote to price hardware or cloud instances, recording storage growth, TURN hosting, and the staff time for installation, LMS integration and upgrades, separated into one-time and recurring items.
How long does a pilot for online classes take to set up?
The timeline depends on how many servers you need, how well your network allows the required ports through, and how many LMS and identity integrations you want in the pilot. BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit, and direct upgrades from 2.6, 2.7 or 3.0 are not supported, so a pilot should start on a clean server rather than an upgraded one. Firewall changes for TCP 80 and 443 and UDP 16384 to 32768 often take the longest in institutional networks. Ask the provider for a written schedule tied to a fixed scope, with dated milestones for network testing, LMS embedding, a test class and a go or no-go review.
Can a school deploy BigBlueButton itself without outside help?
Yes, a team with Linux administration skills can run the bbb-install.sh script on a clean Ubuntu 24.04 server, which can also install the Greenlight front end or LTI support on the same host. The harder parts are ongoing: TLS certificates, firewall rules, TURN configuration, capacity planning, monitoring, backups and upgrades between major releases. Many schools decide to keep operations in-house and buy a fixed-scope implementation or a retainer for the initial build and hardening. Decide based on whether you have staff who can own the system through each upgrade cycle.
What does a school IT team need to support BigBlueButton?
IT staff need to own the server host, network ports, certificates, identity integration and backups, and compliance staff need to know where student data is stored and who can access it. Plan for Greenlight external authentication through OpenID Connect, which the documentation suggests pairing with Keycloak for Google, Microsoft or SAML logins. API integrations must sign every call with a checksum built from a secret that never appears in a web page. Confirm with your LMS team which integration method they will maintain, and confirm your maintenance window for security patches.
What happens to existing Zoom recordings and transcripts?
Zoom saves cloud recordings as MP4 video, M4A audio, TXT chat, VTT transcript and CC.VTT caption files that you can download from the recordings page, so download and archive them before your Zoom subscription ends. Keep the files with their metadata, such as meeting date and course, and decide who may access them, because recordings often contain student voices and images. BigBlueButton does not import Zoom recordings, so plan separate storage for archived files. Ask the implementer to size storage for both new recordings and the archive.
Is Jitsi cheaper than BigBlueButton for small classes?
Jitsi can be the lighter choice for small, informal sessions with few tools, because a Jitsi deployment is built from a web front end, Prosody, Jicofo and Jitsi Videobridge, and it can run on a small central server with videobridges added as load grows. Its self-hosting guide suggests a 4 CPU, 8 GB machine for the central server, which is far below the BigBlueButton 4.0 minimum. However, Jitsi has no built-in whiteboard, polling, breakout rooms or LMS embedding in the way BigBlueButton offers them, so a Jitsi setup can need other tools for those functions. Compare the features your lessons need before comparing server bills.
What should a written quote for a virtual classroom include?
A written quote should follow a written scope and list each deliverable, including the servers and their specifications, bandwidth and TURN design, storage for recordings, identity and LMS integration, backup and restore testing, documentation, and training for staff. Ask for one-time costs and recurring costs separately, and for the assumptions behind concurrency and class sizes. Also ask what is excluded, such as Zoom recording migration, hardware purchases or ongoing support, and what a retainer would cover after go-live. DeployOpen does not publish a price list, and a quote follows from the written scope.
Does a self-hosted classroom platform make FERPA compliance automatic?
No, self-hosting does not make a school FERPA compliant on its own, because FERPA (34 CFR Part 99) applies to the institution's handling of education records, including who can access them, how disclosures are logged and how parents or eligible students can inspect records within 45 days. Contractors may be treated as school officials only under the conditions in 34 CFR 99.31(a)(1)(i)(B), and the institution must keep access controls and a disclosure record under 34 CFR 99.32. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications, so ask a qualified counsel or auditor to assess your program.
How DeployOpen deploys teaching platforms under education privacy rules
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted BigBlueButton or Jitsi Meet inside the institution's own infrastructure, whether that is its cloud account, data center or air-gapped network. We prepare the systems, controls and evidence that a compliance assessment will look at, while independent auditors and certification bodies issue any formal conclusions.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope names which courses, LMS integrations, roles and student groups the virtual classroom will serve.
- We record which education records, recordings and transcripts the platform will hold, and where they will be stored.
- Scope also states the hosting location, the server sizing basis and which legacy Zoom recordings must be archived.
How we build
- We deploy BigBlueButton 4.0 on a clean Ubuntu 24.04 server, since direct upgrades from earlier branches are not supported.
- We configure HTTPS with a valid hostname, the required TCP and UDP ports, and a TURN server for restrictive networks.
- We set up authentication through Greenlight with OpenID Connect or Keycloak, and restrict access so staff see only the rooms they need.
- We test LMS embedding, breakout rooms, polling and recording storage against a documented set of teaching scenarios.
How we hand over
- You receive architecture and data flow documentation covering where student personal information and recordings are held.
- We document access control settings, retention and deletion rules for recordings, and the records kept for disclosures.
- Runbooks cover backups, upgrades, capacity checks and the procedure for rebuilding the platform on a new server.
- Your staff are trained on administration, room management and the evidence needed for internal reviews.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover BigBlueButton maintenance releases, security patches and periodic restore tests of recordings.
- Security testing of the deployed application, APIs and infrastructure can be scoped separately in writing.
- Confirm with your legal and compliance teams which FERPA, COPPA or GLBA obligations apply before scoping begins.
Sources and further reading
- 34 CFR Part 99, Family Educational Rights and Privacy, eCFR ↗
- FSA Electronic Announcement GENERAL-23-09: Updates to the Gramm-Leach-Bliley Act Cybersecurity Requirements ↗
- BigBlueButton install docs ↗
- Greenlight v3 external authentication ↗
- BigBlueButton API ↗
- bigbluebutton/bigbluebutton GitHub repository ↗

