Overview
The Pipecat development runner provides a unified way to run voice AI bots across multiple transport types. It handles infrastructure setup - creating Daily rooms, managing WebRTC connections, and routing telephony calls.Installation
What is a Runner?
A runner in Pipecat refers to a “bot runner”, an HTTP service that provides a gateway for spawning bots on-demand. It’s the component that enables your bot to run by providing it with server infrastructure and connection details like rooms and tokens. A bot runner typically creates transport sessions (like Daily WebRTC rooms), generates authentication tokens for both bots and users, spawns new bot processes when users request sessions, and manages bot lifecycle and cleanup. Think of it as the bridge between incoming user connections and your bot logic.How the Development Runner Works
The development runner operates as a FastAPI web server that automatically discovers and executes your bot code. When you start the runner, it creates the necessary web endpoints and infrastructure for your chosen transport type.- WebRTC connections: It serves a built-in web interface where users can connect directly as well as an endpoint to create new WebRTC sessions
- Daily integration: It provides endpoints that create new rooms and tokens and redirect users to join them
- Telephony providers: For Twilio, it sets up webhook endpoints that handle incoming calls and establish WebSocket connections for audio streaming
Pipecat Cloud Ready
The bot runner is designed to be cloud-ready, meaning that you can run the same bot code locally and deployed to Pipecat Cloud without any modifications. It automatically handles the differences in transport setup, providing you with the flexibility to test locally using a free transport, like SmallWebRTCTransport, but run in production using Daily or telephony transports.Building with the Runner
Now let’s build a practical example to see how this works. The key insight is that your bot code is structured into two parts: the core bot logic that works with any transport, and the entry point that creates the appropriate transport based on the runner arguments. Here’s the basic structure:run_bot()
function contains your actual bot logic and is transport-agnostic. The bot()
function is the entry point that the runner calls - it creates the appropriate transport and passes it to your bot logic. This separation allows the same bot code to work across different transports.
When you run this with python bot.py
, the development runner starts a web server and opens a browser interface at http://localhost:7860/client
. Each time someone connects, the runner calls your bot()
function with WebRTC runner arguments.
Supporting Multiple Transports
To make your bot work across different platforms, you can detect the transport type from the runner arguments and create the appropriate transport. Here’s how to support both Daily and WebRTC:Understanding Runner Arguments
Runner arguments are how the runner communicates transport-specific information to your bot. The runner determines which transport to use based on the command-line arguments, then creates the appropriate runner arguments:DailyRunnerArguments
: Containsroom_url
,token
(Optional),body
(Optional) for joining Daily roomsSmallWebRTCRunnerArguments
: Containswebrtc_connection
for local WebRTC sessionsWebSocketRunnerArguments
: Containswebsocket
for telephony connections
handle_sigint
: Whether the bot should handle SIGINT (Ctrl+C) signals (managed automatically)handle_sigterm
: Whether the bot should handle SIGTERM signals (managed automatically)
handle_sigint
and handle_sigterm
are development only features and cannot
be used when deploying to Pipecat Cloud.from pipecat.transports.services.daily import ...
) inside the conditional blocks. This ensures that transport-specific dependencies are only required when that transport is actually used, making your bot more portable.
RunnerArguments
is the base class for all runner arguments. It provides a
common interface for the runner to pass transport-specific information to your
bot.Environment Detection
When building bots that work both locally and in production, you often need to detect the execution environment to enable different features. The development runner sets theENV
environment variable to help with this:
Environment Values
The development runner automatically sets environment variables based on how your bot is running:- Local development:
ENV=local
(set by the development runner) - Production/Cloud deployment:
ENV
is not set or has a different value
All Supported Transports
The development runner supports five transport types, each designed for different use cases:WebRTC (-t webrtc
)
Local WebRTC connections with a built-in browser interface. Perfect for development and testing.
SmallWebRTCRunnerArguments
webrtc_connection
: Pre-configured WebRTC peer connection
Daily (-t daily
)
Integration with Daily for production video conferencing with rooms, participant management, and Pipecat client compatibility.
DailyRunnerArguments
room_url
: Daily room URL to jointoken
: Authentication token for the roombody
: Request data from /start endpoint (dict)
GET /
: Web interface for creating roomsPOST /start
: RTVI-compatible endpoint for programmatic access
Telephony (-t twilio|telnyx|plivo
)
Phone call integration through telephony providers. Requires a public webhook endpoint and provider credentials.
- Twilio:
TWILIO_ACCOUNT_SID
,TWILIO_AUTH_TOKEN
- Telnyx:
TELNYX_API_KEY
- Plivo:
PLIVO_AUTH_ID
,PLIVO_AUTH_TOKEN
WebSocketRunnerArguments
websocket
: WebSocket connection for audio streaming
Command Line Options
The development runner accepts several command-line arguments to customize its behavior:Key Arguments
--transport
/ -t
: Determines which transport infrastructure to set up
webrtc
: Local WebRTC with browser interfacedaily
: Daily.co integration with room managementtwilio
,telnyx
,plivo
: Telephony provider integration
--proxy
/ -x
: Required for telephony transports. This should be a publicly accessible hostname (like yourbot.ngrok.io
) that can receive webhooks from telephony providers.
--direct
/ -d
: Special mode for Daily that bypasses the web server and connects your bot directly to a Daily room. Useful for quick testing but not recommended for production use.
--esp32
: Enables SDP (Session Description Protocol) modifications needed for ESP32 WebRTC compatibility. Must be used with a specific IP address via --host
.
Environment Variables
Different transports require different environment variables: Daily:DAILY_API_KEY
: Daily API key for creating rooms and tokensDAILY_SAMPLE_ROOM_URL
(Optional): Existing room URL to use
TWILIO_ACCOUNT_SID
,TWILIO_AUTH_TOKEN
: Twilio credentialsPLIVO_AUTH_ID
,PLIVO_AUTH_TOKEN
: Plivo credentialsTELNYX_API_KEY
: Telnyx API key
Simplifying with the Transport Utility
While the manual approach gives you full control, thecreate_transport
utility provides a much cleaner way to handle multiple transports. Instead of writing conditional logic for each transport type, you define transport configurations upfront and let the utility handle the selection:
- Detects the telephony provider from WebSocket messages
- Configures the appropriate serializer (Twilio, Telnyx, or Plivo)
- Sets up authentication using environment variables
- Handles WebRTC and Daily transport creation
RTVI Integration
The development runner provides RTVI (Real-Time Voice Interface) compatible endpoints for the Pipecat client SDKs. This allows you to use the Pipecat client libraries locally during development as well as when deployed to Pipecat Cloud.The /start
Endpoint
For Daily transports, the runner automatically creates a /start
POST endpoint that:
- Creates Daily rooms and tokens using your
DAILY_API_KEY
- Spawns bot instances with request
body
data - Returns connection details in RTVI-compatible format
dailyRoomProperties
are not yet handled by the runner.Accessing Request Data in Your Bot
Thebody
field from the /start
request is passed to your bot through DailyRunnerArguments.body
:
RTVI Client Example
You can use RTVI client libraries to connect to your local development runner:The
/start
endpoint is only available for Daily transports (-t daily
).
WebRTC and telephony transports use different connection methods.Quick Reference
Transport | Command | Access | Environment Variables |
---|---|---|---|
WebRTC | python bot.py | http://localhost:7860/client | None |
Daily | python bot.py -t daily | http://localhost:7860 | DAILY_API_KEY , DAILY_SAMPLE_ROOM_URL (Optional) |
Daily Direct | python bot.py -d | Direct connection | DAILY_API_KEY , DAILY_SAMPLE_ROOM_URL (Optional) |
Twilio | python bot.py -t twilio -x proxy.ngrok.io | Phone calls | TWILIO_ACCOUNT_SID , TWILIO_AUTH_TOKEN |
Telnyx | python bot.py -t telnyx -x proxy.ngrok.io | Phone calls | TELNYX_API_KEY |
Plivo | python bot.py -t plivo -x proxy.ngrok.io | Phone calls | PLIVO_AUTH_ID , PLIVO_AUTH_TOKEN |
ESP32 WebRTC | python bot.py -t webrtc --esp32 --host <ESP32_IP> | ESP32 WebRTC connection | None |
Examples
For practical examples of using the development runner with different transports, check out the following:Runner Examples
Explore the examples for different ways to use the development runner with
various transports.