Jitsi recording and live streaming with Jibri guide

How Jitsi recording with Jibri changes a self-hosted deployment

Jibri is the optional component that records or streams a Jitsi Meet conference, and each concurrent recording needs its own Jibri instance on its own machine or VM. If you already run a self-hosted Jitsi Meet deployment and now need recordings or a live stream for meetings, treat this as a separate capacity decision that belongs in the plan before anyone presses record. The web server, Prosody, Jicofo and videobridges keep the same roles when you add Jibri, but the number of machines you operate, monitor and secure grows. Your design should state the maximum number of simultaneous recordings you expect, because that number sets how many Jibri hosts you need.

Jibri joins a conference much like a participant. It runs Chrome in a virtual framebuffer so the page renders without a physical display, then encodes the output with ffmpeg. That makes each Jibri far heavier than the core services, which mainly route media. The official Docker setup runs jibri as its own container, separate from the web, prosody, jicofo and jvb containers, so the recording workload can be placed, restarted and monitored on its own. The researched facts do not give sizing figures for CPU, memory or shared memory on Jibri, so ask your team to measure them with a test recording at your expected meeting length on the hardware you intend to use, and confirm the settings against the jibri README and the Docker guide.

Plan capacity per recording, not per meeting. Because one Jibri supports only one recording at a time, five overlapping recordings need five Jibri instances, each on its own host, plus a rule for what happens when all of them are busy. Decide who may start recordings, whether recordings may overlap during peak hours, and what users see when no Jibri is free. Ask the people building the deployment to write the concurrency limit and the busy behavior into the design document, and to test a request that arrives when every instance is occupied. Without this, the first busy afternoon becomes the test.

Storage grows with meeting length and with the number of recordings, and it fills the Jibri hosts unless files are moved off them promptly. Define retention before go-live: how long recordings are kept, where they are stored, who may download or view them, and how deletions are recorded. Also decide whether live streams go to a single external destination, since that determines who receives the content and which parties hold a copy. These are organizational decisions, and the platform will not make them for you. Write them down as policy, then configure storage and access to match.

Recording and live streaming create consent and notice obligations that Jitsi does not handle for you. Decide how participants learn that a session is being recorded or streamed, how consent is captured where your jurisdiction or internal policy requires it, and how a participant can object or ask for a recording to be removed. Involve your legal, privacy and HR contacts in the wording, and confirm which rules apply to the countries and staff your meetings involve. DeployOpen can prepare the technical controls, configuration and evidence for these decisions, but the legal position is yours to confirm with qualified counsel.

Which components Jibri adds to the Jitsi stack

Jibri adds a recorder that joins each conference as a participant, drives a browser, and encodes the result. The components below connect through XMPP, Jicofo and a storage location, and each has settings to confirm against the jibri repository before you size or deploy.

Jibri service and its one-recording limit

Jibri is the service that starts, runs and stops a recording or live stream of a Jitsi Meet conference. The jibri README states that one Jibri supports only one recording at a time, so each concurrent recording needs its own Jibri instance. Plan the count from the number of recordings expected to run at the same time, and confirm the current behavior in the jibri repository before sizing.

Chrome and ffmpeg capture path

Jibri drives a Chrome browser that opens the conference like any other participant, then uses ffmpeg to encode the captured audio and video into a recording or stream. The browser is the component most sensitive to version changes, so record which Chrome build your Jibri image or host installs. Test a short recording after every upgrade, and ask the jibri documentation which encoding options and output targets your release supports.

Virtual framebuffer for headless capture

A Jibri host normally has no monitor, so the browser renders the meeting into a virtual framebuffer, an in-memory display that gives Chrome a screen to draw on. The framebuffer's resolution and color settings shape the captured layout. Confirm the display settings the jibri project expects before you change them, and plan for a headless server or container with no desktop session.

XMPP and Jicofo join path

To record a conference, Jibri signs in to the XMPP server, Prosody in the standard layout, and joins the room through Jicofo, the conference focus, as a participant. It needs a dedicated recorder account with access to the rooms it must capture. Check that the account, its domain and its authentication settings match your Prosody configuration, then test that a recording started from a meeting produces output. Exact key names belong to the jibri repository.

Storage path for finished files

