Dapr, the Distributed Application Runtime, is an open-source runtime that gives microservices a set of ready-made capabilities through a local API: call another service, save state, publish and subscribe to messages, read a secret, run a durable workflow. Each capability is a building block with a stable HTTP and gRPC interface, and the system behind it, such as Redis, Kafka, PostgreSQL or a cloud queue, is chosen in configuration rather than code. It addresses the repeated work of wiring retries, tracing, security and infrastructure clients into every service in every language. Microsoft created Dapr and released it as open source in 2019. It joined the CNCF in November 2021 and graduated on October 30, 2024.
CNCF daily · Sprint 3, post 1 of 21 · Application Definition & Image Build
At a glance
| Category | App Definition and Development › Application Definition & Image Build |
| CNCF status | Graduated. Accepted November 9, 2021; graduated October 30, 2024 |
| Written in | Go |
| License | Apache 2.0 |
| Building blocks | Service invocation, state management, pub/sub, bindings, actors, secrets, configuration, workflow, distributed lock, cryptography, jobs |
| SDKs | Go, Java, .NET, Python, JavaScript, PHP, Rust and C++ SDKs; any language can use the HTTP or gRPC API directly |
| Deployment | Kubernetes sidecar (the main target), self-hosted mode for local development, or managed through cloud services |
Architecture
flowchart TB
APP[Application<br/>any language] ==>|HTTP 3500 or gRPC 50001| SC[Dapr sidecar<br/>daprd]
SC ==>|state building block| ST[State store<br/>Redis or PostgreSQL]
SC ==>|pub sub building block| PS[Message broker<br/>Kafka or Redis]
SC ==>|secret building block| SEC[Secret store<br/>Kubernetes or cloud vault]
SC ==>|service invocation<br/>mTLS between sidecars| SC2[Peer sidecar]
SC2 ==> APP2[Other application]
OP[Dapr operator<br/>components and config] -.->|component definitions| SC
INJ[Sidecar injector] -.->|adds sidecar by annotation| APP
SEN[Sentry CA] -.->|workload certificates| SC
PLC[Placement and scheduler<br/>actors, jobs, workflows] -.->|placement tables| SC
SC -.->|OTLP or Zipkin| TR[Tracing backend]
classDef core fill:#0f766e,stroke:#064e4a,stroke-width:2px,color:#ffffff
classDef data fill:#e3f2fd,stroke:#1565c0,stroke-width:1.5px,color:#1d1c1a
classDef ctrl fill:#ede7f6,stroke:#5e35b1,stroke-width:1.5px,color:#1d1c1a
class SC,SC2,OP,INJ,SEN,PLC core
class APP,APP2,ST,PS,SEC,TR data
Key: teal blocks are Dapr components, blue are applications and the systems behind the building blocks. Thick arrows carry application requests, dashed arrows carry control and telemetry.
| Component | Responsibility |
|---|---|
| Sidecar (daprd) | Runs beside each application. Exposes the building block APIs and handles retries, timeouts, tracing, metrics and encryption. |
| Components | YAML resources that bind a building block to a concrete system, such as state.redis or pubsub.kafka. |
| Operator and injector | Distribute component definitions and add the sidecar to pods that carry the dapr.io/enabled annotation. |
| Sentry | Certificate authority that issues workload certificates for mutual TLS between sidecars. |
| Placement and scheduler | Place actors across replicas, and store timers, reminders, jobs and workflow state. |
Design principle. Separate what the application needs from where it is provided. Code calls a stable API, and operators choose and change the backing service through components, so the same service can run against open-source infrastructure on-premises and managed services in a cloud.
Production reference design
A common deployment runs Dapr on Kubernetes with the control plane in its own namespace and components defined per application namespace.
- Install the control plane. Use the project Helm chart in high-availability mode and pin the version:
helm repo add dapr https://dapr.github.io/helm-charts/ helm upgrade --install dapr dapr/dapr \ --version <version> --namespace dapr-system --create-namespace \ --set global.ha.enabled=true --wait - Define components. A state store and a pub/sub broker, with credentials taken from a secret:
apiVersion: dapr.io/v1alpha1 kind: Component metadata: { name: statestore, namespace: shop } spec: type: state.redis version: v1 metadata: - { name: redisHost, value: redis-master.data:6379 } - name: redisPassword secretKeyRef: { name: redis, key: password } --- apiVersion: dapr.io/v1alpha1 kind: Component metadata: { name: orderpubsub, namespace: shop } spec: type: pubsub.kafka version: v1 metadata: - { name: brokers, value: "shop-kafka-bootstrap.data:9092" } - { name: authType, value: "none" } - Enable the sidecar. Annotate the pod template:
annotations: dapr.io/enabled: "true" dapr.io/app-id: "order" dapr.io/app-port: "8080" - Use the building blocks. From the application, over localhost:
POST http://localhost:3500/v1.0/state/statestore POST http://localhost:3500/v1.0/publish/orderpubsub/orders GET http://localhost:3500/v1.0/invoke/inventory/method/stock/A-100 - Add scoping and observability. Restrict which applications may use each component, and send traces to your OpenTelemetry-compatible backend.
Typical uses include event-driven microservices, long-running business workflows, polyglot teams that need one consistent set of APIs, and portability between environments. Check the component version fields against the documentation for the release you install.
Operational considerations
- Sidecar overhead. Each pod gains a sidecar with its own CPU and memory, and each call adds a local hop. Size requests accordingly and measure latency for hot paths.
- Control plane availability. Run the control plane in HA mode. Running applications keep working through brief control plane outages, but new pods and certificate rotation depend on it.
- Component discipline. Components hold infrastructure choices. Version and scope them in Git, and avoid components that expose secrets in plain metadata.
- Security. Enable mutual TLS and API token authentication, restrict access with component scopes and access control policies, and keep the sidecar API on localhost.
- Not every feature fits every backend. Features such as transactions or ordering depend on the chosen component. Read the component support table before relying on a capability.
Adoption
- Microsoft created Dapr, offers Dapr as an integrated feature in Azure Container Apps, and provides a Dapr extension for Azure Kubernetes Service.
- Diagrid, founded by Dapr creators, provides commercial services built on Dapr.
- The project maintains an ADOPTERS file and publishes case studies on its website, listing organisations that run Dapr in production; consult them for current names.
Alternatives
| Solution | Model | Best suited to |
|---|---|---|
| Service mesh (Linkerd, Istio) | Transparent proxies for traffic and security | mTLS, routing and telemetry without code changes; see the Linkerd brief |
| Language frameworks (Spring Cloud, Quarkus) | Libraries in a single ecosystem | Teams standardised on one language and framework |
| Cloud SDKs directly | Provider clients in the application | Single-cloud systems that accept the lock-in |
| Temporal | Durable execution platform | Complex long-running workflows as the main concern |
| Knative Eventing and Kafka clients | Event routing and broker clients | Eventing without the other building blocks; see the Strimzi brief |
Strengths and limitations
| Strengths | Limitations |
|---|---|
| One API across many languages and infrastructure systems | Adds a sidecar and a control plane to operate |
| Swap backing services through configuration | The common API can hide backend-specific features |
| Built-in retries, mTLS, tracing and metrics | Debugging spans application, sidecar and component |
| Graduated CNCF project with broad SDK support | Teams must learn the building block model and component settings |
| Workflow and actor models for stateful logic | Some components are less mature than others |
Recommendation
Trial. Dapr suits teams with polyglot microservices or a need to move between environments without rewriting infrastructure code. Start with one or two building blocks, typically pub/sub and state, in a single service pair, measure the sidecar overhead and operational effort, and widen use if the portability and consistency are worth it. Teams on a single language and one cloud may be better served by their existing framework and a service mesh.
References: CNCF project page · Dapr website · Dapr documentation · Dapr repository · CNCF Landscape