A Jitsi Meet server is lighter than most people expect on CPU and heavier than most people expect on network. The table below is what we size customer servers with, followed by the reasoning so you can adjust it for your own meetings.
Quick sizing table
These figures come from the servers our platform deploys on AWS. Costs are rounded on-demand prices in ap-south-1 (Mumbai) as of August 2026, and they change by region and over time.
| Server | vCPU / RAM | Comfortable load | Approx. AWS cost / month |
|---|---|---|---|
| t3.small | 2 / 2 GB | Up to about 20 participants, testing | $18 |
| t3.medium | 2 / 4 GB | Up to about 50 participants | $33 |
| t3.large | 2 / 8 GB | Up to about 100 participants, minimum for recording | $63 |
| c5.large | 2 / 4 GB, compute optimized | A dedicated recorder for about 1 concurrent recording | $68 |
| c5.xlarge | 4 / 8 GB, compute optimized | A dedicated recorder for 2 to 3 concurrent recordings | $136 |
| t3.xlarge | 4 / 16 GB | Minimum for Vosk transcription | $125 |
“Participants” means the total across all rooms at the same moment, with most people on camera. Audio-only meetings go much further.
CPU
Jitsi Videobridge (JVB) is a selective forwarding unit. It receives each participant’s video once and forwards copies to the others without decoding or re-encoding them. That is why a 2 vCPU machine goes a long way, and why the CPU graph on a busy videobridge often looks calm while the network graph is not.
Where CPU does matter:
- Jibri recording. Jibri joins the meeting in a headless Chrome and encodes the screen with ffmpeg. One Jibri records one meeting at a time and keeps roughly two cores busy while it does.
- Many small rooms. Signalling (Prosody and Jicofo) scales with the number of conferences, so hundreds of tiny rooms cost more than one large room with the same headcount.
A note for AWS: T3 instances are burstable and launch in “unlimited” mode by default. A server that stays above its baseline CPU for hours does not slow down, it bills extra CPU credits. Watch the CPUSurplusCreditsCharged metric, or move steady heavy workloads to a C5 or M5 instance.
RAM
The Jitsi components are Java (Jicofo, JVB) and Lua (Prosody) processes with modest memory needs. On our Docker deployments:
- 4 GB runs web, Prosody, Jicofo and JVB with room to spare.
- 8 GB is the minimum we deploy when Jibri records on the same server, because Chrome and ffmpeg need their own headroom.
- 16 GB is the minimum for local transcription with Vosk. The English speech model is loaded into memory by the Vosk server, and an 8 GB machine runs out once meetings start.
Bandwidth: the real limit
Every participant uploads their camera once, in up to three quality layers (simulcast). The videobridge then sends each receiver only the layers they need: a high layer for the active speaker, low layers for thumbnails.
A useful planning estimate for server upload:
server egress (Mbps) ≈ participants × streams each person receives × Mbps per streamWith typical defaults, thumbnails use around 0.2 to 0.5 Mbps and a large speaker view around 1.5 to 2.5 Mbps. Ten people all on camera in tile view works out to roughly 10 × 9 × 0.4 = 36 Mbps of server upload. The server size calculator does this sum for you.
Things that reduce bandwidth sharply:
- Two-person calls go peer to peer and do not touch the videobridge at all.
- Each receiver only gets video for the tiles actually visible on their screen, so a 40 person room does not mean 40 × 39 full streams.
- Setting a lower maximum resolution in the server config caps every stream.
Inbound traffic is roughly one upload per participant, so it is rarely the bottleneck.
Network and ports
| Port | Protocol | Purpose |
|---|---|---|
| 443 | TCP | Web app and signalling (WebSocket) |
| 10000 | UDP | All audio and video to the videobridge |
| 80 | TCP | Let’s Encrypt HTTP challenge and redirect to HTTPS |
| 22 | TCP | SSH for administration, restrict to your IP |
If 10000/udp is blocked, two-person calls still work (they go peer to peer) but calls with three or more people show black video or drop. That is the single most common Jitsi problem we fix. See video stops with 3 participants.
The server needs a public IP. If it sits behind NAT, as every EC2 instance does, the videobridge must advertise the public address. On AWS it usually detects this through STUN. When it does not, set JVB_ADVERTISE_IPS to the public IP in the Docker .env file.
Domain and HTTPS
Browsers only give a web page access to the camera and microphone in a secure context, which means HTTPS with a certificate they trust. In practice you need:
- A domain or subdomain, for example
meet.example.com. - An
Arecord pointing it at the server’s public IP, created before the first start so Let’s Encrypt can validate it. - Port 80 open during issuance and renewal.
Operating system
Any modern 64-bit Linux that runs Docker Engine with the Compose plugin works for the Docker setup. For the Debian packages, use Debian 12 or Ubuntu 22.04 / 24.04 LTS. Plan for at least 20 GB of disk, more if recordings are kept on the server before upload.
Recording and transcription add-ons
| Add-on | What it needs |
|---|---|
| Jibri recording | 8 GB RAM on a shared server, the snd-aloop kernel module, and one Jibri per concurrent recording |
| Vosk transcription | 16 GB RAM, the Jigasi component in transcriber mode, and a Vosk server container |
| Both together | A t3.2xlarge (8 vCPU, 32 GB) or c5.2xlarge, or split recording onto its own server |
On AWS, Ubuntu’s default linux-aws kernel does not ship snd-aloop, so Jibri cannot capture audio until you install the generic kernel and reboot. Details are in Jitsi recording with Jibri.
Summary
Start with 2 vCPU and 4 GB, a domain, and ports 443/tcp and 10000/udp. Size up for recording and transcription, and watch bandwidth before CPU. If you would rather skip the sizing and setup, our platform deploys a correctly sized server into your own AWS account and shows the monthly estimate before you commit.