Jibri saves finished output to a storage location on its host or container that you configure, and a separate process or manual step moves files to long-term storage. Decide the destination, retention period and access controls before go-live, because recordings can contain confidential discussion. Confirm the output directory setting, file naming and any upload or cleanup hooks in the jibri repository, and check that files are complete after a long session.

Docker and Debian deployment layouts

In the official Docker setup, jibri runs as its own container beside web, prosody, jicofo and jvb, with jigasi optional. Since stable-11146 the containers run rootless with read-only filesystems, so define writable paths for recordings explicitly. On Debian, jibri installs on its own host or VM, separate from the core Jitsi services, because each Jibri should run on its own machine. Choose the layout before sizing hardware, and test the network path between components.

Which Jibri layout and storage model fits the recording need

This table compares the layout, storage and output choices for Jibri, the recorder that joins a meeting as a browser client. Read each row as a decision: the first three rows set up the isolation model, the storage target and the output type, and the last rows show who owns the work and what each choice adds to operations.

Decision	Option A	Option B	When to choose which
Host layout	Dedicated VM per Jibri instance: one recording or stream per machine, with the Chrome and ffmpeg workload kept off other services	Docker container on a shared host: several Jibri containers on one machine, each still handling a single recording at a time	Dedicated VM fits most regulated deployments because the upstream README says one recording per Jibri, run on its own machine or VM. Shared hosts suit low, predictable concurrency and need strict resource limits
Concurrency model	One Jibri per concurrent recording or stream, so capacity grows by adding instances	Fewer instances with a queue: meetings wait for a free recorder, which lengthens the time before a recording starts	Choose one instance per simultaneous recording when meetings must always be captured. Queueing is acceptable only where delayed recordings are tolerable and users are told so
Finished file storage	Local disk on the Jibri host: simple, but files stay on the recorder until a separate process moves them	Mounted network or object storage target: files leave the recorder and can be retained centrally	Use a central target when retention, access control and backup must be managed in one place. Confirm the mount, permissions and failure behavior with your storage team before go-live
Output type	Recording only: files are written locally or to the storage target after the meeting ends	Live streaming to an external destination: the Jibri instance sends a continuous outbound feed while the meeting runs	Record only where a stored file is enough. Choose streaming when viewers outside the meeting need live access, and plan the outbound link as a separate capacity item
Outbound bandwidth	Minimal for recording only, because media is written to storage rather than sent across the network	Continuous upload for each live stream, multiplied by the number of concurrent streams and the destination's ingest requirements	Ask the streaming platform for its ingest bitrate and confirm the site uplink can carry every concurrent stream at once. Upstream does not publish a bitrate figure in the context used here
Isolation needs	Strongest separation: the recorder's browser and encoder cannot compete with videobridge or signaling services	Weaker separation: a resource spike in one container can affect neighbors, so CPU and memory limits must be set per container	Dedicated VMs suit organizations with confidentiality or availability requirements on the video platform. Shared hosts need documented limits and monitoring before they are approved
Retention ownership	Local disk: the IT team must schedule cleanup and copy files before they are removed	Central storage: retention rules, legal hold and deletion are set on the storage system and reviewed by the owning team	Name one owner for deletion and access reviews before launch. Recordings often contain personal data, so the owner should be agreed with legal and privacy staff
Operational effort	Several machines to patch, monitor and size, plus image management for each recorder	Fewer machines but tighter configuration of container limits, storage mounts and shared-host updates	Ask your team how many recorder hosts they can patch and monitor. Recorder count, not participant count, usually drives this effort

How to add Jibri one recording at a time

This sequence adds one Jibri instance to a Jitsi Meet deployment and proves it can record or stream a conference on its own. Each step ends with a check you can run before moving on, so every additional instance is confirmed the same way. Plan to repeat the full test for each Jibri you add.

