Why self-hosted video conferencing for education is a privacy and timetable problem
BigBlueButton fits LMS-centred virtual classrooms, while Jitsi fits lighter meetings and guest access. The design is driven by two forces: FERPA-style duties over student records and the load that appears when every timetabled class starts at the same minute. An education IT leader running a generic meeting tool would be asking the wrong questions. The real questions are which courses must work inside the learning management system, who can join a session that carries student information, and how many classes can start together without degrading the lecture in progress.
A generic deployment treats a meeting as a room with a link. In a school or university, a session is a course event linked to an enrolment roster, so authentication, roles and lobbies must follow the course record, not an ad hoc invitation. FERPA's regulations in 34 CFR Part 99 apply to institutions that receive Department of Education funds, and they require reasonable access controls so that school officials see only the records tied to their legitimate educational interest (34 CFR 99.31(a)(1)(ii)). Recordings of a seminar that includes student names or contributions can therefore become education records, which changes who can view, store and delete them. Confirm with your registrar and counsel how your institution classifies recordings before you pick a retention period.
Timetable load is the second constraint. Demand peaks at the top of the hour and at the start of term, so capacity planning must cover the busiest slot, not the average day. Ask your partner how many BigBlueButton servers or Jitsi videobridges your timetable requires at peak, how recording storage is provisioned per term, and how upgrades avoid exam weeks. Also check whether the contractor will be treated as a school official under the conditions in 34 CFR 99.31(a)(1)(i)(B), since that decides what access agreements and direct-control terms the engagement needs.
Which education rules shape the video conferencing build
This table maps the education and accessibility rules that touch a self-hosted classroom build to the design decisions they force, such as who can open recordings, how access is logged and how long recordings are kept. Read each row as a requirement that your architecture, identity setup and vendor contract must satisfy, then confirm the exact obligations with your counsel and compliance team.
| Rule | What it requires for the build | What to confirm or evidence |
|---|---|---|
| FERPA access controls (34 CFR 99.31(a)(1)(ii)) | Limit recording and chat access to school officials with a legitimate educational interest, using role-based groups tied to course enrollment rather than open links | Role mapping from the LMS or directory, documented group membership and access reviews per term |
| FERPA disclosure logging (34 CFR 99.32) | Log each request for and disclosure of student identifiable recordings, including the party and their interest, for as long as the records are kept | Whether BigBlueButton or Jitsi logs, the reverse proxy and storage access logs are retained and searchable for that period |
| FERPA school official contractor test (34 CFR 99.31(a)(1)(i)(B)) | Treat a hosting or support partner as a school official only if the institution keeps direct control over use and maintenance of the records and the partner follows redisclosure limits | Written contract terms, named administrators on the institution side and a documented process for partner access to recording storage |
| COPPA for under-13 users (16 CFR 312.8 and 312.10) | Keep a written security program with a designated coordinator, run at least annual risk assessments and set deletion timeframes for children's recordings and chat | Named program coordinator, annual risk assessment record and a retention policy that deletes children's data after the purpose ends |
| GLBA Safeguards Rule for Title IV institutions (16 CFR 314.4(c)(5)) | Require multi-factor authentication for anyone accessing an information system that holds student financial or customer data, including admin consoles for the video server | MFA enforced on the LMS, directory, server shell and recording storage, with evidence from the identity provider |
| GLBA FTC notification (16 CFR 314.4(j)) | Notify the FTC within 30 days of discovering a notification event affecting at least 500 consumers, so logs must show when exposure began | Incident runbook covering recording storage exposure, log retention for detection and a named contact for the 30-day clock |
| Accessibility under 28 CFR Part 35 Subpart H | Meet the web accessibility standard for any public or state-entity web content, so the join flow, captions and player controls must be tested with assistive technology | Accessibility test results for the join page and player, a captioning plan and a vendor statement on known gaps for the chosen version |
| Retention per term | Set recording retention to end at the term or a defined period, with automated deletion and a legal hold process for disputed or accommodated sessions | Documented retention schedule per course type, deletion job logs and a record of holds applied by the registrar or legal team |
BigBlueButton or Jitsi for classes, and when each fits
BigBlueButton is the usual fit when lectures and seminars must run inside the learning management system that students already use. The project is licensed under LGPL-3.0 and is embedded in Canvas, Moodle Cloud, Sakai, Jenzabar, D2L and Schoology. Teaching staff get the features that structured classes depend on: audio and video, slides with annotations, chat, screen sharing, polling, a multi-user whiteboard, shared notes and breakout rooms for seminar groups.
- Breakout-heavy seminars: Breakout rooms let an instructor split a cohort into small groups and bring them back to the main session, which is the core workflow for seminars.
- Shared work in session: The multi-user whiteboard and shared notes give groups a place to build an answer together without leaving the class.
- Recording by default in some setups: Recordings are stored on the server, so plan storage per term before enabling them for every course.
- LMS plugin dependency: The LMS integration depends on plugin and LTI versions that must match your LMS release. Confirm supported combinations with your LMS vendor and the BigBlueButton project before committing.
- Greenlight or LTI on the same server: The install script can add the Greenlight front end or LTI support, which changes how users reach rooms and how roles map.
Before choosing this path, confirm which LMS version you run and whether the plugin for that version is supported on BigBlueButton 4.0.
Jitsi Meet is licensed under Apache-2.0 and suits sessions that start without a timetable entry: a tutor and a student, a staff meeting, or a guest joining from outside the institution. A room can be created on demand and shared by link, which keeps the workflow light for people who do not run classes inside an LMS. The web app is served by a deployment of its own rather than by an LMS plugin.
- Guest access: Guests such as parents, external examiners or partner staff can join a room without an institutional account when the deployment allows it.
- JWT token authentication: The Jitsi handbook recommends JWT tokens over the older secure domain method, which is marked as deprecated for new installations. Tokens let the institution's identity system decide who can create or enter a room.
- Separate guest domain: The handbook describes a separate anonymous domain for guests, so authenticated staff and open access do not share one configuration.
- Authentication options: The Docker setup lists internal XMPP accounts, JWT, LDAP, Matrix verification and a hybrid mode, configured through the .env file.
- Certificate requirement: HTTPS with a proper domain certificate is necessary for working audio and video, and self-signed certificates cause problems, especially on mobile clients.
Confirm which authentication method your identity system can supply, and whether guests need a separate domain, before the design is fixed.
BigBlueButton 4.0 has a defined hardware floor, and its install conditions differ from the earlier releases many schools may already know. The BigBlueButton install documentation lists at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance, and 500 GB of disk for recordings, or 50 GB without recording. Bandwidth is listed at 250 Mbit/s symmetrical. Plan these numbers per server, because a single server is the unit of capacity.
- Operating system: BigBlueButton 4.0 installs on Ubuntu 24.04 64-bit.
- Clean install only: Direct upgrades from 2.6, 2.7 or 3.0 are not supported, so the project recommends a clean server installation.
- Network ports: TCP 80 and 443 and UDP 16384 to 32768 must be reachable, with a valid hostname for SSL and Docker for document conversion.
- TURN for restrictive networks: A TURN server is recommended for users behind firewalls, which is common on school networks.
- Release timing: BigBlueButton 4.0.0 was released on October 14, 2026, while the 3.0 branch still receives maintenance releases. Plan the move from an existing 3.0 deployment as a migration, not an upgrade.
Ask your implementation partner to confirm the sizing for your peak concurrency and the storage period for recordings.
Jitsi Meet deploys as a set of services rather than a single appliance. The self-hosting guide describes a web server (nginx or Apache), the Prosody XMPP server, Jicofo and one or more Jitsi Videobridge media routers. The Debian and Ubuntu quick start supports Debian 12 or newer and Ubuntu 24.04 or newer, requires OpenJDK 17, and needs ports 80/TCP, 443/TCP and 10000/UDP open. Port 5349/TCP for TCP fallback and 3478/UDP for STUN are optional.
- Scaling model: Videobridges scale horizontally by adding more. The 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.
- Docker option: The official Docker setup runs web, prosody, jicofo, jvb, jigasi and jibri as separate containers, and since stable-11146 the containers run rootless with read-only filesystems.
- Recording limits: Jibri handles recording and streaming, and the sibling recording topic covers its per-instance limit.
- Release tagging: Stable releases are tagged by build number, such as stable/jitsi-meet_11248 published September 14, 2026. Pin a tag and test upgrades in staging.
- Hosted option: 8x8 offers JaaS, and the free public instance is meet.jit.si. Neither is a self-hosted deployment, so classify them separately in your data protection review.
Confirm the videobridge count your peak needs with your partner, and check whether your network allows UDP 10000 outbound from every client segment.
Deployment patterns for campuses, schools and districts
Schools and campuses rarely need one design for every class. The patterns below separate a single server for one institution from pooled capacity for timetabled peaks, and they show where network reach, recording retention and minors' data change the build. Each card names the trade-off and what the institution must provide before the design is settled.
Single BigBlueButton server for one institution
One BigBlueButton 4.0 server, installed on a clean Ubuntu 24.04 host, serves a single campus or school. It is the simplest pattern and fits a bounded number of concurrent classes. Upgrades from 2.6, 2.7 or 3.0 are not supported directly, so plan a fresh build. The institution must supply a valid hostname for SSL, open TCP 80 and 443 plus UDP 16384 to 32768, and size the host for recording. Check that one box can carry your peak class count.
Pooled BigBlueButton servers behind Scalelite
Scalelite distributes meetings across several BigBlueButton servers, which suits timetabled peaks such as the start of a term when many classes begin together. The trade-off is operational: each server needs its own patching, certificates and capacity, and the pool needs monitoring to show when to add a node. The institution must provide enough bandwidth per node and a shared view of which servers are healthy. Confirm how Scalelite handles recordings across the pool before go-live.
Jitsi with horizontally added videobridges
Jitsi Meet separates the web app, Prosody, Jicofo and one or more Jitsi Videobridge media routers, so capacity grows by adding bridges rather than rebuilding the central services. This suits mixed use such as staff meetings, parent evenings and open classes with guests. The institution must provide HTTPS with a proper domain certificate, since self-signed certificates cause audio and video problems, and must decide how students authenticate, using JWT tokens or another supported method. Bridges need UDP 10000 open.
Separate TURN service for restricted networks
Students on school or district networks often sit behind firewalls that block direct media paths. A TURN server relays the connection so sessions still connect. The trade-off is an extra internet-facing component with its own bandwidth cost and certificate. The institution must confirm which ports its firewall permits, including TCP 443 as a fallback path, and must place the TURN service where the media traffic can reach it. Test from a student-owned network and a guest device before term.
Recording storage sized per term
Recordings grow quickly, and BigBlueButton recommends 500 GB of disk for recordings on a 4.0 server, compared with 50 GB without recording. Storage must be sized for the number of recorded sessions in a term, not a single snapshot. Retention matters because FERPA requires institutions to log disclosures and COPPA requires operators to keep personal information only as long as reasonably necessary, with a written deletion timeframe. The institution must define who approves a recording, how long it stays and when it is deleted.
Private network segment for minors
Running classes for children under 13 on a segregated network segment limits who can reach the video servers and the recordings. The segment can hold the media servers, the LMS connector and the storage, with only the required ports exposed to student devices. The institution must document the data flows, restrict administrator access and confirm that the design supports its written information security program, including the designated coordinator and annual risk assessments that the COPPA Rule requires. Do not assume segmentation alone meets FERPA or COPPA obligations.
How a classroom rollout moves from pilot to term start
The sequence moves a school or university from a privacy-scoped design to a tested pilot, a timed cutover and a live term, with a named output at each phase so that academic, IT and compliance owners can sign off before students join.
Scope data and privacy roles first
The institution, with its legal and records owners, decides which regulations apply: FERPA for students at institutions that receive US Department of Education funds, COPPA where operators collect data from children under 13, and GLBA Safeguards where the institution is a Title IV participant. The team maps every data element a session creates, including attendance, chat, recordings and transcripts, and sets a written retention policy with a deletion timeframe. Output: a signed-off data map and retention schedule, reviewed by the registrar or privacy office. Confirm with counsel whether the hosting partner qualifies as a school official under the institution's own FERPA annual notice and contract terms.
Design platform and identity layers
Architects choose between BigBlueButton, usually embedded in the LMS, and Jitsi Meet, usually for ad hoc tutoring and staff meetings, and define the authentication model. For Jitsi, this covers JWT tokens with a separate guest domain rather than the deprecated secure domain method. For BigBlueButton, it covers LMS launch, Greenlight authentication and the shared secret handling for API calls. The design also fixes network paths, including TCP 80 and 443, the UDP media range, and a TURN server for students behind restrictive firewalls. Output: a reference architecture and an access model that names who can create rooms, moderate and view recordings.
Run a departmental pilot with peak load tests
One department runs real timetabled sessions on the staging environment for a defined period agreed in advance. Testers simulate the largest concurrent class load the timetable produces, measure audio, video and whiteboard performance, and check that recordings land in the planned storage path. The team reviews the findings with faculty and student representatives and records issues in a backlog. Output: a load test report with measured peak behavior, a tuned sizing decision for servers or videobridges, and a go or no-go recommendation. Use the BigBlueButton 4.0 hardware minimums as a baseline, not as a capacity guarantee.
Test LMS integration and accessibility
The team tests the LMS launch end to end using each role the institution uses, such as instructor, teaching assistant, student and guest. It checks that breakout rooms, polls, shared notes and the multi-user whiteboard behave as the course design expects, and that session links expire or lock as intended. Accessibility testing covers keyboard navigation, screen reader behavior on the join and control screens, captioning options and how recordings are delivered, measured against the institution's obligations under the web and mobile accessibility rule for public entities where it applies. Output: a tested LMS launch script and an accessibility test log with open defects triaged.
Validate security, logging and recording deletion
Security staff review TLS certificates, which must be valid for the hostname, and confirm that API calls carry checksums and that no shared secret is exposed in any page. They verify access logs are retained and reviewed, and they test the recording deletion process from the retention schedule end to end, including backups and LMS copies. The team also documents how multi-factor authentication applies to administrative accounts. Output: a recording deletion runbook with evidence of a test deletion and a security configuration baseline that compliance staff can file.
Plan cutover around scheduled breaks
The team sets the production cutover for a break in the academic calendar, so that no live classes depend on the change window. If a BigBlueButton 3.0 installation needs to move to 4.0, the team plans a clean server installation on Ubuntu 24.04 with migration of configuration and recordings, because direct upgrades from 2.6, 2.7 or 3.0 are not supported. The rollback path, DNS changes and LMS endpoint updates are written and rehearsed. Output: an approved cutover plan with a named rollback owner and a communication plan for faculty and students.
Hand over operations before term start
Operators receive monitoring dashboards for server load, bandwidth and recording storage, along with thresholds that trigger adding capacity. Support staff receive a first-line guide for join failures, firewall and TURN issues, and LMS launch errors, plus an escalation path to the platform team. The team confirms the maintenance window for upgrades and the process for patching between terms. Output: a handover record signed by the service owner, an operations runbook and a live monitoring check that proves alerts reach the on-call contact before the first timetabled session.
Evidence that FERPA, COPPA and GLBA reviewers ask for
This table maps each artifact a FERPA, COPPA or GLBA reviewer typically requests to the component that produces it in a self-hosted BigBlueButton or Jitsi deployment. Read it as a checklist of what to collect and who owns each item. DeployOpen prepares this evidence, but independent auditors or the Department of Education assess it, not DeployOpen.
| Evidence | What it shows | Where it comes from |
|---|---|---|
| Disclosure and access log (FERPA 34 CFR 99.32) | Who requested or accessed student records, when, and their legitimate interest | Application and reverse proxy logs, LMS and Greenlight records, retained in a central log store with a documented retention period |
| Access control configuration (34 CFR 99.31) | Limits on which school officials can join, record, or view recordings tied to their courses | LMS or OpenID Connect role mapping, BigBlueButton roles and moderator settings, and recording access rules, exported and dated |
| Written information security program (COPPA 16 CFR 312.8) | Designated coordinator, scope of systems holding children's data, and controls applied | A policy document owned by the institution, with a named coordinator and the hosting boundary described |
| Annual risk assessment (COPPA 16 CFR 312.8) | Threats to meeting recordings, chat, and guest data, with the controls chosen for each | A dated assessment record reviewed each year, covering recording storage, guest access and third-party services |
| Retention and deletion policy (COPPA 16 CFR 312.10) | Deletion timeframes for recordings, chat logs, and user accounts | Recording cleanup settings, backup retention rules and a deletion log, with the timeframe stated in the policy |
| MFA configuration for GLBA-scoped systems (16 CFR 314.4) | Multi-factor authentication enforced for administrators and staff with access to systems holding customer financial data | Identity provider settings (for example Keycloak) and a configuration export showing the enforced factor for each group |
| Accessibility test results (28 CFR Part 35 Subpart H) | Results of testing meeting interfaces, captions and controls against the accessibility standard the institution adopts | A test report naming the standard, the test tools and the date, with remediation tickets for open issues |
What do schools ask before buying self-hosted video help?
What drives the cost of self-hosted video for a school?
The main drivers are server count, peak concurrency, recording volume, LMS integration work and identity integration. Concurrency sets how many media servers you need: a BigBlueButton 4.0 server 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 docs. Jitsi scales by adding videobridges, and the Jitsi scalable setup guide suggests 4 or 8 CPU with 8 GB RAM for each videobridge. Recording storage grows with every term, and LMS and identity work is paid for by the hour or by fixed scope. Ask any partner for a quote that lists servers, storage, bandwidth, LMS work, identity work and ongoing support as separate lines.
How long does a fixed-scope self-hosted video rollout take?
The duration depends on the agreed scope, so it is set in writing before work starts rather than estimated in general terms. The scope items that most often move the timeline are the number of servers, the LMS integration, the identity setup, the firewall and TURN work, and whether recording and retention rules must be built. 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 clean server build is recommended. Ask for a written plan that shows each milestone, who signs off on it, and what happens if a dependency, such as a certificate or firewall change, arrives late.
Can our IT staff run self-hosted video without outside help?
Some schools run it in-house, especially where the IT team already operates Linux servers, Docker and reverse proxies. The work that tends to be underestimated is the continuing operation: upgrades, certificates, capacity changes before exam periods, and recording housekeeping. Jitsi requires HTTPS with a proper domain certificate for working audio and video, and BigBlueButton needs TCP ports 80 and 443, UDP ports 16384 to 32768 and a valid hostname for SSL. Assess your team against those tasks, then decide whether to build, partner or buy a hosted service. A partner can cover the initial build and hand over documented runbooks, or stay on a retainer for upgrades and support.
What does the institution need to provide during the project?
A typical engagement needs three internal roles. Data owners, usually the registrar or the privacy officer, decide which student data may enter the platform, how long recordings are kept and who may access them. LMS administrators provide the test course, the LTI or plugin settings and the single sign-on details. The network team confirms firewall rules, public DNS names, certificates, the TURN plan and the bandwidth available for classrooms. Ask the partner to list these inputs in the written scope, with a named contact and a date for each, so that delays are visible early.
How are recordings deleted at the end of each term?
Deletion is a policy and a technical job, and both must be defined before the first class. FERPA requires institutions to keep a record of each disclosure of personally identifiable information from education records for as long as those records are kept, so access logs need their own retention rule. Under COPPA, operators that collect children's data under 13 may keep it only as long as reasonably necessary and must maintain a written retention policy with a deletion timeframe, as set out in 16 CFR 312.10. Ask the partner how recordings are stored per course and term, how a scheduled cleanup is tested, and how a deleted recording is confirmed gone from backups.
Does a hosting provider become a school official under FERPA?
A contractor can receive education records as a school official only under specific conditions. It must perform a service the institution would otherwise use employees for, it must be under the institution's direct control for the use and maintenance of the records, and it must follow the redisclosure limits in 34 CFR 99.33(a), as described in 34 CFR 99.31(a)(1)(i)(B). Whether a vendor qualifies depends on the contract and the data flow, so the school's counsel should review it. Institutions must also use reasonable access controls so that school officials see only records in which they have a legitimate educational interest. When the platform runs on the school's own infrastructure under its control, these questions are easier to document, but they still need a written review.
Which school data should stay out of the video platform?
Keep the video platform limited to what a live class needs, and check each data type against the rules that apply to your institution. Attendance, names, and recordings can each be education records under FERPA, and recordings of children under 13 fall under COPPA. Institutions in the Title IV programs have agreed to follow the GLBA Safeguards Rule, which requires multi-factor authentication for anyone accessing any information system. Ask the partner to show which fields the LMS sends into the platform, whether guest access is needed, and which recordings can be published or only stored internally.
What to ask a partner before a term-start deadline
Start with capacity, because timetabled peaks are where self-hosted classrooms fail. Ask how the partner sizes BigBlueButton servers or Jitsi videobridges for the busiest hour of the timetable, not the average day, and ask for the sizing calculation in writing. For BigBlueButton 4.0, confirm the server minimums against the install documentation (16 GB RAM with swap, 8 cores, 500 GB disk with recording) and ask how many concurrent classes each server is expected to carry. Ask how Scalelite pools several BigBlueButton servers, how it chooses a server for a new session, and what happens to a class when one server fails mid-lesson. For Jitsi, ask how many videobridges are planned and how new ones are added before term starts.
Next, ask how the partner handles upgrades and authentication. BigBlueButton 4.0 does not support direct upgrades from 2.6, 2.7 or 3.0, so ask whether the partner plans a clean installation and a migration window that stays clear of teaching weeks, and who signs off on the cutover date. Ask how the LMS connection is configured, which version of LTI it uses, and how Greenlight v3 is set to use OpenID Connect with Keycloak or your existing identity provider. For Jitsi, ask whether JWT authentication is in place and whether the guest domain is separate. Ask who holds the BigBlueButton shared secret and how it is kept out of web pages.
Finally, ask about recording deletion, FERPA status and term-time support. Require a written deletion schedule for recordings, a test that proves a deleted recording is gone from storage and backups, and a log of who requested and who performed each deletion. Ask whether the partner will sign an agreement that places its staff under your direct control for education records, and how it limits access to students' records to those with a legitimate educational interest. Finally, ask what support covers incidents during term: response times, who is on call during class hours, and how a problem with a live lesson is escalated. Confirm each answer against the written scope before the deadline.
Where education deployments usually fail
Most failed virtual classroom rollouts were not caused by the platform itself. They came from capacity that was sized for an average day, networks that block media, certificates that break mobile clients, data kept longer than policy allows, access shortcuts and upgrades scheduled into teaching time. Each card below is a check to make before the first timetabled session.
Servers sized for average load
A classroom server sized for a normal day can fail at the start of a timetabled peak, when many sessions open within minutes of each other. BigBlueButton 4.0 expects at least 16 GB of RAM with swap, 8 CPU cores with high single-thread performance and 250 Mbit/s symmetrical bandwidth per server. For Jitsi, each videobridge is added horizontally. Ask your partner to size for the busiest timetable slot, not the average, and to show how the next server is added before a peak arrives.
No TURN for home and dorm networks
Students on home Wi-Fi, dormitory networks and campus guest networks often sit behind firewalls that block direct media paths, so audio and video fail while the login page still loads. BigBlueButton needs UDP ports 16384 to 32768 reachable, and a TURN server is recommended for users behind restrictive firewalls. Test from a residential connection and a dorm-style network before term starts, and confirm whether your partner deploys and monitors the TURN relay.
Self-signed certificates break mobile clients
Jitsi's handbook states that HTTPS with a proper domain certificate is necessary for working audio and video, and that self-signed certificates cause problems, especially on mobile clients. Students often join from phones, so a certificate warning can end a class before it starts. Use a certificate from a trusted authority for each public hostname, set renewal alerts, and check the chain on iOS and Android devices.
Recordings kept beyond retention
Lecture recordings accumulate quickly, and BigBlueButton recommends 500 GB of disk for recordings on a 4.0 server. Recordings of students can be education records under FERPA, and COPPA adds a written retention policy with a deletion timeframe when children under 13 are involved. Set a per-term retention rule, automate deletion, and confirm with your legal or records office which recordings must be kept and for how long.
Guest access bypassing authentication
Open guest links are convenient for guest lecturers and parents, but they can let anyone with a URL enter a class and see student names or shared files. Jitsi's handbook recommends JWT token authentication and a separate anonymous domain for guests, and marks the older username and password room method as deprecated for new installs. Define which roles can join unauthenticated, use waiting rooms or lobbies for guests, and test that a guest cannot reach a teacher-only room.
Upgrades during a term
A BigBlueButton 4.0 upgrade from 2.6, 2.7 or 3.0 is not supported directly, so the change usually means a clean server installation on Ubuntu 24.04 64-bit with data migration planned in advance. Running that work in the middle of a term risks lost sessions and recordings. Agree a freeze window between terms, keep a tested rollback, and ask your partner how upgrades are scheduled around class timetables.
How DeployOpen scopes and supports education video conferencing
DeployOpen starts every education engagement with a written scope that names the platform (BigBlueButton, Jitsi Meet or both), the institutions and campuses that will use it, the LMS integrations in play, the recording and retention rules, and the deliverables and dates both sides have agreed. Most engagements are fixed-scope, so the scope document is where the institution decides whether a feature such as per-course recording storage or Scalelite-based pooling is in or out before work begins. We plan the server layout in the institution's own cloud account, data center or private network, including the ports BigBlueButton or Jitsi need, the TURN path for students behind restrictive campus firewalls, and whether the platform sits in a region where the institution's student data rules apply.
Implementation covers installation, LMS and identity integration, and hardening. For BigBlueButton that means a clean server build, because the 4.0 documentation does not support direct upgrades from earlier branches, plus the LMS connection and an external identity path for Greenlight. For Jitsi it means JWT token authentication with a separate guest domain, HTTPS with a certificate the institution controls, and access rules that match the institution's FERPA school official arrangements. We then test the deployment itself: application and API testing of the endpoints that create meetings and issue recordings, configuration review of the shared secret handling, and load tests before a timetabled peak. Each control is documented so the institution can show how it works.
DeployOpen prepares the systems, controls and evidence that an institution's own auditors or compliance reviewers will examine, including access logs, retention settings and contractor access records relevant to FERPA, the GLBA Safeguards Rule where the institution participates in Title IV programs, and COPPA where younger children attend. DeployOpen does not issue audit reports, attestations or certifications, and the institution should confirm with its counsel and assessors which evidence they need. After go-live, retainers cover upgrades scheduled around term calendars, patching, monitoring and continuous testing. Ask every prospective partner to state in writing what is included in the fixed scope and what a retainer covers.
