Is there a way to pause/disable a cloud agent? or to scale to 0 in livekit.toml?

Thanks for reaching out, Juan. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

I want to stop incoming connections

Thanks — I’m responding to your goal of stopping incoming connections to your cloud agent. Because you cannot pause/disable an agent or scale it to zero via

livekit.toml

, here are practical alternatives you can use to stop incoming connections without immediately deleting the agent: • Block traffic at the application level ◦ Modify the agent code to reject or immediately close new connections (return an error or refuse auth) and then deploy that version via

lk agent deploy

. This preserves the agent and its config while preventing new clients from connecting. • Restrict client authentication ◦ If your setup issues tokens or uses an auth endpoint, temporarily disable token issuance or change token validation so new tokens are invalid. Existing sessions will still run, but no new connections can authenticate. • Network-level blocking (if available) ◦ If your cloud provider or VPC/security groups allow it, add firewall rules or security group rules to block inbound traffic to the agent. This effectively stops incoming connections while leaving the agent deployed. • Use a gateway/proxy to reject traffic ◦ If you front the agent with a proxy or load balancer, update its routing rules to return a 503 or to drop traffic for that agent. • Delete the agent ◦ If you want to fully stop all traffic and are okay removing the deployment, use

lk agent delete

. This is permanent and removes the agent. Which approach sounds best for you? • If you want to preserve the agent and configuration but stop new connections temporarily, I recommend either deploying a version that rejects connections or disabling token issuance. • If you can modify network rules or have a proxy, those will stop traffic without touching code. If you’d like, tell me: • Whether you control the agent code (can you deploy changes?), and • Whether you use token-based auth or a proxy/load balancer — I’ll give step-by-step suggestions for the option you pick., with interactive elements

if there are 2 agents (as different agent IDs) and I want to stop connections on 1 of them

Thanks — I’m responding to stopping incoming connections for only one of two deployed agents (each with its own agent ID). You can’t pause/disable an agent via

livekit.toml

, but you can stop connections to a single agent using one of these targeted approaches. Pick the one that fits your setup: • Deploy a “blocker” version of that agent ◦ Modify the agent code to refuse new connections (return an auth error or immediately close new sessions) and run

lk agent deploy

for that agent ID. This preserves the agent and its config while preventing new clients from connecting to that specific agent. • Stop token issuance or make tokens invalid for that agent ◦ If you issue tokens tied to that agent (or a subdomain/project), temporarily disable the auth endpoint or change token validation for that agent so new tokens are rejected. Existing sessions remain until they disconnect. • Update network/firewall rules for that agent ◦ If your cloud/VPC or load balancer supports per-agent routing or security groups, add rules to block inbound traffic only to the agent’s service or instance. This stops connections to that agent without affecting the other one. • Change proxy/load balancer routing ◦ If you front agents with a proxy or LB, update its configuration to return 503/drop traffic for the target agent’s route. The other agent keeps receiving traffic. • Delete the agent (if you don’t need it) ◦

lk agent delete

will permanently remove that agent and stop all traffic to it. Quick guidance to help me give exact steps: 1. Do you control the agent code and can you deploy a new version for just that agent? 2. Do you use token-based auth or an auth service that issues tokens per agent/project? 3. Do you have access to network controls, security groups, or a proxy/load balancer in front of the agents? Tell me which approach you prefer and answer 1–3, and I’ll provide step-by-step instructions for that method. , with interactive elements

1. Yesm we control the agent code and deploy a new version for that agent 2. no 3. no what about using

agentName

to block connections?

Thanks — I’m replying about using

agentName

to stop incoming connections to one of your agents. Yes — changing the

agentName

in a new deployment is a good, targeted way to block new connections to that specific agent. Key points and steps: • What this does ◦ LiveKit only dispatches jobs to agents whose

agent_name

matches the dispatch request. If you deploy a new version that registers under a different

agentName

, dispatches that reference the old name will no longer find a matching agent, so new sessions for the old agent stop being created. ◦ This affects only new connections. Active sessions already running on the agent are NOT terminated by this change. • Simple steps to implement a. Update your agent code to use a different

agentName

(for example

my-agent

->

my-agent-blocked

or

my-agent-v2

) in the decorator or ServerOptions where you set

agent_name

. b. Build and deploy that agent version for the specific agent ID using your usual

lk agent deploy

workflow. c. Verify with

lk agent status

/ logs that the new agent instance registered under the new name. d. Confirm that your dispatch/frontend still uses the old

agentName

(it will now fail to start new sessions) until you intentionally switch it to the new name. • Additional considerations ◦ If you later want to re-enable new connections for that agent ID, deploy a version that uses the original

agentName

(or update your dispatch to target the new name). ◦ If you need active sessions forcibly terminated, that is a separate operation; changing

agentName

won’t disconnect existing clients. ◦ This approach keeps the agent deployed and preserves its configuration and code, while preventing new incoming connections. If you’d like, tell me the exact language/runtime you’re using (Node.js, Python, etc.) and the current

agentName

you have; I can give the exact code snippet and a short deploy checklist for your environment. Sources: Agent dispatch | LiveKit Documentation | Build a salary negotiation coach with a LemonSlice avatar | LiveKit, with interactive elements