Let me walk you through how workers in LiveKit operate, especially when used with self-hosted agents. Think of workers as helpful intermediaries that register with the LiveKit server and patiently wait for job assignments. When a room is created, the server reaches out to an available worker, who then has the choice to accept or decline the job. Once accepted, the worker brings the agent into the room as a participant to handle tasks like subscribing to tracks.
It's important to know that a single worker instance is
not limited to handling just one call at a time. It can actually manage multiple agent instances all at once, with each agent running in its own separate process. This setup helps make the most of your resources and allows for smooth scalability, depending on your machine’s capacity. Plus, since each job runs in its own process, if one agent happens to crash, it won’t impact the others sharing the same worker.
The LiveKit server smartly uses a job distribution system that assigns each job to only one worker, following a fair round-robin approach. Workers keep the server updated about their availability and current load. And when things get busy, they can pause accepting new jobs to keep everything running smoothly without performance hiccups.
Sources:
agents/src/worker.ts |
Anatomy of an Agent | LiveKit Docs |
Job lifecycle | LiveKit Docs |
Deploying to custom environments | LiveKit Docs