Why recording on self-hosted video conferencing needs its own design
An organization that must record or stream meetings without handing the media to a SaaS vendor has to own every step: capture, storage, playback, retention and deletion. Recording changes a meeting from a transient conversation into stored personal data and, in some sectors, a regulated record. The first design question is therefore not which product has the nicer recording button, but which records rules apply to the calls in scope. Those rules set how long media must be kept, who may access it, whether participants must consent, and what evidence of deletion you must produce. A platform that cannot meet those requirements is the wrong platform, however good its interface.
In short, BigBlueButton fits multi-recording and classroom use, because it records each session as part of the server's own workflow and can run many recorded sessions at once, but it needs heavy disk: the BigBlueButton 4.0 install documentation lists 500 GB for recordings, against 50 GB without recording. Jitsi recording through Jibri fits fewer simultaneous recordings per instance, because Jibri runs Chrome in a virtual framebuffer and its README states that only one recording at a time is supported on a single Jibri. Teams that expect several recorded meetings at the same time should plan for additional Jibri capacity or choose a different platform before rollout.
Confirm the applicable rules with your compliance lead and counsel before you pick a platform. For example, a broker-dealer that must preserve business communications under 17 CFR 240.17a-4 has a different retention clock than a clinic handling ePHI under the HIPAA Security Rule's audit controls at 45 CFR 164.312. Ask each vendor or implementation partner to show, for your scenario, where recordings are written, how retention is enforced, how participants are told a session is recorded, and how a deletion is logged. The answers, not the feature list, decide which design you build.
Which recording requirements change the build
This table maps each recording requirement to its source, what it means for storage, access logging and deletion, and what to confirm. Read it by first identifying which regime applies to your organization, since a rule only changes the build when it governs your recordings. The main takeaway is that the platform limits and the retention decisions shape the design as much as the regulation does.
| Requirement or limit | What it asks for or implies | What it means for storage, access logging and deletion |
|---|---|---|
| SEC Rule 17a-4(b)(4) preservation | Broker-dealers must preserve communications relating to the business, including inter-office communications, for not less than three years. Applies only if your organization is a broker-dealer subject to this rule. | Recordings classed as business communications need a retention period of at least three years, write-protected storage and a deletion process that holds recordings under legal hold. Confirm with counsel whether internal meetings count. |
| HIPAA 164.312(b) audit controls | Systems holding ePHI must record and examine activity. Applies only where meetings or recordings contain ePHI in a covered entity or business associate. | Log who joined, who started or downloaded a recording, and who played back or deleted it. Store logs outside the recording server so administrators cannot silently alter them. |
| HIPAA 164.312(e)(1) transmission security | Technical measures must guard against unauthorized access to ePHI sent over electronic networks. Applies only where ePHI is transmitted in sessions. | Recording streams and copies moved between the media server and storage must be encrypted in transit. Confirm how the chosen platform handles the recording pipeline and internal network paths. |
| Jibri one recording at a time | Jibri records or streams one conference at a time per instance, per the Jibri README. Concurrent recordings need more Jibri instances. | Each parallel recording needs its own Jibri capacity, so plan the count of Jibri hosts for peak overlap. Recording files land on the Jibri host, so define how they are moved to controlled storage and deleted after transfer. |
| BigBlueButton recording disk | A BigBlueButton 4.0 server needs 500 GB of disk for recordings, against 50 GB without recording, per the install documentation. | Recording turns disk sizing into a major input. Plan a retention cycle and an archive target, and monitor free space so recordings do not stop when the disk fills. |
| Consent and notice | No platform setting decides consent. Your legal basis, applicable privacy law and participant notice must be documented before recording starts. | Record the notice and consent state per session where possible, and make recording start visible to participants. Confirm with counsel which jurisdictions apply to guests and patients. |
| Retention and deletion schedule | Your policy must set how long each recording class is kept and how it is removed, including backups and copies. | Automate deletion by class, extend it to backups and downloads, and keep a deletion record. Ask the partner how deletion reaches replicas and archived copies. |
Jitsi with Jibri or BigBlueButton built-in recording: which fits
Recording on a self-hosted platform is a design decision, not a checkbox. Jitsi relies on a separate recorder component that is limited per instance, while BigBlueButton records on the same server and needs far more disk. The cards below set out which requirement profile each option fits and what to confirm before you commit.
Jitsi with Jibri containers
Jibri records or streams a Jitsi Meet conference by running Chrome in a virtual framebuffer, so each recorder is a full browser session. The one-recording-at-a-time limit on a single Jibri means concurrent recordings require additional Jibri instances, each with its own capacity. Jitsi Meet is Apache-2.0, and the Jibri container runs as a separate service in the Docker setup. Confirm how many simultaneous recordings you expect at peak and how many Jibri instances that implies.
BigBlueButton 4.0 built-in recording
BigBlueButton records meetings on the same server that hosts the session, so recording is part of the platform rather than a separate service. The server needs 500 GB of disk for recordings, compared with 50 GB without recording, and 16 GB RAM with 8 high single-thread CPU cores. BigBlueButton is LGPL-3.0 licensed. Confirm disk growth per term, whether recordings can be moved off the server, and whether a clean install is acceptable, since direct upgrades from 2.6, 2.7 or 3.0 are not supported.
External recorder or storage target
Recording capture and storage can be decided separately from the conferencing platform. A recorder that runs on its own host can keep media off the meeting servers, and an object or file store can hold playback and deletion workflows under your retention rules. This adds network paths, credentials and failure points that need monitoring. Confirm who owns the recording files, how deletion requests are fulfilled across all copies, and whether the storage location meets your data residency requirements.
SaaS recording (out of scope)
Many hosted meeting services record calls in their own cloud, which is the contrast this hub is built against. Where recordings are stored, who can access them, and how long they persist are decided by the vendor's terms rather than your retention schedule. DeployOpen does not implement SaaS recording. If your requirements depend on data staying in your own infrastructure, the self-hosted options above are the relevant comparison. Confirm with any vendor where media and recordings are processed and stored before comparing costs.
How Jibri records a Jitsi conference and what its single-recording limit means
Jibri is the component that records or streams a Jitsi Meet conference, and its capacity is set by a simple rule: each Jibri handles one recording at a time, according to the project README in the jitsi/jibri repository. To capture a meeting, Jibri runs Chrome inside a virtual framebuffer, joins the conference like a participant, and encodes what it sees and hears. In the official Docker setup, jibri runs as its own container alongside web, prosody, jicofo, jvb and jigasi, so it can be scaled and restarted without touching the rest of the stack. Because each Jibri is a full browser session, it is a heavier workload than a normal participant, and the host needs enough CPU for the encoder.
Plan Jibri count from the peak number of meetings that must be recorded or streamed at the same moment, not from total meetings per day. Count recorded meetings per hour in your busiest window, add a margin for overlap and failed sessions, and confirm with the Jibri documentation for your chosen release how many Jibri instances each host can run and what each one needs in CPU, memory and disk. Decide up front who may start a recording, whether recordings are started by a moderator or automatically, and what happens when all Jibri instances are busy, since a user who presses record may simply get no capacity. Capture output is written to local storage on the Jibri host or to a path you configure, so disk sizing and the move of finished files to durable storage belong in the plan.
Streaming uses the same capture path as recording, so a live stream to an external endpoint also occupies a Jibri for its full duration. Do not assume a stream and a recording can run side by side on one Jibri; confirm this in the documentation for the release you deploy and test it under load before a town hall or teaching block depends on it. Treat the Jibri count as a capacity decision to be confirmed with your implementation partner in writing, with a load test that starts the expected number of simultaneous recordings and streams.
How a recording rollout moves from policy to tested deletion
This sequence turns a recording decision into a tested system, so each recording has a documented purpose, a controlled storage location, limited playback access, and a retention and deletion path that has been proven to work before users rely on it. Each phase ends with an artifact that the next phase depends on.
Define recording policy and consent wording
Legal counsel, the records owner and the business sponsor agree which meetings may be recorded, who may start a recording, who must be told, how consent is captured (for example, an on-screen notice and a required acknowledgment for guests), and how long each category of recording is kept. Output: a signed one-page recording policy and approved consent text for each entry point, including guest and external join paths. Confirm with counsel which records-retention rules apply to your sector before the policy is final.
Size storage and recording capacity
The platform engineering team converts the policy into capacity numbers: expected recording hours per week, average file size for the chosen resolution, retention period, and how many recordings can run at the same time. For BigBlueButton 4.0, the install documentation lists 500 GB of disk for recordings against 50 GB without recording, which is the starting point for the sizing discussion. For Jitsi, plan one Jibri per concurrent recording, since its README states only one recording at a time is supported on a single Jibri. Output: a capacity sheet agreed with the infrastructure owner and a list of the components that will run the recording path.
Build and harden the recording path
The implementation partner deploys the recording component (Jibri containers for Jitsi, or the built-in recording pipeline on BigBlueButton), sets the storage location on an encrypted volume with restricted write paths, and configures the service so recordings are moved out of temporary space after processing. Access to the recording host is limited to named administrators, and the secrets used by the recorder are kept out of web-facing configuration. Output: a documented build with configuration files under version control and a short hardening record that a security reviewer can check line by line.
Test playback access controls and audit logging
The test team creates recordings with each role (host, moderator, participant, guest) and attempts playback, download and link sharing from inside and outside the intended group. They confirm that only authorized users can open a recording, that expiring or revoked links stop working, and that the platform logs who started a recording, who viewed or downloaded it, and when. Log output is checked against the audit-control expectations in your framework, such as the HIPAA audit-control requirement at 45 CFR 164.312(b) where ePHI may appear. Output: a signed test report with pass and fail results and any defects fixed before the pilot.
Run a controlled pilot with real consent flows
A small group of internal meetings, chosen with the policy owner, runs with recording enabled under the approved consent text. The team watches for missed notices, recordings that start without a visible indicator, storage growth against the capacity sheet, and any participant who could not find how to object or request removal. Participants and the records owner review the findings together. Output: a pilot log, a list of changes to the policy, consent text or configuration, and a go or hold decision recorded by the sponsor.
Validate retention and deletion jobs
The team configures the retention schedule from the approved policy and runs scheduled deletion jobs against test recordings whose age is set to cross each retention threshold. They confirm that files, derived copies such as thumbnails and transcripts, backup copies in scope, and index entries are removed, and that a legal-hold flag blocks deletion where counsel requires it. Deletion results are logged and checked against the records owner's expectations. Output: a deletion test report showing each recording category removed on schedule, plus an operating runbook that names who reviews deletion logs. Ask the partner to show this evidence before production use.
Consent and retention choices by meeting type
Client, advisory and board calls usually carry the strictest consent and retention rules, because the content may be a regulated business communication. Recording should be a deliberate choice for each call, started by a host who knows which record class the call belongs to. Retention comes from your own records policy and any rule that applies to your firm, and the design must let you find and delete one specific recording later.
- Consent from every participant: Require each participant to agree before recording starts, and keep a log of that consent. Confirm with counsel whether an on-screen notice and an explicit yes are needed in each jurisdiction where people join.
- Opt-in by default: Keep recording off unless the host starts it for a documented purpose, such as a client instruction call.
- Retention tied to the record class: Map advisory recordings to a class in your retention schedule. For broker-dealers, 17 CFR 240.17a-4 requires preservation of business communications for not less than three years, and whether a recorded call falls under that requirement is a question for your compliance team.
- Deletion evidence: Log the meeting identifier, the deletion date, the approver and every storage location cleared, including backups and any copies sent to other systems.
Before configuring recording, ask your compliance and legal teams which record class each call type belongs to, and ask your implementation partner how deletion reaches backups and copies.
Town halls are usually addressed to a large audience of staff, so the question is less about whether one person agrees and more about whether everyone who is present has been told. Recording is often expected by employees who could not attend live, which makes the replay a corporate communication with its own owner. Retention and access should follow the communications policy, and the stream should be limited to the audience the event was meant for.
- Announced recording: Send notice in the calendar invitation and on the joining page, and state where the replay will be published and who can see it.
- Speaker and guest consent: Get written agreement from executives, external speakers and any guest who will appear on screen, since their participation may fall outside the employee notice.
- Works council or employee representative rules: Where these apply, confirm with your HR or labor counsel whether any agreement is needed before recording staff.
- Streaming capacity: A single Jibri instance supports only one recording at a time, so plan separate recording and streaming paths before the event is scheduled.
- Deletion evidence: Record when the replay was removed from the intranet, when the storage object was deleted and who approved the removal.
Check the internal communications and HR policies together, because the replay location and the people allowed to view it determine how long the recording should exist.
Classroom sessions combine teacher-led content with students who may be minors, so consent and retention depend on the education law and institutional policy that apply to the learners. Recording a lesson can capture student names, voices, faces and chat messages, which makes each recording a student record. The retention period belongs to the institution, and the design must support removal at the end of each term or course as its policy requires.
- Guardian and student consent: Confirm with your legal or data protection team who must agree for students under the applicable age, and whether students can decline without penalty.
- Announced recording: Tell the class at the start of each session and show the recording state in the course schedule.
- Participation controls: Decide in advance whether students can turn on cameras or microphones during recorded sessions, and whether chat is included in the recording.
- Storage planning: BigBlueButton 4.0 needs 500 GB of disk for recordings, against 50 GB without recording, so retention length directly sets the storage you buy.
- Deletion evidence: Keep a purge log from scheduled removal jobs that shows the course, the term, the number of recordings removed and the date.
Ask the institution to confirm the retention schedule for each course type before the first recorded session, and test the purge job on a copy of the data.
What auditors ask for from recording storage and access
This table maps the evidence an assessor typically asks for around meeting recordings to the component that produces it, so you can check each item before an audit begins. Read each row as a question to answer with logs, exports or configuration records from your own environment. DeployOpen prepares this evidence for assessments, but independent auditors and certification bodies issue any audit report or attestation.
| Evidence item | What it shows | Produced by | Gap to confirm |
|---|---|---|---|
| Recording inventory | Every recording with meeting ID, date, owner and storage location | Jibri output logs or BigBlueButton recording directory, indexed by a script or front end | Whether Jibri output is tracked for each session, since one Jibri handles one recording at a time |
| Retention schedule | Written period per recording class, such as class, board or patient call | Policy document tied to storage lifecycle rules | Whether cleanup jobs match the written schedule and cover backups too |
| Deletion logs | Proof that expired or requested recordings were removed, with date and operator | Storage system audit log or scheduled job output | Whether deletion also removes copies in backup snapshots and object storage replicas |
| Playback access logs | Who opened or downloaded a recording and when | Web server or front end logs, identity provider sign-in records | Whether playback links are authenticated, since shared links may not log the viewer |
| Consent records | Evidence that participants were told about recording and agreed where required | Consent banner or pre-meeting notice, plus stored acknowledgments | Whether consent is captured per participant or only announced once |
| Configuration baseline | Recording settings, storage paths, codecs and encryption at rest as deployed | Version-controlled config files, such as the Jibri or BigBlueButton settings, and change records | Whether changes to recording settings are reviewed and dated |
| Backup and restore records | Confirmation that recordings and logs are backed up and restore tests were run | Backup system job reports and restore test notes | Whether recording storage is in backup scope at all, since it is often large and excluded |
How much does recording add, and how long does it take to set up?
What drives the cost of adding recording to a self-hosted meeting platform?
Recording cost comes from three places: the server capacity that records, the storage that holds the files, and the people who set policy and operate the system. On Jitsi, recording runs through Jibri, which needs its own host with a browser environment, so each recording host adds compute. On BigBlueButton, the main addition is disk. The BigBlueButton 4.0 install documentation lists 500 GB of disk for recordings, against 50 GB without recording. Storage cost recurs as recordings accumulate, so retention periods matter as much as the initial sizing. Ask any partner for a quote that separates one-time setup from recurring storage, backup and support, and that states which recording hosts and storage tiers it assumes.
Can an internal IT team set up Jibri or BigBlueButton recording on its own?
Yes, a capable internal team can install and run both, provided it has Linux administration, reverse proxy and TLS experience, and time to test. The harder part is usually not the install but the policy and integration work around it: consent flows, retention rules, playback access and deletion. The Jibri README states that only one recording at a time is supported on a single Jibri, so a team must plan capacity and test concurrent meetings before go-live. Teams that want an outside view often use a fixed-scope engagement with written deliverables, so the internal staff keep ownership of the system afterward.
How long does recording setup take, and what changes the timeline?
The timeline depends on scope and on decisions that the organization has not yet made. A pilot that records a few meetings on one platform can be scoped quickly, but a production rollout with consent language, retention schedules, storage sizing, identity integration and load testing takes longer. The largest variables are approvals from legal, records and privacy owners, and whether storage must sit in a specific region or data center. DeployOpen does not publish durations, so the reader should ask for a timeline in the written scope, with each milestone tied to a named decision owner.
What does the client need to provide before recording work can start?
Before work starts, the client should name owners for recording policy, retention and deletion, and consent wording. The work also needs storage sizing based on expected meeting hours, retention periods and growth, plus a decision on where recordings are stored and who may play them back. Identity matters too: the team must decide how users and guests are authenticated and which roles may start a recording. On BigBlueButton, the Greenlight front end can use external OpenID Connect authentication, so the identity provider and its test accounts should be ready. Ask any partner to list these inputs in writing before quoting.
Does BigBlueButton recording need more disk than the 500 GB figure?
The 500 GB figure from the BigBlueButton 4.0 install documentation is the sizing baseline for a server that records, not a ceiling for every deployment. Actual use depends on how many recorded hours the server holds, the video and presentation content in each session, and how long recordings stay before deletion or export. A deployment that keeps recordings for years will outgrow the baseline sooner than one with short retention. Teams should measure recording size in a pilot, project it against the retention schedule, and plan for backup copies, which add storage beyond the primary copy. Confirm the sizing method with the vendor or partner before committing to hardware.
How should an organization handle an existing SaaS recording archive during migration?
Treat the existing archive as a separate records project. Start by inventorying what the SaaS provider holds, which recordings are still under a retention obligation, and which can be deleted under policy. Export rights, file formats and the provider's deletion process should be confirmed in writing with the provider, because they vary by contract. Recordings that must be kept should be moved into storage with access controls, audit logging and a documented retention rule before the SaaS account is closed. Legal and records owners should approve the transfer, and the self-hosted platform should not begin recording until the archive plan is agreed.
What should the business owner ask for in a recording quote?
Ask for a written scope that lists each platform, each recording host, the storage size and tier, the retention and deletion method, the consent workflow, the identity integration, and the testing plan. Ask which items are one-time and which recur, including storage growth, backups, patching and support. Confirm how the quote handles a pilot before production, and what happens if policy decisions change scope. DeployOpen does not publish a price list, so a quote follows from this written scope, and the reader should compare offers on the same assumptions.
Questions to ask an implementation partner about recording
Ask first how the partner sizes Jibri for peak recorded meetings, because the Jibri README states that only one recording at a time is supported on a single Jibri. Ask for the number of concurrent recorded or streamed meetings you expect at peak, how many Jibri instances that implies, and how each instance is placed and monitored. Ask whether a recording that fails to start is retried, queued or lost, and how the partner tests that a second meeting can start a recording while the first is still running. For BigBlueButton, ask for the disk sizing behind the 500 GB recording allowance in the install docs, and for the growth rate they assumed for your term or event calendar.
Next, ask how recording storage is encrypted at rest and where the keys live. Ask whether the volume is encrypted by the hosting layer or by the application, who holds the keys, and whether a backup of recordings is encrypted separately from the live copy. Ask how backups are taken, where they are stored, how long they are kept, and how a restore is tested. Recordings often contain personal data and, in healthcare or financial settings, regulated content, so ask which backup copies would also need to be deleted when a retention period ends and how the partner proves that.
Then ask how playback is restricted and logged. Ask which roles can view, download or share a recording, whether playback links expire, and whether access to the recording store is limited to named administrators. For BigBlueButton, ask how the API shared secret is protected and whether recording playback is tied to the Greenlight or LMS identity. Ask where access logs are written, how long they are retained, and who reviews them. Finally, ask how deletion is scheduled and evidenced, how streaming targets and their stream keys are stored and rotated, and how an upgrade is handled when a recording is still in progress. Request a written answer for each, and confirm it against your own environment before signing a fixed-scope agreement.
How DeployOpen scopes and builds recording for your meetings
This sequence turns a recording request into a written scope, a hardened recording path inside your infrastructure, and tested evidence that deletion and access logging work as your policy requires. Each step ends with an artifact you can review before the next one starts.
Document recording requirements and policy owners
DeployOpen works with your compliance, legal, security and platform leads to record what must be captured (meetings, classes, town halls or streams), who may start a recording, who may view or download it, how long each category is kept and who approves deletion. The output is a written requirements note that names a policy owner for each decision. Nothing is built until you have signed off on this note, and any retention period comes from your own policy or regulator, which you should confirm with your counsel.
Confirm platform and recording architecture
The team maps the requirement to the platform. On Jitsi Meet, recording and streaming run through Jibri, which supports one recording at a time on a single Jibri instance, so concurrent recording needs a capacity decision. On BigBlueButton, recordings are written to the server's disk, so storage sizing follows from meeting volume and retention. The output is a short architecture decision record covering recording capacity, storage location and whether any media leaves your network.
Build the recording path and storage location
Engineers install and configure the recording components inside your cloud account, data center or isolated network, including the Jibri containers or BigBlueButton recording storage, the storage volume, and the access path for playback. Secrets, such as BigBlueButton API shared secrets, are kept out of web pages and stored under your key management. The output is a working test deployment where a recording can be started, stored and played back by an authorized user.
Harden access and consent controls
Engineers restrict who can start and view recordings through the chosen authentication method, such as JWT tokens or an identity provider behind Greenlight, and set a visible recording notice and consent step in the meeting flow. Guest and anonymous access are reviewed so that they cannot trigger recording unless your policy allows it. The output is a hardening checklist signed off by your security team, with each control mapped to a configuration setting.
Configure retention and automated deletion
The team implements the retention rules from the first step as scheduled jobs or storage lifecycle settings, so that recordings are removed or archived on the defined schedule. Legal holds, where needed, are documented as an exception path with an owner. The output is a retention configuration and a written description of how each category is handled, which your records team can review against the policy.
Test deletion and access logging
DeployOpen runs scripted tests that create recordings, verify that unauthorized users cannot retrieve them, confirm that starting and viewing events are logged, and confirm that deletion removes the file and its playback links. Results are kept as a dated test record. The output is a test report with pass or fail results for each case, which your team can use as evidence for internal audit or a compliance assessment. DeployOpen prepares this evidence; independent auditors and certification bodies assess it.
Hand over runbooks and agree ongoing support
DeployOpen delivers operating runbooks for starting recordings, rotating secrets, extending storage, restoring from backup and running deletion jobs, along with the test scripts. Your operations team runs a handover session and confirms it can execute each runbook. Ongoing upgrades, monitoring and periodic deletion tests can be covered by a retainer, which is quoted separately from the fixed-scope build. The output is an accepted handover package and, if chosen, a signed retainer scope.
