This message was deleted.

Currently it seems it will be a pain to spin up/down livekit servers for a geographically diverse client base with varying room size requirements, not to mention expensive

@echoing-kitchen-90064 Have you seen the info linked below? https://docs.livekit.io/deploy/distributed/

I have. Those docs assume a uniform node size. I don't want to spin up large nodes in every US region as it's spendy. I want to spin up the livekit control plane on cheap/small nodes and spin up the sfu on demand based on geo location and room size requirements.

Hey dan, good question. I think you can already achieve this today by using region_aware load balancing. It supports nodes of various sizing, so you can set a sysload_limit so that a node will stop taking requests for new rooms after a certain point

Fair point on the ready on request. Perhaps I'll spend some more time thinking through what more granular control over rooms/node sizing looks like for my specific use case. I only need room availability mainly during business hours, and will have varying size rooms: from as low as 2-3 to up to 200ish. I'll also need to good geographic coverage. So with static node size, I obviously have to plan for the worst case which means large nodes in lots of places. Perhaps my best path is to build my own custom k8s controller to spin up the livekit-server specific to my need times and live with the large node sizing.

you could look into an k8s operator that turns up instances of a new Deployment (that has higher CPU requirements). LiveKit is node-size agonistic and does not assume all of the nodes are homogenous in size. The

sysload_limit

config above is a per CPU setting.

@dry-elephant-14928 when using distributed set-up, the API key and API Secret need to be the same for all instances?