We’re currently on the Scale plan of LiveKit Cloud for the LiveKit server, and running our agent workers on GKE. We’ve hit a bottleneck with the concurrent Egress limit (500 on the Scale plan), which is insufficient for our workload.
Ideally, we’d self-host the entire LiveKit stack to remove this constraint, but managing all components — the LiveKit server, Egress, Ingress, SIP, etc. — on GKE via Helm is operationally complex and not something we want to take on right now.
We’re therefore exploring a hybrid approach: continue using LiveKit Cloud for the LiveKit server and all other services, while self-hosting only the Egress service on GKE to bypass the cloud concurrency limit.
However, we understand that the Egress service communicates with the LiveKit server through a shared Redis instance (via messaging queues), and LiveKit Cloud does not expose its internal Redis. This raises a fundamental question about whether this hybrid topology is technically feasible at all.
Specific questions:
-
Has anyone successfully self-hosted the Egress service against LiveKit Cloud (i.e., pointing
ws_urlatwss://*.livekit.cloud)? Is this architecture even supported? -
If it is possible, what were the main configuration or networking challenges on GKE?
-
If it is not possible due to the Redis coupling, are there alternative workarounds short of fully self-hosting the LiveKit server?
-
Has anyone pursued a quota increase on the Scale plan beyond the default 500 Egress concurrency limit, and was that process feasible?
Any experience or insight would be greatly appreciated.