Confirm release and host OS compatibility
Your engineer confirms that the Jitsi Meet release you run is a stable tag and that every host meets the supported platform list. The Debian and Ubuntu quick start supports Debian 12 (Bookworm) or newer and Ubuntu 24.04 or newer, and it requires OpenJDK 17. Confirm the same release tag across the web, Prosody, Jicofo, videobridge and Jibri components, because mixed versions cause hard-to-trace failures. Record the tag and OS version in your change log. Done means every component reports the same stable release and each Jibri host passes the OS check.
Provision a dedicated machine for each Jibri
Your infrastructure team creates a separate virtual machine or server for each Jibri instance. Jibri runs Chrome in a virtual framebuffer and encodes video with ffmpeg, so it should not share a host with other Jitsi roles. The project's README states that only one recording runs at a time on a single Jibri, so the number of machines sets how many recordings can run together. Ask your provider or the project for current hardware guidance, since this guide does not give sizing figures. Done means each host is reachable from the XMPP server and has its own storage mount ready.
Install Jibri from Docker or Debian packages
Your engineer installs Jibri using the Docker extension if you run the official Docker setup, or the Debian packages if you run the Debian or Ubuntu deployment. In the Docker path, Jibri runs as its own container alongside web, prosody, jicofo and jvb, and it is enabled through the optional recording extension. In the Debian path, the jibri package installs the service and its dependencies. Confirm that the Chrome and ffmpeg dependencies install cleanly on the host. Done means the Jibri service starts and stays running after a reboot.
Configure the XMPP connection and recording settings
Your engineer creates a dedicated XMPP account for the recorder in Prosody and sets the connection values in the .env file for Docker or in the Jibri configuration files for Debian installs. The settings cover the XMPP server address, the recorder credentials, the recording and streaming options and the output format. Keep these values in your configuration management tool so every instance receives the same settings. Done means the Jibri log shows a successful XMPP login and Jicofo lists the instance as available for recording.
Set the storage path with restricted access
Your engineer creates a dedicated directory for finished recordings and assigns ownership to the Jibri service account. Other local users and services get no access to this directory, and the path is kept off any shared web root. Confirm your retention and access rules with your privacy and compliance owners before the first recording, since recordings often contain personal data. Done means the service account can write a test file to the path and a second account is denied access.
Start one test recording on the instance
Your team opens a test meeting on the production or staging domain, joins with at least one participant, and starts a recording from the meeting controls. Watch the Jibri logs and the Jicofo view to confirm the instance changes to a busy state while it records. The test should use the same join method your users will use, including any token or authentication setting you have enabled. Done means the recording starts and ends cleanly, and a new file appears in the storage path you set in the previous step.
Confirm the output file plays and streams
Your team opens the recorded file in a standard media player and checks that audio, video and the expected length are present. For live streaming, run a short test broadcast to the destination and confirm that the stream arrives with working audio and video. Keep one copy of the test file as a reference for future comparisons. Done means the recording plays from start to finish and any live stream reaches its destination without dropped audio.
Repeat the full test for every instance
Your team runs the registration check, the test recording and the playback check on each Jibri instance separately, then starts two recordings at the same time to confirm that the scheduler assigns them to different instances. Because each Jibri handles one recording at a time, a second recording request should be served only when another instance is free. Record the results per host in your deployment log. Done means every instance passes each check and the concurrent test assigns recordings to separate hosts.

What drives recording effort, storage and cost

This table lists the drivers you control when adding Jibri to a Jitsi Meet deployment, and how each one changes machines, storage, stream bandwidth and internal operating time. Use it to decide which settings to fix before a pilot and which numbers to measure. Figures for machine size, storage per hour and cost are not given here, so measure them in your own pilot and ask for a quote that prices each Jibri host and storage target separately.

