Components

A component is a YAML spec that wires a Dapr building-block API (such as state, pub/sub, or secrets) to backing infrastructure you operate. You author one component per backing instance (your Redis, your Kafka topic namespace, your Vault), declare which App IDs may use it, and Catalyst handles the runtime wiring.

If you would rather not provision and operate the backing infrastructure yourself, Catalyst also offers managed services for Pub/Sub, Key/Value, and the Workflow Store. The application-side API is identical either way; only the component declaration changes.

Component lifecycle

Every component moves through three roles:

• Define. The spec names what the component connects to and how. A type value (for example state.postgresql, pubsub.kafka, secretstores.hashicorp.vault) selects the integration; the rest of the spec carries the connection details and options that integration needs.
• Scope. The spec lists the App IDs that are allowed to use the component. A component with no listed App IDs is unusable.
• Bind. At runtime, when a scoped App ID calls a Dapr building-block API, Catalyst resolves the call to the defined component and forwards the request to the backing infrastructure.

Project scoping

Components are project-scoped resources. A component declared in one project is not visible to App IDs in any other project. Projects are the unit of isolation for components, App IDs, and managed services alike. To run the same logical workload across two projects (for example, staging and production), you declare the component twice, once per project, typically with different backing infrastructure behind each.

Scoping to App IDs

The scopes field on a component lists the App IDs that may use it. Scoping serves three purposes:

• Access control. An App ID that is not listed cannot read from or write to the component, even within the same project.
• Multi-tenancy. Different App IDs in the same project can point at different infrastructure instances of the same component type (for example, two separate Postgres databases, each scoped to one App ID).
• Isolation. Sensitive backing infrastructure (a billing database, a secret store) can be kept reachable only by the workloads that need it.

Managed services interact with scopes differently. Enabling Managed Pub/Sub or Managed KV provisions a real component (named pubsub or kvstore) whose scopes field defaults to empty, which is interpreted as every App ID in the project; you can restrict that later through the same component-update flow as any BYO component. The Managed Workflow Store is the exception: it is wired implicitly and is not exposed as a scopable component.

Secret resolution and credentials

Most components carry credentials in their spec: a connection string, an API token, or a private key. Catalyst always handles those through a built-in managed secret store, and you can optionally point it at your own.

Transparent secret extraction. When you create a component, Catalyst inspects the spec against the Dapr component schema for that type. Fields the schema marks as sensitive (passwords, tokens, connection strings) are automatically extracted into a Catalyst-managed secret store before the spec is persisted. Plaintext credentials never land in the control-plane database; the stored spec carries references to the secret store instead. The CLI, console, and diagrid apply flows behave identically.

Bring-your-own secret store. If you already keep credentials in HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or another secret backend, you can declare it as a secretstores component and reference its keys from other components' specs. Catalyst resolves the reference at runtime through your secret store instead of its own. This is additive to the built-in managed store, not a replacement: the two can coexist within a project.

Operational details (rotation, the per-secret-store metadata, and how to migrate from one approach to the other) live in Manage secrets.

Resiliency at the component boundary

Timeouts, retries, and circuit breakers attach to the edge between an App ID and a component. Catalyst enforces these policies in the runtime, so application code does not have to implement them. See Policies for the concept and diagrid resiliency for the spec.

The supported catalog

Catalyst supports the full set of Dapr components: state stores, pub/sub brokers, bindings, secret stores, configuration stores, conversation providers, and HTTP middleware. The exhaustive list, including the required and optional metadata fields for each type, is in the Components reference.

What's next

📦

Managed services

Skip the BYO provisioning step with Catalyst-hosted Pub/Sub, KV, and Workflow Store.

⚙️

Manage components

Create, scope, update, and operate components via CLI, declarative YAML, or the Catalyst console.

🛡️

Policies

Apply timeouts, retries, and circuit breakers at the App ID and component boundary.