Video Conferencing Server

The source material this page replaces is almost entirely a stub: a component list and two commands, one of which uses the deprecated apt-key adv method. Last updated April 2022.

Jitsi Meet works well in 2026 and installation on Ubuntu 24.04 is straightforward. There is one significant architectural consideration for this series that is worth addressing before getting into installation steps.

What Jitsi Meet provides

Jitsi Meet is a WebRTC-based video conferencing platform. It runs in the browser: participants join a meeting by navigating to a URL. No app installation is required, though iOS and Android apps are available. The core features:

• Multi-participant video and audio conferencing
• Screen sharing
• Chat
• Recording via Jibri (optional, requires additional server resources)
• Password-protected rooms
• Lobby mode for admitting participants
• Integration with calendar applications
• End-to-end encryption option for smaller meetings

The key self-hosting proposition: all media traffic passes through your server rather than through Zoom, Google Meet, or Microsoft Teams infrastructure. Call data does not leave your network unless you explicitly federate or expose the instance publicly.

Architecture

Jitsi Meet is not a single application. It is a collection of services:

Jitsi Meet is the web interface served by nginx. What participants see in their browser.

Jitsi Videobridge (JVB) is the media server. It receives video and audio streams from all participants and distributes them using Selective Forwarding Unit (SFU) architecture. When there are more than two participants, all media flows through JVB.

Jicofo (Jitsi Conference Focus) is the signalling component. It manages conference rooms, assigns participants to videobridges, and handles focus management.

Prosody provides XMPP signalling between the browser clients and Jicofo. Jitsi Meet installs and configures its own Prosody instance.

The interaction between Jitsi’s Prosody and the existing Prosody instance in this series is the key architectural consideration.

The Prosody conflict

This series already runs Prosody for XMPP instant messaging. Jitsi Meet installs its own Prosody instance and configures it with specific virtual hosts and components for conferencing. Running two Prosody instances on the same server is possible but requires careful configuration to avoid port conflicts.

The cleanest solution for this series is to run Jitsi Meet in a dedicated container, completely isolated from the Prosody container. Each container has its own Prosody instance with no conflict.

Recommended approach: a dedicated LXC container for Jitsi Meet, with its own nginx, its own Prosody, its own Jicofo, and its own JVB. The container exposes ports 80, 443, and 10000/UDP to the network via port forwarding on the router.

This is a clean separation. The Jitsi installer configures everything it needs within the container without touching the existing infrastructure.

The nginx consideration

Jitsi Meet’s installer automatically configures nginx for the Jitsi virtual host. On a fresh container with no existing nginx configuration, this works smoothly. On the shared nginx container used by this series, the installer would interfere with existing virtual servers.

In the dedicated container approach, the Jitsi installer has its own nginx instance and configures it freely. No conflict with the existing nginx container.

Resource requirements

Jitsi Meet’s resource consumption scales with the number of concurrent participants.

For a homelab handling internal calls with a small number of participants (two to five people), the resource requirements are modest:

For a family or small team server, 2GB RAM and 2 cores in an LXC container is sufficient. The February server has capacity to spare.

Firewall requirements

Jitsi Meet requires the following ports open to the internet or at least to participants’ networks:

The UDP 10000 port is the most important. JVB sends all media traffic over this port. If it is blocked, participants can see each other’s tiles but no video or audio flows. This is the most common symptom of a misconfigured Jitsi firewall.

Authentication

By default, Jitsi Meet allows anyone who can reach the server to create a conference room. For a public-facing instance this is not ideal. For a homelab, two options:

Restrict to internal network only: the simplest approach. No port forwarding for Jitsi on the router. Access only from within the WireGuard VPN or the internal network. Anyone on the VPN can use Jitsi.

Secure domain with registered users: configure Prosody to require authentication for room creation. Registered users (created via prosodyctl) can create rooms. Anonymous users can join rooms via a shared link. Covered in the full installation page.

Installation overview

The full Jitsi Meet installation is covered in the following page. The high-level steps:

1. Clone the base container template for a dedicated Jitsi container
2. Add the Jitsi apt repository using the current gpg --dearmor approach
3. Install jitsi-meet which installs all components (nginx, Prosody, Jicofo, JVB)
4. Configure the hostname and obtain a Let’s Encrypt certificate
5. Configure authentication
6. Open firewall ports and configure router port forwarding
7. Test with a browser

The installer is significantly more automated than the source material suggests. For a basic Jitsi Meet instance, the installer handles nginx configuration, Prosody setup, and certificate integration with minimal manual intervention.

Jitsi Meet’s peer-to-peer mode activates automatically for two-participant calls, bypassing JVB entirely and routing media directly between browsers. This is more efficient and uses fewer server resources. Once a third participant joins, JVB takes over and all media routes through the server. This transition is invisible to participants.