Higher resolutions and more participants multiply videobridge traffic. Once the Internet link saturates, adding CPU or RAM will not fix frozen video, packet loss or poor call quality.
Public meetings, classrooms and teams with many simultaneous HD participants.Configuration matérielle requise pour Jitsi Meet : RAM, processeur, réseau et enregistrement
Dimensionnez Jitsi Meet en fonction de la RAM, des cœurs CPU dédiés, de la bande passante, du disque et de l’enregistrement Jibri, avec des conseils pratiques d’installation personnalisée de ZimaOS pour les petites réunions.
Jitsi Meet requirements at a glance
Jitsi's current self-hosting guide emphasizes that real-time conferencing behaves differently from a normal web app. For a basic server it suggests 8 GB RAM, 4 dedicated CPU cores and about 20 GB disk. Small meetings can get away with 4 GB RAM, test or very small setups may try 2 GB, and network uplink/reliability is the first-order constraint.
- RAM
- 8 GB usually suggested. Small meetings can use 4 GB; test or very small meetings may try 2 GB.
- CPU
- For a basic server, 4 dedicated cores can be enough. Real-time performance suffers when CPU time is heavily shared or stolen.
- Network
- Jitsi says 1 Gbit/s is often enough for friends/small organizations and 10 Gbit/s is advisable for serious servers; actual Internet uplink and latency matter more than the LAN-port label alone.
- Storage
- About 20 GB can be enough unless logging or special needs are heavy. SSD is described as nice to have rather than mandatory for the core meeting server.
- Recording
- Jibri needs one system/instance per simultaneous recording. One 720p-class recording needs at least 8 GB RAM; 1280x1024 needs 12 GB, and SSD is needed for cloud recording storage.
- Best Zima starting point
- ZimaBoard 2 832 fits the official 8 GB/4-core basic-server class for small meetings; ZimaCube 2 Pro adds CPU and 10GbE-class LAN headroom, but Internet bandwidth and dedicated Jibri systems remain separate constraints.
From official requirements to the right setup
For Jitsi Meet, start with network and concurrency before CPU or storage. A server that looks powerful on paper can still fail real-time meetings if upstream bandwidth, latency or competing workloads are poor.
-
Official requirements
Estimate active participants, video resolution and simultaneous meetings. Jitsi's guide gives rough per-stream reference rates of about 200 kbit/s at 180p, 500 kbit/s at 360p, 2.5 Mbit/s at 720p and 10 Mbit/s at 4K, but real bandwidth math depends on videobridge behavior and optimizations.
-
Confirm your needs
Use the upstream basic-server hardware class as the starting point: 8 GB RAM and 4 dedicated CPU cores. Drop to 4 GB only for small meetings and 2 GB only for test/very small use.
-
Leave room to grow
Separate recording from the core meeting server. Each simultaneous Jibri recording needs its own instance/system and significantly more RAM, CPU and disk bandwidth than Jitsi Meet itself.
-
Run it on ZimaOS
On ZimaOS, use Install Custom App with the official docker-jitsi-meet stack. Configure PUBLIC_URL, persistent config directories, HTTPS, UDP/TCP port forwarding and firewall/NAT correctly, then test real external calls before sizing up hardware.
Check every playback client
- Maximum simultaneous participants
- Expected video resolution
- Number of simultaneous meetings
- Measured Internet upload/download and latency
- Public IP, NAT and firewall rules
- HTTPS domain and PUBLIC_URL
- Recording/streaming with Jibri
- Other services competing for CPU or network
Official minimum requirements
Jitsi publishes practical sizing guidance rather than a single hard minimum because videoconferencing depends heavily on network quality, meeting size and enabled services.
For a basic real server, the most useful upstream target is 8 GB RAM, 4 dedicated cores and roughly 20 GB disk. The 2–4 GB figures are explicitly for test, very small or small meetings. Network design can invalidate any CPU/RAM recommendation if bandwidth or latency is poor.
| Requirement | Official minimum | What this supports |
|---|---|---|
| RAM | 8 GB usually suggested | Jitsi says 4 GB can work for small meetings and 2 GB may be tried for test servers or very small meetings. |
| CPU | 4 dedicated cores can be enough for a basic server | Very low or heavily shared CPU performance can seriously harm real-time operation. |
| Disk | About 20 GB | Applies when heavy logging or special disk needs are absent; SSD is nice to have rather than required for the core server. |
| Small-org network | 1 Gbit/s often enough | This is a server-link guideline; real Internet uplink, latency and participant bitrate determine actual capacity. |
| Serious-server network | 10 Gbit/s advisable | Large deployments scale by adding videobridges rather than only building one huge server. |
| Jibri 720p-class recording | At least 8 GB RAM per recording instance | Jitsi states one Jibri instance equals one simultaneous recorded meeting. |
| Jibri 1280x1024 recording | 12 GB RAM per recording instance | Recording is much more resource intensive and should not normally share the same server as Jitsi Meet. |
When to upgrade your hardware
For Jitsi, upgrade or scale out when real-time quality shows pressure: packet loss, network saturation, CPU contention or the need for simultaneous recordings are stronger signals than disk usage alone.
Network utilization approaches the uplink limit
CPU contention affects real-time media
You add recording or live streaming
Jitsi warns that low or shared CPU performance can seriously harm a real-time system. Sustained load, jitter or competing ZimaOS apps are reasons to dedicate more compute or a separate host.
Multi-room deployments and servers also running storage, media or AI workloads.Jibri performs video encoding and requires a separate instance per simultaneous recording, with at least 8–12 GB RAM in Jitsi's documented examples.
Schools, webinars, teams and organizations that need recordings or streaming.Plan hardware growth with confidence
Jitsi usually scales by improving the network and adding dedicated videobridges or recording systems rather than by turning one home server into an oversized all-in-one machine.
Protect Internet bandwidth before buying more CPU
Measure real upload/download capacity and latency. LAN 2.5GbE or 10GbE does not help if the WAN connection is the limiting link.
ZimaBoard 2's dual 2.5GbE is enough for many small-LAN scenarios; ZimaCube 2 Pro adds 10GbE-class LAN but still depends on the Internet uplink.Keep Jitsi away from noisy co-hosted workloads
Jitsi's own guide advises against adding unrelated functions because real-time performance is sensitive to CPU and network contention.
Dedicate a ZimaBoard 2 or ZimaCube to Jitsi when call quality matters rather than packing it with heavy media/AI jobs.Scale videobridges horizontally
For larger deployments, Jitsi recommends adding videobridges and using OCTO/federation instead of only adding huge amounts of RAM or cores to one server.
Use additional x86 Zima nodes only after validating routing, bandwidth and multi-bridge Jitsi architecture.Run Jibri separately
Each simultaneous recording needs its own Jibri instance and substantial RAM, CPU and storage throughput. Separating it protects the live conference server.
Use a separate 16 GB+ system for a recording instance; do not count Jibri capacity as free headroom on the meeting host.Can it run on ZimaOS?
Jitsi Meet is not currently presented in the public ZimaOS hardware catalog as a one-click ZimaOS App Store app. It can be deployed through Install Custom App using the official docker-jitsi-meet project, but public networking, UDP ports and HTTPS must be configured correctly for WebRTC.
Custom install Jitsi Meet in ZimaOS
Use Install Custom App with an adapted Compose configuration from the official docker-jitsi-meet release. Persist the required config directories, generate strong passwords, set PUBLIC_URL to the real domain and expose the required web and media ports.
Custom install Jitsi Meet in the ZimaOS app ↗Use the official Jitsi Docker stack
The official Docker deployment separates web, Prosody, Jicofo and JVB services. Current releases also expect explicitly created writable config/storage directories for rootless containers.
Review Jitsi Docker self-hosting ↗Treat HTTPS and public networking as mandatory design work
Jitsi is WebRTC-based and the handbook warns that direct HTTP access causes browser media-device failures. Correct DNS, TLS, NAT, firewall and videobridge port forwarding are part of a working deployment.
Review Jitsi self-hosting networking ↗Choose Zima hardware for Jitsi Meet
Jitsi's basic hardware target maps neatly to an 8 GB, 4-core ZimaBoard 2, but meeting quality depends first on dedicated CPU time and real Internet bandwidth. Larger Zima systems add headroom; they do not replace network engineering.
Are you hosting small meetings only, or do you need more concurrency, stronger networking or broader conferencing infrastructure?
Small meetings on a dedicated host
ZimaBoard 2 832 matches Jitsi's usually suggested 8 GB RAM and basic 4-core class, with 2.5GbE LAN that is above many home WAN links.
- Best small-server starting pointZimaBoard 2 832
- More memory headroomZimaBoard 2 1664
More concurrency, multiple services or faster LAN
Use the stronger Core i5 platform and 10GbE-class connectivity, but scale videobridges horizontally and keep Jibri separate when the deployment grows.
- Higher-headroom meeting hostZimaCube 2 Pro
These recommendations are not participant-count or call-quality guarantees. Video resolution, simultaneous meetings, WAN bandwidth, latency, NAT/firewall behavior, CPU contention, recording and Jitsi tuning all change capacity.
| Zima hardware | Best for | Example workload | Core configuration | Recommended boundary | Next step |
|---|---|---|---|---|---|
| ZimaBoard 2 832 | Small Jitsi Meet servers with a dedicated host and adequate Internet uplink. | Basic meetings without co-hosted Jibri recording or other heavy CPU/network workloads. |
|
The CPU/RAM class aligns with Jitsi's basic guidance, but real capacity is bounded by dedicated CPU availability and Internet bandwidth. Do not infer participant counts from the 2.5GbE LAN ports. | Get Now |
| ZimaBoard 2 1664 | Small to moderate meetings that need extra memory for the core stack or limited companion services. | Jitsi Meet with more operating headroom, monitoring and persistent configuration, but without heavy local recording. |
|
Extra RAM does not create more WAN bandwidth or solve CPU contention. Jitsi recommends scaling bridges rather than simply building one oversized node. | Get Now |
| ZimaCube 2 Pro | A higher-headroom Jitsi host with stronger CPU and 10GbE-class local networking. | More simultaneous meeting activity, monitoring and broader conferencing infrastructure with recording kept on separate Jibri systems. |
|
LAN speed is not the same as Internet capacity. For serious deployments Jitsi recommends multiple videobridges, and Jibri recording remains a separate high-resource workload. | Get Now |
What the Press Says
Highlights from trusted reviewers worldwide.
“ZimaCube 2: Not just another NAS, tested with 25TB storage, local AI agents, 4K transcoding, and real homelab workflows.”Read full review
“The ZimaBoard 2 is a compact x86 server board that can be turned into a mini NAS, home server, media box, or self-hosting hub.”Read full review
“ZimaCube 2: A modern, high-performance NAS with plenty of room to grow—built for users who want more than basic storage.”Read full review
“Coverage focused on ZimaCube 2's open hardware foundation, no monthly fee, and self-hosting flexibility.”Read full review
Loved by the Community
Stories and reviews from people who build with Zima every day.
★★★★★
Zima Blade Little yet Powerful
Maybe I am not digital natives but I live with PCs since 12 years old in 1984 when IBM PC clone come to my home. Many years have passed and many operating system I've tried. For me Zima blade and CasaOS was a quantum leap for home PC enthusiast and server lab machine to make me stay curious and relevant for this era.
★★★★★
Very good!!
I use ZimaCube Pro as 5th Proxmox cluster node. It runs several VMs and containers, including a VM with GPU passthrough to run a self-hosted LLM. A specific LXC container runs a Samba server for NAS capabilities using four of six RAID 6 SATA HDDs with ZFS.
★★★★★
Great innovation for mini server!
It is very useful and makes a powerful mini server for many purposes, including university and college students in engineering and electronics. Thank you so much for making this server.
★★★★★
Avaliação ZimaBoard 2
Construí um servidor de uso pessoal. O desempenho está muito bom e funciona perfeitamente onde quer que eu esteja. A surpresa é não dependermos de grandes estruturas para termos nosso próprio servidor de dados. Como iniciante, estou gostando bastante do ZimaOS, pois ele é simples e eficiente.
Frequently asked questions
These answers cover Jitsi Meet RAM, CPU, bandwidth, storage, recording, GPU and Zima hardware while preserving the upstream distinction between small/test servers and basic real deployments.
How much RAM does Jitsi Meet need?
Jitsi's current requirements guide usually suggests 8 GB RAM. It says 4 GB can work for small meetings and 2 GB may be tried for test servers or very small meetings. Recording with Jibri has separate and much higher memory requirements.
How many CPU cores does Jitsi Meet need?
For a basic server, Jitsi says 4 dedicated cores can be enough. Real-time media is sensitive to CPU contention, so four cores that are consistently available are more useful than a nominally larger but heavily shared CPU allocation.
How much bandwidth does Jitsi Meet need?
Jitsi says 1 Gbit/s often works for friends or small organizations and 10 Gbit/s is advisable for serious servers. It also gives rough per-resolution reference rates from about 200 kbit/s at 180p to 2.5 Mbit/s at 720p and 10 Mbit/s at 4K. Actual conference bandwidth is more complex.
How much storage does Jitsi Meet need?
The core Jitsi guide says about 20 GB can be enough unless logging or special needs are heavy. Recording changes the picture: Jibri creates large media files and needs faster storage, with SSD required in Jitsi's cloud-recording guidance.
Does Jitsi Meet need an SSD?
For the core meeting server, Jitsi describes SSD as nice to have rather than necessary. For recording workflows, storage performance matters much more and the documentation calls for SSD in cloud-storage recording scenarios.
Does Jitsi Meet need a GPU?
The core Jitsi Meet requirements do not call for a GPU. The main server constraints are network, CPU and RAM. Jibri recording performs video encoding and needs substantially more CPU, RAM and storage, but Jitsi's requirement page does not define a GPU minimum for it.
Can ZimaBoard 2 run Jitsi Meet?
Yes for small/basic deployments when the host is dedicated and the Internet connection is adequate. ZimaBoard 2 832 has 8 GB RAM and a 4-core Intel N150, matching Jitsi's usual basic-server RAM/core guidance. WAN bandwidth and port/NAT setup remain critical.
Can I run Jitsi Meet and Jibri on the same ZimaOS server?
Jitsi says it is technically possible but not recommended. Jibri is a resource drain, one recording instance is required per simultaneous recorded meeting, and the recording workload can harm Jitsi Meet performance or exhaust storage.
What sources informed this Jitsi Meet hardware guide?
The guide uses the current Jitsi self-hosting requirements and official Docker deployment guide for server, bandwidth and recording claims. Current Zima product pages are used only for hardware specifications and workload matching.
