Jitsi Meet

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2ms (2 vCPU / 8 GiB RAM) is a good starting size.

Configure the network security group (NSG) to allow inbound 22/tcp from your management network, 443/tcp for the meeting web app and 10000/udp for video bridge media. If UDP 10000 is not open to your participants, browsers fall back to a TCP relay or fail to connect media.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Jitsi Meet by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTPS (443).

Review the dedicated data disk on the Disks tab, then select Review + create and Create. After the VM is created, add an inbound NSG rule for UDP 10000, the video bridge media port.

Step 2 - Deploy from the Azure CLI

Accept the Marketplace terms, create the VM and open ports 443 and 10000:

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:jitsi-meet-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name jitsi-meet \
  --image sac1647283583153:jitsi-meet-ubuntu-24-04:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name jitsi-meet --port 443 --priority 1001
az vm open-port --resource-group <your-rg> --name jitsi-meet --port 10000 --priority 1002

The video bridge uses UDP 10000. If az vm open-port creates a TCP-only rule, add a UDP rule for port 10000 with az network nsg rule create ... --protocol Udp --destination-port-ranges 10000.

Step 3 - Connect to your VM

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the four services are running

Check each service with systemd:

for s in prosody jicofo jitsi-videobridge2 nginx; do echo "$s=$(systemctl is-active $s)"; done

All four report active:

prosody=active jicofo=active jitsi-videobridge2=active nginx=active

Step 5 - Confirm the web app serves HTTPS

Request the meeting page from the VM itself:

curl -ks -o /dev/null -w 'GET https://127.0.0.1/ -> HTTP %{http_code}\n' https://127.0.0.1/

The page returns HTTP 200:

GET https://127.0.0.1/ -> HTTP 200

Step 6 - Retrieve your moderator credentials

Each VM generates a unique moderator account on first boot. Read it from the root-only credentials file:

sudo cat /root/jitsi-meet-credentials.txt

The file lists the meeting URL, the moderator user and a strong, unique password. It also shows the XMPP domain, which is set to your VM's public IP.

Only the moderator can open (create) a room. Once the room is open, guests join with a single link and no login.

Point the web app at your public address

On first boot, the image names the Jitsi deployment after the address Azure reports. With a Standard SKU public IP (the Azure default, and the --public-ip-sku Standard in Step 2), the current image uses the VM's private address (10.0.0.x). The meeting page at the public IP then tells your browser to connect to the private address, and nobody can join.

The current image also renames the deployment without moving the internal XMPP certificates and service accounts. As a result, the conference focus never signs in and no meeting can start, whatever the address. Check both conditions:

sudo grep -E '^jitsi.(meeting.url|xmpp.domain)=' /root/jitsi-meet-credentials.txt
sudo ls /etc/prosody/certs/

If the first line shows a 10. address, or the certificate list holds only jitsi.sac.invalid files, run the following script once. Azure's instance metadata service reports the public IP to the VM itself, so nothing leaves the VM:

PUBLIC_IP=$(curl -s -H Metadata:true 'http://169.254.169.254/metadata/loadbalancer?api-version=2020-10-01' | grep -o '"frontendIpAddress":"[^"]*"' | head -1 | cut -d'"' -f4)
H=$(sudo grep '^jitsi.xmpp.domain=' /root/jitsi-meet-credentials.txt | cut -d= -f2-); echo "public $PUBLIC_IP, xmpp domain $H"
# browser-facing address: connection URLs, certificate, credentials file
sudo sed -i -E "/^ *(bosh|websocket):/s/$H/$PUBLIC_IP/" /etc/jitsi/meet/$H-config.js
sudo sed -i "s/proxy_set_header Host \$http_host;/proxy_set_header Host $H;/" /etc/nginx/sites-available/$H.conf
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 \
  -keyout /etc/jitsi/meet/$H.key -out /etc/jitsi/meet/$H.crt \
  -subj "/CN=$PUBLIC_IP" -addext "subjectAltName=IP:$PUBLIC_IP,IP:$H"
sudo chmod 0640 /etc/jitsi/meet/$H.key
sudo sed -i -E "/^(jitsi.meeting.url=|#)/s/$H/$PUBLIC_IP/g" /root/jitsi-meet-credentials.txt
# internal XMPP: move the focus and bridge accounts, mint the certificates A="/var/lib/prosody/auth%2e${H//./%2e}"
sudo cp -a /var/lib/prosody/auth%2ejitsi%2esac%2einvalid "$A"
sudo grep -rl 'jitsi.sac.invalid' "$A" | xargs -r sudo sed -i "s/jitsi\.sac\.invalid/$H/g" for d in $H auth.$H; do
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout /var/lib/prosody/$d.key \
  -out /var/lib/prosody/$d.crt -subj "/CN=$d" -addext "subjectAltName=DNS:$d"
sudo chown prosody:prosody /var/lib/prosody/$d.key /var/lib/prosody/$d.crt
sudo ln -sf /var/lib/prosody/$d.key /etc/prosody/certs/$d.key
sudo ln -sf /var/lib/prosody/$d.crt /etc/prosody/certs/$d.crt done
sudo ln -sf /var/lib/prosody/auth.$H.crt /usr/local/share/ca-certificates/auth.$H.crt
sudo update-ca-certificates -f >/dev/null 2>&1
sudo systemctl restart prosody jicofo jitsi-videobridge2 nginx

