From Bare-Metal Tinkering to Elastic Video Infrastructure: How ayedo Made Streambase Scalable for Large Live Events

Video is the crown jewel of infrastructure.

While many SaaS applications are relatively forgiving, video is ruthless: A small configuration error immediately manifests as stuttering. A CPU spike causes audio dropouts. An unpredictable surge in demand doesn’t result in “a bit slower,” but in a stream cut-off—live, in front of an audience.

Streambase Media operates a video platform for businesses: Live streaming of corporate events, hybrid meetings, and an on-demand library in one solution—as a European alternative to Zoom Events and Vimeo Enterprise. Around 120 corporate clients use the platform, from town halls with 50 participants to product launches with several thousand viewers.

The product was in the market. The operation was the problem.

Initial Situation: Functional Architecture—but Only as Long as the Load is Predictable

Streambase initially relied on self-hosted Jitsi instances for video conferencing and its own RTMP ingest setup for live streaming. This ran on dedicated bare-metal servers at a data center provider. For the first customers, this was sufficient—because usage was moderate and the load predictable.

As the business grew, this setup became an operational nightmare because video workloads have a pattern that classic server architectures poorly accommodate: extremely volatile load.

A regular meeting on a Tuesday uses few resources. An announced product launch with 3,000 viewers is a completely different system behavior. And thirty minutes after the event, the resource demand is almost back to zero.

Bare metal can handle this. But only if you pay for the “worst case” permanently.

Where It Squeaked: Scaling, Resilience, Distribution, and Sovereignty

Scaling was the first bottleneck. Jitsi videobridges are CPU and RAM hungry; in larger meetings, a single process quickly occupies multiple cores and double-digit GB of RAM. Adding new capacity meant: order servers, install OS, configure Jitsi, adjust DNS. Two to five business days lead time—unusable for short-term large-scale deployments.

Even more dangerous was the fragility of the streaming pipeline. The RTMP ingest ran on a single server. If it failed, the stream was gone. No failover, no automatic restart, no self-healing. This is exactly what happened during a CEO town hall of a DAX corporation: after 20 minutes, the stream broke off. The contract was not renewed.

Customers also demanded multi-destination streaming. The platform should simultaneously broadcast a stream on its own platform, YouTube, LinkedIn Live, and internal intranet pages. The existing architecture could only send a stream to one destination. Customers had to use OBS and their own RTMP setup—a dealbreaker for non-technical users.

Post-processing was also manual labor. Recordings were stored as raw files on the server. Transcoding into multiple quality levels, thumbnail generation, and uploading to the on-demand library were done manually, often days later. Customers expected minutes.

And finally: quality and isolation. Jitsi worked well up to about 20 participants. Beyond that, the quality noticeably decreased. At the same time, all customers shared the same bridges and streaming servers—an intensive event could affect other customers. Guaranteed service quality was thus impossible.

Simultaneously, a sovereignty problem arose. Parts of the transcoding ran through a US-based cloud service. Customers from the public sector and regulated industries wanted a fully European solution without US dependencies—Streambase could not consistently guarantee this.

The turning point was a major deal: An insurance company wanted to use Streambase for quarterly investor calls—with SLA 99.95% during the event and a maximum of 3 seconds latency, including recording and multi-language support. The engineering team knew: With the existing setup, this was not feasible.

ayedo’s Approach: Video as a Platform Workload—Elastic, Isolated, Automated

We didn’t start with the goal of delivering “more servers.” That would have only made the worst-case operation more expensive.

The goal was a Kubernetes based video infrastructure that covers the entire lifecycle:

• Operate real-time communication (WebRTC) scalable
• Make live ingest and distribution resilient and multi-destination capable
• Automate recording and transcoding and scale horizontally
• Cleanly isolate customers to guarantee service quality
• All on European infrastructure, without US dependencies

LiveKit Instead of Jitsi as the Primary WebRTC Engine—Because Scaling Decides Here

The central component was switching the WebRTC foundation.

Jitsi can handle meetings—but the architecture is not optimized for large-scale, dynamic load profiles. LiveKit, on the other hand, is fundamentally designed to run as a scalable service. Each LiveKit server runs as a pod and can be horizontally scaled. A base capacity is sufficient for small meetings. For large hybrid events, additional pods are automatically spun up.

LiveKit uses SFU mechanisms, simulcast, and dynacast: Clients automatically receive the appropriate quality for bandwidth and device. This is crucial in an enterprise context because the viewer environment is heterogeneous: VPNs, mobile networks, corporate firewalls.

