Catalyst architecture
This page is under development. Content is being authored — check back soon.
Catalyst is a managed runtime for Dapr. Operationally it has two parts: a control plane that exposes the management surface (CLI, console, API) and a data plane that runs the actual Dapr runtime alongside your workloads. Your applications and agents run wherever you choose to run them; Catalyst hosts the runtime and the backing infrastructure they talk to.
Control plane and data plane
Stub — populate. Explain what runs in each plane, and how the four hosting models (Catalyst Cloud, Enterprise Dedicated, Self-Hosted, and Air-Gapped) differ in where each plane lives.
What Catalyst hosts vs. what you host
Stub — populate. A table or two-column visual: Catalyst manages the runtime, backing stores, control plane APIs, and the console; the customer hosts application code and agents.
Request lifecycle
Stub — populate. How a single API call flows: application → SDK → Catalyst endpoint → data plane (Dapr runtime + backing infrastructure) → response. Include the role of App ID authentication and mTLS.
Durable workflow lifecycle
Stub — populate. How a workflow execution is checkpointed, what gets persisted at each step, and what happens on crash/restart. See Durable execution for the full mechanics.
See also
- Catalyst and Dapr — relationship between Catalyst and the open-source Dapr runtime
- Application Identities — how workloads authenticate against the data plane
- Hosting options — operational view of the same architecture
- Durable execution — how workflow state is persisted and replayed