Deployment overview

A voice agent is a long-lived session: it holds a pipeline, a conversation and a connection for the whole call. That shapes where it can run. The transport decides most of it:

• SmallWebRTC sends media over UDP. It needs a long-lived server process with UDP reachable: Bun, Node or Deno on a VM, a container or a bare-metal host.
• WebSocket sends audio frames over TCP. It runs on the same servers, and also on Cloudflare Workers and Durable Objects, and on Vercel's Bun runtime.
• Cloudflare Realtime lets users connect over WebRTC to Cloudflare's SFU, which streams their audio to the bot as PCM over WebSockets. The bot can then run in a Worker or Durable Object (see Cloudflare Realtime).

On a server, @pipedog/runner gives you Pipecat's runner routes (the prebuilt client, WebRTC signalling, telephony webhooks and WebSockets) as one fetch handler: createRunnerApp() builds it and serve() listens on Bun, Node or Deno. See Servers.

Pipecat's own deployment guides (Fly.io, Cerebrium, Modal, Pipecat Cloud) assume a Python process per session. The same patterns apply to a pipedog server: one process (or one Durable Object) per session, and a cap on concurrent sessions.

Before you deployCopy Anchor Link

• Authenticate the endpoints. pipedog's endpoints don't authenticate. Put a check in front of them, as in Frameworks: Authentication.
• Provider keys stay on the server. Services read their keys from options you pass; read them from the environment or the host's secret store, never from the client.
• Turn detection and size. Local Silero VAD and Smart Turn load ONNX models (about 100 MB of runtime and models). On Workers, use provider-side turn detection instead. See Turn detection.
• Tracing. Set OTEL_EXPORTER_OTLP_ENDPOINT to export spans. See Metrics & tracing.
• Runtimes. The compatibility table lists where each package is verified.