# Managed services

Catalyst-managed services are backing infrastructure that Catalyst provisions, runs, scales, and patches for you inside your [project](https://docs.diagrid.io/concepts/organisations-and-projects) boundary. Your workloads 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](https://docs.diagrid.io/concepts/components).

If you are new to Catalyst's identity model, [IDs](https://docs.diagrid.io/concepts/identities) are the per-workload identities that components and managed services bind to.

## What "managed" means

With a [component](https://docs.diagrid.io/concepts/components) 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 workload 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 apps; 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.

```mermaid
flowchart LR
  APP1(Orders app)
  APP2(Billing app)
  subgraph Catalyst
    ID1(orders ID)
    ID2(billing ID)
    KV[(Managed KV)]
    BROKER@{ shape: das, label: "Managed Pub/Sub" }
  end
  APP1-->ID1
  APP2-->ID2
  ID1-->KV
  ID1-.->BROKER
  BROKER-.->ID2
```

## 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](https://docs.diagrid.io/operate/plans-and-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 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 apps listed in the component's `scopes`. See [Components](https://docs.diagrid.io/concepts/components#scoping-to-apps). |
| **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. Managed Pub/Sub and Managed KV are set when the project is created and cannot be added afterwards, from either the CLI or the Catalyst console; the Managed Workflow Store can also be enabled on a project that already exists. Once enabled, the service appears as a normal component bound to every app in the project. See [Manage managed services](https://docs.diagrid.io/operate/project-operations/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](https://docs.diagrid.io/references/catalyst/cli-reference/workflow/purge) the instance.

See [Plans & Support](https://docs.diagrid.io/operate/plans-and-support#catalyst-cloud-quotas-and-limits) for the current size limits.

## Access scoping

Managed services live at the project level: enabling one makes it available to every app 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"; you can later restrict access using the standard component-update flow described in [Components](https://docs.diagrid.io/concepts/components#scoping-to-apps). 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 apps 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](https://docs.diagrid.io/operate/plans-and-support#catalyst-cloud-quotas-and-limits); on [Catalyst Enterprise](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted) the ceiling depends on the storage capacity allocated to the region during installation.

## What's next

- [Components](https://docs.diagrid.io/concepts/components) — Bring your own Redis, Postgres, Kafka, or Vault into Catalyst.
- [Dapr APIs](https://docs.diagrid.io/concepts/dapr-apis) — Understand the building-block APIs that managed services and components both expose.
- [Manage managed services](https://docs.diagrid.io/operate/project-operations/managed-services) — Enable, browse, and operate Managed Pub/Sub, Managed KV, and the Managed Workflow Store.