The XMPP domain keeps its first-boot name. Participants never see this internal name, the moderator account and password are unchanged, and Step 9 still finds its configuration through jitsi.xmpp.domain.

A guest who opens a room now sees Waiting for a moderator until the moderator signs in. The certificate is still self-signed. For a DNS name, set PUBLIC_IP to the name and write DNS:$PUBLIC_IP in place of IP:$PUBLIC_IP, or install a trusted certificate with Step 11.

Step 7 - Open the meeting web app

Browse to https://<vm-public-ip>/ in any modern browser. The image ships a self-signed certificate, so accept the browser warning, or follow Step 11 to install a trusted certificate. The Jitsi Meet welcome page opens, where you name a room to start a meeting.

Enter a room name to reach the prejoin screen. There you set your display name and check your camera and microphone before joining. You can also switch the camera, microphone and audio output.

The Settings dialog (the gear icon) covers audio, video, virtual backgrounds, notifications, your profile, keyboard shortcuts and general options.

Step 8 - Start a meeting as the moderator

Secure-domain authentication is enabled, so only the moderator can open a room. Browse to https://<vm-public-ip>/<your-room-name> and, when prompted, sign in with the moderator user and password from Step 6.

Once the room is open, share the room link (https://<vm-public-ip>/<your-room-name>) with anyone you want to invite. Guests join with one click and need no account.

Step 9 - Confirm secure-domain authentication is in effect

Check the prosody configuration for the XMPP domain:

HOST=$(sudo grep '^jitsi.xmpp.domain=' /root/jitsi-meet-credentials.txt | cut -d= -f2-); sudo grep -q 'authentication = "internal_hashed"' /etc/prosody/conf.avail/${HOST}.cfg.lua && echo "secure-domain: ENABLED" || echo "secure-domain: NOT enabled"

The output looks like this:

secure-domain: ENABLED

This confirms that the main XMPP virtual host requires an authenticated moderator to open a room. A separate anonymous guest domain lets invited participants join without a login.

Step 10 - Confirm the XMPP state lives on the dedicated disk

The prosody virtual-host data and the moderator account store live on a dedicated, independently resizable Azure data disk. It is mounted at /var/lib/prosody, separate from the OS disk. Confirm the mount:

df -h /var/lib/prosody | tail -1

Step 11 - Install a trusted TLS certificate (recommended for production)

The image ships a self-signed certificate. For production, point a DNS name at the VM and install a trusted Let's Encrypt certificate.

Jitsi includes a helper script that requests and installs the certificate and reconfigures nginx for your domain. Run it interactively as root and follow the prompts. It asks for your domain and an email address:

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

When the script completes, browse to https://<your-domain>/. The browser shows a valid certificate with no warning.

Maintenance

• Restart the stack: sudo systemctl restart prosody jicofo jitsi-videobridge2 nginx
• Follow the video bridge logs: sudo journalctl -u jitsi-videobridge2 -f
• Follow the focus logs: sudo journalctl -u jicofo -f
• The OS receives unattended security updates. For larger meetings, size up the VM and add video bridge capacity. Contact support for guidance.

Support

SecureAnyCloud provides 24/7 technical support by email and chat. We help with deployment, DNS and trusted TLS certificates, secure-domain and JWT authentication, the video bridge and firewall ports, recording and live streaming, mobile apps, and tuning for larger meetings. Contact sales@secureanycloud.com.

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.

Deploy on Azure

Launch Jitsi Meet on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Prerequisites

You need 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.

Configure the security group to allow inbound 22/tcp from your management network for SSH, 80/tcp and 443/tcp for the web application, and 4443/tcp as the video bridge fallback. You must also allow 10000/udp for the WebRTC media. If UDP 10000 is not 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 and your key pair. Choose 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. For Ubuntu 24.04, the login user is ubuntu.

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

Step 3 - Confirm the services are running

The Jitsi stack runs as four systemd services. A one-shot first-boot unit adapts the web layer to this instance's address and creates the per-instance moderator password.

Confirm that 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 three things: the meeting web application answers over HTTPS, the video bridge is listening for media on UDP 10000, and the conference focus (jicofo) has connected to prosody and registered the videobridge. The last check proves that the appliance can 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 as registered.

Step 5 - Read your per-instance moderator credential

The image ships no shared or default login. On first boot, it generates a unique moderator password for this instance and writes it to a root-only file. Check 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. The entry jitsi.moderator.user is your moderator username, 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 see the password as well.

Step 6 - Prove the moderator credential from the command line

Confirm that 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. 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>/. The certificate is self-signed, so your browser shows a warning the first time. Accept it to continue.

The Jitsi Meet welcome page loads. 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.

Secure-domain authentication is enabled, so 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 opens and you are in the meeting. The toolbar offers muting, camera, screen sharing, chat, reactions, the participants panel and tile view. Share the room link with your participants. They join the 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 do not connect.

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

For production, point a DNS name at the instance and obtain a trusted Let's Encrypt certificate. Browsers then no longer show the self-signed warning. Jitsi includes a helper script 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 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

SecureAnyCloud provides 24/7 technical support by email and chat. We help with deployment, pointing your own domain at the instance, installing 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.

Deploy on AWS

Launch Jitsi Meet on AWS with 24/7 support from SecureAnyCloud.

View on Marketplace

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com