Skip to main content

Catalyst architecture

Catalyst is a managed runtime for distributed applications, durable workflows, and AI agents, built on the open-source Dapr runtime. Architecturally it has three layers: a control plane for management, a data plane where the runtime lives (executing API calls, orchestrating durable workflows, and persisting their state), and the applications and agents you run yourself. Where each layer lives depends on the hosting model, but the conceptual architecture is the same — Catalyst owns the runtime and the backing infrastructure, you own the code.

The three layers​

Catalyst control plane​

The control plane is the management surface. You interact with it through the Catalyst console, the diagrid CLI, and the Catalyst control plane API. It stores resource definitions — App IDs, components, policies, projects, managed services — and reconciles them into the data plane. The control plane is never on the path of a runtime API call: configuration flows from control plane to data plane, but application payloads do not flow through it.

Catalyst data plane​

The data plane is where every runtime API call from your applications terminates. It has three parts:

  • Platform services — the services Catalyst runs to operate the data plane. The Gateway is the regional endpoint your applications connect to over TLS — it authenticates incoming requests and routes them to the Dapr Server that represents the calling App ID. It is composed of various internal services like the Catalyst agent which reconciles configuration from the control plane and configures every other service in the data plane.
  • Dapr Servers — the runtime that executes your API calls. Workflow orchestrations, pub/sub fan-out, state reads and writes, service invocation, and the rest of the Dapr APIs run here. Each Dapr Server carries a SPIFFE identity and uses mTLS to communicate to other Dapr Servers or backing infrastructure.
  • Backing infrastructure — the stores and brokers behind the APIs: the managed Pub/Sub broker, managed key-value store, and managed workflow store that Catalyst provisions for you, plus any bring-your-own components you wire up (Redis, Kafka, Postgres, an LLM provider, and so on).

Your applications and agents​

Your application and agent code runs wherever you choose: containers, virtual machines, physical machines, or serverless functions. Catalyst never executes this code; it only authenticates calls from it and serves API responses back to it. Apps reach the data plane using a Dapr SDK for their language, or by calling the available HTTP or GRPC APIs directly.

Where each layer runs depends on the hosting model. On Catalyst Cloud and Catalyst Enterprise: Dedicated, Diagrid runs both planes; on Self-Hosted, Diagrid runs the control plane and you run the data plane in your own infrastructure; on Air-Gapped, both planes run in your infrastructure with no outbound connectivity to Diagrid. The layering does not change — only the trust and network boundaries between layers do. See Hosting options for the four topologies side by side.

How a request flows​

Take the simplest case: an orders application saves an order to the managed key-value store. The application code is a single SDK call, but the request crosses several steps inside the data plane, with identity and policy enforced at every hop.

  1. App → SDK. The application calls save_state on the Dapr SDK. The SDK serialises the call into a Dapr HTTP or gRPC request.
  2. SDK → Gateway. The SDK opens a TLS connection to the regional Catalyst Gateway and attaches the App ID API token the application bound at startup.
  3. Gateway → Dapr Server. The Gateway authenticates the token, resolves it to an App ID, and routes the request to the Dapr Server that represents that App ID inside the data plane.
  4. Policy gate. Before the Dapr Server reaches a component, the policies attached to the App ID are evaluated — access scoping, payload restrictions, rate limits. A request that fails policy is rejected here and never touches the backing store.
  5. Component → backing infrastructure. The Dapr Server invokes the kvstore component, which writes the value to the managed key-value store. The Dapr Server authenticates downstream with its own SPIFFE SVID over mTLS, so the call has a verifiable principal on both sides.
  6. Response. The result returns up the same path: backing store → component → Dapr Server → Gateway → SDK → application.

Two properties of this flow are worth holding on to:

  • The control plane is never in the path — even though the App ID, the component definition, and the policy rules all originate there, the data plane resolves them locally.
  • The identity model is end-to-end: the application authenticates to the Gateway with its App ID token, and the Dapr Server mutually authenticates downstream with its own SPIFFE identity, so no hop relies on a shared secret or an unauthenticated trust assumption. See Security for the full identity model and trust-boundary breakdown.

The flow looks the same for any other Dapr API — publishing to a topic, invoking another app, calling an LLM through the conversation API, scheduling a job — only the component and backing infrastructure at the end of the chain change.

How workflow state survives​

A workflow or AI agent is a regular application that calls the Dapr workflow API; the orchestration itself runs inside the Dapr Servers and its state lives in the Catalyst-managed workflow store, not in your application memory. Each step the workflow takes — an activity scheduled, an activity completed, a timer set, an external event received — is persisted as an event in the workflow's history before the next step proceeds.

If the Dapr Server or your application restarts, the workflow resumes by replaying its history from the managed store. Long-running workflows that wait days for a human approval or an external signal consume no compute while paused; they wake up when the event arrives, replay from history, and continue from the next step. The mechanics — event sourcing, deterministic replay, activities, child workflows — are covered in depth in Durable execution.

See also​

  • Hosting options — the four hosting topologies and where each plane runs in each.
  • Security — trust boundaries, mTLS and SPIFFE identity, and the shared-responsibility split.
  • Dapr APIs — the building-block API surface the data plane exposes.
  • Application Identities — how App IDs bind workloads to the data plane.
  • Durable execution — how workflow and agent state survives restarts.
  • Catalyst and Dapr — relationship between Catalyst and the open-source Dapr runtime.
Last updated on