Jitsi Meet

Last reviewed Aug 26, 2026 · 823 words

A two-person Jitsi call costs your server almost nothing because it goes peer-to-peer. The moment a third person joins, every video stream routes through your videobridge, and that is the call that exposes an under-provisioned box and a home upload link. Plan for the 3-to-10-person case, not the demo, and most Jitsi disappointments never happen.

Four containers, and the one UDP port that breaks most installs

Jitsi Meet is a set of cooperating services: the web front end, Prosody (an XMPP server that handles signalling and rooms), Jicofo (the conference focus that allocates bridges), and the Jitsi Videobridge, which is the media router. The official docker-jitsi-meet release bundles them:

# from the release archive of docker-jitsi-meet
cp env.example .env
./gen-passwords.sh
mkdir -p ~/.jitsi-meet-cfg/{web,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
docker compose up -d

In the Docker defaults the web container listens on 8000 for HTTP and 8443 for HTTPS, and the bridge uses 10000/udp. That UDP port must be open on the host firewall, forwarded from the router if you are behind NAT, and the bridge must be told the public address it should advertise in .env (JVB_ADVERTISE_IPS in current releases). Miss any of those and two people can talk while a third sees frozen video, because the bridge is unreachable and the call cannot fall back. Put the web tier behind Caddy or Traefik for TLS like anything else; leave the UDP path direct.

Anyone can create a room until you say otherwise

Out of the box, any visitor to your instance can type a room name and start a meeting on your bandwidth. Set ENABLE_AUTH=1 and AUTH_TYPE=internal in .env, then register hosts inside the Prosody container:

docker compose exec prosody prosodyctl --config /config/prosody.cfg.lua \
  register alice meet.jitsi a-strong-password

With ENABLE_GUESTS=1, unauthenticated people can still join a room once a registered host has opened it, which is the behaviour you want for calls with family. LDAP and JWT auth exist for teams that already have Authentik or a similar identity provider.

Bandwidth, not CPU, sets the ceiling

The videobridge is a selective forwarding unit: it does not mix video, it forwards each participant's stream to every other participant. Rough arithmetic for a call of N people is N×(N−1) forwarded streams. Ten people each sending about 1 Mbps means the server pushes out something like 90 Mbps, less with simulcast layers and tiled layouts, more with screen sharing. A typical residential 20 to 40 Mbps upload is spent by the fifth or sixth participant. The 4 GB RAM and multi-core CPU the project recommends are for Prosody and the JVM-based bridge; the number that decides whether your calls work is the upload figure on your ISP plan. For anything beyond a household, this is the service to run on a VPS with symmetric gigabit and bring your other services to it over a VPN, not the other way round.

Recording needs Jibri, and Jibri needs its own machine

Jitsi records a meeting by having a headless Chrome instance join it and capture the screen with ffmpeg. That component, Jibri, wants a dedicated VM with 4 or more cores, an ALSA loopback kernel module, and can handle exactly one recording at a time per instance. It is the "many moving components" con in one package. Unless recording is a requirement, skip it and let participants record locally.

When something smaller is the right answer

Jitsi is the full-featured choice: lobby, breakout rooms, live streaming, end-to-end encryption on supported browsers, phone dial-in through Jigasi. If you want "a video call link for six people that just works", Galene is a single Go binary using a fraction of the resources. If you already run Nextcloud, Nextcloud Talk is fine for 2 to 4 people and needs its High Performance Backend beyond that. For teaching, BigBlueButton has the whiteboard and polls Jitsi lacks. The Zoom alternatives page lays out that spread.

What I'd do

Jitsi on a VPS with real upload bandwidth, the Docker distribution behind Caddy, 10000/udp open, internal auth turned on before the first invite goes out, and no Jibri. Test with three devices, not two, because two will always work and tell you nothing. Watch the bridge container's logs during that first three-way call; a working setup logs the third participant's ICE candidates connecting within a couple of seconds, and a broken one shows them cycling. Run like that it is the closest open-source thing to Zoom that you can hand a URL to someone's grandmother, and among the self-hosted video conferencing options it is the one whose limits are yours rather than a vendor's.