How to Install Jitsi Meet on Ubuntu 24.04 VPS: Self-Hosted Video Conferencing

Running your own Jitsi Meet server gives you a fully featured, browser-based video conferencing platform that rivals Zoom and Google Meet -- without participant caps, without recurring SaaS fees, and without your meeting metadata flowing through a third party. This guide walks you through installing Jitsi Meet on an Ubuntu 24.04 VPS, from hostname configuration to a TLS-secured production deployment with moderator authentication.

Prefer a managed option? If you would rather skip the stack setup, CloudCore Professional comes pre-sized for a 50-user Jitsi deployment -- 4 vCPU, 8 GB RAM, and a generous upstream pipe from a low-latency European backbone.

Table of Contents

What is Jitsi Meet?

Jitsi Meet is an open-source, fully encrypted video conferencing platform built on WebRTC. Participants join meetings directly in a modern browser -- no plugin, no desktop install, no account -- by visiting a URL like https://meet.yourdomain.com/MyMeetingRoom. Under the hood, Jitsi is a small collection of loosely coupled services that each do one job well: Jicofo handles conference focus and signaling, Jitsi Videobridge (JVB) forwards the actual media (audio, video, screen share) using a selective forwarding unit (SFU) architecture, Prosody runs the XMPP signaling layer, and an Nginx front-end serves the web client and routes BOSH/WebSocket traffic to Prosody.

The combined stack supports nearly every feature you expect from a modern meeting platform -- grid and tile layouts, screen sharing, raise-hand, chat, polls, moderated rooms, lobbies, waiting rooms, virtual backgrounds, live streaming to YouTube via Jibri, SIP dial-in, and server-side recording to S3-compatible storage. End-to-end encryption (E2EE) using Insertable Streams is available for small meetings in supported browsers, and transport-layer encryption with DTLS-SRTP is always on between clients and the Videobridge.

Jitsi powers everything from small team standups to massive webinars. Public-sector deployments across the EU use Jitsi for sensitive government meetings, healthcare providers use it for HIPAA-aligned telemedicine (when deployed correctly), universities use it for remote lectures, and open-source projects use it for community calls. The reference deployment at meet.jit.si demonstrates what the stack can handle at scale -- millions of minutes per day -- and the same software runs on your VPS with a couple of apt commands.

Why Self-Host Jitsi Instead of Using meet.jit.si?

The public meet.jit.si instance is free and excellent for casual use, but self-hosting unlocks several capabilities that matter for teams and regulated industries:

• Complete privacy and data sovereignty -- Meeting metadata, chat logs, room names, and participant IP addresses stay on your server. Nothing transits 8x8's infrastructure. For GDPR, HIPAA, or contractual confidentiality, this is often a hard requirement.
• No participant cap imposed by the provider -- meet.jit.si caps rooms at 100 participants. On your own Videobridge, the only limit is your CPU, RAM, and upstream bandwidth. A 4 vCPU / 8 GB VPS comfortably handles 50-75 concurrent participants in a single room; larger deployments scale horizontally with Octo.
• Predictable flat cost -- A VPS runs the same whether you host two meetings a month or two hundred per day. No per-minute billing, no per-user seat charges.
• Custom branding -- Replace the Jitsi logo, set your own color palette, customize the welcome page, and use your own domain. The meeting is your product, not a Jitsi ad.
• Lobby, waiting room, and moderator authentication -- While meet.jit.si supports lobbies, self-hosting lets you lock down room creation entirely so only authenticated users can start a meeting -- guests then join through a moderator-approved lobby.
• No account required for guests -- Share a link and guests join in one click. Combined with authenticated moderators, you get the best of both worlds: friction-free joining, controlled hosting.
• Integration freedom -- Wire Jitsi into your SSO provider with JWT, embed it in your own app via the IFrame API, add custom Jigasi dial-in, or route recordings straight to your S3 bucket.
• End-to-end control over recording -- Jibri records meetings to your own disk or object storage. The recording file never leaves your infrastructure.

Self-Hosted Jitsi vs. SaaS Video Conferencing

Prerequisites

Before you begin, confirm you have the following ready:

