Skip to main content
Deploy an Unmute package to LiveKit Cloud, Pipecat Cloud, or SLNG, then update it from the same authored files. Validation checks your declarations; compilation turns them into what the selected target runs. On this page:

​
Quickstart

Run these commands from the directory that will hold your new package:
Terminal
With no saved organization manifest, named initialization creates a LiveKit package. Run unmute init without a name for the interactive target choices. A saved manifest guides creation through its allowed choices; see initialization. Already have a package? Start inside it at unmute validate. To change its target, follow Switching a package, including the model changes that target needs. --target selects a declared instance; it does not convert the package to another framework. Then follow one hosting guide: The target guides supply the authentication, destination, region, and secret steps those commands need. unmute deploy currently pushes SLNG only.

​
1. Keep the package as the source

unmute validate checks the package against each selected target. unmute compile performs those checks too, then writes build/<target-instance>/. No provider credentials are needed to compile. On LiveKit and Pipecat, that directory includes a Dockerfile, pyproject.toml, runtime code, .env.example, and README.md. Pipecat also gets pcc-deploy.toml. SLNG gets an agent body and a runbook, with no Python project or container to build. Read the generated README.md for your build’s commands and required values. compile-report.json records resolved models, dependencies, sizing, environment names, and target limits. Generated files hold names, never credential values. Recompilation replaces the selected build directory. Keep authored code outside build/. The compiler preserves .env, livekit*.toml, and samples/*.json; it does not preserve arbitrary edits or added modules.

​
2. Choose models and regions

Models live under models in agent.yaml. Agents bind a named reasoning and voice entry; the package also supplies listening and turn detection where its pipeline uses them. For example, this is the reasoning entry from the current scaffold. Merge it into the existing models.think block; it is one supported choice:
agent.yaml
​
supported provider name
required
Selects an integration for this model role and target. See the role pages below.
​
string
The provider’s model identifier. Requiredness and defaults depend on the integration; copy a supported binding from its role page.
​
object
Provider settings for this binding. Omit to use the integration’s defaults. These are not an unrestricted runtime configuration API.
Unmute checks provider support and known invalid settings. It transforms some settings and forwards others to the provider integration; the compile report shows the resolved binding. Validation cannot prove a model exists in your account or that every forwarded parameter will succeed. The role pages link to the provider’s parameter and credential documentation. For a target-specific choice, use a model override. An override replaces the provider, model, and parameters. Omitted shared behavior settings, such as turn timing, carry forward. Keep three different region choices separate: A hosting region does not move a provider’s inference service. See target fields and the SLNG router for their respective settings.

​
3. Separate accounts and credentials

For a code target, declare environment names separately from provisioning their values. Merge the names your package reads into this list:
agent.yaml
​
list of UPPER_SNAKE names
Inventory of environment names the generated project reads, including non-secret configuration. Declaring a name does not create or populate a host secret. SLNG derives its Vault requirements from the compiled body instead.
After compiling, make a deployment file from that target’s .env.example. Fill only the names read by the deployed agent. Some routes also list values for a separately hosted helper; follow the comments rather than uploading the whole development environment. For a handler that reads these two names, a minimal file has this shape. Replace the placeholders privately before using it:
.env.deploy (outside the build directory)
Keep this file out of source control and the uploaded build context. Use a secret manager or a private editor to fill values; do not put them in command arguments, generated code, or image layers. See Credentials for the fields that read environment names. Call variables hold conversation data. Prompt interpolation is not a way to deliver credentials. Updating a deployed value also does not create or revoke its provider key; manage that key with its issuing provider.

​
4. Deploy and verify

Each hosting guide separates first creation, later code updates, and secrets-only changes. It also explains how the host finds the existing agent: LiveKit, Pipecat, SLNG. Check each stage separately:
  1. Validation passes: the package fits the target. Provider access remains untested.
  2. The build finishes: the host has an image or agent body. Check readiness next.
  3. The worker is ready: open a new session through the selected host and transport.
  4. A full interaction works: speak a short question, confirm the input was received, and hear a relevant answer.
  5. The application works: exercise a tool or task that matters to your agent, then end the session.
A greeting proves output works; it does not prove microphone input or tool credentials work. Use host status and logs from the target guide to locate the failed stage. Keep transcript and credential values out of diagnostic reports. For phone calls, deploy first, then finish the carrier setup. unmute dev is the local browser workflow, not a deployed phone test.

​
5. Update the agent

Change the authored prompt, tool, model, or configuration, then run from the package directory:
Terminal
Follow the target’s update command using the existing deployment identity. Code targets build a new image for changed code or compiled settings. SLNG’s unmute deploy validates and recompiles automatically before pushing. A changed value under an existing environment name needs the host’s secrets-only workflow. Adding a new required name also changes the package’s inventory, so compile and deploy that source change. Check a new session after either update. --target livekit replaces only build/livekit/. Deploying from another build directory can ship stale code, names, or requirements. Compile the instance you intend to deploy.

​
Except changing its name

The package’s name joined to its target instance becomes the deployment name. A rename is an identity change, and phone routing may still point at the old one. Renaming a target also changes its build directory. On LiveKit, recover the existing agent config in that new directory before updating; compilation does not move it from the old folder. Follow the rename steps for LiveKit, Pipecat, or SLNG before changing a production name.

​
Advanced

​
Add only the code you need

Start with native declarations and tools. Use a webhook for an HTTP service or MCP for a supported remote tool server. Use a local Python handler for logic inside the generated LiveKit or Pipecat process. Sharing Python helpers explains the supported single-source-file pattern and the limit on separate imported modules. Arbitrary module trees and data files are not copied into the build. Declared knowledge documents have their own supported inclusion path. There is no authored lifecycle-hook API or custom Dockerfile hook. LiveKit’s target pins can change versions of recognized dependencies within supported bounds; they cannot add arbitrary packages. Pipecat does not support those overrides. Per-tool dependency declarations are refused on both code targets. Use the compiler-owned build files for the native workflow. An SDK that needs an extra package or a custom startup service has no durable package extension point today; consider a remote tool service instead.

​
Hosting the generated container yourself

The managed-host pages cover the native deployment commands. Operating the container yourself also means supplying networking, credentials, monitoring, and session draining. A LiveKit worker connects out to LiveKit Server. The server needs public media connectivity and trusted TLS; SIP adds its own signaling and media service. Follow LiveKit’s self-hosting documentation. For self-hosted Pipecat browser calls, the generated SmallWebRTC configuration adds no ICE servers. Cross-network use needs a supported STUN/TURN setup that Unmute does not currently expose as an authored deployment option.

​
Troubleshooting

​
Where to go next

LiveKit Cloud

Create a cloud agent, update it, and manage its secrets.

Pipecat Cloud

Deploy the generated project to a chosen organization and region.

SLNG

Push an agent body and resolve its hosted dependencies.

Python tools

Keep reusable tool logic in the authored package.