Why schools and universities look for a Google Meet alternative
Education institutions usually weigh Workspace for Education against a self-hosted classroom for one of three reasons: student data protection, data residency, or who operates the servers during term time. In most setups, BigBlueButton inside the LMS covers classes, and Jitsi Meet covers staff meetings. Meet is not a standalone line item in this comparison, because it arrives bundled with the Workspace edition the institution already licenses, so the real question is what the institution gives up or takes on by moving those sessions elsewhere. The right answer depends on the institution's federal funding and the age profile of its students, since those determine which student privacy rules apply.
For a US institution that receives funds under a program administered by the Secretary of Education, the FERPA regulations in 34 CFR Part 99 govern education records, and a meeting recording or chat log can become one. A self-hosted platform only helps if the institution can show that the vendor or contractor operating it is under its direct control and that access is limited to people with a legitimate educational interest. Under-13 students add the COPPA Rule, which requires a written retention policy with a deletion timeframe. Confirm with counsel which of these rules applies to your students before scoping any migration.
Operating the servers is the decision most often underestimated. A BigBlueButton 4.0 server needs at least 16 GB of RAM, 8 CPU cores and 500 GB of disk for recordings, and it must be on a clean Ubuntu 24.04 installation because direct upgrades from earlier versions are not supported. Those servers have to stay up during exam periods and enrollment peaks, which is when a central IT team is least available for maintenance. Ask who will hold the on-call duty, who applies security updates to the LMS and the video server, and who keeps the logs and records that FERPA requires institutions to maintain.
What FERPA, GLBA and COPPA require of a meeting platform
Three US federal rules shape what a school or university must control when meetings, recordings and chat move onto a new platform. Which of them apply depends on the institution's funding, its federal aid status and the age of the people it serves, so confirm scope with counsel before choosing an architecture. The cards below set out each duty and what to check in a self-hosted design.
FERPA scope and school officials
FERPA's regulations in 34 CFR Part 99 cover any educational agency or institution that receives funds under a program administered by the US Secretary of Education. An outside party such as a hosting provider or contractor can handle education records as a school official only when it performs a service staff would otherwise do, stays under the institution's direct control for those records, and follows the redisclosure limits. Check whether your hosting contract and support access meet all three conditions before recordings or chat logs containing student information are stored on the platform.
Access limited to legitimate interest
The institution must use reasonable methods, such as technological access controls, so that school officials see only the education records in which they have a legitimate educational interest. For a meeting platform, this means role-based access to recordings, transcripts and chat exports, not one shared administrator login. In a self-hosted Jitsi or BigBlueButton setup, the institution sets these rules through its identity provider and storage permissions. Map who can open each recording type and test that a teacher in one course cannot reach another course's files.
Disclosure logging under 34 CFR 99.32
FERPA requires the institution to record each request for access to, and each disclosure of, personally identifiable information from education records. The log must name the parties and their legitimate interests, and it must be kept for as long as the records are kept. Meeting platforms rarely produce this log on their own, so the institution needs to decide whether its server logs, download events and admin actions are retained in a form that can answer a request. Confirm the log retention period before recordings are moved onto the platform.
GLBA Safeguards duties for Title IV
Institutions in the Title IV federal student aid programs agree in their Program Participation Agreement to comply with the GLBA Safeguards Rule in 16 CFR Part 314. The rule requires a written information security program and multi-factor authentication for anyone accessing any information system. It also requires FTC notification within 30 days of discovering a notification event affecting at least 500 consumers. Check that every admin and remote access path to the meeting servers uses MFA and that the incident runbook includes the 30-day clock.
COPPA security program and retention
The COPPA Rule in 16 CFR Part 312 applies to operators that collect personal information from children under 13, and it requires a written information security program with a designated coordinator and at least annual risk assessments. Operators must also keep children's data only as long as reasonably necessary and maintain a written retention policy with a deletion timeframe. This matters for K-12 classes and younger learners on any platform. Ask who the operator is in each setup and whether a written retention schedule covers recordings and chat.
How BigBlueButton and Jitsi Meet fit classroom and staff use
BigBlueButton is built as a virtual classroom, and its feature set maps closely to live teaching: audio, video, slides with annotations, chat, screen sharing, polling, a multi-user whiteboard, shared notes and breakout rooms. It is embedded in learning management systems including Canvas and Moodle, so students join from the course page they already use rather than from a separate meeting link. Because the server is in your own infrastructure, recordings and chat logs stay under your control, which matters for student records handled under FERPA.
- Classroom tools: Whiteboard, polling, shared notes and breakout rooms are part of the core product, not add-ons.
- LMS embedding: Canvas and Moodle embed BigBlueButton, so access follows course enrollment.
- Recordings: Sessions are stored on your server, which needs disk sized for recordings (the BigBlueButton 4.0 install docs give 500 GB with recording and 50 GB without).
- Gaps: Google Calendar scheduling and Drive-based recording storage have no direct equivalent, so timetabling and file sharing move to your LMS and file platform.
- Sizing: Class sessions with many concurrent users need the server specification in the install docs and a load test before term.
Confirm with the vendor or in a pilot which LMS version and plugin route your institution will use, and test a full class with breakout rooms before committing.
Jitsi Meet suits staff, committee and admin meetings that need a quick link without a classroom structure. It is an Apache-2.0 licensed platform, and a self-hosted deployment consists of the web front end, Prosody, Jicofo and Jitsi Videobridge, with Jibri for recording and Jigasi for SIP as options. Jitsi's self-hosting guide states that HTTPS is necessary for multimedia to work, so the hostname and certificate are the first items to plan.
- Simple joining: Meetings open in a browser with a link, which suits guests and external committee members.
- Authentication: Staff sign-in can be configured, but confirm the method your identity provider supports in the Jitsi handbook before you plan the rollout.
- Recording: Jibri records on the Jitsi side, so recordings are not in Drive and need their own retention and access rules.
- Gaps: Calendar invitations, room booking and Drive file sharing from Google Workspace must be rebuilt with your calendar and file tools.
- Scaling: Videobridges are added as load grows, so capacity planning is an operational task.
Ask your team to test calendar invitation workflows and external guest access during the pilot, since these are where Workspace users notice differences most.
Element Call provides voice and video inside the Matrix ecosystem, and Element Server Suite Community includes it alongside Synapse under AGPL. This option fits institutions that want one self-hosted tool for persistent chat between staff and students and calls that happen inside those conversations. It is a different model from a scheduled classroom, so it is better treated as a complement than as a replacement for BigBlueButton in teaching.
- Chat and calls together: Calls start from the same conversation as messages, which reduces tool switching for working groups.
- Self-hosted server: Synapse runs on your infrastructure, so message history stays with you.
- Licensing: Check the Element pricing page for which components are in the Community bundle and which are commercial.
- Gaps: A classroom with polling, breakout rooms and shared notes is not the design goal here, and calendar integration with Workspace is limited.
- Client rollout: Staff and students need Matrix-compatible clients, so plan user onboarding and device support.
Confirm in a pilot whether Element Call covers the group sizes and call quality your departments need, and whether your data protection officer is comfortable with chat retention settings.
Where student data lives when Meet moves to your servers
Once meetings run on your own servers, the recordings, chat logs, transcripts and attendance data they produce become education records that your institution holds and must control, retain and disclose under FERPA (34 CFR Part 99). Before cutover, map every data type a BigBlueButton or Jitsi session creates, decide where each one is stored, and set a retention period for each. Recordings of lectures in which a student is identifiable, and chat that names students, are the items most likely to be overlooked, because they sit outside the learning management system's gradebook but still fall within the FERPA definition. Confirm with your registrar and general counsel which of these items your institution treats as education records and how long each must be kept. If an outside hosting or support provider operates the servers, that provider can receive education records only as a school official under the conditions in 34 CFR 99.31(a)(1)(i)(B). In practice, the provider must perform a service your staff would otherwise do, remain under your direct control for the use and maintenance of the records, and follow the redisclosure limits in 99.33(a). Put these conditions into the service agreement, and ask any hosting partner to state where backups, logs and support access sit. Your own team should also decide who can see recordings and reports, because FERPA requires reasonable access controls that limit school officials to the records in which they have a legitimate educational interest (34 CFR 99.31(a)(1)(ii)). Access control is where most of this work happens. In Moodle, use roles and course-level enrollment to limit who can view recordings, grades and attendance, and review the role assignments each term. For login, LDAP, SAML or OpenID Connect can tie BigBlueButton's Greenlight front end and Moodle to your directory so that account removal takes effect everywhere. Moodle 5.1 also requires that the web server document root point to the new /public directory rather than the main Moodle folder, and the release notes warn that a misconfigured root can expose directory listings, so include this check in your go-live test. Confirm which authentication plugin your identity provider supports before you commit to a design.
Deploying BigBlueButton 4.0 and Jitsi Meet during term time
This sequence takes a school or university from requirements to a piloted BigBlueButton 4.0 classroom linked to its LMS, plus a Jitsi Meet server for staff meetings, with each stage ending in a check you can record.
Confirm requirements and records scope
The institution's data protection or registrar lead, with the LMS administrator, lists which courses, recordings, chat logs and student identifiers the classroom will hold, and which regulations apply to them. This decides whether the server needs a recording store, how long recordings are kept and who in the institution holds the school official role for any contractor. Done when the scope sheet names the data categories, retention owner and the staff who approve access, and the list is signed off before any server is ordered.
Size a clean BigBlueButton 4.0 server
The infrastructure team provisions a dedicated server for BigBlueButton 4.0 on Ubuntu 24.04 64-bit. The install documentation calls for at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, 500 GB of disk if recordings are kept (50 GB without recording) and 250 Mbit/s symmetrical bandwidth. Confirm these figures against the current install page, since the server must be sized for peak term-time class load, not average use. Done when the host passes a baseline check against each requirement and the team has recorded the disk plan for recordings.
Open ports and prepare the hostname
The network team opens TCP 80 and 443 and UDP 16384 to 32768 to the server, and assigns a valid hostname that can carry an SSL certificate. Docker must be available for sandboxed LibreOffice document conversion, and a TURN server is recommended for students behind restrictive firewalls, such as campus guest networks. Confirm the firewall rules from outside the network, not only from the server. Done when the hostname resolves, the certificate chain is valid and external port checks succeed on each required port.
Install with bbb-install.sh and the front end
The platform engineer runs the bbb-install.sh script on the clean host, adding the Greenlight room manager or LTI support in the same run if the institution wants both. Greenlight is the simpler route for staff-run rooms, while LTI is the route for launching classrooms from Moodle or Canvas. Record the exact installed version and the options chosen. Done when the BigBlueButton login page loads over HTTPS, a test meeting joins with audio, video and screen sharing, and the version matches the 4.0 release.
Connect Moodle or Canvas and set authentication
The LMS administrator registers the BigBlueButton server in Moodle or Canvas using the shared secret and API settings, and confirms that the course activity launches a room. Greenlight v3 supports external authentication through OpenID Connect, and the documentation suggests Keycloak to add Google, Microsoft or SAML sign-in, so the identity team should decide whether students sign in through the institution's directory. Keep the shared secret out of any web page, because API calls depend on it. Done when a student account from the institution's directory can open a course room, and a staff account can create one, without a shared guest login.
Stand up Jitsi Meet with HTTPS
The platform engineer deploys Jitsi Meet for staff meetings, using the Docker containers or Debian and Ubuntu packages described in the Jitsi self-hosting guide. Jitsi needs HTTPS for multimedia to work, so the certificate must be in place before any testing. Decide early whether the server will use Jibri for recording, since that adds its own resource needs. Done when a staff member joins a meeting from an institution browser and a mobile device over HTTPS with camera and microphone working.
Pilot with one course
The academic lead selects one course and one staff meeting group for a limited pilot. Instructors run a session using the whiteboard, breakout rooms, polling and shared notes, and the support desk logs each issue with the browser, device and network. Check that recordings land where the scope sheet says they should and that access matches the approved roles. Done when the pilot record lists the issues found, each has an owner and a fix, and the academic lead approves wider rollout.
Plan maintenance outside exam periods
The operations lead builds a change calendar that keeps upgrades and restarts out of assessment and exam windows, and records the approved window for each change. Because direct upgrades from 2.6, 2.7 or 3.0 are not supported, an existing 3.0 deployment is replaced with a clean 4.0 server rather than upgraded in place, and the 3.0 branch receives maintenance releases in the meantime. Schedule a rehearsal on a test server first. Done when the calendar and the migration runbook are approved, and the institution knows who can authorize an emergency change during term time.
What schools and universities ask before choosing an open-source classroom
What costs recur when running BigBlueButton for a school or university?
The recurring costs are the servers, the bandwidth, the storage for recordings, and the people who keep the platform running, while the software itself carries no license fee. BigBlueButton 4.0 needs 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, according to the BigBlueButton install documentation. Recording storage grows with term time and retention policy, so it is the cost most institutions underestimate. One-time costs include the initial build, LMS integration, single sign-on and staff training. Ask any partner for a quote that separates hardware or cloud spend, bandwidth, storage, setup and annual support so you can compare it against your current Google Workspace for Education renewal line by line.
How long does a pilot take to run before a full rollout?
The pilot length depends on the scope you agree in writing, not on a fixed period. The main inputs are whether BigBlueButton runs inside Moodle or Canvas or as a standalone room, how many courses and staff accounts are connected, whether single sign-on is required, and how much hardware is already available. A clean server install is recommended for BigBlueButton 4.0, because direct upgrades from 2.6, 2.7 or 3.0 are not supported. Confirm with the vendor or partner which parts of the pilot are fixed-scope deliverables and which depend on your identity provider's readiness. Plan for an ordinary term-time test with real instructors, since load and recording behavior differ from a lab test.
Who in IT must operate the servers during term time?
Someone on your team must own uptime, patching, backups and capacity during term time, whether the servers sit in your data center or in a cloud account you control. BigBlueButton depends on TCP ports 80 and 443, UDP ports 16384 to 32768, a valid hostname for SSL, Docker for sandboxed document conversion, and a TURN server for users behind restrictive firewalls. Those network and certificate tasks need named owners. Moodle also has its own upgrade calendar: Moodle 5.1 requires PHP 8.2 or later and its web root moves to the /public directory. Decide before pilot start who is on call during exams and who approves maintenance windows, because a failed server on a lecture day is an incident, not a ticket.
Can our staff run an open-source classroom without an outside partner?
Yes, some institutions run it in-house, but the answer depends on existing Linux, networking and LMS administration skills and on how many people can cover the platform during term. Staff who already run Moodle servers have a head start, though BigBlueButton adds real-time media, UDP networking and recording storage that most web teams have not managed before. Check whether you have at least two people who can respond to an outage, and whether they can handle an in-term upgrade. A partner can plan, install, integrate, harden, back up and document the system within a fixed scope, and can offer ongoing support as a retainer. Compare that with the cost of recruiting or training your own staff.
What should we ask for in a written quote for a school deployment?
Ask for a written scope that names every deliverable, the systems covered, and what the institution must provide. Request the list of hosting assumptions, including server sizing against the BigBlueButton 4.0 requirements, bandwidth, and where recordings are stored. Ask how Moodle or Canvas integration, single sign-on and certificates are handled, and who approves changes to scope. Confirm which items are one-time and which recur, such as support, upgrades and security testing. Ask how backup and restore are tested and how the team documents the system for auditors. DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and provides a quote from the written scope.
How do FERPA and GLBA duties split between the institution and the vendor?
The institution remains responsible for FERPA compliance, while a contractor that receives education records can act as a school official only under specific conditions. Under 34 CFR 99.31(a)(1)(i)(B), the outside party must perform a service the institution would otherwise do with employees, remain under the institution's direct control for use and maintenance of records, and follow the redisclosure limits. The institution must also use access controls so school officials see only records they need, and keep a record of disclosures under 34 CFR 99.32. For GLBA, the Safeguards Rule in 16 CFR Part 314 requires a written information security program and multi-factor authentication for anyone accessing an information system, and Title IV institutions agreed to comply. Your counsel should map each duty to a named owner in the contract. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications; independent auditors do.
Can BigBlueButton replace Google Meet recordings saved in Drive?
BigBlueButton can record sessions to your own servers, but it does not read or migrate recordings already stored in Google Drive. Recordings from a BigBlueButton session are kept on the server disk, which is why the 500 GB recording allowance in the install requirements matters. Plan how existing Drive recordings will be exported, reviewed for student personal information, and moved into a retention policy you control. Confirm with the vendor or your partner how recordings are linked from the LMS, who can view them, and how deletion works when a retention period ends. Google's own export options and their timing rules are covered in a separate guide, so check those before planning any migration of old recordings.
Evidence that regulators and auditors ask for
A self-hosted classroom is only as defensible as the records behind it. The cards below list the documents and logs that FERPA, COPPA and GLBA reviewers typically ask an institution to show, and that a self-hosted BigBlueButton or Jitsi deployment must generate on its own. DeployOpen prepares these systems, controls and evidence for your assessment, but independent auditors and certification bodies issue any audit report or certification.
Written information security program
The GLBA Safeguards Rule requires a written information security program, and COPPA's operator rules call for a written program with a designated coordinator and at least annual risk assessments. For a self-hosted classroom, this document should name the people who own the BigBlueButton or Jitsi servers, the Moodle site and the recordings store, and state how each is assessed each year. Confirm with your counsel which rules apply to your institution, since FERPA, COPPA and GLBA do not all reach every student population or program.
Access control configuration and review
FERPA expects institutions to use physical or technological controls so school officials see only the education records tied to their legitimate educational interests. Keep a current export of Moodle role assignments, Greenlight or Keycloak user groups, and the BigBlueButton admin accounts, and record who reviewed them and when. Check that the auth settings and the shared secret used for API checksums are restricted to the operators who need them.
Disclosure log for student records
FERPA requires a record of each request for access to, and each disclosure of, personally identifiable information from education records, including the parties involved and their legitimate interests. In a self-hosted setup, the disclosure log must cover contractor access too, such as DeployOpen staff or a hosting provider with administrative rights to the servers. Ask your team to define what counts as a disclosure for recordings, transcripts and chat logs before the first term begins.
Retention and deletion schedule for recordings
Class recordings, chat logs and transcripts can contain children's personal information, and COPPA requires a written data retention policy with a deletion timeframe. The policy should cover where BigBlueButton stores recordings, how long they stay on disk, and who approves deletion. Confirm the retention period with your records office and test the deletion job on a copy before relying on it, because a sizing plan that reserves disk for recordings also needs a retention rule.
MFA records for system access
The Safeguards Rule requires multi-factor authentication for anyone accessing any information system. Keep records showing which administrators, teachers and staff accounts have MFA enabled, which identity provider or Keycloak realm enforces it, and when exceptions were granted and removed. Remember that a self-hosted Greenlight or Moodle login is outside the reach of Google's own enrollment settings, so the evidence has to come from your configuration.
Incident notification procedure
The Safeguards Rule requires notice to the FTC within 30 days of discovering a notification event affecting at least 500 consumers. Write a runbook that names the contact for each system (BigBlueButton servers, Moodle, the identity provider and the storage bucket for recordings), the steps to preserve logs, and the person who decides whether to notify. Run a tabletop exercise once a year and file the results with the security program so an assessor can see that the procedure was tested.
What moving classes and recordings actually involves
Moving classes is mostly a question of where course links, recordings and student identities live, and who has to change what before the first lecture. Start by inventorying every Google Meet link embedded in the LMS, syllabi, calendar invites and room bookings, because each one needs a replacement BigBlueButton or Jitsi room URL and a plan for the old link to redirect or stop working. Recordings sitting in Drive need their own pass: list the owners, the folders and the sharing settings, then decide which files move into the new system and which are deleted. The FERPA and COPPA retention rules apply to what you keep, so record the basis for each retained recording before copying it.
LMS integration is where the work tends to concentrate. BigBlueButton is embedded in Moodle through its plugin and in Canvas, so confirm the exact plugin version, the LTI or API configuration and the role mapping for instructors and teaching assistants in a staging copy of your LMS. Moodle 5.1 and 5.3 each carry their own PHP, database and web root requirements, and from Moodle 5.1 the web server document root must point to the /public directory, so check these before you change anything in production. Test that moderator rights, recording permissions and breakout rooms behave as your instructors expect. No supplied fact confirms feature parity with Meet, so run a pilot course that exercises every Meet feature your faculty actually uses, such as captions, screen sharing and attendance reports, and record the gaps.
Students who cannot use the new login are the most predictable failure point, and they need a written fallback before cutover. Identify who cannot authenticate through the standard path, including guests, visiting students, alumni and accounts without a directory identity, and decide whether they receive local accounts, an external login or a temporary guest link. Greenlight v3 can use OpenID Connect, and the project suggests Keycloak for Google, Microsoft and SAML login methods, so confirm which of these your identity provider already supports. Decide retention before the move rather than afterward: set a deletion timeframe for children's data where COPPA applies, keep the disclosure log that FERPA requires for each access request, and confirm with your registrar and counsel which recordings count as education records. Ask your vendor to document how those deletion and access logs are produced.
How DeployOpen deploys a classroom under education privacy rules
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, including BigBlueButton and Jitsi Meet for education. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.
How we scope
- Map which courses, staff groups and meetings move off Workspace and which stay put during term time.
- Document where student records, recordings and chat logs will be stored and who can access them.
- Confirm with your legal and privacy office which FERPA, COPPA or GLBA obligations apply to your institution.
How we build
- Size and install BigBlueButton 4.0 on a clean Ubuntu 24.04 server, with the LMS integration your Moodle or Canvas setup needs.
- Set up single sign-on through your identity provider, and configure Jitsi Meet for staff meetings with HTTPS enabled.
- Set recording retention and deletion rules, then test access controls so staff see only the records they need.
How we hand over
- Deliver architecture, configuration, access control and retention documentation that your IT and compliance teams can review.
- Provide runbooks for term-start checks, server restarts, upgrades and incident response for the classroom servers.
- Walk your operations staff through the handover so they can run the platform without depending on us day to day.
How we support
- Offer ongoing support, upgrades and continuous security testing as a retainer after handover.
- Plan Moodle and BigBlueButton upgrades around academic calendars and the support windows published for each release.
- Prepare systems and evidence for your compliance assessments. Independent auditors, not DeployOpen, issue audit reports and attestations.