Driver	Effect on machines, storage, bandwidth and effort	How to keep it down
Concurrent recordings	Each concurrent recording needs its own Jibri instance, because a single Jibri supports only one recording at a time. Peak concurrency sets the number of Jibri hosts, which are usually separate machines or VMs.	Agree which meetings must be recorded and limit recording to them. Confirm peak concurrency in the pilot before sizing hosts.
Average meeting length	Longer meetings keep a Jibri host busy for longer and grow the recording file, so storage and encoding time rise with total recorded hours rather than with meeting count alone.	Set a clear recording start and stop practice, and ask users to stop recording when a session ends.
Maximum meeting length	Maximum length determines the largest single file and how long one Jibri host stays occupied. Plan for the longest expected session, not the average, when deciding how many hosts to keep ready.	Measure the longest real sessions in the pilot and size against that, rather than against typical sessions.
Recording resolution and format	Higher resolution and quality settings increase CPU load on each Jibri host, reduce the number of recordings one host can handle and increase storage per hour of video.	Choose the lowest resolution that meets the business need and test the output file size and host load before rollout.
Number of live streams	Each live stream uses outbound bandwidth from the Jibri host to the streaming destination and occupies that host the same way a recording does, so streams count toward concurrency.	Limit streaming to approved events and confirm the outbound bandwidth available at each Jibri location.
Retention period	Retention sets how much recorded data accumulates over time. Storage growth follows recorded hours multiplied by the number of months kept, and backup copies add to that total.	Agree a retention schedule with legal and records owners, delete on schedule and ask whether the storage target supports lifecycle rules.
Number of environments	Test and staging environments each need their own Jibri hosts and storage if recording is exercised there, which adds machines, storage and internal test time even when they carry little traffic.	Test recording with short scripted meetings, reuse a small shared Jibri pool for non-production, and remove unused hosts after testing.
Internal operating time	Each Jibri host needs monitoring, updates, certificate and credential rotation, storage checks and recording access requests. This effort grows with the number of hosts, environments and retention rules.	Standardize host builds with configuration management, reduce the number of hosts, and document who answers recording access and deletion requests.

How Jibri differs across Docker, Debian and larger deployments

In the official Docker setup, Jibri runs as its own container beside the web, Prosody, Jicofo, videobridge and other containers. Since release stable-11146, the containers run rootless with read-only filesystems, so Jibri can only write to the locations you mount for it. Every service shares one host, which means Chrome and ffmpeg load competes with the videobridge for CPU, memory and disk during a recording.

Host resources: Confirm CPU, memory and disk headroom with Jibri's workload added. Establish the figures with a test recording at your target resolution, and ask your vendor or test lab for guidance on the numbers you need.
Writable output path: Because the filesystem is read-only, confirm which mounted volume receives finished recordings and that it has room for your retention period.
Concurrency: One Jibri instance handles one recording at a time, so a single container cannot serve overlapping recordings.
Shared impact: A long recording running beside a busy videobridge can affect meeting quality, so monitor both services during peak use.

Before go-live, run a test recording on the host at full load and confirm the output lands on the correct volume.

Where recordings are stored, how long they are kept and who can reach them

The first decision is where a finished recording lands and who controls that location. Jibri runs Chrome in a virtual framebuffer and encodes the output with ffmpeg on its own machine or VM, so the file exists on the Jibri host before anything else touches it. The lifecycle has four stages: the file is written on the Jibri host, it is moved or copied to the storage target you choose, a person downloads it, and it is eventually deleted. Each stage is a copy that needs a named owner. Before you design this, check the jibri repository on GitHub to confirm how output is written, whether the finishing step moves or copies files, and whether it includes any upload step. Do not assume a built-in upload to object storage. Then decide how the storage target is encrypted at rest, and how the temporary copy on the Jibri host is encrypted and cleared.

Jitsi's own encryption statements cover live media, not stored recordings. The security page describes audio and video encrypted on the network with DTLS-SRTP, and says the videobridge decrypts packets in memory while routing and never stores them. That covers the meeting itself. A recording is a new data set created by a separate service, so it carries its own classification, retention and privacy obligations. Confirm with the Jitsi documentation whether end-to-end encrypted sessions can be recorded at all, and what the recorder actually receives in that case. Do not describe a recording to participants as end-to-end encrypted unless your testing shows the recorded file is protected that way. Record the answer in your data inventory so legal and privacy owners review it with the rest of the meeting data.

Set retention by meeting type, not with a single period for everything. Typical categories are internal team meetings, customer or patient calls, board or committee sessions, and public livestreams. Each category needs a stated period, a deletion method and an owner who approves exceptions. Ask whether your Jibri setup deletes files on its own or whether a scheduled job is required, and test it. A legal hold must stop deletion everywhere the recording exists, including the Jibri host, the storage target, replicas and backups. A deletion request from an individual must reach every copy and be logged. Plan how you will identify which recordings belong to one person, because file names alone may not show it. Write the procedure before the first meeting is recorded.

