Organizations building live streaming platforms often rely on managed cloud services for scalability and operational simplicity. However, not every business model fits within the acceptable use policies of managed providers. In this case study, we explain how we built a self-hosted LiveKit on AWS architecture that delivered complete infrastructure ownership, dynamic scaling, and support for more than 2,600 concurrent subscribers.
Live streaming has become a must-have feature for many digital platforms. Managed cloud streaming services are fine for most businesses, but are not always a good fit. Some applications require complete control over the infrastructure, custom user experiences, and deployment flexibility that managed platforms simply do not provide.
In this case study, we share how we designed and built a self-hosted live streaming platform on AWS using LiveKit. The solution was created for a client who needed full ownership of their streaming infrastructure, dynamic cloud scaling, and the ability to support more than 2,600 concurrent subscribers without depending on third-party managed streaming services.
Rather than only discussing technology choices, this piece will focus on the architectural decisions, operational challenges, and lessons learned as we built a scalable real-time streaming platform from scratch.
What Is LiveKit?
LiveKit is an open source WebRTC platform to build real-time audio and video applications. Unlike traditional video conferencing platforms, LiveKit is built around the media layer and allows developers to build completely custom user interfaces with its SDKs.
Essentially, LiveKit is built on a Selective Forwarding Unit (SFU) architecture. Instead of all participants sending media streams to all other participants, the publisher sends just one stream to the LiveKit server. The server then efficiently forwards that stream to all viewers that are connected.
This architecture makes LiveKit a perfect platform for applications that need support for large numbers of concurrent viewers with low latency, predictable performance.
For readers interested in the platform itself, please check out the official LiveKit Documentation, which provides detailed information on the platform architecture, SDKs, deployment options, and media capabilities.
The Business Challenge
Every architecture decision starts with understanding the business requirement.
Our client operates an adult content platform with live streaming capabilities. While technically similar to many other streaming applications, the nature of the content introduced a significant infrastructure challenge.
Most managed live streaming providers—including cloud-native media services and third-party SaaS platforms—enforce acceptable use policies that restrict or prohibit adult content. Violating these policies can result in suspended services, removed content, or even permanent account termination.
For this client, depending on a managed streaming platform wasn’t simply a technical limitation—it represented an unacceptable business risk.
They needed complete ownership of their infrastructure, allowing them to control deployment, operations, moderation policies, and scaling without relying on third-party platform decisions.
Why Managed Live Streaming Services Were Not an Option
Managed streaming platforms simplify deployment and operations, but they also introduce limitations that aren’t suitable for every business.
In this project, several managed solutions were evaluated before being ruled out.
- Content policies restricted the client’s business model.
- Infrastructure ownership remained with the service provider.
- Customization options were limited.
- Long-term operational flexibility depended on third-party policies.
The requirement was clear: build a platform where the client owned every layer of the infrastructure—from compute resources and networking to routing, recording, and scaling.
This naturally led us toward an open-source, self-hosted architecture running entirely on AWS.
Our First Approach: Evaluating Jitsi
Like many engineering teams, our first instinct was to evaluate Jitsi.
Jitsi is a mature, open-source video conferencing platform with a strong community and straightforward deployment process. It appeared to satisfy many of the project’s initial technical requirements.
However, after building a proof of concept, two significant limitations became apparent.
1. Limited User Interface Flexibility
The client already had a well-defined product experience with custom branding, workflows, and user interactions. Jitsi’s bundled interface made deep customization difficult. Even relatively small interface changes required modifying parts of the framework that weren’t designed for extensive customization.
Instead of accelerating development, the platform began restricting it.
2. Scalability for Large Live Audiences
The second challenge was scalability.
Jitsi performs well for video meetings and smaller participant groups. The client’s roadmap, however, included significantly larger live streaming audiences with thousands of concurrent subscribers.
We needed an architecture specifically designed for large-scale media distribution rather than traditional video conferencing.
That search ultimately led us to LiveKit.
Why We Chose LiveKit
After evaluating multiple open-source options, LiveKit stood out as the best fit for the client’s requirements.
Unlike traditional video conferencing platforms, LiveKit focuses entirely on media transport. It doesn’t impose a predefined user interface or application workflow. Instead, it provides a powerful WebRTC media layer that developers can integrate into their own applications using SDKs.
This gave us complete freedom to build a user experience that matched the client’s product instead of adapting the product to fit the platform.
Equally important, LiveKit is fully open source. By deploying it on infrastructure owned by the client, we eliminated dependence on third-party streaming providers and their acceptable use policies.
The platform also uses an efficient Selective Forwarding Unit (SFU) architecture, allowing one published media stream to be distributed efficiently to thousands of viewers. This made it far more suitable for large-scale live streaming than a traditional mesh-based architecture.
Designing a Self-Hosted LiveKit Platform on AWS
Choosing LiveKit solved the media layer challenge. The next question was how to deploy it in a way that remained scalable, operationally simple, and cost-effective.
Instead of maintaining a fixed pool of streaming servers, we designed the platform around dynamic infrastructure provisioning.
Every live streaming session receives its own dedicated LiveKit server running on Amazon EC2. Infrastructure is created only when a host starts broadcasting and is automatically terminated once the session ends.
This approach provides several advantages:
- Infrastructure costs are directly tied to actual usage.
- Every livestream is isolated from other sessions.
- Scaling becomes predictable as new rooms simply launch additional EC2 instances.
- Operational overhead is minimized through full automation.
From the client’s perspective, the process is completely seamless. A creator clicks Start Live, and the required infrastructure is provisioned automatically. When the livestream ends, compute resources are released without manual intervention.
Amazon EC2 provides the flexibility required for this deployment model. More information about EC2 can be found in the official Amazon EC2 documentation.
Dynamic EC2 Provisioning Through .NET Automation
Automation was a critical design goal from the beginning.
Rather than relying on infrastructure teams to provision servers manually, the entire lifecycle of each LiveKit instance is managed programmatically through the application’s .NET backend.
The workflow follows a simple sequence:
- A host initiates a live session.
- The .NET backend provisions a new EC2 instance from a pre-configured LiveKit AMI.
- The instance is registered with the routing layer.
- Viewers are automatically directed to the correct media server.
- When the livestream ends, the EC2 instance is terminated automatically.
Because infrastructure exists only while a session is active, cloud spending scales directly with platform usage rather than idle capacity.
This approach also aligns closely with modern FinOps principles by eliminating unnecessary runtime and ensuring compute resources are consumed only when they generate business value.
For readers interested in cloud cost optimization strategies, you may also find our article on FinOps in Practice: Cloud Cost Optimization Across AWS and Azure useful.
Building an Intelligent Routing Layer
Provisioning streaming servers dynamically introduced another architectural challenge.
How should incoming viewers be routed to the correct LiveKit instance?
Since every livestream runs on its own EC2 server, the routing layer needed to identify the correct destination automatically without requiring users to know server addresses or infrastructure details.
To solve this, we designed a routing architecture based on three components:
- OpenResty reverse proxy
- Redis for room-to-server mapping
- Wildcard DNS entries for every livestream
Each livestream receives its own subdomain under a wildcard DNS configuration. When a viewer accesses the livestream URL, OpenResty extracts the room identifier from the hostname.
Lua scripts running inside OpenResty then query Redis to identify the EC2 instance currently hosting that room. Once the mapping is found, the WebSocket connection is forwarded to the appropriate LiveKit server.
To minimize lookup latency under heavy traffic, frequently accessed mappings are cached locally within the proxy before Redis is queried again.
From the viewer’s perspective, everything appears instantaneous. They simply open the livestream link, while the routing infrastructure performs all server discovery behind the scenes.
For developers interested in these technologies, the official documentation is available for OpenResty and Redis.
Recording Live Streams with LiveKit Egress and Amazon S3
Live streaming was only one part of the client’s requirements. Content creators also needed the option to record their live sessions for future playback or distribution.
Rather than recording directly on the LiveKit media server, we chose to separate recording from the live streaming infrastructure.
Whenever a creator enables recording, the platform automatically provisions a dedicated LiveKit Egress instance on Amazon EC2. This instance joins the livestream as another participant, captures the session, and uploads the final recording directly to Amazon S3.
Keeping recording isolated from the primary media server provides several operational benefits:
- Recording workloads never compete with live streaming traffic.
- Media servers remain focused on delivering low-latency video.
- Recording failures do not affect the live viewing experience.
- Recording resources are created only when required.
Completed recordings are stored securely in Amazon S3, providing highly durable storage that integrates well with downstream content workflows.
For more information, refer to the official Amazon S3 documentation.
Scaling Beyond 2,600 Concurrent Subscribers
One of the most important objectives of this project was validating whether the platform could support a growing subscriber base without sacrificing performance.
Extensive load testing demonstrated stable operation with more than 2,600 concurrent subscribers across the platform.
Interestingly, the first scaling limitation wasn’t LiveKit itself.
The bottleneck appeared at the operating system level.
As connection volumes increased, the OpenResty proxy server began approaching Ubuntu’s default TCP backlog limits. This affected the number of incoming WebSocket connection requests that could be queued simultaneously.
After analyzing system behavior, we tuned Linux kernel networking parameters, including:
net.core.somaxconnnet.ipv4.tcp_max_syn_backlog
Increasing these limits significantly improved the proxy’s ability to handle large bursts of concurrent WebSocket connections.
This reinforced an important lesson:
Building a scalable self-hosted live streaming platform on AWS isn’t only about selecting the right application framework. Network configuration, operating system tuning, and infrastructure optimization play an equally important role.
Planning for Future Growth
The architecture was intentionally designed to support future expansion rather than forcing a complete redesign as the platform grows.
The current deployment model performs extremely well for livestreams serving hundreds or even several thousand concurrent viewers.
However, if individual livestreams eventually reach audiences of 5,000 to 7,000 or more concurrent viewers, a different delivery strategy becomes more appropriate.
Instead of distributing every stream exclusively through WebRTC, the platform can evolve toward HTTP Live Streaming (HLS) delivered through a Content Delivery Network (CDN).
In this architecture:
- LiveKit Egress generates HLS output.
- Media segments are stored in cloud storage.
- A CDN distributes content globally.
- Viewer traffic shifts away from the media servers.
This introduces a few seconds of playback latency, but dramatically improves scalability for very large audiences.
The key advantage is that the existing architecture does not need to be replaced.
The LiveKit deployment, routing layer, automation, and cloud infrastructure remain intact while the delivery layer evolves to support larger traffic volumes.
Lessons Learned from Building LiveKit on AWS
Every engineering project teaches something beyond the technology itself. This implementation reinforced several practical lessons that apply to many cloud-native applications.
- Choose infrastructure based on business requirements—not convenience.
- Self-hosting provides flexibility when managed services introduce business constraints.
- Dynamic infrastructure provisioning keeps cloud costs aligned with actual platform usage.
- Separating routing, media delivery, and recording improves scalability and operational resilience.
- Operating system tuning becomes increasingly important as concurrent traffic grows.
- Design today’s architecture with tomorrow’s scalability in mind.
Many of these infrastructure decisions also align with modern cloud engineering and FinOps practices, where infrastructure is provisioned only when needed and cloud resources are continuously optimized for cost and performance.
If you’re interested in cloud optimization strategies, you can also explore our related article on Hybrid Cloud Cost Optimization, where we explain how architectural decisions helped reduce database costs without modifying an existing AWS EC2 application.
Conclusion
Every cloud architecture project begins with technology, but successful platforms are built around business requirements.
In this case, the objective wasn’t simply to build another live streaming application. The client needed complete infrastructure ownership, unrestricted deployment flexibility, deep UI customization, predictable operating costs, and the ability to scale as their subscriber base continued to grow.
By choosing a self-hosted LiveKit deployment on AWS, we were able to design an architecture that met those requirements without relying on managed streaming platforms or compromising the product experience.
The solution combines dynamic Amazon EC2 provisioning, intelligent routing through OpenResty and Redis, isolated recording using LiveKit Egress, and durable storage with Amazon S3. Together, these components create a scalable platform capable of supporting thousands of concurrent subscribers while keeping infrastructure costs aligned with actual usage.
Perhaps the biggest lesson from this project is that cloud architecture should evolve with business growth. Rather than building an infrastructure that eventually needs replacing, we designed a foundation that can naturally extend toward CDN-backed HLS delivery as audience sizes continue to increase.
For organizations building custom live streaming platforms, choosing the right architecture early can simplify future scaling, reduce operational complexity, and provide long-term flexibility that managed services often cannot offer.
Frequently Asked Questions
What is LiveKit?
LiveKit is an open-source WebRTC platform that enables developers to build self-hosted real-time audio and video applications. It uses a Selective Forwarding Unit (SFU) architecture to efficiently distribute media streams to multiple participants.
Why was LiveKit chosen over Jitsi?
While Jitsi is an excellent open-source conferencing platform, LiveKit offered greater flexibility for custom UI development, better separation between the frontend and media layer, and an architecture better suited for large-scale live streaming applications.
Why build a self-hosted live streaming platform?
Self-hosting provides complete control over infrastructure, security, deployment, customization, and operational policies. It also removes dependence on third-party streaming providers and their acceptable use restrictions.
Can LiveKit run on AWS?
Yes. LiveKit can be deployed on Amazon EC2, Kubernetes, or other cloud infrastructure. In this project, individual LiveKit instances were provisioned dynamically on Amazon EC2 for every live streaming session.
How were livestream recordings stored?
A dedicated LiveKit Egress instance joined the livestream, recorded the session, and uploaded the completed recording directly to Amazon S3. This kept recording workloads separate from the media servers.
How many concurrent subscribers did the platform support?
Load testing demonstrated stable operation with more than 2,600 concurrent subscribers. The primary optimization required at higher traffic levels involved tuning Linux kernel networking parameters rather than modifying LiveKit itself.
How can the platform scale beyond 5,000 concurrent viewers?
The architecture can evolve by introducing LiveKit Egress-generated HLS streams distributed through a Content Delivery Network (CDN). This approach supports significantly larger audiences while maintaining the existing platform architecture.
Related Articles
- FinOps in Practice: Cloud Cost Optimization Across AWS and Azure
- Hybrid Cloud Cost Optimization: Reducing Database Costs Without Changing an AWS EC2 Application
References
- LiveKit Documentation
- WebRTC Official Documentation
- Amazon EC2 Documentation
- Amazon S3 Documentation
- OpenResty
- Redis Documentation
About Quantasis
At Quantasis, we design and build secure, scalable cloud-native platforms for organizations that require complete control over their software and infrastructure. Our expertise spans cloud architecture, custom software development, AI-powered applications, DevOps, FinOps, healthcare technology, and enterprise SaaS platforms. We help businesses transform complex technical challenges into reliable, high-performance digital solutions that are built to scale.