• A VPS running Ubuntu 24.04 LTS with root or sudo access
• SSH access to your server
• A fully qualified domain name (FQDN) such as meet.yourdomain.com -- Jitsi Meet will not work correctly with a bare IP address because browsers require a valid TLS certificate for WebRTC getUserMedia
• DNS A/AAAA records pointing your FQDN to the VPS public IP
• At least 4 vCPU cores and 8 GB RAM for a ~50-participant single-room deployment
• Generous upstream bandwidth -- plan for ~2 Mbps per full-HD participant in an SFU (so 50 participants x 2 Mbps = 100 Mbps peak egress)
• A valid email address for Let's Encrypt certificate registration

Recommended Plan: CloudCore Professional

For a comfortable self-hosted Jitsi serving ~50 concurrent participants, we recommend the CloudCore Professional plan:

- 4 vCPU cores

- 8 GB RAM

- 100 GB NVMe SSD

- Unmetered low-latency bandwidth

- EUR 19.99/month

For larger deployments (200+ participants or multi-region Octo), scale vertically to our 8 vCPU / 16 GB plan or add additional Videobridge nodes behind a shared Jicofo/Prosody.

Connect to your server via SSH:

ssh root@your-server-ip

Step 1: Set the Hostname and DNS Records

Jitsi's installer asks for the FQDN during the interactive setup, and several config files embed that hostname. Setting the hostname correctly up front avoids later reinstalls.

Set the system hostname to your chosen FQDN:

sudo hostnamectl set-hostname meet.yourdomain.com

Add the hostname to /etc/hosts so local lookups resolve correctly:

sudo tee -a /etc/hosts > /dev/null <<EOF
127.0.0.1 meet.yourdomain.com meet
EOF

Verify the hostname:

hostname -f

Expected output:

meet.yourdomain.com

In your DNS provider (Cloudflare, Route 53, or whichever registrar you use), create an A record for meet.yourdomain.com pointing to your VPS public IPv4. If you have IPv6, also create an AAAA record. Propagation is usually instant but can take up to an hour -- verify from your laptop:

dig +short meet.yourdomain.com

Do not continue until DNS resolves correctly. The Let's Encrypt step in particular will fail without valid DNS.

Step 2: Update the System and Install Java

Jitsi Videobridge and Jicofo run on the Java Virtual Machine. Ubuntu 24.04's default JDK is OpenJDK 21, but Jitsi's current packages target OpenJDK 11 for maximum compatibility with the Prosody-bundled Lua and the Videobridge runtime.

Update package indexes and upgrade installed packages:

sudo apt update && sudo apt upgrade -y

Install OpenJDK 11 (JRE headless is sufficient -- the Videobridge does not need a graphical JDK) along with the supporting utilities we'll use later:

sudo apt install -y openjdk-11-jre-headless gnupg2 curl lsb-release apt-transport-https ca-certificates

Set the default Java runtime so Jicofo and JVB pick up version 11:

sudo update-alternatives --set java /usr/lib/jvm/java-11-openjdk-amd64/bin/java

Confirm the active Java version:

java -version

Expected output:

openjdk version "11.0.23" 2024-04-16
OpenJDK Runtime Environment (build 11.0.23+9-post-Ubuntu-1ubuntu1)
OpenJDK 64-Bit Server VM (build 11.0.23+9-post-Ubuntu-1ubuntu1, mixed mode, sharing)

Export JAVA_HOME so the Jitsi package post-install scripts find the runtime:

echo 'JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64' | sudo tee -a /etc/profile.d/java.sh
sudo chmod +x /etc/profile.d/java.sh
source /etc/profile.d/java.sh

Step 3: Add the Prosody Repository

Ubuntu 24.04 ships Prosody 0.12 in the default archive, but Jitsi depends on specific modules (mod_auth_internal_hashed, mod_smacks, mod_carbons) that are best installed from the official Prosody APT repository. This also guarantees you get security updates for Prosody independent of the Ubuntu LTS cadence.

Import the Prosody signing key:

curl -fsSL https://prosody.im/files/prosody-debian-packages.key | sudo tee /etc/apt/keyrings/prosody-debian-packages.asc > /dev/null

Add the Prosody repository for Ubuntu 24.04 (noble):

