Managed services
Catalyst-managed services are backing infrastructure that Catalyst provisions, runs, scales, and patches for you inside your project boundary. Your applications consume them through the standard Dapr building-block APIs (state, pub/sub, workflow), in the same way they would consume a bring-your-own component.
If you are new to Catalyst's identity model, App IDs are the per-application identities that components and managed services bind to.
What "managed" means
With a component you bring your own Redis, Postgres, Kafka, or Vault; you own the connection string, credentials, capacity planning, and upgrades. With a managed service Catalyst owns all of that. You enable the service on the project, and it is immediately available to every App ID in that project. Catalyst generates and maintains the underlying component on your behalf, so you do not author YAML or rotate credentials for it.
Managed services are intentionally opinionated: one instance per project, one set of capacity limits, and fixed component names where one is needed.
The catalog
📣Managed Pub/Sub
Catalyst-hosted message broker for publish/subscribe messaging. Default component name: pubsub.
🗂️Managed KV
Catalyst-hosted state store for key-value workloads, transactions, and queries. Default component name: kvstore.
🔁Managed Workflow Store
Catalyst-hosted state store tuned for durable workflow execution, history, and timers. Wired implicitly to your project's workflow App IDs; there is no user-facing component name to reference.
Each service implements the same Dapr API contract as its BYO counterpart, so application code that targets the Dapr State or Pub/Sub SDK works against either without modification.
Managed vs bring-your-own
| Dimension | Managed service | Bring-your-own component |
|---|---|---|
| Provisioning | Enabled per project with one CLI flag; no infrastructure to stand up. | You provision the underlying store or broker and supply its connection details. |
| Credentials | None to manage. Catalyst handles internal authentication. | You supply connection strings and secrets; Catalyst extracts sensitive fields into a managed secret store. |
| Component name | Fixed for Managed Pub/Sub (pubsub) and Managed KV (kvstore); the Managed Workflow Store is wired implicitly and has no user-facing name. | You choose the name, the type (e.g. state.postgresql, pubsub.kafka), and any number of instances per project. |
| Capacity ceiling | Fixed per-project limits. See Plans & Support. | Bounded by the infrastructure you provisioned. |
| Scoping | Managed Pub/Sub and Managed KV are provisioned as real components (pubsub, kvstore) with an empty scopes field, so every App ID can use them by default; you can later restrict them like any BYO component. The Managed Workflow Store is wired implicitly and is not scopable. | Restricted to the App IDs listed in the component's scopes. See Components. |
| Typical use | Development, demos, small-to-medium production workloads, workflows. | Production workloads with existing infrastructure, strict tenancy isolation, or capacity beyond the managed tier. |
| Migration | Swap to a BYO component without changing application code; only the statestoreref or pubsubname in your subscriptions and Dapr SDK calls changes. | Same model in reverse: point applications at the managed component name to migrate in. |
Lifecycle
How provisioning works
Managed services are opt-in per project, enabled at project creation or via a project update. The CLI and Catalyst console expose flags for each service; once enabled, the service appears as a normal component bound to every App ID in the project. See Manage managed services for the exact commands.
How scaling works
Each managed service has a fixed per-project capacity ceiling. Catalyst handles internal scaling, upgrades, and patching within that ceiling, so there are no instance counts, replicas, or autoscaler thresholds to tune. Workloads that approach the ceiling should migrate to a BYO component.
Retention
- Managed Pub/Sub. Messages are retained per topic up to a size cap (50 MB per topic by default) with no time-based expiry. Within that window, subscribers can read at their own pace; once a topic exceeds the size cap, the oldest messages roll off in Kafka-style log order.
- Managed KV. Values are persisted until you delete them or until their TTL expires. The store supports the full Dapr State API, including transactions and queries.
- Managed Workflow Store. Execution state, history, and timers are retained for the lifetime of each workflow instance, until you purge the instance.
See Plans & Support for the current size limits.
Access scoping
Managed services live at the project level: enabling one makes it available to every App ID in that project by default. The two storage services that surface as components (Managed Pub/Sub and Managed KV) ship with an empty scopes field, which Catalyst interprets as "every App ID"; you can later restrict access using the standard component-update flow described in Components. The Managed Workflow Store is wired implicitly and stays project-wide.
Cross-project access is never granted. A managed service in one project is not reachable from App IDs in another project; the project boundary is the unit of isolation.
Limits and quotas
Managed services are sized for development and small-to-medium production workloads. The current free-tier ceilings are listed in Plans & Support; on Catalyst Enterprise the ceiling depends on the storage capacity allocated to the region during installation.