Deploy LiveKit Agents Without Dropping Live Calls

Quick answer: A deploy drops a call when the old process stops serving it before the call ends, either killed at the platform’s deadline or, like uvicorn, closing the call’s socket itself on SIGTERM. Make SIGTERM stop new calls, let in-flight calls finish, and set the platform’s kill deadline above your longest call: Kubernetes defaults to 30 seconds, while LiveKit Agents 1.8.5 will wait up to 3,600 seconds to drain.

How do I deploy a new version of my voice agent without dropping live calls?

You stop treating a deploy as a restart. A web server can be replaced in seconds because its requests last milliseconds; a voice agent holds a process for the whole conversation, so the old version has to keep running, untouched, until its last call hangs up. The question, almost word for word, was asked on the LiveKit Agents tracker in issue #3020 (25 July 2025): “I’m running LiveKit agents in two pods within a Kubernetes cluster. During a deployment or release, the new pods start up healthy while the old ones are terminated. However, if there are ongoing sip phone calls … those calls may get dropped when the pod handling them is shut down.”

Every platform answers it with the same three moving parts, under different names:

• A stop signal the agent actually receives. Kubernetes and Docker both send SIGTERM to the container’s main process, then SIGKILL when a deadline expires.
• A drain. On that signal the agent stops accepting new calls and keeps the ones it has. LiveKit Agents does this natively; a Pipecat bot served by FastAPI on uvicorn does not, as our test below shows.
• A deadline longer than your longest call. Kubernetes calls it terminationGracePeriodSeconds and defaults it to 30 seconds. Docker’s docker stop defaults to 10 seconds on Linux. Either one, left alone, ends any call longer than that.

The quotable version: a rolling deploy of a voice agent takes as long as your longest call, and any setting that pretends otherwise is where the dropped calls come from. Pipecat’s own production guide says the same thing in different words: with a graceful drain, “you accept that ‘rolling deploys’ can take as long as your longest session.”

The rollout sequence, in order

This is the sequence for a self-hosted agent on Kubernetes. Managed platforms do steps 3 to 6 for you and are covered further down. Do step 1 on day one: when it fails, every later step fails silently.

1. Prove SIGTERM reaches the agent process. Docker’s Dockerfile reference states that a shell-form ENTRYPOINT runs under /bin/sh -c, “which does not pass signals”, so your executable “doesn’t receive a SIGTERM from docker stop”. Use the exec (JSON array) form. A launcher in between is fine if it forwards signals: LiveKit’s Python starter Dockerfile ends CMD ["uv", "run", "src/agent.py", "start"], and uv’s documentation states it forwards most signals to the child on Unix, with exceptions that do not include SIGTERM.
2. Run the production mode, not the dev mode. In livekit-agents 1.8.5 the shutdown path calls server.drain() only when the worker is not in dev mode. A container started with dev exits without draining.
3. On SIGTERM, stop accepting new calls. A draining LiveKit worker reports itself as full to the LiveKit server, so dispatch skips it. For your own HTTP or WebSocket server, flip readiness to failing and refuse new sessions.
4. Let in-flight calls finish, with a deadline you chose. In LiveKit that deadline is drain_timeout. Set it from your longest permitted call plus post-call work, not from the default.
5. Set the kill deadline above the drain deadline. terminationGracePeriodSeconds must cover the preStop hook, the drain and the shutdown, because Kubernetes starts the grace countdown before the preStop hook runs. The formula is in the next section.
6. Add capacity before you remove it. Set the Deployment’s maxUnavailable: 0 and maxSurge to at least 1, so an old pod stops accepting only after its replacement is ready.
7. Make autoscaler scale-down patient. A Horizontal Pod Autoscaler scale-down terminates pods exactly as a deploy does, under the same grace period. LiveKit advises longer scale-down stabilisation “because agent servers take time to drain”.
8. Gate readiness on warm-up, and place a test call. A new pod that reports ready before its models and connections are loaded can lose the first call it is given.
9. Run the finish-state test: start a call, deploy mid-call, and confirm the call ends on its own terms. Until this passes, none of the above is verified.

