Dapr Component Config Generator

Dapr components are pluggable building blocks that define external resources your application uses — state stores, pub/sub brokers, secret stores, and bindings. Each component is a Kubernetes custom resource (or a YAML file in self-hosted mode) that tells the Dapr sidecar how to connect to a specific backend like Redis, Kafka, or Azure Service Bus. Dapr configuration is a separate concept: it controls the Dapr runtime's behavior itself — tracing, middleware, concurrency limits, and secrets scoping. Think of components as the 'what to connect to' and configuration as the 'how the sidecar behaves.'

A Dapr state store component lets your app save and retrieve key-value state via the Dapr State Management API (dapr.io/v1.0/state/{storeName}) without writing backend-specific code. Redis is the best choice for development and low-latency caching scenarios. PostgreSQL is ideal for durable, transactional state with SQL guarantees. DynamoDB and Azure Blob Storage suit cloud-native production workloads in their respective clouds. MongoDB fits document-oriented state. For Dapr Actors (virtual actor pattern), your chosen state store must be marked actorStateStore: true — Redis and many others support this. Choose based on your consistency needs: some stores support strong consistency, others eventual consistency only.

Dapr pub/sub components abstract message brokers behind a unified API. Your service publishes events to a topic via POST /v1.0/publish/{pubsubName}/{topicName}, and subscribes by declaring subscriptions (either programmatically or via Subscription CRs). The Dapr sidecar handles broker connection, retry, and delivery to your app's HTTP/gRPC endpoint. This means you can switch from Redis Streams in development to Kafka or Azure Service Bus in production by changing only the component YAML — your application code stays identical. Dapr handles at-least-once delivery guarantees and CloudEvents envelope by default.

Scoped components restrict which applications can access a component. By adding app IDs to the scopes list in a Component spec, only those apps' Dapr sidecars will load that component. Apps not in the scope list will behave as if the component doesn't exist — their API calls to that component will return errors. Scoping is useful for multi-tenant clusters where different teams share a namespace: you can deploy separate Redis instances for different app groups while preventing cross-team access. Without scopes, all apps in the component's namespace can use it.

Never put sensitive values (passwords, connection strings, API keys) as plain values in Component YAML stored in Git. Dapr supports two secure patterns: First, use secretKeyRef to reference a Kubernetes Secret or a Dapr secret store — the sidecar resolves the secret at runtime. Second, configure a Dapr secret store component (Kubernetes secrets, HashiCorp Vault, Azure Key Vault, AWS Secrets Manager) and then reference it in other components via auth.secretStore. The Dapr secret store approach centralizes secret management and works in non-Kubernetes environments. For Kubernetes, the simplest approach is using secretKeyRef pointing to a standard Kubernetes Secret created separately via kubectl or your secrets management pipeline.

The Dapr sidecar is a separate process (or container in Kubernetes) that runs alongside your application. When your app starts, Dapr injects a sidecar that reads all Component resources in the namespace (filtered by scopes) and establishes connections to the configured backends. Your app communicates with the sidecar via localhost HTTP (port 3500 by default) or gRPC — never directly with Redis, Kafka, or other backends. The sidecar handles connection pooling, retries, observability (tracing, metrics), and API translation. In Kubernetes, Dapr uses a mutating webhook to auto-inject the sidecar container when you annotate your Deployment with dapr.io/enabled: 'true' and dapr.io/app-id: 'my-app'.