Catalyst Managed Services

Catalyst includes first-party managed infrastructure that you can enable per project without provisioning anything yourself. These managed services are ideal for development, testing, and production workloads that fit within the per-project limits.

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. 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.

📣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.
• 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 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

# 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 and diagrid 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 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.

# 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 for the full CLI reference.

Use the managed broker as the pubsubname in your subscriptions:

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:

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

See diagrid call publish.

Topics explorer

The Catalyst console at 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.

# 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 for store management and diagrid 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.

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.

# 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 and diagrid workflow list.

Once the managed workflow store is enabled, it is automatically wired up to your project's workflow apps.

A project has one workflow store. It is either the managed store or a state component of your own with the actorStateStore metadata set to true, never both. While the managed store is enabled, Catalyst refuses to create a component with actorStateStore set to true. To use your own store, see Migrating to your own infrastructure.

For complete workflow operation commands — pause, resume, terminate, rerun, purge, raise events — see the workflow CLI reference.

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 for the full tour.

Limits

The managed services are sized to comfortably handle development and small-to-medium production workloads. On 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, the limits depend on the capacity of the region's underlying storage.

See Plans & Support for the full quota table and higher-tier options.

Migrating to your own infrastructure

When a workload outgrows the managed services, move it to a component backed by your own infrastructure.

Pub/Sub and Key/Value

1. Create a component backed by your chosen broker or state store.
2. Update the component's scopes to include the workload's App ID.
3. Point your application at the new component name, in place of pubsub or kvstore. This covers every place the name appears: publish and subscribe calls, declarative subscriptions, and state calls.

The Dapr APIs are the same whichever component backs them, so your application logic does not change. Only the component name does. If your application reads the name from configuration, the move is a configuration change. If the name is written in the code, change it there.

Workflows

A project has one workflow store, so you replace the managed store rather than add a second one.

1. Let running workflows finish. Workflow state is not copied between stores, so a workflow that is still running in the managed store does not continue in the new one.

2. Disable the managed workflow store:

   diagrid project update my-project --enable-managed-workflow=false --wait

3. Create a state component backed by your own database, with the actorStateStore metadata set to true.

Your workflow code does not change, because it never names the workflow store.

Your store now holds each run's execution state and full history. Catalyst also keeps a record of each run in a database it manages in your project's region: its status, timing, input, output, error details, and a summary of its steps. The Catalyst console and the workflow APIs use this record to search, list, and visualize runs, and read the full step history from your store. Because the record includes each run's input and output, that data is also stored outside your own database. Like the rest of your workflow data, the record stays in the data plane that runs your workflows and is never replicated outside it. With self-managed BYOC or Enterprise Server, you own the database that holds it. With BYOC: Managed, it runs in your cloud account. Purging a run removes it from both.

What's next

• Components — wire backing infrastructure to apps.
• Develop Workflows — build durable workflows on top of the workflow store.
• Develop Dapr APIs — language-specific guides for state and pub/sub.