dapr · javier-aliaga · May 13, 2026
@@ -54,7 +54,7 @@ For more information read [Pluggable components overview]({{% ref "pluggable-com
 
 ## Hot Reloading
 
-With the [`HotReload` feature enabled]({{% ref "support-preview-features" %}}), components are able to be "hot reloaded" at runtime.
+Since Dapr v1.18, components are "hot reloaded" at runtime by default. To opt out, disable the `HotReload` feature in the [Dapr application configuration]({{% ref "preview-features.md" %}}).
 This means that you can update component configuration without restarting the Dapr runtime.
 Component reloading occurs when a component resource is created, updated, or deleted, either in the Kubernetes API or in self-hosted mode when a file is changed in the `resources` directory.
 When a component is updated, the component is first closed, and then reinitialized using the new configuration.

@@ -188,9 +188,14 @@ The example above shows an event subscription to topic `orders`, for the pubsub
 Place `subscription.yaml` in the same directory as your `pubsub.yaml` component. When Dapr starts up, it loads subscriptions along with the components.
 
 {{% alert title="Note" color="primary" %}}
-This feature is currently in preview.
-Dapr can be made to "hot reload" declarative subscriptions, whereby updates are picked up automatically without needing a restart.
-This is enabled by via the [`HotReload` feature gate]({{% ref "support-preview-features" %}}).
+Since Dapr v1.18, declarative subscriptions are "hot reloaded" by default, whereby updates are picked up automatically without needing a restart. To opt out, disable the `HotReload` feature in the Dapr application configuration:
+
+```yaml
+spec:
+  features:
+    - name: HotReload
+      enabled: false
+```
 To prevent reprocessing or loss of unprocessed messages, in-flight messages between Dapr and your application are unaffected during hot reload events.
 {{% /alert %}}
 

@@ -87,9 +87,8 @@ For more information, read [about the subscriptions in Subscription Types]({{% r
 
 ### Reloading topic subscriptions
 
-To reload topic subscriptions that are defined programmatically or declaratively, the Dapr sidecar needs to be restarted.
-The Dapr sidecar can be made to dynamically reload changed declarative topic subscriptions without restarting by enabling the [`HotReload` feature gate]({{% ref "support-preview-features" %}}).
-Hot reloading of topic subscriptions is currently a preview feature.
+Programmatic topic subscriptions require the Dapr sidecar to be restarted in order to be reloaded.
+Since Dapr v1.18, the Dapr sidecar dynamically reloads changed declarative topic subscriptions without restarting. This is enabled by default; to opt out, disable the `HotReload` feature in the [Dapr application configuration]({{% ref "preview-features.md" %}}).
 In-flight messages are unaffected when reloading a subscription.
 
 ### Message routing

@@ -21,9 +21,14 @@ The examples below demonstrate pub/sub messaging between a `checkout` app and an
 ### Declarative subscriptions
 
 {{% alert title="Note" color="primary" %}}
-This feature is currently in preview.
-Dapr can be made to "hot reload" declarative subscriptions, whereby updates are picked up automatically without needing a restart.
-This is enabled by via the [`HotReload` feature gate]({{% ref "support-preview-features" %}}).
+Since Dapr v1.18, declarative subscriptions are "hot reloaded" by default, whereby updates are picked up automatically without needing a restart. To opt out, disable the `HotReload` feature in the Dapr application configuration:
+
+```yaml
+spec:
+  features:
+    - name: HotReload
+      enabled: false
+```
 To prevent reprocessing or loss of unprocessed messages, in-flight messages between Dapr and your application are unaffected during hot reload events.
 {{% /alert %}}
 

@@ -6,27 +6,23 @@ weight: 300
 description: "Updating deployed components used by applications"
 ---
 
-When making an update to an existing deployed component used by an application, Dapr does not update the component automatically unless the [`HotReload`](#hot-reloading-preview-feature) feature gate is enabled.
-The Dapr sidecar needs to be restarted in order to pick up the latest version of the component.
-How this is done depends on the hosting environment.
+Since Dapr v1.18, updates to a deployed component are picked up automatically by the sidecar via [hot reloading](#hot-reloading). Hot reloading is enabled by default; to opt out, disable the `HotReload` feature in the [Dapr application configuration]({{% ref "preview-features.md" %}}).
+When hot reloading is disabled, the Dapr sidecar needs to be restarted in order to pick up the latest version of the component. How this is done depends on the hosting environment.
 
 ### Kubernetes
 
-When running in Kubernetes, the process of updating a component involves two steps:
+When hot reloading is disabled and running in Kubernetes, the process of updating a component involves two steps:
 
 1. Apply the new component YAML to the desired namespace
-1. Unless the [`HotReload` feature gate is enabled](#hot-reloading-preview-feature), perform a [rollout restart operation](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#updating-resources) on your deployments to pick up the latest component
+1. Perform a [rollout restart operation](https://kubernetes.io/docs/reference/kubectl/cheatsheet/#updating-resources) on your deployments to pick up the latest component
 
 ### Self Hosted
 
-Unless the [`HotReload` feature gate is enabled](#hot-reloading-preview-feature), the process of updating a component involves a single step of stopping and restarting the `daprd` process to pick up the latest component.
+When hot reloading is disabled, the process of updating a component involves a single step of stopping and restarting the `daprd` process to pick up the latest component.
 
-## Hot Reloading (Preview Feature)
+## Hot Reloading
 
-> This feature is currently in [preview]({{% ref "preview-features.md" %}}).
-> Hot reloading is enabled by via the [`HotReload` feature gate]({{% ref "support-preview-features.md" %}}).
-
-Dapr can be made to "hot reload" components whereby component updates are picked up automatically without the need to restart the Dapr sidecar process or Kubernetes pod.
+Dapr "hot reloads" components, whereby component updates are picked up automatically without the need to restart the Dapr sidecar process or Kubernetes pod.
 This means creating, updating, or deleting a component manifest will be reflected in the Dapr sidecar during runtime.
 
 {{% alert title="Updating Components" color="warning" %}}

@@ -19,7 +19,5 @@ For CLI there is no explicit opt-in, just the version that this was first made a
 | **Multi-App Run for Kubernetes** | Configure multiple Dapr applications from a single configuration file and run from a single command on Kubernetes | `dapr run -k -f` | [Multi-App Run]({{% ref multi-app-dapr-run.md %}}) | v1.12 |
 | **Cryptography** | Encrypt or decrypt data without having to manage secrets keys  | N/A | [Cryptography concept]({{% ref "components-concept#cryptography" %}})| v1.11  |
 | **Actor State TTL** | Allow 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]({{% ref actors_api.md %}}) for more information. | `ActorStateTTL` | [Actor State Transactions]({{% ref actors_api.md %}}) | v1.11  |
-| **Component Hot Reloading** | Allows for Dapr-loaded components to be "hot reloaded". A component spec is reloaded when it is created/updated/deleted in Kubernetes or on file when running in self-hosted mode. Ignores changes to actor state stores and workflow backends. | `HotReload`| [Hot Reloading]({{% ref components-concept.md %}}) | v1.13  |
-| **Subscription Hot Reloading** | Allows for declarative subscriptions to be "hot reloaded". A subscription is reloaded either when it is created/updated/deleted in Kubernetes, or on file in self-hosted mode. In-flight messages are unaffected when reloading. | `HotReload`| [Hot Reloading]({{% ref "subscription-methods.md#declarative-subscriptions" %}}) | v1.14  |
 | **Workflows Clustered Deployment** | Enable Workflows to function when workflow clients communicate to multiple daprds of the same appID who are behind a loadbalancer. Only relevant when using [Dapr shared]({{% ref "kubernetes-dapr-shared" %}}) | `WorkflowsClusteredDeployment`| [Dapr Shared]({{% ref "kubernetes-dapr-shared" %}}) | v1.16  |
 | **Workflows Durable Activity Results** | If set, ensures that activity results are durably sent to the owning workflow in multi-application scenarios, even when the owning workflow application is unavailable. Unless running multiple Dapr versions, this feature gate should be enabled. Disabled by default for backwards compatibility.  | `WorkflowsRemoteActivityReminder` | [Multi-application Workflows]({{% ref "workflow-multi-app.md#durable-activity-results" %}}) | v1.17 |