Jitsi Meet: The Self-Hosted Video Conferencing Stack — Plus the TURN Server Nobody Tells You That You Need
Zoom's business model is a per-seat fee on a thing that is, underneath, a WebRTC packet router. Jitsi is that router, Apache-2.0 licensed, running on a server you control.
Video conferencing is the worst-behaved category in enterprise software from a data-sovereignty perspective, and it is worth articulating why.
A note-taking app holds text you typed. A video call carries your face, your voice, your home office, the bookshelf behind you, the medication bottle on the desk, your children walking through the frame. It carries a real-time recording of everyone in the meeting — and for therapy sessions, medical consultations, legal counsel, and board discussions, it carries content that is legally protected.
And the incumbent model is: all of that flows through a vendor's servers, in a jurisdiction you did not choose, under a retention policy you did not set, for a per-seat monthly fee.
Jitsi Meet is the most mature open-source answer. Roughly
30,000 GitHub stars,
Apache-2.0, maintained by 8x8 with around 360 contributors and steady release cadence —
stable/jitsi-meet_11146 landed in August 2026. It runs in a browser with no client install, supports end-to-end encryption, and can be deployed entirely on infrastructure you own, with no media or signalling ever touching a third party.
It is also not a meeting link with a self-hosting option. It is a
six-component real-time system — and most of the difficulty people have with self-hosted Jitsi comes from not knowing that. This is a deep-dive on the architecture, the deployment, the TURN server that is mandatory in practice if not in theory, what the encryption does and what it disables, the compliance story that surprises people, and the bandwidth bill that is the real cost.
1. What Jitsi Meet Is
Jitsi Meet is an
open-source video conferencing platform built on WebRTC. You get a room URL, participants join from a browser or mobile app, and the media flows either peer-to-peer (two people) or through a Selective Forwarding Unit (three or more).
Concretely you get: HD audio and video, screen and content sharing, chat with private conversations, raise hand and reactions, polls, virtual backgrounds, recording and live streaming (via an optional component), phone dial-in (via another optional component), moderation controls, and extensive embedding and API options.
The licence is
Apache-2.0, which is the most permissive thing in this category. No SSPL, no BUSL, no copyleft. You can fork it, modify it, deploy it commercially, and sell it, with no obligation to release anything. For an organisation that has been burned by a project relicense mid-adoption, that matters.
The corporate context:
Jitsi is maintained by 8x8, Inc., a publicly traded US company that also sells JaaS (Jitsi as a Service). That relationship is mostly healthy — the open-source project gets real engineering — but it does mean the commercial product is where the company's revenue is, and some choices reflect that. We will come back to it.
2. Why Video Is Different
It is worth being concrete about what is at stake, because "data sovereignty" can sound abstract until you apply it to a video call.
Content sensitivity. A therapy session, a medical consultation, a legal deposition, a whistleblower conversation, a board discussion about an acquisition. These are not spreadsheets. They are real-time audio and video of identifiable people saying things that are legally privileged.
Metadata sensitivity. Even without content, the record of
who met with whom, when, and for how long is valuable intelligence. A vendor holding that for every meeting in your organisation holds an org chart of your actual working relationships.
Jurisdiction. A US-hosted video provider is subject to US legal process. Self-hosting on infrastructure in your own jurisdiction removes that vector entirely — not by policy, but architecturally, because there is no third party in the path to compel.
Retention. If recordings exist, who holds them, encrypted with what, deleted when? With a self-hosted stack the answer is "you decide," which is more work and also the only acceptable answer in a lot of regulated contexts.
The counter-argument, stated fairly: commercial video vendors are very good at this. They handle NAT traversal, adaptive bitrate, global media placement, and device compatibility at a scale you will not match. Zoom calls just work. That is worth real money, and for many organisations it is the right trade. Self-hosted Jitsi is for the cases where "just works" is not sufficient.
3. The Architecture: Six Components
This is the section that makes everything else make sense.
Jitsi Meet — the web client. TypeScript. This is the interface: join flow, device selection, chat, layout, moderation. It is a
participant endpoint, not the system.
Prosody — an XMPP server carrying
signalling. Room membership, permissions, presence, and the control-plane state.
Jicofo (JItsi COnference FOcus) — the conference orchestrator. It decides which videobridge serves a conference, manages participants joining and leaving, and coordinates media-bridge selection.
Jitsi Videobridge (JVB) — the
SFU. This is the centre of gravity. Clients send their media to the bridge; the bridge forwards selected streams to other participants.
Jigasi — optional. A SIP gateway for phone dial-in and dial-out.
Jibri — optional. A recording and streaming component that joins a conference as a hidden participant with a browser and captures it.
Why this separation is good: it gives you a
vocabulary for failure. When a meeting works for two people but degrades for twenty, is it an auth and room-state issue (Prosody), a bridge selection issue (Jicofo), or a media transport issue (JVB)? Teams that can answer that question fix problems in minutes. Teams that think Jitsi is one thing flail.
Why it is hard: you now operate six things with independent failure modes, and the documentation for advanced configuration assumes you know which one you are configuring.
4. P2P vs SFU
Two participants: peer-to-peer. Media flows directly between the two browsers, encrypted end-to-end by DTLS-SRTP as a property of WebRTC. The server only handled signalling. This mode is cheap, private, and it is why a two-person Jitsi call on a modest VPS feels effortless.
Three or more: SFU. Everyone sends one stream up to the bridge, and the bridge forwards selected streams down to each participant. JVB does
not decode, composite, and re-encode a single mixed video — that is what an MCU does, and it is dramatically more expensive. Forwarding selected streams means each participant can receive a different quality, and the bridge's job stays routing rather than transcoding.
The term "selective" is doing real work. The bridge chooses which streams to forward based on who is speaking, who is pinned, and what bandwidth each participant has. This is why JVB scales to far more participants per unit of CPU than a mixing architecture would.
The trade-off:
an SFU sees the media. Media is encrypted in transit to the bridge, but the bridge must decrypt to forward, so the bridge's memory holds cleartext frames. This is why the "no media leaves your infrastructure" claim is about
your infrastructure, not about the JVB operator being unable to read it. Real E2EE (section 5) changes that, at a cost.
5. End-to-End Encryption, and What It Disables
Jitsi supports E2EE for conferences. When enabled, media is encrypted such that the bridge forwards ciphertext it cannot decrypt.
This is a genuine capability and it comes with real constraints that people discover the hard way:
- Recording and streaming stop working. Jibri joins as a participant and captures media. If the bridge cannot decrypt, neither can Jibri. You cannot have E2EE and server-side recording simultaneously — it is a hard either/or.
- SIP dial-in does not work. Same reason: Jigasi needs to bridge audio.
- It is a per-conference choice in most deployments, not a global switch, which means it depends on someone remembering to enable it.
- Server-side features that need media — transcription, some moderation tooling, noise suppression on the bridge — are unavailable.
The honest framing: E2EE is the right setting for a sensitive one-to-one or small-group conversation where no recording is needed, and it is unavailable for the "record this training session" use case. Decide per use case rather than looking for a global answer.
For everything else,
DTLS-SRTP protects media in transit between client and bridge by default. That is real transport encryption, and it means the network cannot read your call. It does not mean your server operator cannot.
6. Deployment
The standard path is Docker Compose, which the project maintains:
``
bash
git clone https://github.com/jitsi/docker-jitsi-meet
cd docker-jitsi-meet
cp env.example .env
./gen-passwords.sh
mkdir -p ~/.jitsi-meet-cfg/{web/letsencrypt,transcripts,prosody/config,prosody/prosody-plugins-custom,jicofo,jvb,jigasi,jibri}
docker compose up -d
`
That brings up Meet, Prosody, Jicofo, and JVB, with Let's Encrypt certificates if you have a public hostname and open ports 80/443. The gen-passwords.sh
step matters — the default .env
has placeholder secrets and people do skip it.
Initial sizing: a 2 vCPU / 4 GB VPS handles a handful of small conferences comfortably. Video is CPU-cheap on an SFU but bandwidth-hungry, which inverts the usual intuition about what to buy.
Native Debian packages are also available and are the better-supported route for larger or long-lived deployments.
7. You Need a TURN Server
This is the failure that produces the most forum posts, and it is worth understanding properly.
WebRTC tries to connect directly. It uses ICE to discover candidate network paths, with STUN helping a client learn its own public address. For most home and office networks this works, and media flows peer-to-peer or client-to-bridge with no relay.
It fails when a participant is behind symmetric NAT or a restrictive corporate firewall that will not allow the negotiated direct path. The symptom is distinctive and maddening: audio works but video does not, or the call works for everyone except one person, or a participant connects and then drops after thirty seconds.
The fix is a TURN server, which relays media when direct connection fails. The usual choice is coturn, which is open source, small, and not especially hard to run:
`
bash
apt install coturn
configure a listening port, a shared secret, a realm, and a TLS cert
`
Then point Jitsi at it in the configuration, with the shared secret so Jitsi can mint short-lived TURN credentials.
Two things people get wrong. First, they assume TURN is optional because it is not in the quick-start. It is optional right up until the day a client's network makes it mandatory. Second, they run TURN without authentication, at which point they have deployed an open relay that anyone on the internet can use to move traffic, and they will discover this via a bandwidth bill or an abuse complaint.
Run TURN. Authenticate it. Budget bandwidth for it. If you self-host Jitsi for an organisation, this is not an advanced topic — it is part of the baseline install.
8. Ports and Firewall
| Port | Protocol | Purpose |
|---|---|---|
| 80 / 443 | TCP | Web client, and Let's Encrypt validation |
| 4443 | TCP | WebRTC media fallback (TCP/TLS) |
| 10000 | UDP | JVB media — the main media path |
| 3478 | UDP/TCP | STUN |
| 5349 | TCP | TURN over TLS |
| 5222 | TCP | XMPP client-to-server (usually internal) |
| 5280 | TCP | Prosody HTTP (usually internal) |
Port 10000 UDP is the one that matters. If it is blocked, media cannot flow and you get a call that connects and then sits there in silence. Jitsi's TCP fallback on 4443 exists for exactly this, but it is a fallback — it is slower and it concentrates load on the bridge.
Only the web ports need to be public. Everything else can be internal once TURN and the bridges are reachable by the clients that need them.
9. Authentication: Open Rooms, JWT, or SSO
By default, anyone who knows or guesses a room name can join. For a public-facing instance that is a real problem — room-name squatting is trivial and there are bots that scan for open Jitsi instances.
The options, in ascending order of effort:
Secure rooms / internal authentication. Require that a room be created by an authenticated user; guests then need to be admitted. Simple, and enough for a small team.
JWT-based authentication. Your application mints a signed token granting access to a specific room for a specific duration. This is the right answer if you are embedding Jitsi into your own product, because it lets your existing session logic control access.
SSO via Prosody modules. LDAP or Active Directory integration is available through Prosody's authentication modules, which is what an organisation wanting "log in with the corporate account" needs. It is configuration work in Prosody, not a checkbox in the web UI.
Whichever you choose, do not leave an internet-facing Jitsi instance fully open. This is the single most common misconfiguration and it is routinely exploited.
10. Recording and Streaming (Jibri)
Jibri is a separate component that launches a headless Chrome instance, joins the conference as a hidden participant, and captures the output — to a file or to a live stream (YouTube and others).
Realistic expectations:
It requires dedicated resources. A Jibri node needs meaningful CPU and memory, because it is running a browser that is compositing video. It is not something you add to an existing small VPS.
It needs /dev/shm
sized correctly. The classic Jibri failure is Chrome crashing because shared memory is too small. Every deployment guide mentions it and people still hit it.
One recording per Jibri node. If you need concurrent recordings, you need a pool of them, with the associated orchestration.
It is incompatible with E2EE, as covered. Decide which you need per meeting type.
Storage and retention are yours to design, which is the point — but it means thinking about encryption at rest, who can access recordings, and when they are deleted.
11. Phone Dial-In (Jigasi)
Jigasi is the SIP gateway: it lets people join a conference by dialling a number, and lets conference participants dial out.
To use it you need a SIP trunk from a provider, which means a telephony account and per-minute charges. This is the one part of a self-hosted Jitsi deployment that has an unavoidable recurring third-party cost, and it is also the part where the "everything is on my infrastructure" story necessarily bends — the audio has to travel over the phone network.
Also note the same E2EE incompatibility: bridging phone audio requires decrypting it.
12. Scaling Beyond One Bridge
A single JVB handles a surprising amount — dozens of participants across several conferences on modest hardware. Past that:
Add videobridges. Multiple JVBs, with Jicofo distributing conferences across them based on load and region.
Add Prosody instances for large deployments, since signalling volume grows with participant count.
Consider geographical placement. Latency matters more than raw throughput for call quality. A bridge close to participants beats a bigger bridge far away.
Use Octo (Jitsi's bridge-to-bridge relaying) for very large or geographically distributed conferences, which is a genuinely advanced topic with real operational complexity.
The honest guidance: most organisations never need any of this. One well-provisioned bridge with a TURN server covers a company of a few hundred people. The scaling story is excellent, but it is a story you should only read when you have evidence you are in it.
Embedding Jitsi in Your Own Product
One of Jitsi's genuine strengths is that it is designed to be embedded. There is an IFrame API for dropping a conference into a web page with a script tag, plus web and native SDKs for deeper integration.
The IFrame API is the low-effort path: load the external API script, create a JitsiMeetExternalAPI
object with a room name and options, and you have a working call inside your own interface. You can control it programmatically — start with audio muted, set the display name, hang up, react to participant events — through a documented command and event surface.
The SDKs are for when you need the client to be yours: custom UI, custom authentication flows, or a native mobile wrapper. That is a bigger commitment and it means tracking upstream client changes, but Apache-2.0 makes it a legitimate option rather than a licence negotiation.
The pattern that works best: generate room names server-side, and gate them behind JWTs. Your application decides who may enter which room and for how long, mints a token, and hands it to the client. This closes the open-room problem from section 9 and gives you an audit trail of who created which room.
The thing to plan for is that embedding makes Jitsi a dependency of your product's reliability. When the bridge is down, your product's calls are down, and your users will report it to you rather than to anyone else.
13. Where Your Data Goes
Self-hosted, default configuration: signalling and media transit your server. No media or signalling touches 8x8 or any third party. This is the core claim and it holds — a self-hosted Jitsi deployment is architecturally incapable of leaking media to a vendor, because there is no vendor component in the media path.
Self-hosted with E2EE: the bridge forwards ciphertext. Even a full compromise of your own server yields encrypted frames, not content.
Self-hosted without E2EE: your server operator could, in principle, capture media. That operator is you, which is exactly the point — the question changes from "do I trust this vendor" to "do I control this server."
JaaS (8x8's hosted service): media flows through 8x8's infrastructure in their jurisdiction. Fine for many use cases, and different from self-hosting in the way every SaaS is different.
What is not collected: Jitsi does not build a profile of your meetings. There is no analytics layer selling your call metadata. The open-source deployment has no such component.
14. The Compliance Question That Surprises People
Here is the thing most Jitsi write-ups get wrong.
8x8 holds SOC 2 Type II and ISO 27001 certifications — for their hosted service. Those certifications do not extend to your self-hosted instance.
This surprises people who assume that deploying certified software inherits the certification. It does not. A SOC 2 report covers a specific system operated by a specific organisation with specific controls, audited at a point in time. Your VPS running Docker Compose is not in scope for 8x8's audit.
So the accurate picture is:
- Self-hosted Jitsi can be HIPAA eligible and GDPR ready — because you are operating it on infrastructure whose compliance posture you control, with controls you implement.
- Achieving that is your work, not something you inherit: DTLS-SRTP for signalling and media, a hardened and authenticated TURN server, SSO through Prosody's LDAP modules, dedicated Jibri nodes for compliant recording, encryption at rest for recordings, access logging, and a retention policy.
- If you need a vendor attestation to hand an auditor, self-hosting means producing your own, which is a bigger project than installing Jitsi.
The upside is real though: for a European organisation with GDPR obligations, or anyone with data-residency requirements, self-hosting converts "trust that the vendor's US-hosted infrastructure is adequate" into "prove that ours is." And regarding the CLOUD Act: self-hosting on non-US infrastructure eliminates that exposure entirely, because there is no US entity in the path holding your data.
15. What It Actually Costs
| Component | Zoom (Business) | Jitsi self-hosted |
|---|---|---|
| Licence | ~$15.99/user/month | $0 (Apache-2.0) |
| Infrastructure | $0 | ~$30–100/mo VPS for an SFU |
| Bandwidth | Included | The real line item |
| TURN | Included | ~$5–10/mo, or colocated |
| Phone dial-in | Included in some tiers | SIP trunk + per-minute |
| Recording storage | Tiered | Your storage |
| Compliance | Vendor's SOC 2 | Yours to build |
Do the bandwidth arithmetic, because it is the cost people miss. A 720p stream is roughly 1.5–2.5 Mbps. In a ten-person conference on an SFU, each participant uploads one stream and downloads several, so the bridge is moving something on the order of 20–25 Mbps aggregate, sustained, for the duration. Run that for a working day and you are into real transfer volumes.
Budget a VPS with generous or unmetered transfer. The classic mistake is buying a cheap instance with a 1 TB monthly cap and discovering in week three that you have burned through it.
The comparison that matters: Zoom's per-seat fee scales with headcount and is billed forever. Jitsi's cost scales with usage and is capped by your infrastructure. For an organisation where most people are on calls rarely, self-hosting is dramatically cheaper. For an organisation where everyone is on video all day, the gap narrows and the operational burden starts to dominate.
There is one more cost that only appears at the second meeting of the day: the operational attention tax. Someone has to notice that Let's Encrypt failed to renew, that Jibri has filled the disk, that the TURN credentials expired, that the bridge is at 90% of its bandwidth cap. None of these are hard. All of them are yours now, and they arrive at inconvenient times. Budget a few hours a month honestly, and decide in advance who owns that.
16. Jitsi vs the Field
Zoom is the incumbent and it is better at the thing it does: it works on every device, on every network, with no configuration. If your requirement is "calls just work and I do not want to think about it," pay for Zoom. The argument for Jitsi is not quality, it is control and cost structure.
BigBlueButton is the better choice for education and structured training. It has a built-in whiteboard, breakout rooms, and presentation tooling designed for teaching. Its focus is narrower and its real-time model is different. If you are running virtual classes, evaluate BigBlueButton seriously before choosing Jitsi.
Element / Matrix offers video calling inside a federated chat platform. If you want chat as the primary product with video attached, that is a coherent choice. If you want video as the primary product, Jitsi is more focused.
Microsoft Teams and Google Meet are bundles. You get video because you bought the suite. The sovereignty analysis is the same as any US-hosted SaaS.
Jitsi's position is the strongest self-hosted general-purpose video conferencing option, with the most permissive licence in the category and the most deployment flexibility.
17. Honest Limitations
It is six components, not one app. More failure modes, more to learn, more to monitor.
TURN is mandatory in practice. Without it, some participants cannot connect at all, and the symptom looks like a Jitsi bug rather than a network problem.
Self-hosting does not inherit SOC 2 or ISO 27001. Compliance becomes your project.
E2EE disables recording, streaming, and SIP. A hard trade, not a bug.
Bandwidth is the real cost and it is easy to underestimate.
Jibri is resource-hungry and one-recording-per-node. Recording at scale means a pool of nodes.
Call quality is less forgiving than commercial services on bad networks. Commercial vendors do aggressive adaptive bitrate and have global media placement; you have one bridge in one datacentre.
8x8's commercial interests come first. The company's revenue is JaaS. Self-hosting is well supported and genuinely open, but roadmap priority follows the product that pays.
Mobile and browser edge cases exist. WebRTC compatibility is good but not universal, and you will eventually meet a device that behaves oddly.
Room-name security is not on by default. Secure it or someone will find your instance.
18. Performance and Sizing
Counter-intuitively, CPU is rarely the bottleneck; bandwidth and latency are.
An SFU forwards packets rather than transcoding them, so CPU load scales with packet count rather than with expensive encode work. A modest VPS handles more concurrent streams than people expect.
What actually matters:
- Network throughput — the aggregate of all forwarded streams.
- Latency to participants — a bridge closer to your users beats a bigger bridge farther away.
- Packet loss — WebRTC degrades gracefully but noticeably; loss shows up as blocky video before it shows up as dropouts.
- Jibri resources — if you record, this becomes your CPU bottleneck, not the bridge.
Practical sizing: start with 2 vCPU / 4 GB and unmetered or generous bandwidth. Monitor actual usage. Scale up or add a second bridge when you have data rather than in anticipation.
19. Troubleshooting
"Connected but no audio or video." Port 10000 UDP is blocked, or TURN is missing. Test with a client on a different network.
"It works for everyone except one person." That person is behind symmetric NAT. TURN.
"Recording fails immediately." Jibri's /dev/shm
is too small, or there is no free Jibri node, or the conference has E2EE enabled.
"Participant count is fine but quality is poor." Bandwidth ceiling or packet loss, not CPU.
"Room was taken by a stranger." You left authentication open. Enable secure rooms or JWT.
"Certificate errors on join." Let's Encrypt renewal failed, or APP_BASE_URL
/public URL is wrong.
"Jicofo cannot reach Prosody." Internal XMPP connectivity. Check the internal network between containers.
"Call drops after 30 seconds." Almost always STUN/TURN.
"Everything worked yesterday and nothing changed." Something changed. Check certificate renewal first, then whether a container restarted with a new image after an unattended upgrade, then whether the host ran out of disk.
20. Security Hardening
The baseline for anything internet-facing:
1. Enable authentication. Secure rooms at minimum; JWT or LDAP/SSO if you can.
2. Run and authenticate TURN. Never an open relay.
3. Keep ports minimal. Only 80/443 and the media ports need exposure.
4. Enable DTLS-SRTP (default) and verify it is on.
5. Restrict Prosody and Jicofo to the internal Docker network.
6. Automate updates. Jitsi ships frequently; the release cadence is a security feature if you keep up with it.
7. Encrypt recordings at rest and set a retention policy before you need one.
8. Rate-limit room creation if your instance is public.
21. Backup and Upgrades
The good news: there is very little durable state. Jitsi is a real-time system. Conferences are ephemeral. There is no database of meetings to protect.
What is worth backing up:
.env
and the config directory. Version it.
Prosody configuration — accounts and auth settings.
Recordings — if you use Jibri, these are the actually-irreplaceable artifacts, and they need the same treatment as any sensitive media: encryption, access control, retention.
Upgrades via Docker are a matter of pulling new images and recreating containers. Read the release notes — Jitsi's Docker setup occasionally changes configuration variable names between versions, and the upgrade that silently breaks is usually the one where an env var was renamed.
One practice that pays for itself immediately: keep your generated .env
and your config directory in a private git repository. Nearly every Jitsi problem is a configuration problem, and being able to diff today's config against last month's turns "what changed?" from an afternoon of guessing into a single command. It also means a rebuild is a clone and a docker compose up` rather than an archaeology exercise.
22. Who Should Run It, and Who Shouldn't
Run it if you need video calls where the media cannot leave your infrastructure; you have regulatory or jurisdictional constraints that hosted video cannot satisfy; per-seat video licensing is a growing line item you want to cap; or you want to embed conferencing into a product you control.
Also run it if you want a video stack you can actually inspect and modify — with Apache-2.0 and a component architecture, that is genuinely available to you in a way it is not with any commercial product.
Think twice if you need recordings and E2EE at the same time (impossible); you need a vendor SOC 2 report and have no appetite for building your own compliance posture; your participants are on unpredictable networks and you cannot run a TURN server; or nobody wants to own a six-component real-time system.
Consider BigBlueButton instead if your use case is classes and training rather than meetings.
23. The Verdict
Jitsi Meet is the best self-hosted video conferencing option available, with the most permissive licence in its category and an architecture that genuinely delivers on the sovereignty claim: with a self-hosted deployment, no media and no signalling touches a third party, because there is no third-party component in the path.
The honest costs are operational rather than financial. It is six components, not an app.
You need a TURN server, and the symptom of not having one looks like an unrelated bug.
Self-hosting does not inherit 8x8's SOC 2 or ISO 27001 — if you need compliance, you build it. E2EE and recording are mutually exclusive, so you choose per meeting type. And bandwidth, not licences, is the cost that scales.
What you get for that: no per-seat fee, no vendor holding recordings of your board meetings, no foreign jurisdiction in the media path, and a codebase you can fork under Apache-2.0 if the maintainers ever go somewhere you do not want to follow.
For an organisation where video calls are occasional and sensitive, that trade is obviously correct. For one where everyone is on video all day on unpredictable networks, it is a closer call — and the closer call is worth making deliberately rather than by default.
Related
Comments (0)
No comments yet. Be the first to comment!