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.
state.py is present when the package has a State class. Unmute does not write the SIP inbound trunk or dispatch rule files for this target yet. For a phone number, write those records yourself. LiveKit over Twilio shows the shape.

​
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.

​
The modules

The project imports the unmute-core library from PyPI (unmute-core[livekit]). The library holds the call logic: state, tasks, tools, telemetry and the model call. The files here only wire it to LiveKit. agent.py is the entry point. It creates the worker and runs one session. spec.py reads agent.json and builds the objects the library runs: the tools, each agent’s tasks, the prefetch and the greeting. It checks every name and path at import, so a broken package fails at start and never during a call. speech.py holds the speech and model bindings. state.py is your own State class, copied as you wrote it, and present when the package has one. Prompts live in agent.json. Edit agent.yaml and compile again rather than these files.

​
Run it without Unmute

start needs a running LiveKit server and its LIVEKIT_URL, LIVEKIT_API_KEY, and LIVEKIT_API_SECRET in the environment. If the worker’s environment sets HTTPS_PROXY, the worker would send its LiveKit connection through that proxy too. To reach the LiveKit server directly, add its host to NO_PROXY. Model and speech calls still use the proxy. Under unmute dev the host is livekit_server, so a worker image that sets a proxy also needs NO_PROXY=livekit_server.

​
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, so use it in the rule you write. 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.