@millions-hair-24956 Hey, I’m new to LiveKit, and I couldn’t understand from the documentation if the self posted version can work up to an unlimited amount of users, given that I have the knowledge and the infrastructure to support the scale? If so, would I still need to subscribe to one of the plans? Thanks!

It seems likely that the self-hosted version of LiveKit can support a large number of users, but there are some limitations. According to the LiveKit documentation, the self-hosted version is designed to scale horizontally, but each room must fit within a single node. This means that while you can have many concurrent rooms, the number of participants per room is limited by the capacity of a single node. Regarding subscription plans, the self-hosted version does not require a subscription to LiveKit's cloud plans. However, you would need to manage your own infrastructure and any associated costs, such as server hosting and bandwidth. If you prefer not to manage infrastructure, you might consider LiveKit's managed cloud service, which offers different plans based on usage. Would you like more details on setting up a self-hosted LiveKit deployment? Sources: - LiveKit documentation 👍 1 button 👎 0 button 💡 Hint: Mention @millions-hair-24956 in the thread for followups.

@millions-hair-24956 Yes, please provide me details regarding deployment to EKS clusters

To deploy LiveKit to an EKS cluster, follow these steps: 1. Pre-requisites: Ensure you have a Kubernetes cluster on AWS, and Helm is installed on your machine. You'll also need a Redis instance and SSL certificates for your primary domain and TURN/TLS. 2. Add LiveKit Helm Repository: Add the LiveKit Helm repository to your Helm setup:

helm repo add livekit https://helm.livekit.io

3. Create a

values.yaml

File: Use a sample configuration file like

server-sample.yaml

as a template to create your

values.yaml

file. This file will contain your specific configuration settings. 4. Install LiveKit: Use Helm to install LiveKit on your EKS cluster:

helm install <INSTANCE_NAME> livekit/livekit-server --namespace <NAMESPACE> --values values.yaml

5. Configure Networking: Ensure your firewall is configured to allow traffic into LiveKit ports. This includes ports for WebRTC, TURN, and any other services you plan to use. 6. Use ALB Ingress Controller: On AWS, it's recommended to use the ALB Ingress Controller as the main load balancer for LiveKit's signal connection. This setup helps with TLS termination and routing traffic correctly. For more detailed instructions, you can refer to the LiveKit Kubernetes deployment guide. Would you like more information on any specific part of the deployment process? Sources: - LiveKit Kubernetes deployment guide 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@millions-hair-24956 Yes, would the deployment plan you provided work with private cluster?

Deploying LiveKit on a private EKS cluster is possible, but it requires additional configuration to handle network traffic and connectivity. Here are some key considerations: 1. Network Load Balancer (NLB): Since your nodes are in a private subnet, you can use an NLB to route traffic from the internet to your cluster. This setup allows you to keep your nodes private while still accepting external traffic. 2. TURN Server: A TURN server is essential for handling WebRTC traffic, especially when nodes are in private subnets. LiveKit includes an embedded TURN server, but you can also deploy a standalone TURN server if needed. 3. External IP Configuration: Ensure that the

use_external_ip

setting is configured correctly. This setting helps LiveKit discover and advertise the correct public IP address to clients. 4. Security Groups and Firewall Rules: Configure your security groups to allow necessary traffic to the LiveKit ports, such as TCP/UDP for WebRTC and TURN. 5. Redis Configuration: Ensure that Redis is accessible from all nodes in your cluster, as it is used for coordination between nodes. For more detailed guidance, refer to the LiveKit deployment documentation. Would you like more details on any specific aspect of deploying to a private cluster? Sources: - LiveKit deployment documentation 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@millions-hair-24956 Would NLB be a better fit for a private cluster deployment than ALB?

Sure thing! I'm looking through the available data to answer your question. Hold on a second... ⏳

@millions-hair-24956 ?

I'm here to help with questions related to LiveKit. If you have any questions about deploying, configuring, or using LiveKit, feel free to ask! If your question is about something else, please provide more details or rephrase it. 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@millions-hair-24956 Would NLB be a better fit for a private cluster deployment than ALB?

It seems likely that using a Network Load Balancer (NLB) might be more suitable for a private cluster deployment of LiveKit compared to an Application Load Balancer (ALB). According to the LiveKit documentation, NLBs are typically used for handling TCP/UDP traffic, which is essential for WebRTC applications like LiveKit. NLBs can efficiently route traffic to nodes in private subnets without requiring public IP addresses on the nodes themselves. In contrast, ALBs are generally used for HTTP/HTTPS traffic and might not be as efficient for the low-latency, high-throughput requirements of WebRTC traffic. Therefore, for a private cluster where you need to handle WebRTC traffic effectively, an NLB would likely be a better fit. Would you like more information on configuring NLB for LiveKit? Sources: - LiveKit Kubernetes deployment guide 👍 0 button 👎 0 button 💡 Hint: Mention @runllm in the thread for followups.

@millions-hair-24956 yes, thank you

To configure a Network Load Balancer (NLB) for a private cluster deployment of LiveKit, follow these steps: 1. Create an NLB: In the AWS Management Console, navigate to the EC2 service and create a new Network Load Balancer. Ensure that it is set to handle TCP/UDP traffic, which is necessary for WebRTC. 2. Target Groups: Create target groups for the NLB that point to the instances or pods running LiveKit. Ensure that the health checks are configured to monitor the appropriate ports used by LiveKit. 3. Security Groups: Update the security groups associated with your instances or pods to allow traffic from the NLB. This includes opening the necessary ports for WebRTC and TURN traffic. 4. DNS Configuration: If you have a domain name, configure DNS to point to the NLB. This setup will allow clients to connect to LiveKit using a friendly domain name. 5. LiveKit Configuration: Ensure that LiveKit is configured to use the external IP address provided by the NLB. This configuration is crucial for clients to connect correctly. For more detailed instructions, refer to the LiveKit deployment documentation. If you need further assistance with any specific configuration step, feel free to ask! Sources: - LiveKit deployment documentation 👍 1 button 👎 0 button 💡 Hint: Mention @millions-hair-24956 in the thread for followups.