Access to downloads is controlled by the storage system, not by the meeting room. Limit read access to a small named group, use individual accounts rather than shared credentials, and turn on logging for downloads and deletions. Restrict who can start a recording by tying it to moderator roles in your authentication setup, which is covered in the SSO section. Give participants clear notice before recording starts, and confirm how your policy handles consent and guests. Before the first real recording, get legal and privacy owners to approve the retention periods, hold procedure, deletion process and access rules in writing. Then run a test meeting through the full lifecycle, including a hold, a deletion and a download by an unauthorized account, and keep the results as evidence.

Protecting recordings, streams and the Jibri account

Recording and streaming put some of the most sensitive data in a Jitsi deployment on your own hosts: a bot account that can enter rooms, decisions about who may capture a meeting, files that hold audio and video, and keys that open a live destination. The cards below cover each control and the check that confirms it. Work through them before the first recording, and repeat the checks after every upgrade.

Jibri XMPP account credentials

Jibri joins conferences through its own XMPP account on Prosody, so that account can enter rooms and capture media. Create it as a dedicated user with a long random password, held only in the deployment's environment file or a restricted secrets store. Confirm in your Prosody and Jibri configuration what the account is permitted to do, and limit who can read the host files that contain its password. Rotate the password on a schedule your security team sets and after any staff change that touched the host.

Who can start a recording

Recording and streaming controls can be reached by participants depending on how your deployment handles roles and moderation, so settle the rule before launch. Identify how your authentication model, such as JWT tokens issued by your identity system, determines who holds moderator rights. Confirm whether the start control is limited to moderators or specific roles. Test with a non-moderator account to check that the control is hidden or refused, and record who started each session where your configuration supports it.

Rootless containers and the output path

Since stable-11146, the official Docker setup runs its containers rootless with read-only filesystems. Jibri is the exception because it must write recordings, so its writable output directory is the one path that needs deliberate lockdown. Give it a dedicated host directory owned by the account the container runs as, grant no group or world write access, and keep it off shared mounts. Confirm the ownership and permissions again after each upgrade, then verify with a test recording that files appear only in that directory.

Encryption at rest for recordings

Jitsi encrypts audio and video on the network with DTLS-SRTP, and the videobridge decrypts packets in memory without storing them. Jibri captures and encodes the conference, so the recording files on the host hold audio and video in the clear. Encrypt the volume or filesystem that holds them using the storage platform your organization already runs, and agree key management and backup handling with your security team. Confirm whether Jibri offers any built-in option, and treat host-level encryption as the default plan.

Stream keys and destination URLs

A live-stream destination URL and its stream key work together as a credential that grants publishing rights. Treat both as secrets: keep them out of room links, chat, tickets and version control, and supply them per session where your setup allows. Restrict who can read the configuration that holds them. Ask your streaming platform how keys are issued, expired and revoked, and rotate any key that may have been shared. Log that a stream started without writing the key into the log.

Notice and consent for participants

Recording a meeting creates obligations that the software does not meet on its own. Build an organizational process that gives notice before recording starts, sets out how consent or objection is handled, and tells guests and external participants how they are informed. Set retention rules for the files and write them into your meeting policy. Confirm the requirements with legal counsel for every jurisdiction where participants are located, because they vary.

How to confirm a recording or stream works and fails safely

A recording test should prove three things: the file is complete and correct, the second recording is handled as configured, and every failure is visible to someone who can act on it. Start with the basic path. Sign in with an account that is authorized to start recording under your authentication setup, start a recording in a test room, and let it run for a known length while speaking and sharing a screen. When it ends, open the file and confirm that its length matches the meeting, that audio from every speaker is present, that video is not frozen, and that the file lands at the storage path your deployment defines. Write down the exact path and file name pattern for your release, because you will check them again after every upgrade.

Next, test concurrency. The Jibri README states that only one recording runs at a time on a single Jibri, and that each Jibri should run on its own machine or virtual machine. Start a recording in one test meeting, then start a second recording in another meeting while the first is still running. Observe whether the second request is queued, refused with a message, or accepted and then lost. Silent loss is the outcome to rule out. Confirm the behavior your release actually shows, then check the logs on the Jibri host and the message the user sees. Repeat the test with one more Jibri instance online to confirm that the second recording starts on the free instance.

Test live streaming end to end, using a stream destination you control rather than a public channel. Start a stream, confirm that a viewer on the destination sees the correct video and hears the correct audio with acceptable delay, then stop the stream from the meeting and confirm that the destination closes cleanly. Check how the stream key is supplied and where it appears in logs, since a key exposed in a log is a credential leak. Then run the failure case: stop the Jibri host during a stream and confirm whether the destination shows an error, whether the meeting participants are told, and whether a new stream can start afterward.

