Short answers to common questions about Dapr, with links to the Dapr docs for the details.
Dapr is the durable execution engine for workflows and AI agents. It provides APIs for building event-driven architectures. Each Dapr building block, such as workflows, service invocation, publish and subscribe, or state management, is an HTTP or gRPC API that your code calls and that uses one or more Dapr components.
Durable execution is the guarantee that your code runs to completion despite crashes, restarts, and outages. Dapr is built around durable execution: at its core is a workflow engine that orchestrates long-running business processes and powers durable AI agents.
Dapr includes one: Dapr Workflow is a durable execution engine, and you write workflow logic as ordinary code with a Dapr SDK. Dapr persists the result of each completed step and resumes the workflow from the last completed step after a crash, a restart, or a redeployment. Workflows can also orchestrate other Dapr building blocks, such as service invocation, pub/sub, state management, and bindings.
Dapr Agents is a Python framework for building AI agents powered by large language models (LLMs) using Dapr's distributed systems capabilities. Its agents can execute durable tasks, make decisions, and collaborate through workflows, while using Dapr's state management, messaging, and observability features. Dapr Agents v1.0 is generally available and production ready.
The Dapr MCP server is a standalone Model Context Protocol (MCP) server that runs next to a Dapr sidecar and turns the sidecar's building blocks, such as state, pub/sub, bindings, secrets, and service invocation, into tools that any MCP client can call. It is a separate binary with its own release cycle, not a feature of the Dapr sidecar itself. The Dapr MCP server is in alpha, so tool names, inputs, and configuration may change in a future release.
No, but most organizations do run Dapr on Kubernetes in production. Dapr can run in self-hosted mode on your local developer machine or on production virtual machines, where each running service has a Dapr sidecar process. Self-hosted mode can be initialized with Docker, which is the default, or in slim-init mode, and it can also run in offline or airgapped environments.
Dapr has stable SDKs for .NET, Python, Java, Go, PHP, and JavaScript, and SDKs for C++ and Rust are in development. Depending on the language, an SDK provides client, server extension, actor, and workflow packages for working with the Dapr APIs. From any language, your code can also call the Dapr HTTP or gRPC APIs directly.
Dapr runs as a separate process, the Dapr sidecar, alongside your application, and your application calls the Dapr APIs over local HTTP or gRPC endpoints. When you develop locally, the Dapr CLI run command launches the sidecar together with your application. On Kubernetes, the Dapr sidecar injector adds the sidecar to pods that have the dapr.io/enabled annotation.
Yes, Dapr has been production ready for years. Dapr is a graduated project of the Cloud Native Computing Foundation (CNCF). Organizations describe how they use Dapr on the CNCF case studies page.
Yes. Dapr is open source software licensed under the Apache License, Version 2.0, and its source code is on GitHub.
Companies in the Dapr ecosystem offer commercial support, managed services, and enterprise distributions for running Dapr in production. The Dapr enterprise page lists these offerings.