Diagrid Managed Services

Diagrid 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 Diagrid Web 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 Diagrid Web Console 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

Diagrid-hosted message broker. Use it as a pubsub component in your project.

🗂️Managed Key/Value

Diagrid-hosted key-value store. Use it as a state-store component.

🔁Managed Workflow Store

Diagrid-hosted state store for durable workflow execution.

Managed services let you build end-to-end on Diagrid 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 Diagrid 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 — Diagrid 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 Diagrid management, use a component backed by your own state store, broker, or database.

Enable managed services on a project

Managed Pub/Sub and managed Key/Value are opt-in, and you set them when you create the project. The managed workflow store is on by default: every new project gets it, so workflows and agents run without any setup. You can turn it off, or back on, for 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	On by default. --disable-managed-workflow opts out	--enable-managed-workflow to turn on, --enable-managed-workflow=false to turn off

# Create a project with managed Pub/Sub and KV; the managed workflow store is included
diagrid project create my-project \
  --deploy-managed-pubsub \
  --deploy-managed-kv \
  --wait

# Turn the managed workflow store back on for a project that has it off
diagrid project update my-project \
  --enable-managed-workflow \
  --wait

--enable-managed-workflow on diagrid project create is deprecated, because the store is now the default.

In the Diagrid Web Console, the Development environment and Non-development environment cards both create the project with the managed workflow store. The cards choose only whether the project gets managed Pub/Sub and Key/Value.

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 Diagrid Web 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. Diagrid treats the three services differently when you create a project:

• --deploy-managed-kv fails 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.
• The managed workflow store is added only when the region supports workflows. For a region group, every member region must support them. Otherwise the project is created without the store, and its workflows need a store of your own. diagrid project get shows whether the project has it.

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 Diagrid Web 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 Diagrid-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 Diagrid Web Console.

Key/Value visualizer

The Diagrid Web 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 Diagrid 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.

New projects get the managed workflow store by default, and it is wired up to the project's workflow apps automatically.

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, Diagrid refuses to create a component with actorStateStore set to true.

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

Workflows view

The Diagrid Web 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.

Use your own workflow store

Turning off the managed workflow store is an advanced setup. Do it only when workflow state must live in a database you operate, for example to keep signed workflow history in your own PostgreSQL. You then run, scale, and back up that database yourself.

Turn the managed store off when you create the project:

Where	How
CLI	diagrid project create <name> --disable-managed-workflow
Control plane API	Set defaultWorkflowStoreEnabled: false in the project spec
Diagrid Web Console	Not available. Create the project with the CLI or the API.

Then create a state component backed by your own database, with the actorStateStore metadata set to true. Use a store type with workflow support: in the console's component catalog, its card shows the Workflow capability.

diagrid project create my-project --disable-managed-workflow --wait

diagrid component create workflow-store \
  --type state.postgresql \
  --metadata connectionString="<your-connection-string>" \
  --metadata actorStateStore=true \
  --wait

Until a store exists, workflow calls fail with an error saying the Workflow API has not been configured, and Diagrid refuses to create a durable agent.

For a project that already exists, turn the managed store off with diagrid project update my-project --enable-managed-workflow=false or --disable-managed-workflow, and back on with --enable-managed-workflow. Running workflows do not move between stores. See Workflows under migration.

In the control plane API, defaultWorkflowStoreEnabled in the project spec sets the store explicitly: true turns it on and false turns it off. If a create request leaves it out, the project gets the default.

Your store holds each run's execution state and full history. Diagrid 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 Diagrid Web 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.

Limits

The managed services are sized to comfortably handle development and small-to-medium production workloads. On Diagrid 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 self-managed BYOC, 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, as in Use your own workflow store.

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

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.