Host Jitsi on your own VPS

Consumer video conferencing services (Zoom, Google Meet, Teams) impose time limits on free plans, participant quotas, and keep your recordings on their servers. Self-hosted Jitsi Meet removes these constraints: rooms with no cap on participants, no meeting time limit, no account required to join a meeting, and video streams that stay on your infrastructure. This is particularly relevant for an organization concerned about the confidentiality of its meetings, a firm handling sensitive data, or anyone who wants to embed video calling in a third-party application (Jitsi provides a stable iframe API). Running costs come down to the VPS bill — no per-seat subscription, no software surcharge.

Jitsi is sized by bandwidth, not CPU. For meetings up to 10 participants: 2 vCPU, 4 GB RAM minimum, generous outbound traffic (100 Mbps recommended). Above 20 simultaneous participants, plan for 8 GB RAM and monitor JVB network load. Three ports must be reachable from the internet: TCP 443 (HTTPS and TURN/TLS), TCP 80 (Let's Encrypt renewal), UDP 10000 (JVB media). Add TCP 3478 if you expose coturn on its native port. You need Docker 24+ and Compose V2, a domain name meet.yourdomain.com with an A record pointing to the VPS public IP, and a dedicated, stable public IP — a shared IP makes coturn configuration significantly harder.

Meeting recording. Jitsi includes Jibri for local recording or RTMP streaming. Jibri requires a second VPS or at minimum 4 additional vCPU, as it captures the browser render in real time. Enable ENABLE_RECORDING=1 in .env and deploy a separate Jibri container pointing to your Jicofo. Organizer authentication. By default, anyone can create a room. Enable AUTH_TYPE=internal to require an account on the organizer's side while letting guests join freely. Create host accounts with docker exec <prosody-container> prosodyctl --config /config/prosody.cfg.lua register admin meet.yourdomain.com password. Limiting anonymous participants. Add ENABLE_LOBBY=1 so a moderator approves each entry before accessing the room. Combined with AUTH_TYPE=internal, this gives full control over who accesses what.

Missing audio or video stuck on 'connecting' — coturn + UDP 10000. This is the most frequent failure. Check in this order: (1) ufw status — are TCP 443 and UDP 10000 open? (2) docker compose logs coturn | grep -i error — does coturn start without certificate errors? (3) From an external machine: curl -v telnet://meet.yourdomain.com:3478 — does coturn respond? (4) In browser logs (F12 → Console): do you see ICE failed or failed to gather candidates? If so, coturn is not reachable from outside. Compare TURN_HOST in .env with the actual VPS IP. Connection refused on TCP 443. If Let's Encrypt could not issue a certificate (port 80 was closed on first start), the web container attempts to serve HTTPS with a self-signed certificate that the browser rejects. Fix: open port 80, delete the volume ~/.jitsi-meet-cfg/web and re-run docker compose up -d. Screen sharing refused by the browser. Screen sharing requires a secure context (valid HTTPS). If you see getUserMedia is not supported, the certificate is invalid or the domain is not on HTTPS. Check PUBLIC_URL — it must start with https:// with a domain whose certificate is valid, not a raw IP. Persistent 'ICE failed' error despite a working coturn. Check the DOCKER_HOST_ADDRESS variable: it must contain the VPS public IP, not the internal Docker container IP (172.17.x.x). If your VPS sits behind cloud NAT (rare but possible), you need the external NAT IP, not the network interface IP.

The JVB video bridge exposes a real-time statistics API at http://localhost:8080/colibri/stats. This JSON endpoint reports the number of active conferences, participants, inbound and outbound bandwidth in bits/s, and packet loss. For continuous monitoring, enable Prometheus support in .env (JVB_ENABLE_STATS=1, PROSODY_ENABLE_METRICS=1) and connect a Prometheus + Grafana stack: an official Jitsi dashboard is available on Grafana Labs (ID 11925) covering CPU, memory, bandwidth and video quality metrics.

Without Prometheus, minimal monitoring is achieved with a cron that queries /colibri/stats and alerts when throughput exceeds a threshold: docker exec jvb curl -s http://localhost:8080/colibri/stats | python3 -c "import json,sys; s=json.load(sys.stdin); print(s.get('bit_rate_download',0), s.get('bit_rate_upload',0))".

To estimate capacity before saturation: one JVB comfortably handles 200 to 250 interactive participants at moderate video quality on a well-connected VPS. Beyond that, the packet_loss_fraction and rtt_aggregate metrics climb and perceived quality drops before the CPU saturates — that is the signal to add another JVB instance.

Jitsi runs in SFU mode: the video bridge (JVB) relays each stream to each participant, so outbound bandwidth scales with the number of participants multiplied by the number of streams. For 10 participants at 720p, expect 20 to 40 Mbps outbound continuously. Enable lastN=5 (last N active videos) to cap client-side streams in large meetings, and watch docker stats jvb to anticipate saturation. Above about twenty regular simultaneous participants, deploy several JVB instances on separate VPSes behind a single Jicofo: that is Jitsi's native horizontal scaling architecture. For multi-organization or multi-domain deployments, Jitsi supports multiple PUBLIC_URL entries via the Prosody tenant mechanism: each organization gets its own isolated room namespace on the same installation, with no additional infrastructure.