cloudparts

Dapr

A sidecar next to each service that offers pub/sub, state, service calls, workflows and actors over local HTTP or gRPC, with the broker or database behind each one swapped by a YAML file.

CNCF · Graduated
What it is
Microservices
Used for
Pub/sub,Actor model,Workflow orchestration,Secrets management,Remote procedure calls
Type
Open source
Made by
Cloud Native Computing Foundation
Foundation
Cloud Native Computing Foundation, graduated, joined November 2021. Part of the Linux Foundation
License
Apache 2.0
Facts checked
24 October 2026
Website Source code

What it is

Dapr (Distributed Application Runtime) runs a sidecar process, daprd, next to every instance of your service. Your code never links a Kafka or Redis client; it calls the sidecar on localhost, over HTTP (port 3500 by default) or gRPC (port 50001), and the sidecar talks to the real infrastructure. The APIs are called building blocks: service invocation (call another app by its app ID, with retries and mTLS), publish and subscribe, key/value state, bindings to external systems, virtual actors, secrets, configuration, distributed locks, cryptography, scheduled jobs and durable workflows, plus newer ones for LLM calls, search and vectors. SDKs exist for Go, Java, JavaScript, .NET and Python, but they are thin wrappers: anything that can send an HTTP request can use Dapr.

What sits behind each building block is a component, declared in a YAML file. A state store of type state.redis can become state.postgresql or AWS DynamoDB by changing that file, not the code, and the same goes for pub/sub (Kafka, RabbitMQ, Redis Streams, SNS/SQS, Google Pub/Sub and others). Components carry a maturity label (alpha, beta or stable), and not every one supports every feature; actors, for example, need a state store with transactions and ETags. On a laptop, dapr run starts the sidecar as a process beside your app. On Kubernetes, a control plane does the work: an injector adds the daprd container to any pod annotated dapr.io/enabled, Sentry issues the certificates for mTLS, Placement tracks where each actor lives, and Scheduler stores jobs and reminders.

Microsoft started Dapr and released it in October 2019. It reached 1.0 in February 2021, joined the CNCF in November 2021 and graduated in November 2024, and it ships a minor release about every quarter; 1.19 came out on 22 October 2026. The project now describes itself first as a durable execution engine, for workflows and for AI agents that must survive crashes, with the original building blocks around it.

Why teams pick it

  • Code calls one local API for state, messaging and secrets, so moving from Redis to PostgreSQL or from Kafka to a cloud queue is a component change, not a rewrite
  • Language-neutral: the sidecar speaks HTTP and gRPC, so services in different languages share the same features, and actors can call each other across languages
  • Service-to-service mTLS, retries, resiliency policies and tracing of both direct calls and pub/sub messages come with the sidecar
  • Workflows and actors give long-running, stateful processes without adopting a separate workflow server

Watch out for

  • A sidecar per instance plus a control plane on Kubernetes: one more process in every request path and more to operate and upgrade
  • The common API hides each backend’s special features, and components differ in maturity and capabilities; many are alpha or beta, which the project recommends only for non-critical uses
  • Not a networking service mesh: no traffic splitting or routing for canary releases, and if you also run a mesh, the docs advise letting only one of them do mTLS and tracing
  • Actors need a transactional state store with ETag support, and only one state store can serve all actors

Alternatives

What all microservices have in common →Compare side by side →
TARSOpen sourceTencent’s microservice platform, in use there since 2008: an IDL and binary protocol, RPC libraries for C++, Go, Java, Node.js and PHP, and its own registry, config, logging, monitoring and deployment services with a web console.

How it fits with other technologies

Declare a Redis state store, then save and read a value through the sidecar · bash

cat > components/statestore.yaml <<'EOF'
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: statestore
spec:
  type: state.redis        # swap for state.postgresql without touching the app
  version: v1
  metadata:
  - name: redisHost
    value: localhost:6379
  - name: redisPassword
    value: ""
EOF

# Start the app with a sidecar listening on localhost:3500
dapr run --app-id orderprocessing --app-port 6001 --dapr-http-port 3500 \
  --resources-path ./components -- python app.py

# Any language: plain HTTP to the sidecar
curl -X POST -H "Content-Type: application/json" \
  -d '[{ "key": "order_1", "value": "250" }]' \
  http://localhost:3500/v1.0/state/statestore
curl http://localhost:3500/v1.0/state/statestore/order_1

See it in a real stack

No architecture uses Dapr yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2019–2026

Microsoft announced the Distributed Application Runtime on 16 October 2019. The project leads wrote that developers building microservices “continually end up solving the same distributed system problems such as state management” and resilient calls, that many runtimes supported only a few languages, and that code was hard to move between cloud and edge. Their answer was a sidecar, run as a process or a container, that exposes these features over standard HTTP and gRPC, so an app needs no compile-time dependency on Dapr. The alpha had service invocation with retries, key/value state, pub/sub, bindings, virtual actors and W3C tracing.

Dapr moved to open governance in 2020 and released 1.0 on 17 February 2021, declaring the API stable and Kubernetes the main hosting environment; contributors had grown from 114 to about 700. It joined the CNCF as an incubating project in November 2021 and graduated on 12 November 2024, when 21 maintainers from eight organisations looked after it. Two of them, Mark Fussell and Yaron Schneider, had co-founded Diagrid, a company built around Dapr.

Since then the emphasis has shifted to durable execution. Dapr 1.15 (February 2025) made the workflow API stable, moved actor reminders to the new Scheduler service and added an alpha API for calling LLM providers. Version 1.18 made component changes reload without a restart, and the docs now present the workflow engine as the core, for business processes and for AI agents that must survive crashes and restarts.

Why it’s built this way

A sidecar instead of a library
Libraries have to be rewritten for each language and compiled into every service. A separate process that speaks HTTP and gRPC works with any language and keeps infrastructure code out of the app.
Pluggable components behind fixed APIs
The same app should run on a laptop with Redis and in a cloud with that cloud’s queue or database. Choosing the backend in a YAML file keeps that choice out of the code.
Virtual actors as a built-in block
Many services need lots of small stateful objects. Actors that are placed automatically, handle one call at a time and are collected when idle remove the need for locks in that code.
Developer APIs, not network routing
Service meshes already handle traffic at the network level. Dapr lets code call services by name and leaves traffic splitting to a mesh.

Timeline

  1. 2019

    Microsoft announces Dapr as an open-source alpha in October

  2. 2021

    Dapr 1.0 in February; joins the CNCF as incubating in November

  3. 2024

    Graduates from the CNCF in November

  4. 2025

    Dapr 1.15 makes workflows stable and adds an LLM conversation API

  5. 2026

    Dapr 1.19 released in October

Sources16 · facts checked 24 October 2026

Improve this page on GitHub