Dapr: a sidecar runtime for durable workflows, agents and service-to-service calls

What Dapr solves, and for whom

Distributed applications keep re-solving the same problems: keeping state across restarts, delivering messages, authenticating one service to another, and resuming a multi-step process after a crash. Dapr's answer is a runtime that supplies those as building blocks, exposed as APIs, rather than as libraries each team wires up separately.

The README frames the audience explicitly. It targets teams building "AI agents, business-critical workflows, microservices, or event-driven systems", and draws a line between platform teams, who use Dapr "to provide governance and golden paths", and application teams, who get "simple APIs that work the same everywhere". That split is the real pitch: the platform team picks the backing infrastructure, the application team writes business logic.

The language story matters more than it first appears. Because capabilities are reached over standard HTTP and gRPC, a service written in Go can call a workflow hosted by a Python service without either side sharing a framework. Native SDKs are listed for .NET, Java, Python, Go, JavaScript/TypeScript and Rust. If your organisation has already standardised on one language and one framework, the value here is smaller than the README implies.

Sidecar architecture and the five binaries

Dapr runs as a sidecar next to your application process. Your code talks to localhost; the sidecar talks to the rest of the system. That is what makes the language-agnostic claim possible, and it is also the source of most operational questions.

The Makefile names the binaries the project builds: daprd, placement, operator, injector and sentry. That list is a useful map of the architecture. daprd is the sidecar itself. The injector is what puts a sidecar into a pod on Kubernetes. Sentry handles the certificate side of the identity story the README describes as mutual TLS for all service-to-service traffic, with automatic certificate issuance and rotation. Placement and operator are the control-plane pieces that keep actors and configuration coordinated across a cluster.

Workflow durability is not implemented in this repository alone. The go.mod requires github.com/dapr/durabletask-go v0.14.1, which is the library behind the persisted-progress behaviour the README describes: a workflow that crashes resumes "from the next unfinished step" rather than from the beginning. The same go.mod pulls github.com/dapr/components-contrib v1.18.4, the module that holds the actual state stores, pub/sub brokers and secret vaults. Dapr the runtime is therefore a thin orchestration layer over two large dependency trees, and the component you care about is usually maintained in components-contrib, not here.

The sidecar model has a cost the README does not discuss. Every call between two services becomes a network hop through two local proxies, and every pod carries an extra container with its own memory and CPU request. For a chatty service graph, that is a real change to your latency and capacity planning.

Installing Dapr and running a first sidecar

The README does not include install commands, and the repository is the runtime source rather than the CLI distribution. The homepage at dapr.io is where the project points readers for getting started, and the charts/ directory in this repository holds the Helm charts used to deploy the control plane. Confirm exact syntax against dapr.io before you run anything.

On Kubernetes, the charts directory is the deployment path. The injector adds the sidecar to pods that carry Dapr annotations, which is the mechanism behind the "runs anywhere" claim. The README shows a Configuration object controlling which applications may talk to which, and the sample below follows it. Note that the sample in the README stops mid-key; the full schema lives in the docs, not in this repository.

apiVersion: dapr.io/v1alpha1
kind: Configuration
metadata:
  name: access-policy
spec:
  acc

To build the runtime from source instead, the Makefile exposes the binary list directly. Setting DAPR_SIDECAR_FLAVOR to stablecomponents produces a sidecar with only stable components compiled in, which is the lever to pull if you want a smaller build than the default allcomponents flavour.

BINARIES    ?= daprd placement operator injector sentry
DAPR_SIDECAR_FLAVOR ?= allcomponents

Where the sidecar model gets in the way

The clearest limitation is the one the README never states: Dapr is a proxy, and proxies fail in ways in-process libraries do not. If the sidecar is not ready, your application cannot reach state or publish an event even though it is running fine. Startup ordering, health probes and resource limits for the sidecar container become part of your application's reliability story, and that responsibility moves from the library author to you.

Durability has a storage bill attached. The README says workflows persist progress with "no extra database or state-machine code to write", which is true from the application's point of view and misleading from the operator's. Something must store that progress. The runtime does not pick that something for you, and the choice lives in the components-contrib module rather than in this repository.

Version skew is the second trap. The recent release list shows three supported lines at once: v1.17.14, v1.16.20 and v1.18.4, all published within days of each other. That is a healthy backport practice, and it also means you must decide deliberately which line you are on. A cluster running a sidecar from one line and a control plane from another is a configuration the project supports only within its stated compatibility rules.

Finally, Dapr is the wrong tool for a single-process application, for a monolith that will not be split, and for any call path where an extra local network hop is unacceptable. The README's own framing, "distributed applications, workflows, and AI agents", is a fair statement of the boundary.

Dapr compared with a service mesh and with plain SDKs

The nearest alternative in kind is a service mesh. A mesh also injects a sidecar and also gives you mTLS and traffic policy, so the overlap with Dapr's secure service-to-service story is substantial. The difference is the API surface. A mesh operates at the network layer and is largely transparent to your code; you do not call it to save state or start a workflow. Dapr exposes application-level building blocks, which is why the README can promise durable execution and pub/sub from the same sidecar that terminates mTLS. If you only need identity and traffic control, a mesh is the smaller commitment. If you need state and workflow APIs, a mesh will not provide them.

The other alternative is to use libraries directly: a workflow engine such as the durable task library on its own, a broker client, a secrets client, and a certificate manager, wired into each service. That gives you no sidecar, no control plane and no extra hop. It also gives you one integration per language per service, which is exactly the boilerplate the README argues against. The honest trade-off is that Dapr centralises the plumbing and its failure modes, while libraries distribute them.

Maintenance, releases and the Apache-2.0 licence

The repository is not archived, and the last push was on 2026-09-17, so the project is under current development. Three release lines received patches in the same week of September 2026, which tells you the maintenance model is backports to supported minor versions rather than a single moving target. Plan your upgrade cadence around that: you will be asked to move between minor lines periodically, and the sidecar, control plane and CLI should move together.

Upgrade cost is dominated by the sidecar, not by your code. Because the APIs are stable and reached over the network, the application usually does not change. What changes is the deployment: new sidecar images, a control-plane upgrade, and a check that your components in components-contrib are still compatible with the runtime version you are moving to. The Makefile's DAPR_SIDECAR_FLAVOR variable is worth remembering here, since a custom build flavour is one more thing to rebuild per upgrade.

The licence is Apache-2.0, stated in the README badge list and present as a LICENSE file at the repository root. That is a permissive licence with an explicit patent grant, and it is the same licence used by the wider ecosystem this project depends on. It does not by itself settle the licensing of the backing services you connect through components, which is a separate question for your own legal review.

Editorial conclusion

Adopt Dapr if you run polyglot services or long-running workflows and want durability, identity and pub/sub behind one API instead of reimplementing them per service, and if you can accept a sidecar in every pod and a control plane to operate. Do not adopt it for a single-process application, a latency-critical in-process call path, or a team with no capacity to run the placement, sentry and operator services. Verify first which of the five binaries your platform needs, whether your target environment supports the sidecar injection model, and which storage backend your workflow state will land in, because the runtime does not choose one for you.

Frequently asked questions

Official sources

1. dapr/dapr on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases