# Component & Resiliency Builders
Create Dapr components and resiliency policies using visual, guided interfaces. The builders simplify configuration, validate inputs, and generate correct YAML manifests.
---
## Why Use Builders?
- Simplify Configuration — No need to remember component schemas, field names, authentication patterns, or resiliency policy syntax. Builders guide you through each step with auto-completion for cluster resources like apps, components, and namespaces.
- Prevent Errors
- Learn Best Practices
- Customize & Deploy — Override Dapr defaults, set custom retry strategies, configure circuit breakers and timeouts. Generate validated YAML files ready for deployment to your Kubernetes cluster.
---
## Component Builder
Create Dapr component manifests for state stores, pub/sub, bindings, secrets, and more with a step-by-step visual interface.
### Overview Video
[Introducing the Dapr Component Builder](https://www.youtube.com/watch?v=JXjh8IWXac0)
### Accessing Component Builder
**Location:** Dapr Ops Dashboard Console side menu → **"Component Builder"**
### Creating Components: Step-by-Step
**1. Select Component Type**
Choose what type of component you want to create:
**State Store**
**Purpose:** Persist and retrieve application state
**Common implementations:**
- Redis
- PostgreSQL
- CosmosDB
- Azure Table Storage
- AWS DynamoDB
- MongoDB
**Use cases:**
- Session management
- Shopping carts
- User preferences
- Application cache
**Pub/Sub**
**Purpose:** Asynchronous messaging between services
**Common implementations:**
- Redis Streams
- Apache Kafka
- Azure Service Bus
- AWS SNS/SQS
- Google Cloud Pub/Sub
- RabbitMQ
**Use cases:**
- Event broadcasting
- Service decoupling
- Message queues
- Event-driven architectures
**Bindings**
**Purpose:** Trigger or invoke external systems
**Common implementations:**
- HTTP endpoints
- Cron schedules
- Kafka
- Azure Event Hubs
- AWS SQS
- MQTT
**Use cases:**
- Scheduled jobs
- External system integration
- IoT device communication
- Webhook triggers
**Secret Stores**
**Purpose:** Retrieve secrets securely
**Common implementations:**
- Kubernetes Secrets
- Azure Key Vault
- AWS Secrets Manager
- HashiCorp Vault
- GCP Secret Manager
**Use cases:**
- Database credentials
- API keys
- Certificates
- Configuration secrets
**2. Choose Implementation**
Select the backing infrastructure resource:
**Examples:**
**For State Store:**
- Redis
- PostgreSQL
- MySQL
- MongoDB
- CosmosDB
- DynamoDB
**For Pub/Sub:**
- Redis Streams
- Kafka
- RabbitMQ
- Azure Service Bus
- Google Cloud Pub/Sub
**Tips:**
- Use what you already have deployed
- Consider consistency requirements
- Check performance characteristics
- Review [Dapr component docs](https://docs.dapr.io/reference/components-reference/)
**3. Configure Authentication**
Choose authentication method and provide credentials:
**Connection String**
**Most common for:**
- Redis
- PostgreSQL
- MySQL
- SQL Server
**Format:**
```yaml
metadata:
- name: connectionString
value: "host=localhost user=postgres password=secret db=mydb"
```
**Best practice:** Use secret references
```yaml
metadata:
- name: connectionString
secretKeyRef:
name: db-credentials
key: connectionString
```
**Access Keys**
**Most common for:**
- Azure services
- AWS services
- CosmosDB
**Example:**
```yaml
metadata:
- name: accountName
value: "mystorageaccount"
- name: accountKey
secretKeyRef:
name: azure-secret
key: storage-key
```
**IAM/Managed Identity**
**Most common for:**
- AWS (IAM roles)
- Azure (Managed Identity)
- GCP (Service Accounts)
**Example:**
```yaml
metadata:
- name: awsRegion
value: "us-east-1"
# No credentials - uses IAM role
```
**Benefits:**
- No secrets in configuration
- Automatic credential rotation
- Better security posture
**Certificates**
**Most common for:**
- Kafka with TLS
- MQTT with mutual TLS
- gRPC services
**Example:**
```yaml
metadata:
- name: clientCert
secretKeyRef:
name: kafka-certs
key: client.crt
- name: clientKey
secretKeyRef:
name: kafka-certs
key: client.key
- name: caCert
secretKeyRef:
name: kafka-certs
key: ca.crt
```
**4. Set Configuration Items**
Configure required and optional metadata fields:
**Required vs. Optional:**
- Required Items
- Optional Items
**Smart selector:**
Use the right panel to add optional configuration items. Builder shows:
- Field description
- Allowed values
- Default values
- Examples
**5. Configure Access Control**
Scope component to specific applications and namespaces:
**Scoping options:**
**Cluster-Wide**
**Access:** All applications in all namespaces
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
namespace: default
spec:
type: state.redis
# No scopes = available to all apps
```
**When to use:**
- Shared infrastructure
- Development environments
- Non-sensitive components
**Namespace-Scoped**
**Access:** All applications in specific namespace
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
namespace: production # Only apps in production namespace
spec:
type: state.redis
```
**When to use:**
- Environment isolation
- Team boundaries
- Multi-tenant clusters
**Application-Scoped**
**Access:** Specific applications only
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
namespace: default
spec:
type: state.redis
scopes:
- order-service
- cart-service
```
**When to use:**
- Least-privilege access
- Sensitive components
- Production environments
- Secrets
**Deny Specific Apps**
**Access:** All except specified applications
```yaml
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
name: statestore
spec:
type: state.redis
scopes:
- "!test-app" # Deny test-app
```
**When to use:**
- Blacklisting problematic apps
- Preventing specific access
**Best practices:**
:::tip Access control checklist
- ✅ **Always scope secrets** - Use application scoping
- ✅ **Scope production components** - Limit to necessary apps
- ✅ **Use namespace isolation** - Separate environments
- ⚠️ **Review Advisor** - Check for unscoped components
- ⚠️ **Audit access** - Regularly review scoping
:::
**6. Review & Download**
Preview the generated YAML and make final edits:
**Final actions:**
1. **Review YAML** - Verify all settings correct
2. **Edit manually** (optional) - Make direct YAML changes
3. **Copy to clipboard** - Paste into your deployment
4. **Download file** - Save as `.yaml` file
5. **Add to source control** - Version your components
**YAML validation:**
- ✅ Schema validated
- ✅ Required fields present
- ✅ Correct API version
- ✅ Valid metadata format
:::note Important
Dapr Ops Dashboard **does not** apply the manifest to your cluster. You must deploy it manually.
:::
**Deploy the component:**
```bash
kubectl apply -f my-component.yaml
```
---
## Resiliency Builder
Create Dapr resiliency policies with timeouts, retries, and circuit breakers using a visual interface.
### Creating Resiliency Policies: Step-by-Step
**1. Set Context & Scope**
Define policy name and optional cluster context:
**Context options:**
**No Cluster Context**
**When to use:**
- Creating generic policies
- Deploying to multiple clusters
- Template policies
**Limitations:**
- Manual typing for resources
- No auto-completion
- No validation against actual resources
**Example:**
```yaml
apiVersion: dapr.io/v1alpha1
kind: Resiliency
metadata:
name: myresiliency
```
**With Cluster Context**
**When to use:**
- Cluster-specific policies
- Leveraging existing resources
- Need validation
**Benefits:**
- ✅ Auto-complete namespaces
- ✅ Select from deployed apps
- ✅ Choose existing components
- ✅ Reference actor types
**Available resources:**
- Namespaces in cluster
- Deployed applications (app-IDs)
- Component names
- Actor types
**Example:**
Select cluster → Get resources → Use in policy
**2. Create Policy Types**
The builder supports three types of policies:
**Timeout Policies**
**Purpose:** Prevent long-running operations from blocking
**Configuration:**
```yaml
policies:
timeouts:
generalTimeout: 5s
httpTimeout: 10s
actorTimeout: 30s
```
**When to use:**
- Prevent indefinite waits
- Set maximum operation durations
- Handle slow services
**Example scenario:**
If service normally responds in 200ms:
- Set timeout to 500ms-1s
- Account for occasional delays
- Prevent indefinite hangs
**Best practices:**
- Set based on P95/P99 latency
- Leave buffer for slow cases
- Don't set too aggressively
**Retry Policies**
**Purpose:** Automatically retry failed operations
**Strategies available:**
1. **Constant backoff**
```yaml
policies:
retries:
constantRetry:
policy: constant
duration: 5s
maxRetries: 3
```
Retry every 5 seconds, up to 3 times.
2. **Exponential backoff**
```yaml
policies:
retries:
exponentialRetry:
policy: exponential
maxInterval: 60s
maxRetries: 5
```
Wait increases exponentially: 1s, 2s, 4s, 8s, 16s...
3. **Linear backoff**
```yaml
policies:
retries:
linearRetry:
policy: linear
initialInterval: 1s
maxInterval: 30s
```
Wait increases linearly: 1s, 2s, 3s, 4s...
**Configuration example:**
**When to use each:**
- **Constant:** Predictable, fast retries (network blips)
- **Exponential:** Overloaded services (give time to recover)
- **Linear:** Moderate backoff (balanced approach)
**Circuit Breaker**
**Purpose:** Stop traffic to failing services
**Circuit breaker states:**
```mermaid
stateDiagram-v2
[*] --> Closed
Closed --> Open: Failure threshold reached
Open --> HalfOpen: Timeout expires
HalfOpen --> Closed: Success
HalfOpen --> Open: Failure
```
**Configuration:**
```yaml
policies:
circuitBreakers:
pubsubCB:
maxRequests: 3
timeout: 5s
trip: consecutiveFailures >= 5
```
**Parameters:**
- **maxRequests:** Requests allowed in half-open state
- **timeout:** How long to wait before trying again
- **trip:** Condition to open circuit
**Trip conditions:**
```yaml
# Open after 5 consecutive failures
trip: consecutiveFailures >= 5
# Open if 80% fail in window
trip: (consecutiveFailures / requestVolume) >= 0.8
```
**3. Configure Targets**
Specify when policies activate:
**App Targets**
**Purpose:** Apply policies to service-to-service calls
**Configuration:**
```yaml
targets:
apps:
order-service:
timeout: generalTimeout
retry: exponentialRetry
circuitBreaker: serviceCB
payment-service:
timeout: httpTimeout
retry: constantRetry
```
**When policies activate:**
- Service invocation calls
- When one Dapr sidecar calls another
- Synchronous communication
**Example:**
```
order-service → payment-service
[Retry if fails, timeout after 10s, circuit breaker if 5 consecutive failures]
```
**Component Targets**
**Purpose:** Apply policies to component operations
**Configuration:**
```yaml
targets:
components:
statestore:
outbound:
timeout: generalTimeout
retry: constantRetry
circuitBreaker: statestoreCB
inbound:
timeout: generalTimeout
```
**Directions:**
- **Outbound:** App → Component (saves, gets, publishes)
- **Inbound:** Component → App (subscriptions, bindings)
**Example:**
```yaml
targets:
components:
pubsub:
# When app publishes message
outbound:
retry: exponentialRetry
timeout: 30s
# When message delivered to app
inbound:
retry: constantRetry
timeout: 60s
```
**Actor Targets**
**Purpose:** Apply policies to actor operations
**Configuration:**
```yaml
targets:
actors:
orderActor:
timeout: actorTimeout
retry: exponentialRetry
circuitBreaker: actorCB
circuitBreakerScope: both # or 'type', 'id'
circuitBreakerCacheSize: 5000
```
**Special options:**
**circuitBreakerScope:**
- `type` - Per actor type
- `id` - Per actor ID
- `both` - Separate for each combination
**circuitBreakerCacheSize:**
- Max circuit breakers to cache
- Prevents memory issues with many actors
**4. Preview & Download**
Review the complete policy YAML:
**Actions:**
1. **Review generated YAML**
2. **Manual edits** (optional)
- Once edited manually, builder becomes read-only
3. **Download file**
4. **Copy to clipboard**
:::note Important
Dapr Ops Dashboard **does not** apply the manifest. You must deploy manually.
:::
**Deploy the policy:**
```bash
kubectl apply -f dapr-resiliency.yaml
```
---
## Troubleshooting
Component not initializing after deployment
**Check in Dapr Ops Dashboard:**
1. Navigate to Applications → Select app
2. View Components tab
3. Check initialization status and error
**Common issues:**
- Incorrect connection details
- Missing secrets
- Network connectivity
- Invalid credentials
**Fix:**
- Update component YAML
- Create missing secrets
- Test connection from pod
Resiliency policy not activating
**Verify:**
```bash
# Check policy exists
kubectl get resiliency -n
# View policy details
kubectl get resiliency -o yaml
```
**Common issues:**
- Policy in wrong namespace
- Target app/component name mismatch
- Policy not applied to cluster
**Check in Dapr Ops Dashboard:**
- Applications → Resiliency tab
- View active policies
- Check activation metrics
---
## Next Steps
- [Monitor Components](https://docs.diagrid.io/dapr-open-source/dapr-ops-dashboard/observe) — View component health and metrics in Dapr Ops Dashboard
- [Dapr Components](https://docs.dapr.io/reference/components-reference/) — Learn about all available Dapr components
- [Resiliency Concepts](https://docs.dapr.io/concepts/resiliency-concept/) — Deep dive into Dapr resiliency features