// the find
jitsi/jitsi-meet
Jitsi Meet - Secure, Simple and Scalable Video Conferences that you use as a standalone app or embed in your web application.
Jitsi Meet is a production-grade, self-hostable video conferencing platform built on WebRTC with an SFU architecture via Jitsi Videobridge. It covers the full stack: web app, Android/iOS mobile apps, and embeddable SDKs. The target audience is teams or businesses that want a Zoom/Google Meet alternative they actually control.
- The SFU architecture (Jitsi Videobridge) scales to large calls without participant-count-squared bandwidth blowup — each client sends one stream up, the bridge fans it out selectively.
- E2EE support is real, not a checkbox: they published a whitepaper explaining the implementation, and insertable streams are used on the web to avoid the server seeing decrypted media.
- Deployment story is solid for a project this size — Debian packages, a Docker Compose setup, and a handbook that actually explains what each component does (Prosody, Jicofo, JVB, nginx) rather than just saying 'run this script'.
- The embedded SDK (web and mobile) is genuinely useful for adding video calls to an existing app without building WebRTC signaling yourself — the ExternalAPI surface is wide enough to control most meeting state from the host page.
- Self-hosting is deceptively complex: you need Prosody (XMPP), Jicofo (focus component), at least one JVB, nginx, and optionally coturn — getting all four talking correctly, especially behind NAT or in a cloud VPC, is where most people get stuck and the docs don't fully save you.
- The codebase is React/Redux with years of accumulated state management baggage; the Redux store is enormous and deeply nested, which makes meaningful contributions or customizations harder than the 'just fork it' pitch implies.
- Mobile SDK is React Native, which means you're shipping the full RN runtime and a bundled JS engine — binary size and startup latency are real costs compared to a native WebRTC integration.
- No built-in persistent recording to cloud storage without a separate Jibri instance, which requires a dedicated machine (or VM) running a headless Chrome session — operationally expensive for a feature users expect to just work.