The Client: A Virtual Event Platform
Virtual Event Site runs virtual events: exhibitor halls, keynotes, Q&A sessions and a live chat that runs through every event. It brings exhibitors, organizers and attendees together without anyone travelling, and it has been in the events business for over 20 years. Events regularly have thousands of attendees, and they expect the video to hold up when they do. Given how technical the platform is, Virtual Event Site brought in Meetrix to rework the video side and keep it confidential where clients need that.
The platform's pitch is face-to-face interaction without the venue. That only works if the video behaves like a room: no frozen tiles when a session fills up, and recordings that actually exist afterwards.
The Problem: One Region Wasn't Enough
The team at Virtual Event Site asked Meetrix to upgrade the existing system for better performance and security. They needed a stable video conferencing backend for their event clients that could take as many guests as possible without the experience falling apart.
The hard part was geography. Attendees joined from several continents, often at the same time, and a lot of sessions had to be recorded. That meant three requirements at once:
- Infrastructure in several regions, so attendees connect to a server near them
- Capacity that grows during a big event and shrinks afterwards, so the client isn't paying peak prices at 3 a.m.
- Recording for up to 50 concurrent users per region, stored somewhere safe
The Multi-Region Jitsi Meet Architecture
Meetrix proposed this stack:
- Amazon Web Services (AWS) with autoscaling
- JVBs (Jitsi Videobridges) and Jibris (Jitsi's recorder)
- HAProxy
- Jitsi Meet
- Coturn servers
Four AWS Regions, HAProxy and DNS Routing
Meetrix deployed EC2 instances in four AWS regions, with several HAProxy load balancers in each one to spread incoming traffic. DNS routing sends each Virtual Event Site user to their assigned region. It's the same pattern we describe in routing Jitsi users to the nearest videobridge, and the balancing side is covered in more depth in Jitsi Meet load balancing.
Autoscaling Videobridges with Octo
Each region got its own autoscaling group that adds or removes JVB instances as load changes, driven by scaling policies Meetrix configured for the client's traffic. On top of that, Octo was set up so that one conference can span bridges in different regions. Participants connect to the JVB closest to them, and the bridges forward media between each other. That spreads the conference traffic and keeps each attendee's media path short.
If you want to build the autoscaling part yourself, our guide to autoscaling Jitsi Meet on AWS walks through it, and the same idea on Kubernetes is in scaling videobridges with Octo on Kubernetes.
Octo is called relays in current Jitsi
This project ran jitsi-videobridge 2.1, where cross-bridge conferences used Octo. Current releases replace it with relays (secure Octo), which encrypt bridge-to-bridge traffic with DTLS/SRTP, so the bridges no longer need a private network between them. The architecture is the same; the config is different.
Recording: Autoscaling Jibri to S3
Jibri records one meeting at a time, and each one needs a whole instance to do it. Sizing a fixed pool for the busiest hour means paying for idle recorders the rest of the day. So the Jibri instances were also put in an autoscaling group.
A few Jibris are always warm and ready to record. When those start recording, new instances are launched so there's always spare capacity. When the number of idle instances goes above a limit Meetrix set, the group scales back down. With a requirement of up to 50 concurrent users per region able to record, that difference between peak and off-peak capacity is where most of the cost saving comes from. Finished recordings upload automatically to an AWS S3 bucket. For how Jibri captures a meeting in the first place, see how Jibri recording works.
Coturn for Attendees Behind Firewalls
With thousands of attendees, some of them will always be behind a corporate firewall that blocks the ports Jitsi uses for media. Without help, those people can't send or receive audio and video with the JVBs at all. A Coturn TURN server relays their traffic over ports the firewall allows, so they still get a working meeting. Our guide to setting up a TURN server for Jitsi Meet covers the configuration.
Integration with the Client's Scheduling System
Meetrix also integrated Virtual Event Site with the meeting management systems the client already used and synchronized meeting schedules between them. Organizers keep working in the tools they know, and meetings appear on the video side without anyone copying them over by hand.
Component Versions
These are the versions Meetrix deployed for this project (2023):
| Component | Version |
|---|---|
| Jitsi-meet | 2.0.7001 |
| Prosody | 0.11.4-1 |
| Jicofo | 1.0-862-1 |
| Jitsi-videobridge2 | 2.1-634-gff8609ad-1 |
| Haproxy | 2.3 |
| Jibri | 8.0-114-g20e233e-1 |
Customer Review
"The Meetrix team has been an invaluable partner in helping us build a stable video conferencing system for our virtual event clients. Their responsiveness is second to none, and they have helped us design a system to maximize guest count while ensuring a great user experience. It's awesome to have a partner who can provide a full stack solution with great customer service."
Results
Meetrix helped Virtual Event Site fix its infrastructure and load-balancing problems, and the platform kept hosting large video events without the stack becoming the bottleneck.
Cost was part of the brief too. After the architecture was settled, Meetrix worked out an optimal cost for the setup that kept Virtual Event Site within budget. That estimate included the recurring AWS bill and ongoing cloud usage, since the client pays that bill directly for as long as they run the system. For a rough sense of what self-hosted Jitsi costs at smaller scale, see how much it costs to self-host Jitsi Meet on AWS.
Why Jitsi Meet Fit This Project
Jitsi Meet is very configurable and easy to integrate with other software. That's why Meetrix used it here, and why it suits most companies that want WebRTC help without being locked into a vendor's roadmap. Because it's open source and actively developed, Meetrix can fit Jitsi Meet into existing systems for clients around the world.
Another example of the same approach, in webinars rather than events, is the Workcast case study.
Frequently Asked Questions
Can Jitsi Meet run a virtual event platform with thousands of attendees?
Yes, if the bridges scale out. One conference is capped by what a single videobridge can carry, so large events spread participants over many JVBs, here with autoscaling groups in four AWS regions and Octo linking bridges so one meeting can span them.
What is Jitsi Octo?
Octo lets one Jitsi conference use several videobridges at once, so participants in different regions connect to the bridge nearest them while still seeing each other. Current Jitsi releases call it relays (secure Octo), which encrypt bridge-to-bridge traffic with DTLS/SRTP.
Why autoscale Jibri instead of running a fixed recording pool?
Each Jibri records one meeting at a time and needs a full instance to do it. A fixed pool sized for peak demand sits idle most of the day. Autoscaling keeps a few warm instances ready and adds more only while recordings are running.
Why does a large Jitsi deployment need a TURN server?
Some attendees sit behind corporate firewalls that block the UDP ports Jitsi uses for media. A Coturn server relays their audio and video over TCP or TLS on port 443, so they can still join instead of seeing a frozen screen.
How long does a multi-region Jitsi build like this take?
It depends on how much already exists, but the components are standard: AWS autoscaling groups, HAProxy, Octo, Jibri, Coturn. The slow part is usually testing load and failover per region and integrating the client's own scheduling system, not installing Jitsi.