Jitsi Meet server requirements

This guide is for administrators choosing a self-hosted Jitsi Meet server. Participants joining an existing meeting do not need to buy a server; see joining a meeting.

If you can join but your connection struggles, use the participant guide to Low bandwidth mode and data usage before translating a call symptom into a server-size decision.

Start with official planning guidance

These are the handbook’s suggestions, not a tested capacity guarantee. Adding memory alone does not establish how many participants you can serve. [S1]

Define the workload before buying

Write down the simultaneous participants across all rooms, room sizes, camera activity, received video streams and target quality. Include screen sharing, recordings, captions and restrictive networks. Use the planning calculator for an illustrative bandwidth estimate, then measure the actual deployment.

We do not publish a fixed participants-per-instance promise here. A statement such as “this server supports 50 users” needs a release, workload, network specification and measured quality results to be useful.

Bandwidth planning

A simple video-only estimate is:

server video egress Mbps = participants × received camera streams per participant × Mbps per stream

For an illustrative ten-person tile-view meeting, assume nine other camera streams per receiver and 0.4 Mbps per stream. The estimate is 10 × 9 × 0.4 = 36 Mbps before audio, screen sharing, protocol overhead or relay traffic. Those inputs are assumptions, not measured Jitsi defaults.

Use camera share and layout to estimate received streams. Do not apply the same large-room layout to every small room. P2P can reduce bridge media for a two-person call when enabled and successfully connected, but bridge or TURN fallback still needs capacity. The calculator budgets for bridge video rather than assuming two-person traffic is free. [S5]

Docker first, package differences second

For Docker, start with matching release files and image tags from the Docker installation guide. Check memory available to Docker as well as host RAM. A container does not remove the Java runtime’s memory requirements. [S4][S6]

For Debian packages, the current handbook lists Debian 12 or newer and Ubuntu 24.04 or newer. Follow its current installation instructions rather than applying Docker environment variables to a package deployment. [S3]

HTTPS, bridge media, certificate renewal and configured TURN fallback need appropriate firewall rules. Docker port mappings can differ from package defaults. Use the ports and firewall guide and test from outside your server’s network. [S3][S4]

Recording: size a separate Jibri service

One Jibri instance records one meeting at a time. It captures a Chrome session and encodes the output with ffmpeg, and is intended to run on a separate machine or VM. Hosting several instances on one machine requires validating CPU, memory, disk and encoding performance for the chosen output. [S2]

For three simultaneous recordings, plan three Jibri instances, not one recorder capable of three meetings. Keep recorder failure or full storage from taking down meeting services. Follow the Jibri recording guide for installation and output verification. [S1][S2]

Transcription: choose the model first

Vosk’s small models typically need about 300 MB of runtime memory; large models can need up to 16 GB. This is model memory, not the total size of a Jitsi, Jigasi and transcription server. Language, accuracy requirements and simultaneous transcription work affect the choice. [S7]

Record the exact model name and measure memory under your target load. Add resources for the transcription service and other processes. A universal “16 GB minimum for transcription” is not justified. See transcription options.

Validate before production

1. Record the release, host resources, provider network and meeting configuration.
2. Run the intended simultaneous rooms with cameras, screen sharing and representative client networks.
3. Include three-person calls and a network that blocks UDP to exercise bridge and fallback paths.
4. Watch CPU, memory, outbound traffic, packet loss and visible media quality over a representative duration.
5. Test recordings and captions separately; verify the saved output and disk usage.
6. Keep headroom and repeat after meaningful release or workload changes.

This is a proposed evaluation checklist. We have not run a capacity benchmark for this article, and the calculator does not establish production capacity.

Use the blank capacity validation worksheet to keep a reproducible record. The calculator can download your assumptions as planning notes; record observed measurements separately. Keep release, duration, network conditions and failures alongside the results, and remove meeting links, credentials and participant details before sharing.

Cost planning

Budget for compute, disks, outbound data, recording storage, backups and operating time. Burstable instances can have additional CPU-credit costs. Check current regional pricing and the selected instance’s network characteristics before committing. The self-hosting cost guide explains cost categories; this article does not quote an unverified monthly total. [S8]

Open questions for your deployment

• How many rooms run at once, and how many camera streams do receivers subscribe to?
• What happens when P2P or direct UDP fails?
• Which recording output and speech model do you need?
• What measured load leaves enough headroom for your peak?

Sources

Reviewed on 2026-10-13. Recheck upstream guidance on releases and validate your workload before buying capacity.

• [S1] Jitsi requirements
• [S2] Jibri architecture and recording concurrency
• [S3] Jitsi Debian/Ubuntu installation and firewall
• [S4] Jitsi Docker handbook
• [S5] Jitsi Meet configuration, P2P settings
• [S6] Historical Docker memory investigation, 2024 report, not a claim of a current general bug
• [S7] Vosk model memory guidance
• [S8] AWS burstable unlimited mode