Jitsi Meet Self-Hosted Video Conferencing on AWS User Guide

Overview

Jitsi Meet is a free, open source video conferencing platform that delivers browser based audio and video meetings with screen sharing, in-call chat, raise-hand and reactions, breakout rooms and recording, with no client software to install and no per-seat licensing. This cloudimg image runs the complete single-node Jitsi stack: prosody (the XMPP signalling server), jicofo (the conference focus that assigns participants to the bridge), jitsi-videobridge2 (the WebRTC Selective Forwarding Unit that routes media), and nginx (which serves the meeting web application over HTTPS and proxies the signalling). The image is secure by default: prosody secure-domain authentication is enabled so only an authenticated moderator can open a room while invited guests join by link with no login, and a unique moderator password is generated on the first boot of every instance so no shared or default credential ships. The prosody virtual-host data and account store live on a dedicated data volume mounted at /var/lib/prosody. Backed by 24/7 cloudimg support.

What is included:

• The full Jitsi Meet stack (prosody, jicofo, jitsi-videobridge2, nginx) managed by systemd
• The meeting web application served over HTTPS on port 443 (HTTP on 80 redirects to 443)
• Secure-domain authentication: only an authenticated moderator can create a room; guests join an open room by link
• A unique moderator password generated on first boot and recorded in a root-only file
• WebRTC media routed by the video bridge over UDP port 10000
• A dedicated data volume at /var/lib/prosody holding the XMPP authentication state
• A self-signed TLS certificate regenerated for the instance address on first boot
• 24/7 cloudimg support

Prerequisites

An AWS account, an EC2 key pair in the target region, and a VPC with a public subnet. m5.large (2 vCPU / 8 GiB RAM) is the recommended instance type. Security group inbound: allow 22/tcp from your management network for SSH, 80/tcp and 443/tcp for the web application, 4443/tcp as the video-bridge fallback, and — importantly — 10000/udp for the WebRTC media. Without UDP 10000 open to your participants, browsers cannot establish the media stream to the bridge.

Step 1 - Launch the AMI

Subscribe to the listing in AWS Marketplace, choose Continue to Launch, and launch through the EC2 console or the AWS CLI. Select the m5.large instance type, your key pair, and a security group that opens ports 22, 80, 443, 4443/tcp and 10000/udp.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.large \
  --key-name <your-key-pair> \
  --security-group-ids <security-group-id> \
  --subnet-id <subnet-id>

Step 2 - Connect to your instance

Connect over SSH as the default login user for your operating system variant.

ssh -i <your-key.pem> ubuntu@<instance-public-ip>

Step 3 - Confirm the services are running

The Jitsi stack is four systemd services plus a one-shot first-boot unit that adapts the web layer to this instance's address and mints the per-instance moderator password. Confirm the four long-running services are healthy:

systemctl is-active prosody.service jicofo.service jitsi-videobridge2.service nginx.service

All four report active.

Step 4 - Verify the web app and the conference focus

Confirm the meeting web application answers over HTTPS, that the video bridge is listening for media on UDP 10000, and — most importantly — that the conference focus (jicofo) has connected to prosody and registered the videobridge. The last check is what proves the appliance can actually host a meeting, not merely serve a page:

curl -sk -o /dev/null -w 'web app: HTTP %{http_code}\n' https://127.0.0.1/
curl -sk -o /dev/null -w 'config.js: HTTP %{http_code}\n' https://127.0.0.1/config.js
ss -ulnp 2>/dev/null | grep -q ':10000' && echo 'JVB media: UDP 10000 listening' || echo 'JVB media: NOT listening'
grep -q 'Added new videobridge' /var/log/jitsi/jicofo.log && echo 'conference focus: videobridge registered' || echo 'conference focus: NOT ready'

The web app and config.js both return 200 (the certificate is self-signed), UDP 10000 is listening, and jicofo reports the videobridge registered.

