Skip to main content
This page describes the generated LiveKit project and its target settings.

Deploy to LiveKit Cloud

Start here to create a deployment, choose its destination, supply credentials, and update its code or secrets.
A target with an inbound SIP route writes three more files. sip-inbound-trunk.json and sip-dispatch-rule.json are the records that create the inbound trunk and the dispatch rule, which sends calls on your number to this agent. telephony-setup.sh creates both. Inbound calls covers them.

Target fields

Write these inside targets.<name> in targets.yaml. The name is your target instance name, used by --target and the build/<name>/ output folder.
string
required
Use livekit for this target. Omission is refused.
string
required
An exact x.y.z framework version from the supported window. Omission and unsupported versions are refused; there is no automatic upgrade.
string
Accepts python. If omitted, the generated project still uses Python.
string
Required for telephony: the stem of a file under connections/, using sip or connector with a supported carrier. See connection fields. Omit for a browser-only package; a connection without phone use is refused.
string or list of strings
Accepts us-east, eu-central, or ap-south, as one region or a list with no empty or duplicate entries. Unknown names are refused at validation. If omitted, no region is passed and platform placement applies. The region is chosen at first create and cannot be changed by a redeploy. See deployment regions.
map of model definitions
Overrides keyed by existing model names from agent.yaml, using the model fields. Omit to use the package’s models. An override replaces the entry, except that omitted pace, endpointing_delay, semantic_endpointing, and prompt_suffix carry forward. An override cannot author pace or a different prompt_suffix.
map of strings
Known LiveKit package names mapped to semantic versions. Unknown names and versions below the catalog floor are refused. Omit to use the catalog pins.
integer
Positive values are refused on LiveKit. Omit this Pipecat setting; Unmute configures no LiveKit warm-instance count. Zero also emits no setting.

agent.py

One worker file: your prompts, the agent classes, the tasks and task groups if you declared any, the tool functions, and the session wiring. The entry agent becomes a class, named after your agent, and the generated README says which one it is. It imports LiveKit and your handlers. Nothing from Unmute.

Run it without Unmute

start needs a running LiveKit server and its LIVEKIT_URL, LIVEKIT_API_KEY, and LIVEKIT_API_SECRET in the environment. Add --log-format colored for readable logs while developing, which is what the generated development Compose file does.

Dependencies are pinned

The generated pyproject.toml follows your target’s framework version, selected providers, and tracing settings. Use the target fields to change supported pins, then compile again.

Deploy

Follow Deploy to LiveKit Cloud for the complete sequence: package preparation, destination selection, runtime values, first deployment, updates, and a test interaction. The guide also covers secrets-only changes. Use the generated build/livekit/ directory as the build context. Keep secret values out of the image. Supply the runtime values listed by its .env.example and runbook through the platform’s secret store.

The worker’s agent name

The worker registers under the package’s name: joined to the target it was compiled for, so name: acme-support on a target called livekit registers acme-support-livekit. A SIP dispatch rule matches a worker by that string, and the emitted sip-dispatch-rule.json and telephony-setup.sh both name the same one. Renaming the package changes the worker name. Follow the rename steps to update the SIP dispatch rule too.
Do not edit files in build/. Change the source package and compile again.

Where to go next

The SLNG deployment body

The third target: a hosted deployment body instead of a project.

Going live

What to do with the project you were handed.