Jitsi Meet Terraform Scripts for JVB and Jibri Autoscaling

Building a Jitsi cluster by hand works exactly once. The second time, for staging or a new region, you find out which of the forty steps nobody wrote down. Terraform fixes that by describing the whole AWS side of the deployment as code: apply it, and the same cluster comes up every time.

This is how we lay out Terraform for Jitsi Meet with autoscaling videobridges (JVB) and Jibri recorders. We sell the finished scripts, but the structure below is useful whether you buy them or write your own.

What Terraform does for a Jitsi deployment

Terraform is HashiCorp's infrastructure as code tool. You declare resources in HCL files, Terraform works out what has to be created or changed, shows you the plan, and applies it. It keeps a state file so the next run knows what already exists.

For Jitsi, that means:

• You see every change before it happens with terraform plan, instead of finding out after you clicked the wrong thing in the console.
• Staging is the same code with different variables.
• Growing from 250 to 1,000 users is a code change and one apply, not a rebuild.

What the scripts build

Split it into modules along those lines: network, meet, jvb, jibri. Then each deployment is a short root file that sets sizes and domain names.

module "jvb" {
  source        = "./modules/jvb"
  ami_id        = var.jvb_ami
  instance_type = "c6i.xlarge"
  min_size      = 1
  max_size      = 6
  shard_domain  = module.meet.xmpp_domain
  subnet_ids    = module.network.public_subnet_ids
}

JVB autoscaling

A new videobridge is only useful once Jicofo knows about it. Each bridge logs in to Prosody and joins the bridge "brewery" room; Jicofo watches that room and starts sending conferences to any bridge that appears. So the launch template has one job: boot a server that already has Jitsi Videobridge installed, with the shard's XMPP address and password filled in.

Two ways to get there:

• Baked image: build an AMI with the bridge installed (Packer, or Ansible against a temporary instance), and pass only the shard details through user data. Boots in about a minute. This is what we use.
• Install at boot: user data runs the apt install on a plain Ubuntu image. Simpler, but a slow or failed package mirror now breaks your scaling during your busiest hour.

Scaling on CPU works as a start, but bridges are usually network-bound, and CPU lags behind real load. Publishing the bridge's own stress_level or participant count as a CloudWatch metric gives better signals; our guide to monitoring Jitsi Videobridge with CloudWatch shows how.

Jibri autoscaling

Jibri scales differently from bridges, because one Jibri records one meeting. Ten meetings recording at once need ten idle Jibri instances waiting. So the target is not CPU at all, it is "how many Jibris are free right now". Each Jibri reports whether it is busy; count the idle ones and keep that number above a small buffer, such as two.

Recordings should leave the instance as soon as they finish. Give the Jibri instance role write access to one S3 bucket and upload from Jibri's finalize script, so a scale-in never deletes an unsaved file.

Occasional large meetings at a low cost

The most common question we get about this setup, nearly word for word: "I need Jitsi for occasional large meetings. How do I make it autoscale when participants spike and stay cheap the rest of the time?"

1. Keep the always-on part small. The Meet server doesn't carry media, so a modest instance handles a lot of signalling.
2. Minimum of one bridge. Enough for everyday calls. Everything above that is scaled capacity you only pay for while it runs.
3. Pre-scale for known events. Autoscaling reacts in minutes; a 500-person all-hands arrives in seconds. A scheduled action that raises the minimum an hour before the event is cheap insurance.
4. Turn it off at night. If nobody meets outside office hours, a scheduled shutdown saves more than any instance tuning. See cutting Jitsi costs with scheduled shutdown.

Before a big event, raise your EC2 vCPU quota; new AWS accounts often can't launch more than a handful of instances. Here is how to request more.

Ready-made Jitsi Terraform scripts

Writing and testing all of this takes weeks, mostly spent on the scale-in and registration edge cases. Our Jitsi infrastructure as code scripts cover single-shard setups from 50 to 500 users and auto-scaling multi-shard clusters from 1,000 to 2,000, with or without Jibri recording, for your own AWS account. If you would rather not run Terraform at all, we can host and set up Jitsi on AWS for you, and the benefits of Ansible automation explains where configuration management fits alongside Terraform.

Related Articles

Jitsi Scaling on AWS: Auto Scaling Videobridges and Jibri

Jitsi scaling on AWS: videobridge Auto Scaling groups driven by bridge stress, graceful scale-in with lifecycle hooks, a Jibri pool, and what to monitor.

By Hiruna Kumara • Meetrix.io

Jitsi Meet Horizontal Scaling: Load Balancing Multiple Videobridges

Jitsi Meet horizontal scaling: add multiple videobridges to a shard with jvb.conf, tune Jicofo bridge selection, and route rooms across shards with HAProxy.

By Hiruna Kumara • Meetrix.io

How Much Does It Cost to Self-Host Jitsi Meet on AWS?

Jitsi Meet is free, but Jitsi hosting on AWS isn't. Real Jitsi Meet pricing: EC2 instances, bandwidth, S3 storage, and the Meetrix AMI, broken down by month.

By Binuka Ranatunga • Meetrix.io