For large events with thousands of passive viewers, WebRTC is not always the most efficient delivery format. Therefore, the WebRTC stream is converted into an HLS egress for these scenarios, which is better suited for mass distribution—without customers having to switch between two systems.

Jitsi remained as an option—but as a self-service variant for customers who consciously want a classic meeting solution without deeper platform integration. The difference: Jitsi now also runs on Kubernetes and can be operated in customer isolation.

Multi-Destination Streaming as a Product Feature—with Restreamer

Multi-destination was not a “nice-to-have,” but a selling point. For this, we integrated Restreamer (datarhei): An incoming stream is automatically forwarded to any number of destinations in parallel—platform, YouTube Live, LinkedIn Live, intranet player, partner CDNs.

The key was not just the technical capability but the usability. Customers configure destinations via a UI, without RTMP know-how and without additional tools. And Restreamer runs as a deployment with autoscaling, based on active streams and output destinations.

This turns multi-destination from “customer must operate OBS” to “platform can do it.”

Automated Video Processing Pipeline: From Raw File to On-Demand in Minutes

Recordings are automatically transferred to a processing pipeline after the event ends. Transcoding into multiple quality levels, thumbnail generation, and optional subtitles are part of a standardized job system that scales horizontally.

This is a typical Kubernetes use case: Many similar jobs, parallelizable, with clear resource allocation. During peaks—such as after a big event day with many parallel recordings—additional transcoding workers are automatically spun up. The pipeline then scales back down.

This means recordings are no longer manually “processed” days later but are typically available within minutes.

Autoscaling on Pod and Node Level: Resources Only When Needed

Video platforms often fail due to an economic problem: They constantly pay for the worst case to handle a peak once a quarter.

With horizontal pod autoscaling, the platform dynamically scales the services (LiveKit, processing workers, Restreamer). Additionally, node autoscaling ensures that the cluster capacity follows when pods need more resources.

Before announced large events, capacity can be proactively increased; after the event, it automatically scales back. This is the core of the economic transformation: moving away from permanent over-provisioning to elastic consumption.

Tenant Isolation: Service Quality Becomes Guaranteeable

An underestimated part of video is isolation. A customer with a large event must not affect the meeting quality of other customers.

Each customer runs in their own namespace with resource quotas and network policies. Dedicated node pools can be provided for enterprise customers, offering guaranteed resources. This not only creates technical stability but also an SLA-capable operational model.

Observability: Video-Specific Metrics Instead of “Server is Alive”

With VictoriaMetrics, VictoriaLogs, Grafana, and Tempo, we have built an observability stack that reflects video reality: bitrate, packet loss, WebRTC connection quality, participant numbers, egress latencies, queue lengths in transcoding, error rates per stream.

This is crucial because video problems are often not “down” but “degraded.” Those who only measure uptime recognize problems only when viewers complain. Streambase can now detect quality drops and react before they become visible in the event.

GitOps and Identity: Operation Becomes Reproducible, Access Becomes Controllable

ArgoCD manages infrastructure and configuration via GitOps. Changes to customer namespaces, policies, and platform services are versioned, reviewable, and traceable.

Authentik provides SSO for platform administration, customer access, and integration with customer directories. For enterprise customers, this is not comfort but a prerequisite.

Result: Large Events Become Reliable—and Costs Decrease

With the new platform, Streambase was able to meet the insurance company’s requirements for the first time. Quarterly investor calls run stably with live streaming, recording, and multi-language support—with under two seconds latency and a measured availability of 99.98% during the events.

Scaling no longer happens in business days by ordering servers but in minutes through autoscaling. Unexpected load spikes are automatically absorbed. After events, no empty servers run for weeks.

Multi-destination streaming has become a product feature. Recordings are available in the library within five to fifteen minutes, not days later.

Infrastructure costs have decreased by over 50% because capacity is no longer permanently dimensioned for the worst case.

Customer isolation ensures that one customer’s event does not affect the quality of other customers. SLAs thus become serious.

And the sovereignty requirement is met: Ingest, processing, storage, and distribution run entirely on European infrastructure, without US cloud dependency.

Why This Approach Works

Video is the domain of unpredictable load. This is precisely why a platform architecture that reacts elastically and automatically is the decisive competitive advantage.

LiveKit provides the scalable WebRTC foundation. Kubernetes provides scheduling, autoscaling, and self-healing. GitOps makes operation reproducible. Observability makes quality controllable. Tenant isolation makes SLAs reliable. And self-hosting on European infrastructure makes the whole thing marketable in regulated industries.

Call to Action

If you operate video or streaming workloads and are still using dedicated servers, manual provisioning