Can I deploy 2 agents on one machine?
# ask-ai
b
Can I deploy 2 agents on one machine?
✅ 1
t
Thanks for reaching out, Atul. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
Thanks — good question. Yes, you can run multiple LiveKit agents on a single machine. What that looks like and what to consider: • Each agent server can run multiple jobs (agent instances) simultaneously; each job runs in its own isolated process. • The framework supports running multiple agent workers on the same host and will load-balance work across them based on availability and capacity. • For production reliability, it’s recommended to run multiple workers per
agent_name
so you have redundancy and higher availability if one worker fails. • Running more agents on one machine increases concurrency, but be sure to size CPU, memory, and network capacity so processes don’t compete for resources. If you want, tell me: • Are you planning a self-hosted or LiveKit Cloud setup? • How many agents/workers you want to run and the machine specs (CPU, RAM)? I can then suggest a simple process layout and resource-sizing guidance or a sample startup command/config based on your environment. Sources: Server lifecycle | LiveKit Documentation | Self-hosted deployments | LiveKit Documentation | Agents Framework | livekit/livekit_composite | DeepWiki, with interactive elements
b
can we deploy an agent on livekit cloud,, but while deplloying that agent in its dockerfile can we somehow provide more than one agents in that... so that even it looks on the cloud its one agent deployed,, but inside it multiple are deployed
t
Thanks — great question. You're asking whether you can deploy a single container to LiveKit Cloud that appears as one agent externally but actually runs multiple, distinct agents inside the container via the Dockerfile. Short answer: • No — you cannot package multiple independent agents (different `agent_name`s or separate agent deployments) inside one container and have LiveKit Cloud treat them as separate agents. LiveKit Cloud expects one primary agent process per container. • Yes — you can run multiple worker processes of the same agent inside a container (each job runs in its own isolated process), and you can deploy multiple containers using the same
agent_name
so the service looks like a single logical agent while handling many concurrent sessions. What that means in practice: • A single container should run one agent server process. That agent can spawn isolated processes per job to handle concurrency, but all jobs are instances of the same agent logic. • To scale capacity or provide redundancy, run multiple containers (or workers) with the same
agent_name
. LiveKit will balance incoming sessions across those workers. • If your goal is to have multiple specialized agents (different roles/logic), deploy them as separate agents and coordinate them via tools/handoffs or by having one agent call another. If you want, tell me: • Are you trying to run multiple identical workers for capacity, or different specialized agents that need to collaborate? • Are you using LiveKit Cloud or self-hosted LiveKit? (You mentioned Cloud, but confirming helps me give exact command/config examples.) I can then suggest: • A simple container startup pattern for running multiple worker processes of the same agent, or • Recommended architecture for multi-agent workflows (how to split roles and wire them together) with example calls/tools. Sources: Voice Agent Architecture: STT, LLM, and TTS Pipelines Explained | LiveKit | Agents Framework | livekit/livekit_composite | DeepWiki | Self-hosted deployments | LiveKit Documentation | Server lifecycle | LiveKit Documentation | examples/voice_agents | livekit/livekit_composite | DeepWiki, with interactive elements
b
Are you trying to run multiple identical workers for capacity, or different specialized agents that need to collaborate?
yes
Are you using LiveKit Cloud or self-hosted LiveKit?
livekit cloud
t
Thanks — this is helpful. Since you're on LiveKit Cloud and want both: (A) multiple identical workers for capacity, and (B) separate specialized agents that collaborate, here’s a clear, practical plan and recommended architecture. Key facts up front • LiveKit Cloud expects one primary agent process per container deployment. You cannot package multiple independent agent deployments (different `agent_name`s) inside a single container and have the platform treat them as separate agents. • You can scale capacity by running multiple worker instances (containers) with the same
agent_name
. Each worker handles jobs as isolated processes. • For multiple specialized agents, deploy them as separate agent deployments and coordinate them (tools, handoffs, function calls) so they can collaborate. Recommended approaches 1) Scale capacity (multiple identical workers) • Deploy one container image that runs your agent server logic for a given
agent_name
. • Run multiple instances (containers) of that same image on LiveKit Cloud. All instances register under the same
agent_name
and LiveKit will balance jobs across them. • Inside each container the agent can spawn per-job isolated processes, increasing concurrency; but those are all instances of the same agent logic. • This model gives redundancy and high availability. 2) Multi-agent collaboration (specialized agents) • Create separate agent deployments for each specialized role (for example:
orchestrator_agent
,
qa_agent
,
nlp_helper
). • Deploy each role as its own container/agent on LiveKit Cloud (one primary agent process per container). • Coordinate between agents using: ◦ Tools or function calls where one agent invokes another agent’s capability. ◦ Explicit handoffs: one agent finishes then calls the next agent via an API/tool. ◦ Shared state or task queues if you need loose coupling. • This keeps roles modular, testable, and independently scalable. 3) If you want the “appearance of a single agent” but with multiple workers and roles • Use a single logical
agent_name
for capacity (many identical workers). • For specialized behavior, have that logical agent call specialized services or microservices (which can themselves be separate agents) rather than trying to embed multiple agent deployments inside one container. Practical next steps I can help with • If you want capacity: I can provide a sample container startup command and a recommended worker count based on your expected concurrent sessions (tell me expected concurrency and machine size). • If you want collaboration: I can sketch a simple multi-agent workflow example (call sequence and tool definitions) showing how one agent can call another. • If you want hybrid guidance: describe which parts need to be identical workers and which are specialized roles, and I’ll recommend a deployment topology. Which of the next steps do you want to try first? , with interactive elements