How to run Jitsi Meet on AWS

AWS is a good home for Jitsi: you choose the region closest to your users, you pay only for the instance and traffic, and the data never leaves your own account. The catch is the amount of AWS plumbing between “launch an instance” and “a working meeting”.

This guide covers the manual path. Our platform automates exactly these steps with Terraform and Ansible in your own AWS account, in 10 to 20 minutes.

1. Choose a region and instance

Pick the region nearest to most participants. Latency matters more for conversation than for streaming.

Rounded on-demand compute as of August 2026. Storage, data transfer and S3 are extra.

Two AWS details worth knowing:

• T3 unlimited mode. T3 instances launch in unlimited mode, so sustained high CPU is billed as surplus credits instead of throttled. Fine for bursts, costly for a server that records all day.
• Data transfer out. Video leaving AWS is billed per GB. For busy servers it can exceed the instance cost.

2. Launch the instance

• AMI: Ubuntu Server 24.04 LTS (64-bit x86).
• Storage: 20 GB gp3 at least, more if recordings stay on disk before upload.
• Key pair: create or reuse one for SSH.

3. Security group rules

If you later add a separate recording server, allow 5222/tcp on the Jitsi server only from the recorder’s security group, never from the internet. Referencing the security group rather than an IP keeps it correct when the recorder is replaced.

4. Attach an Elastic IP

An instance’s default public IP changes when it stops and starts. Allocate an Elastic IP and associate it with the instance, so DNS and the videobridge’s advertised address stay valid.

5. Point DNS at it

Create an A record, for example meet.example.com, pointing at the Elastic IP. Wait until dig +short meet.example.com returns it before the first start, or Let’s Encrypt will fail and you will hit its rate limit on retries.

6. Install Jitsi

SSH in and follow the Docker install guide. On EC2 the videobridge usually discovers its public IP through STUN. If three-person calls fail, set JVB_ADVERTISE_IPS to the Elastic IP in .env and restart the stack.

7. Recording on AWS: the kernel trap

Jibri captures meeting audio through the ALSA loopback module, snd-aloop. Ubuntu’s AWS-optimized kernel (linux-aws) does not include it, and Jibri fails in confusing ways until it is fixed.

Check first:

sudo modprobe -n snd-aloop && echo "available" || echo "missing"

If it is missing, install the generic kernel, make it the default in GRUB, and reboot once:

sudo apt-get install -y linux-generic
# Set GRUB_DEFAULT to the generic kernel entry, then:
sudo update-grub
sudo reboot

After the reboot, load the module and persist it:

echo "options snd-aloop enable=1,1,1 index=0,1,2 pcm_substreams=8" | sudo tee /etc/modprobe.d/jibri-aloop.conf
sudo modprobe snd-aloop
echo snd-aloop | sudo tee /etc/modules-load.d/snd-aloop.conf

The full recording setup, including S3 upload with an IAM role, is in Jitsi recording with Jibri.

8. Store recordings in S3

Do not put AWS access keys on the server. Create an IAM role that allows s3:PutObject on one bucket, attach it to the instance as an instance profile, and let the AWS CLI on the server pick up temporary credentials automatically.

9. Keep it running

• Enable automatic security updates (unattended-upgrades).
• Snapshot the root volume before upgrades.
• Set a CloudWatch alarm on CPU and on NetworkOut.

The one-click alternative

Everything above, including the instance, security groups, Elastic IP, SSL, your domain, the snd-aloop kernel fix and S3 recording with an IAM role, is what our platform sets up in your own AWS account. You keep full ownership of the server and pay AWS directly.