The most important failure test is a Jibri host going down mid-recording. Stop the container or virtual machine during a test recording, then check four things. Does a partial file remain, and can it be played? Are the user who started the recording and the other participants told that recording stopped? Is the recording marked as failed rather than complete? Does the Jibri instance return to a clean idle state after restart, or does a stale busy state block later recordings? Confirm each answer in the Jibri release you run, because failure handling changes between releases. Also confirm that the Docker volume mapping allows the container to write to the storage location under its read-only filesystem settings.

Finally, test retention. Use a short retention period in a non-production environment, create a test recording, and confirm that it is removed from primary storage when the period expires. Check backups and any copies made by a sync job, since a deleted file that survives in a backup still counts as retained. Confirm that no link, index or metadata entry still gives access to the deleted file. Ask your team which mechanism performs the deletion, whether a script, a scheduled task or a storage lifecycle policy, and where its logs are kept. Keep the results as evidence for your compliance team, and rerun the full plan after each Jibri or Docker image upgrade.

What to monitor, back up, upgrade and document after go-live

Recording adds moving parts that a plain Jitsi Meet deployment does not have: a dedicated Jibri host for each concurrent recording, a storage path that fills over time, and a browser-driven pipeline that can fail quietly. The cards below cover what the operations team watches, what it backs up, how it keeps versions aligned and which documents it should receive before handover.

Jibri host health and failed recordings

Each Jibri host runs Chrome in a virtual framebuffer and encodes with ffmpeg, so CPU, memory and disk pressure show up there first. Collect those metrics per host and count failed recordings as a separate signal, since a host can look healthy while every session ends in an error. Track the failure reason where Jibri reports one, and confirm the metric names and thresholds with your monitoring platform and the Jibri documentation before go-live.

Alerts for storage fill and stalled recordings

Alert on storage fill before the recording directory is full, because a full disk can stop encoding mid-meeting and leave partial files. Also alert when a recording starts but never reaches a completed state, which often points to a stuck Chrome or ffmpeg process rather than a disk problem. Set thresholds against the length of your longest meetings and the write rate you measure during testing.

Backup of configuration and secrets

Back up the Jibri configuration, the relevant .env values and the credentials Jibri uses to connect to Jitsi, stored encrypted and restorable on a clean host. Keep secrets out of general file shares and rotate them through the same process as the rest of the Jitsi stack. Exclude recordings from routine backup unless a written retention policy requires a copy, since recordings are large and carry their own access obligations.

Release alignment with XMPP and Jicofo

Run Jibri on the same Jitsi release family as Prosody, Jicofo, the videobridges and the web app, so the XMPP messages and Jicofo interfaces it depends on stay compatible. Mixed versions can leave a Jibri that starts but never joins a conference, so treat version drift as a defect. Test each upgrade on a staging stack first, and confirm the current stable build with the jitsi-meet repository before scheduling a change.

Runbook and on-call steps for failures

The runbook should cover how an operator starts and stops a recording, how to confirm the file is being written, and how to clear a stuck session without disturbing the meeting. The on-call procedure should name who is paged when one Jibri instance fails, how to take that instance out of rotation, and how to restore recording capacity on a spare host. Rehearse both with the team before go-live.

Retention schedule and storage map

The retention schedule states how long each recording is kept, who approves deletion and how deletion is verified, following the policies your legal and compliance teams set. The storage map records which host writes to which volume, where finished files move, and which systems can read them. Keep both documents in version control and review them at every upgrade or change to the storage layout.

Questions buyers ask about Jibri recording and streaming

How much does adding Jibri recording to Jitsi Meet cost?

The cost depends on a few drivers, so a quote should separate them instead of showing one total. One-time work covers planning, building the Jibri hosts, connecting them to the Jitsi deployment, testing with a plan of test meetings, and writing documentation. Recurring costs are paid to your cloud provider or data center for the Jibri machines or VMs, recording storage and bandwidth, plus any ongoing support, upgrades and monitoring you buy. Ask the quote to list each Jibri instance, the storage assumption, how retention is handled, and whether support covers the recording component. DeployOpen does not publish prices. A quote follows from the written scope.