echo "deb [signed-by=/etc/apt/keyrings/prosody-debian-packages.asc] http://packages.prosody.im/debian noble main" | sudo tee /etc/apt/sources.list.d/prosody.list

Pin Prosody packages to prefer the official repo over the Ubuntu archive:

sudo tee /etc/apt/preferences.d/prosody-pin > /dev/null <<EOF
Package: prosody*
Pin: origin packages.prosody.im
Pin-Priority: 1001
EOF

Refresh the APT cache:

sudo apt update

Step 4: Add the Jitsi Repository

Jitsi publishes Debian packages for Meet, Jicofo, Videobridge, and Jibri from download.jitsi.org. The same repo works on Ubuntu 24.04 because Jitsi packages are architecture-independent where it matters.

Import the Jitsi signing key:

curl -fsSL https://download.jitsi.org/jitsi-key.gpg.key | sudo gpg --dearmor -o /usr/share/keyrings/jitsi-keyring.gpg

Add the Jitsi stable repository:

echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list

Update the APT cache to pick up both Prosody and Jitsi:

sudo apt update

Step 5: Install Jitsi Meet

The jitsi-meet meta-package pulls in the full stack: Jicofo, Videobridge, Prosody, Nginx, and the React web client. During install you will be prompted for two things -- the FQDN, and whether to generate a self-signed certificate or use an existing one.

Open port 80 temporarily so the installer can render the configuration page, then kick off the install:

sudo apt install -y jitsi-meet

When the first interactive prompt appears, enter the exact FQDN you set in Step 1:

Hostname of the current installation:
meet.yourdomain.com

At the second prompt, choose "Generate a new self-signed certificate" for now. We will replace it with a real Let's Encrypt certificate in the next step.

