# Catalyst Managed Services

Catalyst includes first-party managed infrastructure that you can enable per [project](https://docs.diagrid.io/operate/platform-operations/projects) without provisioning anything yourself. These managed services are ideal for development, testing, and production workloads that fit within the per-project limits.

:::tip Manage from the Catalyst console

Every operation on this page — enabling managed services on a project, browsing topics and keys, inspecting workflow executions — can also be done from the Catalyst Web UI at [catalyst.diagrid.io](https://catalyst.diagrid.io). The console additionally provides **visual data explorers** for each managed service: a Pub/Sub topics explorer, a Key/Value store visualizer, and a dedicated [Workflows view](https://docs.diagrid.io/operate/project-operations/workflows).

:::

- Managed Pub/Sub — Catalyst-hosted message broker. Use it as a pubsub component in your project.
- Managed Key/Value — Catalyst-hosted key-value store. Use it as a state-store component.
- Managed Workflow Store — Catalyst-hosted state store for durable workflow execution.

Managed services let you build end-to-end on Catalyst in minutes — no external Redis, Postgres, or Kafka required. The managed broker's component name is always `pubsub`. The managed KV store's component name is `kvstore`. Reference these names directly from your subscriptions, state calls, and application code.

## When to use managed services

Managed services are a good fit when:

- You want to build and validate Catalyst workloads without standing up your own pub/sub, database, or workflow store.
- You are running small-to-medium workloads that fit within the project-level size and throughput [limits](https://docs.diagrid.io/operate/plans-and-support#plan-limits).
- You want a single point of operation — Catalyst upgrades, patches, scales, and monitors the infrastructure on your behalf.

For production workloads beyond the limits of the managed services, or when you need to bring existing infrastructure under Catalyst management, use a [component](https://docs.diagrid.io/operate/project-operations/components) backed by your own state store, broker, or database.

## Enable managed services on a project

Managed services are opt-in per project. Managed Pub/Sub and managed Key/Value are set when you create the project; the managed workflow store can also be enabled on a project that already exists.

| Managed service | At project creation | On an existing project |
| --------------- | ------------------- | ---------------------- |
| Pub/Sub | `--deploy-managed-pubsub` | Not supported |
| Key/Value | `--deploy-managed-kv` | Not supported |
| Workflow store | `--enable-managed-workflow` | `--enable-managed-workflow` |

```bash
# Create a project with managed Pub/Sub and KV
diagrid project create my-project \
  --deploy-managed-pubsub \
  --deploy-managed-kv \
  --wait

# Enable the managed workflow store on an existing project
diagrid project update my-project \
  --enable-managed-workflow \
  --wait
```

See [`diagrid project create`](https://docs.diagrid.io/references/catalyst/cli-reference/project/create) and [`diagrid project update`](https://docs.diagrid.io/references/catalyst/cli-reference/project/update).

Once enabled, the managed service appears as a normal component in your project and can be referenced by apps.

To use managed Pub/Sub or managed Key/Value in a project created without them, create a new project with the flags set, or add a [component](https://docs.diagrid.io/operate/project-operations/components) backed by your own broker or store. Neither the CLI nor the Catalyst console can add either service to an existing project.

### When a region does not offer a managed service

Which managed services a region offers depends on how that region was installed, so this applies mainly to private and dedicated regions. Catalyst treats the three services differently when you create a project:

- `--deploy-managed-kv` and `--enable-managed-workflow` fail with an error, and the project is not created.
- `--deploy-managed-pubsub` is dropped. The project is created without a managed broker and the command still reports success, so run `diagrid pubsub list` afterwards to confirm the broker exists.

## Managed Pub/Sub

The managed Pub/Sub broker supports standard Dapr pub/sub semantics — publish, subscribe, topic routing, and declarative subscriptions. Each project gets one broker, named `pubsub`, with its own topic namespace.

```bash
# List the brokers in the project
diagrid pubsub list

# Show details for the managed broker
diagrid pubsub get pubsub

# List topics on the managed broker
diagrid pubsub topic list --pubsub pubsub
```

Topics are created on first publish. There is no command to create one, and `diagrid pubsub create` creates a broker rather than a topic — a project is limited to a single broker, so that call fails once the managed broker exists.

See [`diagrid pubsub`](https://docs.diagrid.io/references/catalyst/cli-reference/pubsub) for the full CLI reference.

Use the managed broker as the `pubsubname` in your subscriptions:

```yaml
apiVersion: cra.diagrid.io/v1beta1
kind: Subscription
metadata:
  name: orders-subscription
spec:
  pubsubname: pubsub
  topic: orders
  routes:
    default: /orders
  scopes:
    - my-app
```

### Publishing and subscribing

Your applications use the standard Dapr Pub/Sub API — no code changes are needed when migrating from a self-managed broker. For a quick smoke test:

```bash
diagrid call publish my-topic \
  --component pubsub \
  --id my-app \
  --data '{"message": "hello"}'
```

See [`diagrid call publish`](https://docs.diagrid.io/references/catalyst/cli-reference/call/publish).

### Topics explorer

The Catalyst console at [catalyst.diagrid.io](https://catalyst.diagrid.io) includes a **Pub/Sub topics explorer** for the managed broker. Use it to browse topics, inspect current subscribers, and see recent traffic without leaving the UI.

## Managed Key/Value

The managed KV store is a Catalyst-hosted state store suitable for small-to-medium key-value workloads. It supports the full Dapr State API, including get, set, delete, transactions, and queries.

```bash
# List managed KV stores in the project
diagrid kv list

# Runtime get/set/delete via the Dapr State API
diagrid call state set order-123 --component kvstore --id my-app --value '{"status":"paid"}'
diagrid call state get order-123 --component kvstore --id my-app
diagrid call state delete order-123 --component kvstore --id my-app

# Execute a multi-item transaction
diagrid call state transaction --component kvstore --id my-app \
  --operations upsert:order-123:paid,delete:order-122
```

See [`diagrid kv`](https://docs.diagrid.io/references/catalyst/cli-reference/kv) for store management and [`diagrid call state`](https://docs.diagrid.io/references/catalyst/cli-reference/call/state) for runtime get/set/delete/transaction.

The managed KV exposes query filters on key, creation date, and expiry, which you can use both from the CLI and from the [Catalyst console](https://docs.diagrid.io/operate/project-operations/observability).

### Key/Value visualizer

The Catalyst console includes a **Key/Value store visualizer** that lists every key in the managed KV store, with inline viewing of values, metadata, and expiry. Filter by key prefix, creation date, or TTL to inspect and debug state without writing CLI queries.

## Managed Workflow Store

Durable workflows require a state store to persist execution state, history, and timers. The managed workflow store is a first-party state store tuned for workflow workloads — it's the simplest way to run durable workflows on Catalyst without provisioning your own PostgreSQL, Redis, or other backing database.

```bash
# Start a workflow instance against an App ID using the managed store
diagrid workflow start order-processing \
  --id my-workflow-app \
  --instance-id order-123 \
  --data '{"orderId": "123"}'

# List recent executions
diagrid workflow list --id my-workflow-app
```

See [`diagrid workflow start`](https://docs.diagrid.io/references/catalyst/cli-reference/workflow/start) and [`diagrid workflow list`](https://docs.diagrid.io/references/catalyst/cli-reference/workflow/list).

Once the managed workflow store is enabled, it is automatically wired up to your project's workflow apps. You can also pair it with a self-managed state store by creating a standard `state` component and scoping it to specific workflow apps instead.

For complete workflow operation commands — pause, resume, terminate, rerun, purge, raise events — see the [workflow CLI reference](https://docs.diagrid.io/references/catalyst/cli-reference/workflow).

### Workflows view

The Catalyst console includes a dedicated **Workflows view** for browsing every execution persisted in the managed workflow store — with execution graph, history, inputs/outputs, and one-click rerun/resume/purge. See [Workflows](https://docs.diagrid.io/operate/project-operations/workflows) for the full tour.

## Limits

The managed services are sized to comfortably handle development and small-to-medium production workloads. On [Catalyst Cloud](https://docs.diagrid.io/operate/hosting/catalyst-cloud) the free-tier limits apply per project:

| Resource | Cloud free-tier limit |
|----------|-----------------------|
| Diagrid Pub/Sub broker max data size | 512 MB |
| Diagrid Key/Value store max data size | 512 MB |
| Diagrid Workflow store max data size | 512 MB |

On [Catalyst Enterprise](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted), the limits depend on the capacity of the region's underlying storage.

See [Plans & Support](https://docs.diagrid.io/operate/plans-and-support) for the full quota table and higher-tier options.

## Migrating to your own infrastructure

When a workload outgrows the managed services, migrate it to your own infrastructure without application code changes:

1. Create a [component](https://docs.diagrid.io/operate/project-operations/components) backed by your chosen state store, broker, or database.
2. Update scopes to include the workload's ID.
3. Update your application's `pubsubname` or `statestoreref` to point at the new component.

The Dapr programming model hides the component choice from your app, so the migration is a configuration change rather than a code change.

## What's next

- [Components](https://docs.diagrid.io/operate/project-operations/components) — wire backing infrastructure to apps.
- [Develop Workflows](https://docs.diagrid.io/develop/workflows) — build durable workflows on top of the workflow store.
- [Develop Dapr APIs](https://docs.diagrid.io/develop/dapr-apis) — language-specific guides for state and pub/sub.