> Source: https://meetrix.io/blogs/meetrix-virtual-event-upgrades/ > Markdown copy of that page. Cite the URL above, not this file. Development # Virtual Event Platform Case Study: Scaling Jitsi Meet Across Four AWS Regions [By Avindi Nisansala](https://meetrix.io/blogs/authors/avindi-nisansala/) • October 12, 2026 • 6 min read Revised by - ![Portrait of Hiruna Kumara, Senior DevOps Engineer at Meetrix](https://meetrix.io/blog-images/assets/authors/hiruna-kumara.webp)[Hiruna Kumara](https://meetrix.io/blogs/authors/hiruna-kumara/)Senior DevOps Engineer, Meetrix This article was reviewed and refreshed for accuracy. Last reviewed October 2026. ## 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**](https://meetrix.io/) 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**](https://meetrix.io/) 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**](https://meetrix.io/) proposed this stack: - [**Amazon Web Services (AWS)**](https://aws.amazon.com/) with autoscaling - JVBs (Jitsi Videobridges) and Jibris (Jitsi's recorder) - HAProxy - [**Jitsi Meet**](https://jitsi.org/jitsi-meet/) - Coturn servers ### Four AWS Regions, HAProxy and DNS Routing Meetrix deployed EC2 instances in four AWS regions, with several [HAProxy](https://www.haproxy.org/) 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](https://meetrix.io/blogs/jitsi-meet-geolocation-routing/), and the balancing side is covered in more depth in [Jitsi Meet load balancing](https://meetrix.io/blogs/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](https://meetrix.io/blogs/jitsi-meet-auto-scaling-aws/) walks through it, and the same idea on Kubernetes is in [scaling videobridges with Octo on Kubernetes](https://meetrix.io/blogs/jitsi-kubernetes-scaling-videobridges-octo/). 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)](https://github.com/jitsi/jitsi-videobridge/blob/master/doc/relay.md), 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](https://meetrix.io/blogs/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](https://github.com/coturn/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](https://meetrix.io/blogs/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](https://meetrix.io/blogs/jitsi-meet-self-hosting-cost/). ## 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**](https://meetrix.io/) 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](https://meetrix.io/blogs/workcast-meetrix-collaboration-case-study/). [ ### Setup Jitsi Meet with Recordings - Developer Guide A comprehensive guide to setting up Jitsi Meet with recording capabilities on AWS, including detailed steps for deployment, configuration, and management. By Hiruna Kumara • Meetrix.io ](https://meetrix.io/blogs/setup-jitsi-meet-with-recordings-developer-guide/) ## 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. Meetrix Store Jitsi Meet Self-hosted video calls for 50 to 500 users [Deploy it](https://meetrix.io/store/jitsi-meet/) Meetrix Store New Deploy what this guide covers, pre-configured. - [Jitsi Meet Self-hosted video calls for 50 to 500 users](https://meetrix.io/store/jitsi-meet/) - [Coturn TURN/STUN for WebRTC, no per-minute relay fees](https://meetrix.io/store/coturn/) - [Mattermost Team chat, a self-hosted Slack alternative](https://meetrix.io/store/mattermost/) - [RustDesk Remote desktop AMI, a TeamViewer alternative](https://meetrix.io/store/rustdesk/) - [OpenVPN Encrypted remote access, no per-user fees](https://meetrix.io/store/openvpn/) - [Plane Issues, cycles and roadmaps, a Jira alternative](https://meetrix.io/store/plane/) [Browse all products](https://meetrix.io/store/)