Jitsi Meet: self-hosted WebRTC conferencing and what the repository actually commits you to
Jitsi Meet - Secure, Simple and Scalable Video Conferences that you use as a standalone app or embed in your web application.
At a glance
- What is it?
- Jitsi Meet is an Apache-2.0 video conferencing stack that you can use at meet.jit.si or deploy yourself from Debian packages, a Docker setup, or source. The judgement: the client is the easy part, the deployment and the SFU behind it are the real commitment.
- Who is it for?
- Adopt Jitsi Meet if you need a browser-based conference client you can host yourself and embed through the web or native SDKs, and if you are prepared to own the server side rather than just the front end. Do not adopt it if you want a product where scaling, monitoring and updates are somebody else's problem, or if you need a licensing posture other than Apache-2.0 for the code and whatever terms the mobile store builds carry.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Jitsi Meet is aimed at, and who ends up using it
Most video calling products give you a room and a bill. Jitsi Meet gives you a codebase. The README frames the project as a set of open source projects that let users use and deploy video conferencing platforms, which is a deliberately two-sided statement: you can consume the hosted instance at meet.jit.si, or you can stand up your own. The repository is the client and integration layer of that set, written primarily in TypeScript, licensed Apache-2.0.
The audience splits cleanly. On one side are people who want a meeting link and nothing else, and the README addresses them directly: go to meet.jit.si, sign in with a Google, Facebook or GitHub account, and start. On the other side are engineers who need conferencing inside their own product or under their own domain. For them the README lists web and native SDKs for integration, plus mobile applications for Android, iOS and F-Droid. That second group is the one the repository is really built for. If you are in the first group, the source code is irrelevant to you; if you are in the second, the source code is the product.
What the project does not claim to be is a turnkey SaaS. The README's own framing of Jitsi as a Service, offered by 8x8, is explicit that the reason to consider it is avoiding the complexity of monitoring, scaling and updates. That sentence is the honest description of what self-hosting costs you.
How the pieces fit: client, SDKs, and the server you have to supply
The repository you are reading is the browser client. It is TypeScript, it runs in the browser, and the README states support for all current browsers. The feature list is client-visible surface: HD audio and video, content sharing, raise hand and reactions, chat with private conversations, polls, virtual backgrounds. Those are the things the web app implements.
What the README does not do is describe the media path. It names a topic, sfu, and it points at the handbook for deployment, but the repository itself is not the selective forwarding unit. That distinction matters more than any feature bullet. A Jitsi deployment is not one process. The client you build here has to talk to a signalling and media backend that you install separately, which is why the README's answer to running your own instance is a link to the handbook's DevOps guide rather than a build command.
Integration happens through the web and native SDKs the README lists. That is the intended embedding route: you keep the client, wrap it in your application, and point it at your own infrastructure. The README also mentions an end-to-end encryption implementation with its own whitepaper, and a separate security page. Both are pointers, not specifications, and anyone evaluating E2EE for a compliance requirement should read the whitepaper rather than infer behaviour from the README's one-line mention.
Getting an instance running: the three routes the README names
The README gives three deployment options and no commands. Debian packages, a Docker setup, and building all components from source for advanced users. The handbook at jitsi.github.io/handbook/docs/devops-guide is where the actual instructions live. Any article that hands you a copy-pasteable install line for this project is either reproducing the handbook or inventing it; the repository's own documentation does not put one in front of you.
What you can confirm from the repository metadata is the release cadence and naming. Recent tags follow the pattern stable/jitsi-meet_11146 (2.0.11146), stable/jitsi-meet_11031 (2.0.11031), and stable/jitsi-meet_10978 (2.0.10978), dated August, June and May of 2026. The README points at a releases page in the handbook for the latest. If you are pinning a version for production, that tag format is what you pin, and the gap between consecutive stable tags is roughly one to two months.
There is also a hosted path with no installation at all. meet.jit.si is the README's suggested first step, and it is the fastest way to see whether the client behaves the way your users need before you spend any time on servers. Treat it as a smoke test, not as a deployment target, because the branding and control it gives you are exactly what it does not give you.
Where self-hosting becomes the actual work
The README's own description of JaaS is the clearest statement of this project's limitation, and it comes from the project itself: running your own instance means dealing with monitoring, scaling and updates. Nothing in the repository removes that. The Debian packages and the Docker setup make installation simpler, in the README's phrasing, not operation simpler. Those are different problems.
A second limitation is structural. Because the repository is the client, evaluating it tells you very little about whether the whole system will hold up under your load. The media server is elsewhere, the configuration surface is elsewhere, and the failure modes you will actually hit (a conference that degrades under packet loss, a deployment that will not scale past a certain number of concurrent rooms) are not visible in this codebase at all.
A third is the mobile story. The README links Google Play, F-Droid and the App Store, and separately links open beta channels on both platforms. Shipping a branded mobile client means going through those stores with your own listing, which is a distribution constraint the Apache-2.0 licence on the source does not remove. The README does not discuss this, and anyone planning a white-labelled mobile app should treat it as an open question to resolve before committing.
What you are choosing instead: a hosted meeting API
The realistic alternative for most teams is not another self-hosted stack. It is a hosted conferencing API where the vendor runs the media infrastructure and you call an endpoint. The difference is not feature parity, it is where the operational boundary sits. With a hosted API you get a room identifier and a token, and you never see a media server. With Jitsi Meet you get a client, an SDK, and a handbook chapter on DevOps that you are expected to work through.
That trade cuts both ways. The hosted route removes the monitoring, scaling and updates burden that the README itself flags. It also removes your control over where media terminates, what the branding looks like, and what happens to the product when the vendor changes direction or pricing. Jitsi Meet's answer to that is that the code is Apache-2.0 and the deployment is yours, so the ceiling on what you can do with it is set by your own engineering capacity rather than by a plan tier.
There is a middle option the README names directly: 8x8 Jitsi as a Service, which is the same project run on 8x8's platform with branding controls. If your reason for wanting self-hosting is branding rather than data residency or infrastructure control, that is the option the README is pointing you toward, and it is worth reading that paragraph before you start installing packages.
Maintenance cost, release cadence and what the licence does and does not cover
The repository is actively maintained: the last push recorded is 2026-09-10, and stable releases land on a roughly one-to-two-month cadence based on the three most recent tags. That cadence is a maintenance obligation, not just a sign of health. If you self-host, you are the one who decides when to move from 2.0.10978 to 2.0.11031 to 2.0.11146, and you are the one who tests the upgrade against your own configuration and any SDK integration you have written.
The licence is Apache-2.0, which is a permissive licence with an explicit patent grant and a requirement to preserve notices. That covers the code in this repository. It does not, by itself, tell you anything about the terms attached to the mobile store listings, the hosted meet.jit.si service, or the JaaS offering, all of which are separate things the README links to. If your organisation has a policy about which licences are acceptable, Apache-2.0 is generally on the approved list, but the surrounding services are a separate question and this is not legal advice.
The practical maintenance cost is the deployment itself. Debian packages and a Docker setup both exist, and the README presents them as the simple path, but the project's own comparison with JaaS concedes that monitoring, scaling and updates remain yours. Budget for that before you budget for anything else.
A specific judgement on when to take this on
Jitsi Meet is the right choice when the requirement is a browser-based conference client you control, embedded through the web or native SDKs, under a permissive licence, with the server side treated as a separate engineering project you are willing to own. The feature list in the README (content sharing, chat with private conversations, polls, raise hand and reactions, virtual backgrounds) is the surface your users will see, and the SDKs are how you get it into your own product.
It is the wrong choice when the requirement is a meeting link by Friday with no infrastructure work behind it. The README's own framing of JaaS exists precisely because that is a common case, and the honest reading is that self-hosting is a commitment to running servers, not a configuration toggle.
The first thing to verify is which deployment route you are taking, because the README offers Debian packages, a Docker setup and a source build, and the handbook is the only place that distinguishes them. The second is which stable tag you will pin, given the 2.0.x cadence. The third, if you need end-to-end encryption for a compliance reason, is the E2EE whitepaper rather than the README's mention of it. Those three answers determine whether this project fits, and none of them are in the repository's front page.
Editorial conclusion
Adopt Jitsi Meet if you need a browser-based conference client you can host yourself and embed through the web or native SDKs, and if you are prepared to own the server side rather than just the front end. Do not adopt it if you want a product where scaling, monitoring and updates are somebody else's problem, or if you need a licensing posture other than Apache-2.0 for the code and whatever terms the mobile store builds carry. Before committing, read the handbook's DevOps guide end to end, confirm which release tag you will pin, and decide whether you are running the Debian packages or the Docker setup, because those are different operational paths and the README points at both.
Community notes