Component schema

The basic schema for a Dapr component

Dapr defines and registers components using a CustomResourceDefinition. All components are defined as a CRD and can be applied to any hosting environment where Dapr is running, not just Kubernetes.


kind: Component
  version: v1
  initTimeout: [TIMEOUT-DURATION]
  ignoreErrors: [BOOLEAN]
  - name: [METADATA-NAME]
    value: [METADATA-VALUE]


Field Required Details Example
apiVersion Y The version of the Dapr (and Kubernetes if applicable) API you are calling
kind Y The type of CRD. For components is must always be Component Component
metadata - Information about the component registration Y The name of the component prod-statestore
metadata.namespace N The namespace for the component for hosting environments with namespaces myapp-namespace
spec - Detailed information on the component resource
spec.type Y The type of the component state.redis
spec.version Y The version of the component v1
spec.initTimeout N The timeout duration for the initialization of the component. Default is 5s 5m, 1h, 20s
spec.ignoreErrors N Tells the Dapr sidecar to continue initialization if the component fails to load. Default is false false
spec.metadata - A key/value pair of component specific configuration. See your component definition for fields

Templated metadata values

Metadata values can contain template tags that are resolved on Dapr sidecar startup. The table below shows the current templating tags that can be used in components.

Tag Details Example use case
{uuid} Randomly generated UUIDv4 When you need a unique identifier in self-hosted mode; for example, multiple application instances consuming a shared MQTT subscription
{podName} Name of the pod containing the Dapr sidecar Use to have a persisted behavior, where the ConsumerID does not change on restart when using StatefulSets in Kubernetes
{namespace} Namespace where the Dapr sidecar resides combined with its appId Using a shared clientId when multiple application instances consume a Kafka topic in Kubernetes
{appID} The configured appID of the resource containing the Dapr sidecar Having a shared clientId when multiple application instances consumer a Kafka topic in self-hosted mode

Below is an example of using the {uuid} tag in an MQTT pubsub component. Note that multiple template tags can be used in a single metadata value.

kind: Component
  name: messagebus
  type: pubsub.mqtt3
  version: v1
    - name: consumerID
      value: "{uuid}"
    - name: url
      value: "tcp://admin:public@localhost:1883"
    - name: qos
      value: 1
    - name: retain
      value: "false"
    - name: cleanSession
      value: "false"

Further reading