Dapr sidecar (daprd) overview

Dapr uses a sidecar pattern, meaning the Dapr APIs are run and exposed on a separate process, the Dapr sidecar, running alongside your application. The Dapr sidecar process is named daprd and is launched in different ways depending on the hosting environment.

The Dapr sidecar exposes used by your application business logic, a metadata API for discoverability of capabiliites and to set attributes and a to determine health status.

The sidecar APIs are called from your application over local http or gRPC endpoints.

On Kubernetes, the Dapr control plane includes the , which watches for new pods with the dapr.io/enabled annotation and injects a container with the process within the pod. In this case, sidecar arguments can be passed through annotations as outlined in the Kubernetes annotations column in this table.

In most cases you do not need to run daprd explicitly, as the sidecar is either launched by the (self-hosted mode) or by the dapr-sidecar-injector service (Kubernetes). For advanced use cases (debugging, scripted deployments, etc.) the daprd process can be launched directly.

For a detailed list of all available arguments run daprd --help or see this table which outlines how the daprd arguments relate to the CLI arguments and Kubernetes annotations.

1. Start a sidecar along with an application by specifying its unique ID. Note is a required field:

2. If you are using several custom components and want to specify the location of the component definition files, use the --components-path argument:

3. Enable collection of Prometheus metrics while running your app