How long should terminationGracePeriodSeconds be?

Longer than everything that has to happen between SIGTERM and a clean exit, added up. The sizing formula we use:

grace ≥ preStop time + longest permitted call + post-call work + process shutdown + margin

• Longest permitted call is a cap you enforce, not your average handle time. If nothing ends a call at a fixed length, you have no number to put here, and the right first step is to add one: an agent-side timer, a carrier maximum duration, or Pipecat Cloud’s --max-session-duration (enforced inside the bot from base image 0.1.27).
• Post-call work is anything the job does after the caller hangs up, such as writing a summary to your CRM. livekit-agents 1.8.5 allows on_session_end up to session_end_timeout, default 300 seconds.
• Process shutdown in livekit-agents 1.8.5 is shutdown_process_timeout, default 10 seconds.
• Margin is our choice of 30 seconds, for the signal path and log flushing. It is a judgement, not a published figure.

Worked example (LiveKit Agents on Kubernetes). Calls are capped at 15 minutes (900 seconds) and the CRM write-back takes up to 60 seconds. Set drain_timeout = 900 + 60 = 960. Then terminationGracePeriodSeconds = 960 + 10 + 30 = 1,000. With that ordering the worker’s own drain deadline fires first and the framework shuts its jobs down itself, logging “drain timed out, forcing shutdown”, instead of the kubelet sending SIGKILL with no log line from your code.

Second example (Pipecat bot on uvicorn). Calls capped at 10 minutes (600 seconds), 30 seconds of post-call work, and a preStop hook that waits for active calls to reach zero. Because the hook itself is the drain, grace = 600 + 30 + 30 = 660 seconds.

The mismatch to check for in your own manifest: LiveKit’s example Kubernetes manifest sets terminationGracePeriodSeconds: 600 with the comment “Give the agent 10 minutes to finish up any ongoing conversations”, while the drain default in current releases is 3,600 seconds. Deployed as-is, the kubelet decides when calls end, at 600 seconds, not the worker.

Threshold table: what to set for your longest call

Your longest permitted call	drain_timeout (LiveKit)	terminationGracePeriodSeconds	What breaks if you leave the default
20 seconds, no post-call work	20	60	Kubernetes default 30 covers the call itself but leaves 10 seconds for shutdown and nothing for a preStop hook
5 minutes, 60 s post-call	360	400	Kubernetes default 30: any call with more than 30 s left to run at SIGTERM is killed
15 minutes, 60 s post-call	960	1,000	LiveKit example manifest’s 600: any call with more than 10 minutes left to run at SIGTERM is killed
30 minutes, no post-call	1,800	1,840	livekit-agents 1.6.4 and earlier default drain of 1,800 just fits; the kill deadline still has to be raised
Over 60 minutes	Your cap + post-call	Your cap + post-call + 40	Self-hosted: the 3,600-second default drain ends first. LiveKit Cloud gives old instances up to 1 hour, so deploy outside call hours
No cap at all	0 (waits indefinitely)	Cannot be sized	Every deploy can run for hours; add a cap first

Rows 1 to 4 apply the formula with a 10-second shutdown and 30-second margin: 20 + 10 + 30 = 60; 360 + 10 + 30 = 400; 960 + 10 + 30 = 1,000; 1,800 + 10 + 30 = 1,840. The cost of a long grace period is capacity, not risk: the Kubernetes Deployment documentation notes that terminating pods are not counted as available, so total resources can exceed replicas + maxSurge until the terminating pods’ grace period expires. Budget cluster room for one old ReplicaSet draining alongside the new one.

What LiveKit Agents does on SIGTERM, by version

The drain is built in, but its defaults have moved, so read them from the version you run rather than from a forum answer. We read the source at each release tag on 8 October 2026.

