January 9, 2026
Comments Off on Reduce WebRTC Infrastructure Costs with a Hybrid P2P Architecture

Reducing WebRTC infrastructure costs is critical as your application scales. While WebRTC technology is open-source and free to use, the infrastructure required to run it in production is often a major operational expense. (How Much Does It Really Cost to Build and Run a WebRTC Application?) Success in a communication app brings higher usage and without optimization, this traffic linearly increases your cloud bills.

The largest variable cost in cloud hosting for real-time video is Data Transfer (egress). When video calls route through a Selective Forwarding Unit (SFU) media server, you pay for every byte that leaves that server. However, by leveraging Peer-to-Peer (P2P) architecture for certain scenarios, you can eliminate egress costs and decouple user growth from infrastructure costs.

Here is how using a hybrid approach, like the one available in Jitsi open source video conferencing, can significantly lower your operational expenses.

How Hybrid P2P Architecture Reduces Costs

The key is using a hybrid P2P approach that intelligently routes calls based on participant count. 

For 1-on-1 calls, video streams flow directly between users peer-to-peer, completely bypassing your servers and eliminating egress costs. 

When a third participant joins, the system automatically switches to an SFU media server to efficiently manage the increased bandwidth requirements. 

This dynamic routing ensures you only pay for server infrastructure when it’s actually needed.

Hybrid WebRTC Architecture in Jitsi: Best of Both Worlds

To understand the savings, it helps to look at how platforms like Jitsi manage connections. The ecosystem generally relies on two core components: the client-side application (Jitsi Meet) and the media server (Jitsi VideoBridge or JVB).

In a standard setup, the media server receives video streams from participants and forwards them to others. This is essential for large meetings to save bandwidth on the client side.

Depiction of the SFU forwarding each participant’s streams to the rest of participants.
Depiction of the SFU forwarding each participant’s streams to the rest of participants

However, it is possible to configure Jitsi to implement intelligent routing logic to determine if such a server is actually necessary.

This logic acts as a dynamic switch:

  1. 2 Participants: If Jitsi Meet detects only two users in a room, it attempts to establish a direct P2P connection between them. The media bypasses the server entirely.
  2. 3+ Participants: When a third person joins, the application automatically escalates the session to the VideoBridge. The server then takes over to manage bandwidth and CPU load via its SFU architecture.

This hybrid approach allows you to utilize the scalability of a server when needed without sacrificing the cost-efficiency of P2P for simpler calls.

Jitsi logic for switching between P2P and SFU approaches
Jitsi logic for switching between P2P and SFU approaches

Operational Savings: Reducing Compute and Data Egress 

Routing 1-on-1 calls through a server creates a “double hop” for media packets. By keeping these smaller calls off the server, data flows directly between users. The result is zero cloud egress fees for those specific sessions.

There is also a secondary benefit regarding compute load. Offloading 1-on-1 calls to P2P allows your existing Jitsi VideoBridge instances to idle lower. This capacity can then be reserved for concurrent large meetings, delaying the need to spin up additional server nodes as your user base grows.

Technical Implementation: Configuring Jitsi for P2P

Enabling this feature in Jitsi happens within the config.js file in Jitsi Meet.

The primary control is the P2P flag: p2p: { enabled: true }

This master switch allows the client to attempt direct connections. In addition to enabling the P2P flag, you must also configure stunServers. These help the application navigate NATs and firewalls. Without valid STUN settings, P2P attempts will fail, forcing the application to revert to the server.

You should also consider the backToP2PDelay setting. This configuration stabilizes the user experience. If a third user joins a call and leaves rapidly, this delay prevents the system from aggressively “flapping” or switching back and forth between P2P and Server mode, which can cause media interruptions.

Reduce WebRTC Costs with Hybrid P2P Architecture

Leveraging hybrid P2P capabilities is a low-effort, high-reward optimization that directly reduces WebRTC infrastructure costs without compromising call quality. By routing 1-on-1 calls peer-to-peer, you eliminate data transfer fees for a significant portion of your traffic. This strategy extends the lifespan of current infrastructure and improves the unit economics of the application.

If you are looking to audit your current Jitsi configuration to ensure P2P is active and optimized, or if you need a comprehensive infrastructure cost analysis, contact WebRTC.ventures today. Our team can help you build and optimize your real-time communication applications for both performance and profitability.

Further Reading:

Recent Blog Posts