# Best pratices for livekit prod **URL:** \ **Category:** Self Hosting\ **Created:** [July 30, 2026, 9:57pm UTC](https://community.livekit.io/t/best-pratices-for-livekit-prod/1774 "2026-07-30T21:57:07Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![PABN\_LIVEKIT](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/pabn_livekit/32/2122_2.png) [@PABN\_LIVEKIT](https://community.livekit.io/u/PABN_LIVEKIT)\ **Post date:** [July 30, 2026, 9:57pm UTC](https://community.livekit.io/t/best-pratices-for-livekit-prod/1774/1 "2026-07-30T21:57:07Z")
Hello everyone, I’m looking for best practices and recommendations for deploying a **self-hosted (on-premises) LiveKit server**. My target is to support **around 1,500 participants in a single room**. My available network bandwidth is **1 Gbps**. The typical usage scenario is: - One presenter shares their **screen** , **camera** , and **microphone**. - Students join as viewers with their **microphones and cameras disabled** (listen-only mode). - The session is also recorded using **LiveKit Egress**. My current server configuration is as follows: _( vCPU 16, RAM 32GB, storage 500GB and MiniO, Ubuntu 22.04, LiveKit Server 1.13)_ I would appreciate your advice on the following points: - Is a single LiveKit server sufficient for this scenario, or would you recommend a clustered deployment? - What are the recommended LiveKit settings for this type of webinar? - Are there any specific optimizations for handling 1,500 viewers with only one active publisher? - What are the best practices for LiveKit Egress recording in this context? - Are there any bottlenecks or limitations I should anticipate, particularly with a 1 Gbps network connection? - If anyone has successfully deployed a similar on-premises setup, I’d be grateful if you could share your experience, architecture, or performance metrics. Thank you in advance for your feedback and recommendations! ##################### cat /opt/livekit/livekit-server.yaml port: 7880 redis: address: 127.0.0.1:6379 password: “MyPassword” keys: AAAAAAA: BBBBBBBBBBBBBBBBBBBBBB rtc: port\_range\_start: 40000 port\_range\_end: 60000 tcp\_port: 7881 node\_ip: mypublic-ip use\_external\_ip: false interfaces: includes: - ens160 allow\_tcp\_fallback: false use\_mdns: false packet\_buffer\_size\_video: 1500 packet\_buffer\_size\_audio: 500 batch\_io: batch\_size: 128 max\_flush\_interval: 2ms pli\_throttle: low\_quality: 1s mid\_quality: 1.5s high\_quality: 2s congestion\_control: enabled: true allow\_pause: true stun\_servers: - myapp-turndotexampledotcom:3478 - myapp-turndotexampledotcom:443 turn\_servers: - host: myapp-turndotexampledotcom port: 443 protocol: udp username: XXXX credential: “XXXXXXM3AoakMMOnpp7MIVd8aj8” - host: myapp-turndotexampledotcom port: 443 protocol: tls username: XXXX credential: “XXXXXXXXXXMMOnpp7MIVd8aj8” ### turn: enabled: false udp\_port: 443 # room: max\_participants: 10000 empty\_timeout: 300 departure\_timeout: 20 enable\_remote\_unmute: true enabled\_codecs: - mime: audio/opus - mime: video/vp8 - mime: video/h264 limit: num\_tracks: -1 bytes\_per\_sec: 1\_000\_000\_000 logging: level: warn pion\_level: error json: true sample: true ingress: rtmp\_base\_url: rtmps://myapp-rtc.example.com:1936/live whip\_base\_url: https-//myapp-rtcdotexampledotcom/whip webhook: api\_key: APIiRdMAsmvNobg urls: - [https://myappdotexampledotcom/api/webhook/livekit](https://myappdotexampledotcom/api/webhook/livekit) prometheus: port: 6789 ---
**Author:** ![troy](https://avatars.discourse-cdn.com/v4/letter/t/85f322/32.png) [@troy](https://community.livekit.io/u/troy)\ **Post date:** [July 31, 2026, 11:29am UTC](https://community.livekit.io/t/best-pratices-for-livekit-prod/1774/2 "2026-07-31T11:29:56Z")
If the students are watching, why not stream it to YouTube? LiveKit includes an Egress service that records or renders a room and broadcasts it via RTMP. You provide your YouTube Live RTMP URL and stream key to the LiveKit Egress API, and LiveKit handles pushing the live feed directly to YouTube. It means you’re doing one stream only. Or using a passive viewers’ CDN. If viewers just need to watch and can tolerate a few seconds of lag, don’t use WebRTC for everyone. Use LiveKit Egress to output HLS files to object storage like S3, then drop Cloudflare or CloudFront in front of it. LiveKit does one encode job, and the CDN handles the heavy lifting. or for interactive viewers a WebRTC SFU Cluster. If sub-second interaction is non-negotiable, HTTP CDNs won’t work. LiveKit handles high volume here by clustering its SFUs. The host stream hits a primary node, and LiveKit fans it out across edge nodes to stream directly to viewers. The single most important thing to decide first is whether your audience actually needs sub-second interactivity, because an HLS CDN setup will cost a fraction of the price and spare you major infrastructure headaches. ---
**Author:** ![PABN\_LIVEKIT](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/pabn_livekit/32/2122_2.png) [@PABN\_LIVEKIT](https://community.livekit.io/u/PABN_LIVEKIT)\ **Post date:** [July 31, 2026, 12:06pm UTC](https://community.livekit.io/t/best-pratices-for-livekit-prod/1774/3 "2026-07-31T12:06:40Z")
Thank you for your detailed response. In our use case, the audience is not completely passive, so HLS or YouTube Live alone would not meet our requirements. During a typical session, the instructor shares their screen, camera, and microphone. Students normally join in listen-only mode, but they can **raise their hand**. When the instructor grants permission, a student can temporarily enable their microphone to ask or answer a question, and in some cases even **share their screen**. Once the interaction is over, the student is removed from the stage and returns to listen-only mode. So we need real-time interaction with sub-second latency, which is why we chose LiveKit. We also performed load testing with **lk load** on a local **10 Gbps** network and were able to reach approximately **8,000 participants** in a single room. The limiting factor in our production environment is currently our **1 Gbps Internet connection** , which is why we intentionally cap our rooms at around **1,000 participants**. At this stage, my main question is not whether LiveKit can scale, but whether **our current LiveKit deployment and configuration follow best practices** for this type of workload. I’m particularly interested in recommendations regarding: - LiveKit server configuration and tuning for large webinar rooms. - Whether our SFU configuration is appropriate or could be optimized. - Network and bandwidth optimization. - Any settings that could improve scalability, reliability, or media quality. - Whether anyone has experience running a similar **on-premises deployment** with around 1,000 concurrent interactive participants. I’d really appreciate any feedback or suggestions from people who have deployed LiveKit at this scale. ---
**Author:** ![system](https://sea1.discourse-cdn.com/flex001/user_avatar/community.livekit.io/system/32/26_2.png) [@system](https://community.livekit.io/u/system)\ **Post date:** [August 15, 2026, 12:07pm UTC](https://community.livekit.io/t/best-pratices-for-livekit-prod/1774/4 "2026-08-15T12:07:40Z")
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.