Skip to main content

Manage Catalyst Projects

A Catalyst project is the top-level container that groups workloads, components, configurations, subscriptions, and managed infrastructure. Each project exposes its own HTTP and gRPC Dapr endpoints, ingress and egress addresses, and role assignments — making projects the main unit of isolation between environments, teams, or applications in Catalyst.

Manage from the Catalyst console

Every operation on this page — creating projects, selecting them, updating managed services, and deleting them — can also be done from the Catalyst Web UI at catalyst.diagrid.io.

📦Logical container

A project groups all Dapr resources (workloads, components, subscriptions, configurations) and provides shared endpoints for the workloads inside it.

🔒Isolation boundary

Projects have their own network addresses, role scopes, and optionally managed Pub/Sub, Key/Value, and Workflow stores.

When to create a new project​

Use a project to draw an isolation boundary. Common patterns:

  • Per-environment — separate dev, staging, and prod projects so resources, components, and API keys never cross boundaries.
  • Per-team or per-business-unit — give each team its own project and scoped roles so they can only manage their own apps.
  • Per-application — for workloads with stricter isolation requirements (regulated data, tenant-specific infrastructure, or dedicated resiliency policies).

A project lives inside a Region. On Catalyst Cloud the region is managed by Diagrid; on Catalyst Enterprise Self-Hosted you can create and deploy your own regions.

Create a project​

Use the Diagrid CLI to create a project:

diagrid product use catalyst

# Create a project in the organization's default region
diagrid project create my-project --wait

# Or target a specific region explicitly
diagrid project create my-project --region my-region --wait

# Create a project that opts into the managed Pub/Sub broker and KV store
diagrid project create my-dev-project \
  --deploy-managed-pubsub \
  --deploy-managed-kv \
  --wait

Without --region, projects are provisioned in the organization default region. On Catalyst Cloud the default is managed by Diagrid; on Catalyst Enterprise Self-Hosted you set it yourself with diagrid region use — creating a region does not auto-set it.

See diagrid project create and diagrid product use for the full flag set.

Managed infrastructure

Managed Pub/Sub, Key/Value, and Workflow stores are hosted by Catalyst and available as backing infrastructure for development without provisioning your own. See Managed services.

Inspect a project​

Every project exposes the network details your applications need to connect:

diagrid project get my-project

See diagrid project get for output formats. The output includes:

  • HTTP endpoint and gRPC endpoint — the URLs your Dapr SDKs should point at.
  • Ingress address — the public network address of the Catalyst Data Plane for this project.
  • Egress address — the source IP address Catalyst uses when calling back into your applications. If your app lives behind a firewall, this is the IP you need to allow. Add it to your firewall, API gateway, or load balancer allowlists.
  • Region — the region hosting the project.
  • Managed services status — whether the managed Pub/Sub, KV, or workflow stores are enabled.

See the Connect to Catalyst guide for how these values are used.

Select the active project​

Most Diagrid CLI commands operate on a currently selected project. Set it with:

# List all projects in the org
diagrid project list

# Select the active project for subsequent commands
diagrid project use my-project

See diagrid project list and diagrid project use.

You can also target a specific project per command with --project:

diagrid app list --project my-staging-project

Update a project​

Update managed infrastructure or other project settings:

# Enable the managed KV store on an existing project
diagrid project update my-project --deploy-managed-kv --wait

See diagrid project update for the full flag set.

Delete a project​

Deleting a project tears down all apps, components, subscriptions, and managed infrastructure inside it. Make sure no workloads still depend on the project before deleting.

diagrid project delete my-project --wait

See diagrid project delete.

Scoping roles to a project​

Catalyst supports both global and project-scoped roles. Use project-scoped roles to let a developer team manage only their own project without granting access to the entire organization:

# Editor role scoped to a single project
diagrid apikey create --name dev-team-key \
  --role cra.diagrid:editor:projects:my-dev-project \
  --duration 2592000

See diagrid apikey create for the full role syntax and examples.

See Manage Access for the full list of roles and API keys for scoping patterns.

Enable verifiable execution​

Verifiable execution cryptographically signs every event in a workflow's history, giving you a tamper-evident record that can be independently verified. Because signing builds on the workload identity and mTLS that Catalyst provides by default, there is nothing to configure in your application code — you enable it on the project, and it applies to every workflow that runs there:

# Workflow history signing can only be enabled at project creation
diagrid project create payments --enable-workflow-history-signing --wait

Signing is a permanent commitment for the workflows created under the project: a signed workflow must always run on signing-enabled infrastructure, you cannot retroactively sign an existing unsigned workflow, and disabling signing would prevent already-signed histories from loading. The signing adds negligible CPU cost, though the extra signature and certificate data increases the storage each workflow step consumes.

See diagrid project create for the full flag set.

Limits and quotas​

Each project has limits that apply to the resources it contains — the number of workloads, components, pub/sub subscriptions, managed service data size, and request rate. These limits are counted per region: each region maintains its own independent quotas, so resources in different regions don't affect each other's limits. On Catalyst Cloud the free-tier limits apply per Cloud region; on Catalyst Enterprise the limits apply per Self-Hosted region.

Per-project request-rate limits and per-app body-size limits can be tuned at the app level — see Manage IDs for the --max-body-size flag and related controls.

What's next​

Last updated on