Preview features

List of current preview features

Preview features in Dapr are considered experimental when they are first released.

Runtime preview features require explicit opt-in in order to be used. The runtime opt-in is specified in a preview setting feature in Dapr’s application configuration. See How-To: Enable preview features for more information.

For CLI there is no explicit opt-in, just the version that this was first made available.

Current preview features

FeatureDescriptionSettingDocumentationVersion introduced
Pluggable componentsAllows creating self-hosted gRPC-based components written in any language that supports gRPC. The following component APIs are supported: State stores, Pub/sub, BindingsN/APluggable components conceptv1.9
Multi-App Run for KubernetesConfigure multiple Dapr applications from a single configuration file and run from a single command on Kubernetesdapr run -k -fMulti-App Runv1.12
CryptographyEncrypt or decrypt data without having to manage secrets keysN/ACryptography conceptv1.11
Actor State TTLAllow actors to save records to state stores with Time To Live (TTL) set to automatically clean up old data. In its current implementation, actor state with TTL may not be reflected correctly by clients, read Actor State Transactions for more information.ActorStateTTLActor State Transactionsv1.11
Workflows Clustered DeploymentEnable Workflows to function when workflow clients communicate to multiple daprds of the same appID who are behind a loadbalancer. Only relevant when using Dapr sharedWorkflowsClusteredDeploymentDapr Sharedv1.16
Workflows Durable Activity ResultsIf set, ensures that activity results are durably sent to the owning workflow in multi-application scenarios, even when the owning workflow application is unavailable. Strongly recommended to always be enabled when all Dapr applications are running the same version. Enabled by default as of v1.18.WorkflowsRemoteActivityReminderMulti-application Workflowsv1.17
Workflow History SigningCryptographic signing and verification of workflow history events using the sidecar’s mTLS X.509 identity. Detects tampering of workflow state. Disabled by default; set to true to enable. Signing is a one-way commitment: once enabled for a workflow, it cannot be disabled.WorkflowHistorySigningWorkflow History Signingv1.18