Skip to main content
A splits Pipecat Cloud into two planes. The control plane is Pipecat Cloud itself — the API, dashboard, CLI backend, and the Region gateway your cluster connects to — and it stays on Daily’s infrastructure. The data plane is everything that runs a session, and it runs in your cluster. This page describes what each plane does, what it can see, and how traffic moves between them, because two questions come up on almost every evaluation: do I have to expose the control plane to my users? (no) and what does the control plane do beyond billing? (quite a lot).

​
The two planes

Self-hosted region architecture: developer and application on the left, the Pipecat Cloud control plane above your cluster's data plane in the middle, end users connecting directly to your region on the right

Management traffic flows over one outbound connection from your cluster. End users connect to your region directly, whatever the transport.

​
The control plane

The control plane is the same Pipecat Cloud your team already uses; a is one more region in it. It owns:
  • Identity and access — your organization, its members, API keys, and personal access tokens. Your users authenticate to your application; only your servers hold Pipecat Cloud API keys, exactly as with .
  • The agent catalog — every agent’s definition: image, secrets and image-pull secrets by name, sizing, scaling limits, architecture, WebSocket authentication mode. pipecat cloud deploy and the dashboard write here, and the control plane turns each deploy into instructions for your region.
  • Session starts — POST /start is a control-plane call. It authenticates the API key, checks the agent and region, mints the WebSocket session token when the transport needs one, and returns a session ID plus, for WebSocket transports, the wsUrl under your region’s public endpoint. The call takes milliseconds and no audio passes through it.
  • Session records and observability — the sessions list, per-session outcome and CPU/memory metrics, the region’s health and event history, and the log query interface (which fetches from your region on demand).
  • Region lifecycle — registration, enrollment, certificate issuance and renewal, the platform image registry, and the record of which platform version each region runs.
  • Billing and entitlements — including the entitlement that allows your organization to run self-hosted regions.
Nothing in the control plane is reachable from your cluster’s users, and nothing in it needs to be exposed by you. Your end users interact with your application and, for WebSocket transports, with your region’s public endpoint.

​
The data plane

The region package installs the data plane into two namespaces of your cluster: a system namespace (pipecat-system) for the platform components, and a workloads namespace (pipecat-agents) for your agents. Every session runs entirely inside the data plane: the activation service picks a pod, the pod runs your pipeline, and the pipeline talks to the AI providers you configured, directly from your network. The control plane learns that the session started, ended, and what it cost in CPU and memory — never what was said.

​
How traffic flows

Management (deploys, session starts, log queries, diagnostics) rides one connection: the region agent dials out to the control plane’s Region gateway on port 8443 with a certificate issued at enrollment, and the control plane sends its requests back down that connection. There is no inbound path into your cluster, no VPN, and no static IP to allow-list on your side. Sessions never use that connection:
  • WebSocket and telephony. The client — your browser app, or a telephony provider such as Twilio — connects to wss://<your public endpoint>/ws/…, which your ingress or gateway routes to the activation service in your cluster. The audio stays between the caller and your data plane. The control plane’s only involvement is the /start call that returns the URL (and, for provider-direct dial-in, none at all — the provider’s configuration names your endpoint directly). See WebSockets and telephony.
  • Daily WebRTC. The agent pod joins the Daily room from inside your cluster, as it does in every region; media flows between the participants and Daily’s WebRTC infrastructure, not through the Pipecat Cloud control plane.
Platform images are pulled by your cluster from the Pipecat Cloud registry using a credential delivered at enrollment; your agent images come from whatever registry you already use.

​
What each plane can see

The full list, including how to turn each channel off, is on What Pipecat Cloud Can See.

​
Why keep a control plane at all

Because it is the product. The control plane is what makes a behave like every other region: the same pipecat cloud deploy, the same dashboard, the same session API, the same secrets-by-name model, the same session records and metrics, one place to see all of your regions, and the region’s certificates, platform upgrades, and diagnostics handled for you. Running the data plane yourself changes where sessions execute and where data rests — it does not change how you operate agents.