Collaboration Infrastructure_Parallaxis Internal CollaborationCapacity planning

Planning recorder capacity for self-hosted meetings_

Parallaxis converted the working Jibri deployment into a capacity model with one active recording per worker, queue behavior, resource telemetry, file-retention rules, and recovery checks. Teams can set honest recording

Jitsi recording capacity
Recorder-per-session capacity model
CPU and memory telemetry

Challenge_

A single working recording does not establish production capacity. Concurrent meetings compete for recorder workers, CPU, memory, browser processes, and storage bandwidth.

Approach_

Parallaxis converted the working Jibri deployment into a capacity model with one active recording per worker, queue behavior, resource telemetry, file-retention rules, and recovery checks.

Outcome_

Teams can set honest recording limits and decide when to add workers instead of discovering saturation during an important meeting.

Overview

A single working recording does not establish production capacity. Concurrent meetings compete for recorder workers, CPU, memory, browser processes, and storage bandwidth.

Parallaxis converted the working Jibri deployment into a capacity model with one active recording per worker, queue behavior, resource telemetry, file-retention rules, and recovery checks.

The engineering decision

Capacity planning starts with the scarce component. For Jibri that is the recorder worker; scaling the web frontend alone does not create recording slots.

How the system works

The implementation separates intake, validation, state changes, side effects, and reporting. That separation makes failures visible and allows one layer to change without rewriting the entire workflow.

Operational users see explicit statuses and exceptions; technical teams retain identifiers, timestamps, versions, and logs needed to reproduce a result.

Outcome