Behaviour	What the source shows	Versions
Default drain_timeout	1,800 seconds	1.6.4 and earlier (checked at 1.2.0, 1.5.0 and 1.6.0 to 1.6.4)
Default drain_timeout	3,600 seconds (DRAIN_TIMEOUT = 3600 # 1hr)	1.6.5 (released 9 July 2026) to 1.8.5 (released 6 October 2026)
drain_timeout = 0	No deadline: the drain waits until jobs finish	1.8.5; PR #7365 to document this is open as at 8 October 2026
Drain in dev mode	Skipped; the drain runs only when not in dev mode	1.8.5
A second SIGTERM or SIGINT	Force exit (“exiting forcefully”)	1.8.5
SIGTERM while a request_fnc blocks the event loop	Handled: the exit is scheduled on the event loop, with a 3-second watchdog if the loop is blocked	Read at 1.8.5. Issue #6724 was closed by PR #7034, merged 29 August 2026; the first release containing that commit is 1.8.0
Draining worker’s status	Reported to the LiveKit server as full, so no new jobs are dispatched to it	1.8.5
Worker HTTP endpoint	/worker on port 8081 in production returns active_jobs	1.8.5

First, the blocking-loop bug. Issue #6724 (opened 6 August 2026) reported, reproduced on 1.6.0, 1.6.6 and 1.6.8, that a SIGTERM arriving while a request_fnc did blocking I/O could be swallowed, so the worker “continues to register as available, and may accept new job dispatches until SIGKILL”. It was closed on 29 August 2026 by PR #7034. A second fix for the same issue, PR #6738, is still open as at 8 October 2026, but the merged fix already ships. Our check of the release tags shows 1.7.1 does not contain the #7034 commit and 1.8.0 does; we did not check for backports to older lines. If your request_fnc does any synchronous I/O, upgrade before you trust the drain.

Second, the default changed under people. The community answer that closed #3020 in August 2025 says the default “is 1800 now”, which was true then; on 1.6.5 and later it is 3,600. That answer came from a user who wrote “I’m not a livekit dev”, with a LiveKit maintainer replying “+1” and a link to the docs. Set the value explicitly and the change cannot surprise you.

Capacity during the drain is the subject of our worked sizing on how many voice agent workers you need at peak, which adds one worker for the N − 1 accepting capacity a rolling deploy leaves you with.

Pipecat on FastAPI: why SIGTERM cut our test call in 0.2 seconds

Pipecat is a pipeline framework, not a worker pool, so when you self-host a telephony bot the process that receives SIGTERM is usually the web server. Pipecat’s own development runner (pipecat.runner.run in v1.12.0) is a FastAPI app started with uvicorn.run(), the #3769 reporter’s traceback shows a FastAPI server.py in production, and Pipecat’s production guide says plainly that the runner has “no graceful drain”. uvicorn’s graceful shutdown is built for HTTP. In uvicorn 0.54.0 (released 25 September 2026), Server.shutdown() calls shutdown() on every open connection before it waits for --timeout-graceful-shutdown, and all three of its WebSocket implementations answer that by sending WebSocket close code 1012. The graceful-shutdown timeout only bounds the wait that follows, by which point the call’s socket is already closing.

On 8 October 2026 we ran a FastAPI WebSocket endpoint that streams a frame every 0.2 seconds for an 8-second simulated call, on Python 3.12.3, uvicorn 0.54.0, FastAPI 0.142.4 and websockets 17.2, with --timeout-graceful-shutdown 60. A client connected, and we sent SIGTERM 2 seconds later. Three runs each:

Scenario	Close code	Call length reached	New call during shutdown	SIGTERM to exit
SIGTERM sent straight to uvicorn	1012 in 3 of 3 runs	1.95–2.00 s of 8 s	Not tested	0.16–0.20 s
Drain first (stop accepting, wait for active calls = 0), then SIGTERM	1000 (normal) in 3 of 3 runs	8.07 s of 8 s	Refused at handshake (HTTP 403)	6.85–6.88 s, including the wait for the call to end

A 60-second graceful-shutdown setting protected an 8-second call for none of its remaining 6 seconds. The scope is narrow on purpose: one host, loopback, our own fixture rather than a Pipecat bot, and one uvicorn version. It is consistent with the second comment on Pipecat issue #3769, where a user preparing to deploy on Kubernetes with Twilio anticipated that ongoing calls “will be cut off because the FastAPI server will be down, which closes the sockets”.

The fix is to drain before the signal arrives. Kubernetes runs a preStop hook before it sends SIGTERM, and the hook must finish first. Give your app two small endpoints of its own: one that flips readiness to failing and refuses new sockets, one that reports the active call count. The preStop hook calls the first, then polls the second until it reads zero. Only then does uvicorn receive SIGTERM, with nothing left to close. That is what the “drain first” row above emulates (our test script played the preStop role; we did not run it inside a cluster), and it is what Pipecat’s production guide describes: “mark the old version as not-accepting-new-sessions, redirect new traffic to the new version, wait for the old version’s sessions to finish (with a deadline), then terminate.”

One carrier-side backstop worth knowing about: Twilio’s documentation for <Connect><Stream> states that Twilio executes the remaining TwiML instructions only after your server closes the WebSocket. A TwiML instruction placed after the stream, such as a redirect back to your webhook, is therefore what runs if a socket is cut. We have not tested that path; it would start a fresh session without the conversation so far, which is better than dead air and worse than a drain.

Which framework fits your deployment model in the first place is compared in LiveKit Agents vs Pipecat.

Managed platforms: LiveKit Cloud and Pipecat Cloud

On a managed runtime the drain and the deadline are the vendor’s. What you still own is call length, the warm-up, and knowing whether a deploy actually replaced anything.

Platform	What happens to live calls on deploy	Limit stated	What you still have to do
LiveKit Cloud (lk agent deploy)	Rolling deployment: new instances take new sessions; old instances stop accepting and stay up to complete active ones	Old instances get up to 1 hour; new instances get 5 minutes for the health check to start passing	Keep calls under an hour or deploy outside call hours; keep prewarm under 5 minutes. Rollback without a rebuild needs a paid plan
Pipecat Cloud (pipecat cloud deploy)	Running instances continue on the old image until their session concludes, then are discarded rather than returned to the pool	Old sessions run to completion, bounded by the maximum session duration: 7,200 seconds (2 hours) by default, configurable from 60 to 14,400 seconds, after which bot() is cancelled (enforced inside the bot from base image 0.1.27; on older images the session can keep running past the limit)	Expect some new requests to start on the prior configuration while the update propagates. A scaling-only change, a re-pushed image tag or a new secret value does not create a new version; use --force
Self-hosted LiveKit Agents on Kubernetes	Worker drains on SIGTERM in production mode	Kubernetes kills at terminationGracePeriodSeconds, default 30 s	Everything in the rollout sequence above
Self-hosted Pipecat on FastAPI and uvicorn	Open WebSockets closed with 1012 on SIGTERM (uvicorn 0.54.0)	Same Kubernetes deadline; docker stop 10 s on Linux	A preStop drain, plus everything above

The Pipecat Cloud caveat in the second row cuts against the “deploy is instant” assumption in both directions: a routine deploy cannot cut off a session in progress, but when a deploy does not create a new version, warm instances “can keep serving your old code while the deploy reports success”. Pipecat Cloud’s /readyz endpoint (customisable from base image 0.1.14) is the same lever as a Kubernetes readiness probe: an instance reporting not ready receives no new sessions, and “any session already running on that instance is unaffected and continues to completion”.

Which configuration you are promoting between environments is a separate problem, covered in version control and promotion for AI agent config. This page is only about replacing the running process under live calls.

Why the first call after a deploy fails

A deploy has two ends, and the second one is a cold start. Pipecat issue #3769 (19 February 2026, Pipecat 0.0.101 on Google Kubernetes Engine) is titled “First pipecat call after deployment always fails”. In the reporter’s log the module starts loading the Silero VAD model at 16:03:31, logs that all components loaded at 16:03:34, and accepts the first telephony WebSocket at 16:03:37, which then fails while parsing the opening message; “All subsequent calls get connected without any issues.” The reporter closed the issue the next day without a linked fix or a stated cause, so treat it as a symptom report, not a diagnosis.

The defensive pattern is the same whatever the cause: a new pod should not report ready until it can take a call. On LiveKit Cloud the readiness gate is the health check, with 5 minutes allowed for prewarm; on the Build plan, a production agent scaled to zero cold-starts with 10 to 20 seconds before it joins the room. Pipecat Cloud describes about 10 seconds as a best-case cold start and calls it a floor rather than a promise. Self-hosted, point your readiness probe at something that only passes after models and outbound connections are loaded, and make the finish-state test below include a call to a freshly started pod.

The finish-state test: deploy mid-call and the call survives

Run this test after every change to the Dockerfile, the manifest or the framework version.

1. Place a real test call through your carrier and keep it talking past the old grace period (more than 30 seconds if you never changed the default).
2. Trigger the deploy while the call is up.
3. Confirm the old pod enters Terminating and, for LiveKit, that its /worker endpoint still shows the call in active_jobs.
4. Place a second call. It must land on the new pod and connect first time.
5. Hang up the first call yourself. The old pod should exit within seconds of that hang-up, not at the grace deadline.
6. Read the old pod’s last log lines: “draining worker” and a normal shutdown pass; “drain timed out, forcing shutdown”, “exiting forcefully” or a SIGKILL from the kubelet fail.

Then repeat the test with an autoscaler scale-down instead of a deploy. HPA scale-down uses the same termination path, and its default stabilisation window is 300 seconds. Kubernetes also offers a controller.kubernetes.io/pod-deletion-cost annotation to prefer deleting idle pods, but its documentation calls it best effort and warns against updating it frequently from a metric, so it does not replace the drain.

Run the drain yourself, or hand the runtime over

Everything above is doable in-house. The recurring cost is what people underestimate: someone re-reads the framework defaults at every upgrade (one changed from 1,800 to 3,600 seconds between two patch releases), keeps the call cap, the drain and the grace period in step, budgets cluster headroom for a whole ReplicaSet draining for up to an hour, and reruns the mid-call test after every image change.

Your situation	Do this
Fewer than one deploy a week, calls under 5 minutes	Deploy outside call hours, set the grace period from the formula, run the test once per framework upgrade
Daily deploys on LiveKit or Pipecat Cloud	Let the platform drain; own the call cap, the warm-up and the --force and image-tag checks
Self-hosted on Kubernetes, calls over 10 minutes	Full sequence above, explicit drain_timeout, maxUnavailable: 0, preStop drain for any web-server bot
Traffic must stay on your own infrastructure	Self-host, and treat the finish-state test as a release gate rather than a one-off

Zian AI runs its sales agents across phone, SMS, email and WhatsApp, and supports private AI deployment for sales agents on customer infrastructure, where the drain discipline on this page is part of operating the runtime.

Frequently asked questions

Where every figure on this page comes from

Figure	Who published it	Link	Date read
Issue #3020 wording, 25 July 2025; closed 18 August 2025; “default is 1800 now”; “I’m not a livekit dev”	LiveKit Agents GitHub tracker	livekit/agents #3020	8 October 2026
terminationGracePeriodSeconds default 30 seconds; SIGTERM then SIGKILL; preStop runs before TERM	Kubernetes	Pod lifecycle	8 October 2026
Grace countdown begins before the preStop hook; grace covers hook plus container stop	Kubernetes	Container lifecycle hooks	8 October 2026
Terminating pods not counted as available; resources can exceed replicas + maxSurge	Kubernetes	Deployments	8 October 2026
HPA scale-down stabilisation default 300 seconds	Kubernetes	Horizontal Pod Autoscaling	8 October 2026
pod-deletion-cost is best effort	Kubernetes	ReplicaSet	8 October 2026
docker stop default timeout 10 seconds on Linux	Docker	docker container stop	8 October 2026
Shell-form ENTRYPOINT does not pass signals	Docker	Dockerfile reference	8 October 2026
uv forwards most signals to the child on Unix	Astral (uv)	uv: running commands	8 October 2026
Starter Dockerfile CMD ["uv", "run", "src/agent.py", "start"]	LiveKit	agent-starter-python Dockerfile at 76ddabb	8 October 2026
Agent servers stop accepting jobs on SIGTERM; voice apps might need a 10+ minute grace period; longer scale-down stabilisation because servers take time to drain	LiveKit	Self-hosted deployments	8 October 2026
Example manifest terminationGracePeriodSeconds: 600	LiveKit	agent-deployment manifest at fc48d3a	8 October 2026
drain_timeout 3,600 s; shutdown_process_timeout 10 s; session_end_timeout 300 s; drain marks worker full; /worker on port 8081	LiveKit	worker.py at [email protected]	8 October 2026
drain_timeout 1,800 s in 1.6.4 and earlier	LiveKit	worker.py at [email protected]	8 October 2026
Drain skipped in dev mode; second signal force-exits; 3-second escalation watchdog	LiveKit	cli.py at [email protected]	8 October 2026
Release dates: 1.6.5 on 9 July 2026, 1.8.0 on 5 September 2026, 1.8.5 on 6 October 2026	LiveKit	livekit/agents releases	8 October 2026
Issue #6724 opened 6 August 2026, closed 29 August 2026; reproduced on 1.6.0, 1.6.6 and 1.6.8	LiveKit Agents GitHub tracker	livekit/agents #6724	8 October 2026
PR #7034 merged 29 August 2026; present in 1.8.0, absent from 1.7.1	LiveKit Agents GitHub	livekit/agents #7034	8 October 2026
PR #6738 open as at 8 October 2026	LiveKit Agents GitHub	livekit/agents #6738	8 October 2026
PR #7365 open as at 8 October 2026; drain_timeout 0 waits indefinitely	LiveKit Agents GitHub	livekit/agents #7365	8 October 2026
LiveKit Cloud: up to 1 hour for old instances; 5 minutes for health check; 10 to 20 seconds cold start on Build; rollback paid plans only	LiveKit	Deployment management	8 October 2026
Rolling deploys can take as long as your longest session; drain sequence quoted	Pipecat	Running bots in production	8 October 2026
Old image continues until the session concludes; prior configuration during propagation; –force	Pipecat	Pipecat Cloud deployments	8 October 2026
/readyz not ready: running sessions continue to completion	Pipecat	Pipecat Cloud health checks	8 October 2026
About 10 seconds best-case cold start; –max-session-duration	Pipecat	Pipecat Cloud scaling	8 October 2026
Maximum session duration 7,200 s default, 60 to 14,400 s range; bot() cancelled at the cap from base image 0.1.27	Pipecat	Starting Pipecat Cloud sessions	8 October 2026
Development runner is FastAPI started with uvicorn.run() (v1.12.0); runner has “no graceful drain”	Pipecat	runner/run.py at v1.12.0 and Running bots in production	8 October 2026
Issue #3769, 19 February 2026, Pipecat 0.0.101, log times, closed 20 February 2026 by reporter; second comment on cut sockets	Pipecat GitHub tracker	pipecat-ai/pipecat #3769	8 October 2026
uvicorn 0.54.0 shutdown closes connections before the graceful timeout; WebSocket close code 1012	uvicorn maintainers	server.py at 0.54.0 and websockets_sansio_impl.py at 0.54.0	8 October 2026
–timeout-graceful-shutdown definition; 0.54.0 released 25 September 2026	uvicorn maintainers	uvicorn settings and 0.54.0 release	8 October 2026
Remaining TwiML runs after the server closes the stream WebSocket	Twilio	TwiML Stream	8 October 2026
Test results: 1012 in 3 of 3, 1.95–2.00 s, 0.16–0.20 s; drain 1000 in 3 of 3, 8.07 s, 6.85–6.88 s	First-party test by this site, method disclosed above	This page	Run 8 October 2026
Margin of 30 seconds in the formula	Our judgement, not a published figure	This page	8 October 2026