Dapr v1.11 Release Highlights

The Dapr maintainers released a new version of Dapr, the distributed application runtime, this week. This post highlights the major new features and changes for the APIs and components in release 1.11.

Dapr v1.11 Release Highlights

The Dapr maintainers released a new version of Dapr, the distributed application runtime, this week. This post highlights the major new features and changes for the APIs and components in release 1.11.


Dapr provides a common set of APIs for building microservices quickly and reliably. The new building block APIs, and major upgrades to existing APIs, are described in this section.

Configuration API stable

Configuration API

The Configuration building block allows developers to easily consume application configuration values as key/value pairs. Use this API to retrieve values that are likely to change over time but are coupled to the service. For instance, this API can be used to get App IDs, which are used when invoking other Dapr services. Or to get a component name of a state store when using the State Management API.

Applications can subscribe to changes of these configuration values, so the apps always use the latest value. The Configuration API was introduced in Dapr v1.5, and it’s great to see it now stable in v1.11.

Get a configuration value

GET http://localhost:/v1.0/configuration/?key=

Subscribe to configuration changes

GET http://localhost:/v1.0/configuration//subscribe

Service Invocation for non-Dapr endpoints 🆕

Service Invocation for non-Dapr endpoints

An exciting new preview feature is the ability to invoke non-Dapr endpoints. This feature enables developers to apply resiliency policies, access control via scoping, header authentication, and middleware to any endpoint. This gives you nearly all the benefits of service invocation when calling any HTTP API. Invoking non-Dapr endpoints can also be very useful when working on existing code bases where Dapr can be introduced incrementally.

Non-Dapr endpoints can be invoked in two ways:

1. Using an <inline-h>HTTPEndpoint<inline-h> resource type.

GET http://localhost:/v1.0/invoke//method/

2. The HTTPEndpoint resource is specified in a yaml file:

apiVersion: dapr.io/v1alpha1
kind: HTTPEndpoint
  version: v1alpha1
  baseUrl:  # Required. Use "http://" or "https://" prefix.
  headers: # Optional
  - name: 
  - name: 
scopes: # Optional
auth: # Optional

3. Using the Fully Qualified Domain Name (FQDN) of the endpoint.

GET http://localhost:/v1.0/invoke//method/

Workflow updates

Workflow management API

The Dapr Workflow management API has been updated to allow workflows to be paused, resumed, and purged. Purging workflows means the workflow state will be deleted. Once a workflow has been completed, it’s a good practice to purge the workflow state to keep the storage requirements to a minimum. In addition, workflows can now wait for external events. This is particularly useful for business processes that involve human interaction, such as approval workflows, or waiting for callbacks from other long-running processes.

These are the current Workflow management HTTP API methods:

POST http://localhost:/v1.0-alpha1/workflows/dapr/start?instanceID=POST http://localhost:/v1.0-alpha1/workflows/dapr//terminatePOST http://localhost:/v1.0-alpha1/workflows/dapr//pausePOST http://localhost:/v1.0-alpha1/workflows/dapr//resumePOST http://localhost:/v1.0-alpha1/workflows/dapr//purgePOST http://localhost:/v1.0-alpha1/workflows/dapr//raiseEvent/  

Note that the Workflow management API, which is still in preview, has breaking changes compared to v1.10. The changes are outlined in this GitHub issue. Another breaking change is the ability to support multiple workflow apps in a single cluster, as mentioned in this GitHub issue.

The Dapr Python SDK has been upgraded to allow authoring of workflows, so now workflow applications can be written in either C# or Python.

Cryptography API 🆕

Cryptography API

The Cryptography API is a new preview building block that enables developers to encrypt/decrypt data in a safe and consistent way. Cryptography can be used within key vaults or the Dapr sidecar without exposing cryptographic keys to the application. With this new API, a set of new Cryptography components is made available that is listed in the New Components section.

These examples show how data can be encrypted and decrypted with the Cryptography API using the Dapr JavaScript SDK:


// When passing data (a buffer or string), `encrypt` returns a Buffer with the encrypted message
const ciphertext = await client.crypto.encrypt(plaintext, {
    // Name of the Dapr component (required)
    componentName: "mycryptocomponent",
    // Name of the key stored in the component (required)
    keyName: "mykey",
    // Algorithm used for wrapping the key, which must be supported by the key named above.
    // Options include: "RSA", "AES"
    keyWrapAlgorithm: "RSA",


// When passing data as a buffer, `decrypt` returns a Buffer with the decrypted message
const plaintext = await client.crypto.decrypt(ciphertext, {
    // Only required option is the component name
    componentName: "mycryptocomponent",

For more info on how to use the Cryptography API, see the Dapr docs.


Dapr decouples the functionality of the common set of APIs with their underlying implementations via components. Components of the same type are interchangeable since they implement the same interface. Release 1.11 contains both new components as improvements to existing components.

New components


  • WASM: allows invoking applications compiled to WebAssembly and run in modern browsers.
  • Kitex: allows invoking Generic Calls in Kitex, a high-performance and strong-extensibility Golang RPC framework.

State Stores

  • etcd: enables state store functionality using etcd, a distributed, reliable key-value store.


Component improvements

Component Lifecycle

With 1.11 many components have graduated to the Stable certification level, which means these can be used in production confidently. All components have a certification level as mentioned in the Certification Lifecycle. The Stable level means:

  • The component must have component certification tests validating functionality and resiliency.
  • The component is maintained by Dapr maintainers and supported by the community.
  • The component is well documented and tested.
  • The component has been available as Alpha or Beta for at least 1 minor version release of Dapr runtime prior.
  • A maintainer will address component security, core functionality and test issues according to the Dapr support policy and issue a patch release that includes the patched stable component.

The following components have progressed to Stable:


  • AWS S3: output binding to store data in AWS S3 buckets.



State stores

Configuration stores

If you're using any of these components and have a demo to show, drop a link in the #show-and-tell channel on the Dapr Discord.

Azure components authentication improvements

Azure AD authentication has been added to the Azure Storage Queues binding and the SQL Server state store.

All Azure components that support Azure AD now support authentication using:

What is next?

This post is not a complete list of features and changes released in version 1.11. Read the official Dapr release notes for more information. The release notes also contain information on how to upgrade to this latest version.

Excited about these features and want to learn more? I'll cover the new features in more detail in future posts. Until then, join the Dapr Discord to connect with thousands of Dapr users.

Diagrid Newsletter

Subscribe today for exclusive Dapr insights