Pipecat Enterprise

Run Pipecat Cloud agents in your own Kubernetes cluster with Pipecat Enterprise: what stays managed, what you operate, what leaves your cluster.

is Pipecat Cloud with your agents running on infrastructure you own. You get it by registering a .

A is a Pipecat Cloud region that runs in a Kubernetes cluster you operate. Pipecat Cloud remains the control plane: you deploy agents, start sessions, and read logs and session records exactly as you do for , while your agents execute on your infrastructure — in your network, next to your data.

The pipecat cloud CLI, the REST API, the Python SDK, and the agent image format are identical to — Pipecat Cloud’s documentation covers them for both offerings. This section covers only what you operate: the cluster, the region package, and the data that stays inside it.

are part of . To enable them for your organization, contact Daily.

What stays the same

A appears in your organization’s region list and is used like any other region:

• Deploy with pipecat cloud deploy --region <your-region> or the dashboard, from any container registry.
• Start sessions with the REST API or Python SDK, on any transport — Daily WebRTC, WebSocket, or telephony providers.
• Observe sessions, CPU and memory metrics, and agent logs in the dashboard, the CLI, and the API.
• Reference secrets by set name, and scale with the same min_agents / max_agents controls.

What changes

Area	Self-hosted regions
Where agents run	Daily’s infrastructure	Your Kubernetes cluster
Secrets	Uploaded to Pipecat Cloud as secret sets	Created by you in your cluster and referenced by name — values never leave your cluster
Agent sizing	Fixed agent profiles	Explicit CPU and memory, or your own profiles
CPU architecture	arm64	Whatever your nodes provide; you declare amd64, arm64, or both
WebSocket endpoint	wss://api.pipecat.daily.co/ws/…	A public endpoint you expose and register
Agent logs	Stored by Pipecat Cloud	Stored in your own log store, optional and off by default
Supporting services	Managed	You provide a broker and, optionally, a log store; the package bundles development-grade versions of both
Scaling ceiling	Your organization’s replica limit	No platform-imposed ceiling — your cluster’s capacity
Billing	Per agent-minute by profile	Per your enterprise agreement; agent-minutes in self-hosted regions are not metered by profile

How your region connects

The region package installs a small set of platform components into your cluster alongside your agents. One of them, the region agent, opens an outbound, mutually authenticated TLS connection to Pipecat Cloud and keeps it open. Everything the control plane does in your region — creating deployments, starting sessions, querying logs — travels over that connection. Nothing connects inbound to your cluster, and the certificates involved are issued during enrollment and renewed automatically. Session traffic — WebSocket and telephony audio — goes straight to your region and never touches the control plane. The architecture page walks through both planes.

What leaves your cluster

Running a keeps your data in your region while giving Pipecat Cloud enough to manage it:

• Always: session records and per-session metrics (start and end times, outcome, CPU and memory usage), and the region’s own health — connected agents, component versions, certificate expiry.
• By default, on request: a read-only diagnostic snapshot of the platform components, which Daily support can pull when you ask for help. It never includes secret values or your agents’ logs.
• Only when you enable it: agent log lines, and only when someone in your organization queries them.
• Never: session audio or media, secret values, environment variables, or the contents of your configuration.

The full breakdown is on What Pipecat Cloud Can See.

Shared with Pipecat Cloud

These work identically in a . They live in the Pipecat Cloud section because they are the same for both offerings.

Agent Images

Containerizing an agent: Dockerfile structure and base images.

Deploying Agents

pipecat cloud deploy, cloud image builds, and deployment configuration.

Secrets

Secret sets and how deploys bind to them. See also referenced secrets.

Scaling

min_agents / max_agents and how the pool responds to load.

Session API

Sending HTTP requests to a running session through the session API proxy.

Regions

How regions work, and how a joins the list.

Getting started

1. Get enabled

   Self-hosted regions are enabled per organization by Daily. Contact us to get started.

2. Prepare a cluster

   Check the requirements — a conforming Kubernetes cluster, two platform prerequisites, and outbound network access.

3. Register and install

   Follow Set up a region: register the region, mint an enrollment token, and install the region package with Helm. You’ll need pipecatcloud or later.

4. Deploy an agent

   Deploy to the new region exactly as you would to any other, and start a session.