Dapr pays off when several distributed problems meet
Dapr runs beside an application as a process or container and exposes its capabilities over HTTP or gRPC. Application code calls Dapr for state, pub/sub, service invocation, secrets, configuration, jobs, locks, cryptography, workflows, actors, bindings, or conversations with language models. Native SDKs exist for several languages, but the network API is the important boundary: services written in different stacks can use the same runtime contract.
The breadth is the attraction and the warning. A platform team can present one approved way to call services, store state, publish events, and retrieve secrets. A team using only 1 of those APIs inherits the sidecar, configuration model, and release process without much consolidation benefit. Dapr is easier to justify across a fleet than beside one uncomplicated application.
Durable workflows depend on state and runtime operations
Dapr Workflows persist progress so an execution can resume after process crashes, pod restarts, node failures, rolling deployments, or other infrastructure interruptions. The same mechanism is pitched for business processes and long-running agents. Actors add another stateful programming model, while the Conversation API connects LLM providers with prompt caching and tool calls. These pieces can share Dapr's identity, messaging, and state interfaces.
Durability does not remove backing infrastructure. Workflows and actors need a correctly configured actor state store, and applications still choose the component implementation behind every API. Open issue 9729 also shows an administrative gap: the runtime has operations for listing workflow instances, reading history, and rerunning failures, but the issue asks for all SDKs to expose them. Operators may need direct gRPC access until their chosen SDK catches up.
What happened when we ran it
Our fresh Debian sandbox installed 1,338 Go packages in 193 seconds. Building commit 6cf57ab succeeded in 229 seconds. The repository had 4,524 files, roughly 535,895 lines of source, and a 36 MB checkout. We found 23 CI workflow files and a tests directory, but no Dockerfile in the repository root.
Tests ended with exit code 1 after 168 seconds: 218 passed and 21 failed out of 239. The supplied tail listed successful packages for integration helpers, metrics, scheduler proxies, performance, Kubernetes platforms, runners, load testing, summaries, and utilities. It then printed FAIL without the individual failing package names or error messages. That evidence tells us the suite was red, but not why.
The failure happened in an unprivileged container with 3 CPUs, 8 GB of RAM, and no secrets. A fresh environment can expose unstated service or system-package requirements, yet this log does not show either. Teams evaluating Dapr should rerun the failing targets with full logs and the services their intended components require. Calling the suite healthy because many packages passed would hide the 21 failures.
At-least-once messaging puts duplication in your application
Dapr's pub/sub API separates application code from a specific broker, and service invocation adds retries, tracing, and mutual TLS around calls. Component definitions select the actual state store, queue, vault, or cloud service. This can make a platform change less invasive because the application-facing API stays stable while the backing component changes.
The README explicitly describes pub/sub as at-least-once delivery. Consumers therefore need idempotency or another way to cope with repeated events. Release v1.18.3 is a useful reminder of the failure modes around that boundary: it fixed a crash caused by a non-string trace field in an HTTP CloudEvent and a gRPC delivery problem involving closed connections. The release also notes that redelivery behavior depends on the broker component.
Security defaults still need policy and component work
Dapr issues workload identities and supports mutual TLS between applications. Access policies can deny traffic by default and allow named applications. Secret APIs keep vault-specific clients out of application code, while cryptography APIs can operate without exposing keys to the application process. These are good building blocks for a platform standard.
They are not a finished security policy. Operators decide which identities may call which apps, where component credentials live, how certificates and secrets are rotated, and which API surfaces are enabled. Every added state store, broker, or cloud service brings its own permissions. The README's claim that Dapr runs across Kubernetes, clouds, virtual machines, edge hosts, and air-gapped systems describes portability of the runtime model, not identical operational work on 5 environments.
Version 1.18.3 fixed failures worth testing in upgrades
The latest release was v1.18.3 on August 14, 2026. Its fix list includes an actor state store that could not be hot reloaded, sidecars disconnecting from Placement, scheduler shutdown and redelivery faults, stalled workflows that could remain stuck, workflow termination events that could be dropped, and Azure authentication fallback that could stop too early. One fix prevented malformed trace data from crashing an HTTP pub/sub sidecar.
Those are specific production faults in core paths. Their fixes show maintainers responding, while their severity argues for staged upgrades, workload-specific regression tests, and an exit plan for sidecar failures. Dapr had 26,046 stars and 440 combined issues and pull requests when fetched. The last push was August 28, 2026, so the issue count sits alongside current development rather than a dormant repository.
The repository is one part of the product
The main repository contains the Go runtime and overview material. The CLI, documentation, quickstarts, samples, contributed components, and language SDKs live in separate repositories. That split is reasonable for a project this large, but a source audit of dapr/dapr alone cannot verify the connector or SDK version your application will use.
Dapr is a strong platform choice when a team is already paying separately for workflow durability, messaging wrappers, service identity, state adapters, and secret integrations. Our 193-second install, 229-second build, and failed test step describe a codebase with real weight and a test result that needs investigation. Trial the exact APIs, components, SDKs, and failure scenarios you plan to operate before making the sidecar a dependency of every service.