Dapr Extension for Azure Functions

The Dapr Extension for Azure Functions is a set of tools and services that allow developers to easily integrate Azure Functions with the Distributed Application Runtime (Dapr) platform.

Azure Functions is an event-driven compute service that provides a set of triggers and bindings to easily connect with other Azure services. Dapr provides a set of building blocks and best practices for building distributed applications, including microservices, state management, pub/sub messaging, and more.

With the integration between Dapr and Functions, you can build functions that react to events from Dapr or external systems.

dotnet add package Microsoft.Azure.WebJobs.Extensions.Dapr

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Dapr

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle",
    "version": "[4.*, 4.42.0)"
  }
}

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Preview",
    "version": "[4.*, 4.60.0)"
  }
}

Migrate from the Dapr extension

You can continue using Dapr in Azure Container Apps without the Azure Functions Dapr extension. This migration requires changes to your function code and Dapr callback configuration; installing a client SDK alone doesn't replace Dapr triggers.

1. Replace Dapr input and output bindings with calls to a Dapr client SDK or the Dapr HTTP APIs. Use the corresponding APIs for state reads and writes, secret retrieval, service invocation, message publishing, and output bindings. Preserve component names, app IDs, state keys, and metadata required by your existing app. Select APIs and SDK packages supported in Azure Container Apps.

2. Replace extension-specific triggers with HTTP-triggered functions and configure Dapr to call the new endpoints:

   Existing trigger	Replacement
   daprServiceInvocationTrigger	An HTTP endpoint that handles the invoked method. See Dapr service invocation.
   daprTopicTrigger	An HTTP endpoint that receives topic messages, with a declarative or programmatic Dapr subscription that routes messages to it.
   daprBindingTrigger	An HTTP endpoint that accepts the binding's POST callbacks and OPTIONS discovery requests. See Dapr input binding callbacks.

3. Update the Dapr configuration in Azure Container Apps to use the function app's HTTP listening port and the HTTP app protocol, rather than the extension's listener on port 3001. Match callback routes to the function endpoints, accounting for the default /api route prefix. If you use programmatic pub/sub subscriptions, expose the discovery endpoint at the exact /dapr/subscribe path. Ensure Dapr can reach the required endpoints while preserving your app's authentication and access controls.

4. Verify state and secret access, service invocation, publishing, callback payloads, acknowledgments, retries, and duplicate-event handling before switching traffic. After all extension-specific bindings and triggers are replaced, remove the Dapr extension package or registration and the temporary bundle pin. Use the normal bundle configuration required by your remaining bindings.

The following sections describe configuration for existing apps that still use the Dapr extension before its retirement on April 20, 2027.

Dapr enablement

You can configure Dapr using various [arguments and annotations][dapr-args] based on the runtime context. You can configure Dapr for Azure Functions through two channels:

• Infrastructure as Code (IaC) templates, as in Bicep or Azure Resource Manager (ARM) templates
• The Azure portal

When using an IaC template, specify the following arguments in the properties section of the container app resource definition.

DaprConfig: {
  enabled: true
  appId: '${envResourceNamePrefix}-funcapp'
  appPort: 3001
  httpReadBufferSize: ''
  httpMaxRequestSize: ''
  logLevel: ''
  enableApiLogging: true
}

"DaprConfig": {
  "enabled": true,
  "appId": "${envResourceNamePrefix}-funcapp",
  "appPort": 3001,
  "httpReadBufferSize": "",
  "httpMaxRequestSize": "",
  "logLevel": "",
  "enableApiLogging": true
}

The above Dapr configuration values are considered application-scope changes. When you run a container app in multiple-revision mode, changes to these settings won't create a new revision. Instead, all existing revisions are restarted to ensure they're configured with the most up-to-date values.

When configuring Dapr using the Azure portal, navigate to your function app and select Dapr from the left-side menu:

Dapr ports and listeners

When you're triggering a function from Dapr, the extension exposes port 3001 automatically to listen to incoming requests from the Dapr sidecar.

By default, when Azure Functions tries to communicate with Dapr, it calls Dapr over the port resolved from the environment variable DAPR_HTTP_PORT. If that variable is null, it defaults to port 3500.

You can override the Dapr address used by input and output bindings by setting the DaprAddress property in the function.json for the binding (or the attribute). By default, it uses http://localhost:{DAPR_HTTP_PORT}.

The function app still exposes another port and endpoint for things like HTTP triggers, which locally defaults to 7071, but in a container, defaults to 80.

Troubleshooting

This section describes how to troubleshoot issues that can occur when using the Dapr extension for Azure Functions.

Ensure Dapr is enabled in your environment

If you're using Dapr bindings and triggers in Azure Functions, and Dapr isn't enabled in your environment, you might receive the error message: Dapr sidecar isn't present. Please see (https://aka.ms/azure-functions-dapr-sidecar-missing) for more information. To enable Dapr in your environment:

• If your Azure Function is deployed in Azure Container Apps, refer to Dapr enablement instructions for the Dapr extension for Azure Functions.

• If your Azure Function is deployed in Kubernetes, verify that your deployment's YAML configuration has the following annotations:

  annotations:
    ...
    dapr.io/enabled: "true"
    dapr.io/app-id: "functionapp"
    # You should only set app-port if you are using a Dapr trigger in your code.
    dapr.io/app-port: "<DAPR_APP_PORT>"
    ...
  

• If you're running your Azure Function locally, run the following command to ensure you're running the function app with Dapr:

  dapr run --app-id functionapp --app-port <DAPR_APP_PORT>  --components-path <COMPONENTS_PATH> -- func host start 
  

Verify app-port value in Dapr configuration

The Dapr extension for Azure Functions starts an HTTP server on port 3001 by default. You can configure this port using the DAPR_APP_PORT environment variable.

If you provide an incorrect app port value when running an Azure Functions app, you might receive the error message: The Dapr sidecar is configured to listen on port {portInt}, but the app server is running on port {appPort}. This may cause unexpected behavior. For more information, visit [this link](https://aka.ms/azfunc-dapr-app-config-error). To resolve this error message:

1. In your container app's Dapr settings:

   • If you're using a Dapr trigger in your code, verify that the app port is set to 3001 or to the value of the DAPR_APP_PORT environment variable.

   • If you're not using a Dapr trigger in your code, verify that the app port is not set. It should be empty.

2. Verify that you provide the correct app port value in the Dapr configuration.

   • If you're using Azure Container Apps, specify the app port in Bicep:

     DaprConfig: {
        ...
        appPort: <DAPR_APP_PORT>
        ...
     }
     

   • If you're using a Kubernetes environment, set the dapr.io/app-port annotation:

     annotations:
        ...
        dapr.io/app-port: "<DAPR_APP_PORT>"
        ...
     

   • If you're developing locally, verify you set --app-port when running the function app with Dapr:

     dapr run --app-id functionapp --app-port <DAPR_APP_PORT> --components-path <COMPONENTS_PATH> -- func host start 
     

Next steps

Learn more about Dapr.