Step 5 - Read your per-instance moderator credential

The image ships no shared or default login. On first boot a unique moderator password is generated for this instance and written to a root-only file. Read it, confirming the file permissions, the moderator username, the meeting URL and the XMPP domain:

sudo stat -c '%a %U:%G' /root/jitsi-meet-credentials.txt
sudo grep -E '^jitsi\.(moderator\.user|meeting\.url|xmpp\.domain)=' /root/jitsi-meet-credentials.txt

The file is 600 root:root, jitsi.moderator.user is your moderator username (moderator), jitsi.meeting.url is the address to open in your browser, and jitsi.xmpp.domain is the fixed internal signalling domain. Run sudo cat /root/jitsi-meet-credentials.txt to also see the password.

Step 6 - Prove the moderator credential from the command line

Confirm the per-instance moderator password authenticates against the prosody account store, exactly as it will when you sign in to open a room. The helper recomputes the SCRAM stored key and compares it, so a correct password prints OK and a wrong one prints BAD:

PASS=$(sudo grep '^jitsi.moderator.pass=' /root/jitsi-meet-credentials.txt | cut -d= -f2-)
USER=$(sudo grep '^jitsi.moderator.user=' /root/jitsi-meet-credentials.txt | cut -d= -f2-)
HOST=$(sudo grep '^jitsi.xmpp.domain=' /root/jitsi-meet-credentials.txt | cut -d= -f2-)
echo "correct password: $(sudo python3 /usr/local/sbin/jitsi-verify-pass.py "$HOST" "$USER" "$PASS")"
echo "wrong password:   $(sudo python3 /usr/local/sbin/jitsi-verify-pass.py "$HOST" "$USER" 'wrong-password-xyz')"

The correct password prints OK; the wrong one prints BAD.

Step 7 - Open the meeting web app

Open the meeting URL from the credentials file in your browser: https://<instance-public-ip>/. Because the certificate is self-signed, your browser shows a warning the first time; accept it to continue. The Jitsi Meet welcome page loads, where you type a room name to start a meeting.

Step 8 - Host your first meeting

Type a room name and choose Start meeting. Jitsi shows a pre-join screen where you set your display name and check your camera and microphone before entering.

Because secure-domain authentication is enabled, the first person into a room must authenticate as the moderator to open it. Choose Log-in when prompted and enter the moderator username and password from your credentials file. The room then opens and you are in the meeting, with the full toolbar for muting, camera, screen sharing, chat, reactions, the participants panel and tile view. Share the room link with your participants; they join the already-open room with one click and no login.

Step 9 - Open the media port

WebRTC media flows to the video bridge over UDP port 10000. Make sure your instance security group allows inbound 10000/udp from your participants (in addition to TCP 80 and 443 for the web app). Without it, participants reach the meeting page but their audio and video will not connect.

Step 10 - Move to your own domain and a trusted certificate

For production use, point a DNS name at the instance and obtain a trusted Let's Encrypt certificate so browsers no longer show the self-signed warning. Jitsi ships a helper for this:

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

Run it after your DNS record resolves to the instance and follow the prompts. See the Jitsi Meet documentation for using your own domain as the public web address.

Maintenance

The stack runs under systemd. Inspect or restart the services with:

systemctl status prosody jicofo jitsi-videobridge2 nginx

The XMPP authentication state lives on the dedicated data volume at /var/lib/prosody; back it up with EBS snapshots or AWS Backup, and resize it independently of the OS disk as your deployment grows. Keep the instance patched with sudo apt-get update && sudo apt-get upgrade.

Support

cloudimg provides 24/7 technical support by email and chat: help with deployment, pointing your own domain at the instance and terminating a trusted certificate, opening the UDP media port, moderator account management, and backup planning for your authentication state. All product and company names are trademarks or registered trademarks of their respective holders; use of them does not imply any affiliation with or endorsement by them.