How long does a Jibri build take to finish?

The duration depends on the starting point and the recording load, so no single timeline fits every environment. Teams that already run a stable Jitsi Meet deployment need less time than teams building the web, Prosody, Jicofo and videobridge tiers at the same moment. The main drivers are the number of Jibri instances, whether they run as Docker containers or on Debian or Ubuntu hosts, how storage and retention are approved, how much testing is needed across browsers and networks, and how quickly your change process moves. Agree the duration in the written scope, and ask for the milestones that depend on your approvals, such as legal sign-off on retention.

Can our internal IT team set up Jibri on its own?

Some teams can, but the work is not a good first project for a team new to Jitsi. The Jitsi scalable setup guide warns that building scalable infrastructure is not a task for beginning administrators and recommends configuration management tools such as Ansible or Puppet. Jibri adds more moving parts: Chrome running in a virtual framebuffer, ffmpeg for encoding, dedicated hosts, storage paths and container settings. Check whether your team has experience with Linux administration, containers, certificates and browser-based test automation. A practical option is to build one Jibri instance with an outside partner, then let your team repeat the pattern with a runbook.

What must our team supply before a Jibri project starts?

Your team supplies the decisions and resources that only your organization can provide. These include the hosts or VMs for each Jibri instance, which must be dedicated to that role, and the storage location and expected recording volume. Legal and compliance teams must set retention periods, consent and notice wording, and who is allowed to start a recording or stream. Security must approve network paths, certificates for the Jitsi domain (Jitsi's handbook says HTTPS with a proper domain certificate is necessary for working audio and video), and access to stored files. Finally, name the people who will run a test meeting plan that covers normal and failure cases before recording goes live.

How many Jibri instances do we need for concurrent recordings?

Plan one Jibri instance for each recording that may run at the same time. The Jibri project documentation states that only one recording at a time is supported on a single Jibri, and that it should run on its own machine or VM. To size the pool, count the maximum number of meetings that could need a recording at once, then add spare capacity so a failed or busy instance does not block a meeting that must be recorded. Confirm how streaming and recording share an instance, because a stream and a recording may compete for the same host. Your test meeting plan should include two simultaneous sessions to prove the pool behaves as designed.

Can Jibri recordings be encrypted or deleted on a schedule?

Confirm both points before design, because the Jitsi material on encryption covers live media rather than stored files. Jitsi states that audio and video are encrypted on the network with DTLS-SRTP, and its end-to-end encryption is limited to audio, video and screen sharing in supported browsers. A recording is produced by a Jibri participant, so the protections for stored files must come from your design. Ask how Jibri writes recording files, whether they can be encrypted at rest on your storage platform, and whether deletion on schedule is handled by the application or by lifecycle rules on your storage. Put the answers and the retention approval into the written scope.

How DeployOpen scopes, builds and hands over Jibri recording work

DeployOpen plans, implements and documents Jitsi recording and live streaming with Jibri inside your own infrastructure, so the recording path is designed alongside the Jitsi Meet deployment rather than bolted on afterward. Each engagement starts from a written scope that fixes what is recorded, where recordings are kept and who operates the result.

How we scope

Count the concurrent recordings and live streams you expect, since each active recording needs its own Jibri instance.
Record which meetings must be recorded, who may start a recording, and how participants are told.
Agree in writing where recordings are stored, how long they are kept, and who may access them.

How we build

Provision Jibri on dedicated machines or VMs, one recording per Jibri, with Chrome and ffmpeg configured.
Confirm the Jibri containers or hosts can reach the Jitsi signaling and web components on the internal network.
Test a recording and a live stream end to end, then check file output, audio sync and storage paths.

How we hand over

Deliver written runbooks for starting, stopping and troubleshooting recordings and live streams.
Document Jibri sizing, storage locations, retention settings and the procedure for removing old files.
Walk your operators through monitoring points and the steps to add another Jibri when demand grows.

How we support

Ongoing support and upgrades for Jibri are available as a retainer, agreed separately from the build.
Re-test recording after each Jitsi Meet or Jibri upgrade, since browser and encoder changes can affect output.
Confirm with your team which support hours, response paths and change requests the retainer covers before signing.