SSL certificate for the Jitsi Meet instance:
( ) I want to use my own certificate
(*) Generate a new self-signed certificate (You will later get a chance to obtain a Let's Encrypt certificate)

The installer runs for 1-2 minutes, pulls dependencies, configures Nginx, generates Prosody virtual hosts, writes systemd units, and starts all three services. Expected final output:

Setting up jitsi-meet-web-config (1.0.8203-1) ...
Setting up jitsi-meet (2.0.9779-1) ...
Processing triggers for nginx (1.24.0-2ubuntu7.3) ...
Processing triggers for systemd (255.4-1ubuntu8.4) ...

Verify each service is running:

sudo systemctl status prosody jicofo jitsi-videobridge2 nginx

All four should report active (running). If any unit is in failed state, check the logs with sudo journalctl -u <service> -n 50 --no-pager.

Step 6: Obtain a Let's Encrypt Certificate

WebRTC refuses to request microphone or camera access over non-HTTPS origins, and self-signed certificates produce a warning that scares off guests. Jitsi ships a helper script that wraps Certbot with the correct renewal hooks for Nginx.

Run the Let's Encrypt helper:

sudo /usr/share/jitsi-meet/scripts/install-letsencrypt-cert.sh

You will be prompted for a contact email (used by Let's Encrypt for expiry reminders):

Enter your email and press [ENTER]: [email protected]

The script performs an HTTP-01 challenge against your FQDN, writes the certificate to /etc/letsencrypt/live/meet.yourdomain.com/, updates the Nginx server block, and installs a systemd timer for automatic renewal. Expected tail of output:

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/meet.yourdomain.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/meet.yourdomain.com/privkey.pem
This certificate expires on 2026-07-15.
These files will be updated when the certificate renews.
Adding a cron job in /etc/cron.weekly ...
Done.

Test automatic renewal (dry run -- does not actually hit Let's Encrypt's rate-limited production API):

sudo certbot renew --dry-run

Visit https://meet.yourdomain.com in a browser. You should see the Jitsi welcome page with a valid padlock icon. Type any room name ("test-room") and click Start Meeting; after allowing camera and microphone you will be alone in a room with your own video preview. Your Jitsi is live.

Step 7: Configure the Firewall

Jitsi requires a specific, small set of ports to be reachable from the public internet. If you are using UFW (Ubuntu's default firewall) or you are behind a cloud provider security group, open these:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 4443/tcp
sudo ufw allow 10000/udp
sudo ufw enable
sudo ufw status verbose

Expected output:

Status: active
To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
80/tcp                     ALLOW IN    Anywhere
443/tcp                    ALLOW IN    Anywhere
4443/tcp                   ALLOW IN    Anywhere
10000/udp                  ALLOW IN    Anywhere

Critical: UDP/10000 must be open end-to-end from your client to the Videobridge. This is the single most common cause of "I can see others but hear no audio" or "video freezes after 30 seconds" complaints. If your VPS is behind a NAT (some OVH and Hetzner setups), set org.jitsi.videobridge.NAT_HARVESTER_PUBLIC_ADDRESS in /etc/jitsi/videobridge/sip-communicator.properties to the public IP, and NAT_HARVESTER_LOCAL_ADDRESS to the private IP. On Contabo and most straight-through VPS providers this is not needed.

If you use our UFW firewall guide to set up the firewall before installing Jitsi, remember to open the four Jitsi-specific ports above.

Step 8: Restrict Room Creation to Moderators

Out of the box, anyone who knows your FQDN can create a room. For public community instances that is fine. For team, customer, or internal deployments you want only authenticated users to create rooms, while still letting unauthenticated guests join those rooms.

This is the "secure domain" pattern and it combines Prosody's internal_hashed auth with an anonymous guest virtual host.

Edit the Prosody configuration:

sudo nano /etc/prosody/conf.avail/meet.yourdomain.com.cfg.lua

Locate the main VirtualHost "meet.yourdomain.com" block and change:

authentication = "jitsi-anonymous"

to:

authentication = "internal_hashed"

Immediately below that block, append a new anonymous guest virtual host:

VirtualHost "guest.meet.yourdomain.com"
    authentication = "jitsi-anonymous"
    c2s_require_encryption = false
    modules_enabled = {
        "turncredentials";
    }

Save and exit. Next, tell Jicofo about the guest domain:

sudo nano /etc/jitsi/jicofo/jicofo.conf

Inside the jicofo { } block, add (or update) the authentication section:

authentication: {
    enabled: true
    type: XMPP
    login-url: meet.yourdomain.com
}

Finally, update the Meet web client config:

sudo nano /etc/jitsi/meet/meet.yourdomain.com-config.js

Find the hosts block and add:

var config = {
    hosts: {
        domain: 'meet.yourdomain.com',
        anonymousdomain: 'guest.meet.yourdomain.com',
        muc: 'conference.meet.yourdomain.com',
        focus: 'focus.meet.yourdomain.com'
    },
    // ...
};

Create your first moderator account using the prosodyctl tool:

sudo prosodyctl register admin meet.yourdomain.com 'a-strong-password'

Restart the stack to apply all three config changes:

sudo systemctl restart prosody jicofo jitsi-videobridge2

Test the flow -- open an incognito browser, visit https://meet.yourdomain.com/secure-test, and you should see a "Waiting for the host..." screen. In a separate browser, log in at the same URL with admin / a-strong-password. You become the moderator and the waiting guest joins automatically.

Add more moderators any time:

sudo prosodyctl register alice meet.yourdomain.com 'alice-password'

Remove a moderator:

sudo prosodyctl deluser [email protected]

Step 9: Optional JWT Authentication

For SaaS integrations, SSO, or programmatic room provisioning, JWT is a cleaner fit than static Prosody accounts. A backend service signs a short-lived JWT with a shared secret and passes it to the client, which sends it to Prosody at connection time.

Install the JWT-capable Prosody modules:

sudo apt install -y jitsi-meet-tokens

The installer asks for two values:

Application ID (APP ID): my-app
Application secret: <32+ character random string>

Generate a strong secret if you do not have one:

openssl rand -hex 32

After install, restart the stack:

sudo systemctl restart prosody jicofo

Your backend can now mint tokens with claims like:

{
  "aud": "jitsi",
  "iss": "my-app",
  "sub": "meet.yourdomain.com",
  "room": "*",
  "exp": 1765459200,
  "context": {
    "user": {
      "name": "Alice",
      "email": "[email protected]",
      "moderator": "true"
    }
  }
}

Clients join with https://meet.yourdomain.com/MyRoom?jwt=<signed-token> and are auto-promoted to moderator. Full claim reference is documented in the Jitsi handbook.

Step 10: Recording with Jibri (Overview)

Jibri (Jitsi Broadcasting Infrastructure) is a separate service that records meetings by spinning up a headless Chrome instance, joining the room as a silent participant, and capturing the browser output with FFmpeg. Because Jibri needs its own Chrome process and consumes ~2-3 GB RAM plus a full CPU core per recording, it is typically deployed on a second VPS rather than sharing the Jitsi host.

A typical Jibri setup looks like this:

Once Jibri is online, moderators see a Start Recording button in the meeting overflow menu. Recordings are MP4 files and are uploaded via your finalize hook. The Jibri documentation covers the full setup; this guide stops short of a step-by-step Jibri install because production recording is a dedicated topic in its own right.

Live streaming to YouTube uses the same Jibri service -- moderators provide a YouTube stream key and Jibri pipes the browser capture to RTMP instead of a local file.

Mobile Apps and Custom Branding

Jitsi Mobile Apps

The official Jitsi Meet apps on iOS and Android connect to any self-hosted server. Users simply tap Settings, set Server URL to https://meet.yourdomain.com, and all meetings on your domain open in the native app instead of the browser. No separate app build is required for basic usage.

For white-labelled apps with your own branding in the App Store and Play Store, clone the Jitsi Meet SDK and rebuild with your logo, colors, and bundle identifier. This is a multi-day effort but gives you a product-grade mobile experience.

Custom Branding on the Web

Swap the default Jitsi logo and welcome page content by editing:

sudo nano /etc/jitsi/meet/meet.yourdomain.com-config.js

Key customisations:

• interfaceConfig.SHOW_JITSI_WATERMARK = false -- hide the Jitsi logo
• interfaceConfig.APP_NAME = 'YourCorp Meet' -- rename the app
• interfaceConfig.DEFAULT_BACKGROUND = '#1a1a1a' -- pre-call background
• Replace /usr/share/jitsi-meet/images/watermark.svg with your own logo (same dimensions)

sudo systemctl reload nginx

Scaling Jitsi with Octo

A single Videobridge saturates at roughly 500 concurrent participants distributed across many rooms, or ~75 in a single hero room. Beyond that, you scale horizontally with Octo -- Jitsi's cascade architecture that lets multiple Videobridges in different regions act as one, routing media between bridges transparently to the client.

Octo scaling at a high level:

Jicofo automatically assigns each participant to the closest bridge based on geo-latency probes. When Alice in Europe and Bob in the US join the same room, Alice connects to the Frankfurt bridge, Bob connects to the Ashburn bridge, and the two bridges relay only the aggregated streams across the Atlantic -- one flow per bridge pair instead of N-per-participant.

For most teams, a single 4 vCPU / 8 GB VPS handles every meeting you will ever hold. Octo becomes relevant when you cross 200+ concurrent participants or you have a truly global user base where single-region latency becomes painful.

Troubleshooting

Viewing Logs

Each Jitsi service logs via systemd. The three most useful tail commands:

# Jicofo (conference focus / signaling)
sudo journalctl -u jicofo -f
Videobridge (media router)
sudo journalctl -u jitsi-videobridge2 -f
Prosody (XMPP server)
sudo tail -f /var/log/prosody/prosody.log

Nginx access and error logs are in /var/log/nginx/access.log and /var/log/nginx/error.log.

FAQ

How many participants can a single-server Jitsi handle?

This depends almost entirely on CPU and upstream bandwidth. As a rule of thumb, a 4 vCPU / 8 GB VPS comfortably hosts ~50 participants in a single room at 720p, or several hundred participants split across many small rooms. Each HD video stream routed through the Videobridge consumes roughly 2-5% of a single CPU core and ~2 Mbps of egress. If you plan large town-halls, use lastN to limit how many videos are actually forwarded to each client (for example, lastN: 9 sends only the nine most recent speakers to every participant regardless of room size), and lower the default resolution to 360p.

Do I need a GPU for Jitsi?

No. Jitsi Videobridge is a selective forwarding unit -- it routes packets without decoding or re-encoding them, so CPU (and bandwidth) are the only bottlenecks. The only Jitsi component that benefits from a GPU is Jibri, which runs a Chrome instance and captures the browser output -- and even Jibri works fine on CPU-only VPS with software encoding via FFmpeg's libx264.

Is Jitsi end-to-end encrypted?

Transport encryption (DTLS-SRTP) is always on between clients and the Videobridge, so nobody on the network path can snoop media. True end-to-end encryption (E2EE) -- where the Videobridge itself cannot decrypt media -- is available in supported browsers (Chrome, Edge) using Insertable Streams and is toggled by participants in the meeting security menu. E2EE currently has limitations: it only works in peer-to-peer or small-room modes, and recording via Jibri is incompatible (Jibri cannot decrypt E2EE media). For most teams, transport-layer encryption on your own self-hosted server provides sufficient privacy; reserve E2EE for highly sensitive ad-hoc meetings.

Can I integrate Jitsi with my existing SSO?

Yes, via JWT. Your SSO provider (or a small OAuth-aware backend) mints a JWT containing the user's name, email, and moderator: true/false claim, signs it with your shared secret, and redirects the user to https://meet.yourdomain.com/RoomName?jwt=<token>. Prosody validates the signature on connection and Jicofo promotes moderators automatically. See Step 9 for setup details. Keycloak, Auth0, Okta, Google Workspace, and custom backends all work.

How does Jitsi compare to BigBlueButton for education use cases?

Jitsi Meet is a pure video conferencing platform -- excellent for team meetings, webinars up to a few hundred participants, and ad-hoc rooms with zero onboarding friction. It is lightweight (one server, no database required for the base stack), integrates cleanly with any web app via the IFrame API, and its mobile apps are first-rate.

BigBlueButton is purpose-built for online classrooms -- multi-user whiteboard, shared notes, breakout rooms with presenter controls, polls with analytics, and tight Moodle/Canvas LMS integration. It is heavier (requires Postgres, Redis, Kurento, BBB-LTI, and several more services) and more opinionated about its UI.

For a generic team or customer meeting platform, Jitsi wins on simplicity and performance. For structured K-12 or university classrooms with lesson flow, BBB wins on pedagogy-focused features. Some deployments run both.

Next Steps

With Jitsi Meet running on your VPS, here are the recommended follow-ups to harden and extend your deployment:

• Set up Nginx tuning for high-concurrency meetings -- The default Nginx config works but raises worker_connections and enables HTTP/2 are worth tuning for 100+ simultaneous WebSocket connections. See our Nginx configuration guide for worker and keepalive tuning.

• Harden TLS with modern cipher suites -- Our Let's Encrypt with Certbot guide covers A+ grade Qualys SSL Labs settings including HSTS, OCSP stapling, and Mozilla Modern TLS profile.

• Lock down SSH and the firewall properly -- The UFW firewall setup guide walks through fail2ban, SSH key-only auth, and rate-limiting brute-force scanners on port 22.

• Deploy Jibri on a secondary VPS for recording -- Follow the Jibri deployment handbook to add server-side recording and YouTube live streaming to your stack.

• Add Matrix/Element for persistent chat -- Pair Jitsi (ephemeral video) with a Matrix homeserver (persistent chat, rooms, file share) for a complete self-hosted collaboration stack. Jitsi is the default video widget in Element.

• Monitor your Jitsi stack with Prometheus and Grafana -- The Videobridge exposes metrics at /colibri/stats; pipe them into Prometheus and build a Grafana dashboard tracking participant counts, conference RTT, and packet loss.

Ready to Launch Your Self-Hosted Jitsi?

Our CloudCore Professional plan is pre-sized for a ~50-participant Jitsi deployment with plenty of headroom for Nginx, Prosody, and the Videobridge.

- 4 vCPU cores optimised for media routing

- 8 GB RAM for the full Jitsi stack

- 100 GB NVMe SSD for logs and optional local recordings

- Unmetered low-latency bandwidth from European backbone

- Root SSH access on Ubuntu 24.04 LTS

Launch Your Jitsi VPS Now -- Plans start at EUR 19.99/month.