--- schema_version: "1" id: cd9a4519e49ad94bc00d868d4bd3ec1f7b2339131ada4507e1c8310ff88d6df9 title: Reviewing Mule App Versioning on Runtime Fabric collection: mulesoft version: current locale: en-us portal_url: https://docs.salesforce.com/mulesoft/current/en-us/runtime-fabric/2.11/app-versioning.md canonical_url: https://docs.mulesoft.com/runtime-fabric/2.11/app-versioning source_site: docs.mulesoft.com content_type: documentation content_hash: f0cacbd9bcd00068d8e276ccf5c2eb5ffdbb3e9c6d6a9713ec213864354a5cf2 description: MuleSoft Documentation Site release: "2.11" latest: false --- --- product: Runtime Fabric version: 2.11 --- # Reviewing Mule App Versioning on Runtime Fabric > For the full documentation index, see: https://docs.mulesoft.com/llms.txt When an application is deployed to Runtime Fabric, Runtime Manager automatically versions the application and its configuration. Application versioning enables you to: - View the configuration change history of the application. - Roll back the configurations to an earlier version in case the currently applied configuration has issues or is unstable. - View the application status. Possible values are: - Running: At least one replica is receiving traffic (Started state). - Not running: None of the replicas are receiving traffic. - Unknown: The target is disconnected. - Make updates to a deployed application’s configuration, including: - The application package. - Application deployment package version. - Deployment target settings, such as runtime version, number of replicas, and whether the application is running in cluster mode. - Resource allocations, including number of cores and memory allocation. - Ingress and property values. ## Access the Application’s Settings Page 1. Sign into Anypoint Platform and navigate to **Runtime Manager** The **Applications** page is displayed. 2. From the **Applications** page, select an application deployed to Runtime Fabric. 3. Open the management panel on the right side. 4. On the management panel, click the **Manage Application** button. The **Settings** page displays information about the application’s status, configuration history, and other useful information about the application. In the **Config changes** tab on the application’s **Settings** page. Runtime Fabric displays each change to the successfully deployed application configuration. The last ten configuration deployments are displayed in order of their respective configuration date. Each configuration in the history has a unique hash to identify it. ![Configuration page for a Runtime Fabric application, displaying the application file, version, deployment target, runtime version, and replicas](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning.png) > [!NOTE] The configuration history displays the last ten configuration deployments in order of > creation date. The **All changes** tab displays a history of versions created from the configuration deployment, and the actions performed on each version. ## Apply Configuration Changes 1. On the **Settings** page for the application, you can make these changes to a deployed configuration: - Upload a new application package. - Make changes to the deployment target and resource allocation. - Modify values for **Ingress** and **Properties**. 2. Once your changes are made, click **Apply Changes**. At the top of the **Settings** page, a status bar appears. ![Applying configuration status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-applying-config.png) 3. Click **View Status** to view the status for each replica in the deployment. Replica statuses include: - Started: The replica is receiving traffic. - Pending: The replica is waiting to start. - Starting: The replica is starting. - Deleting: The deletion of the replica is in progress. - Deleted: The replica has been deleted. - Stopping: The replica is stopping. - Stopped: The replica has stopped (is not receiving traffic). - Failed: The configuration failed to deploy. - Recovering: The replica is attempting to restart after terminating. The last successfully deployed configuration is retained until the new (desired) configuration is successfully deployed. New configurations are applied as "rolling updates." For example: - A replica is created with the desired configuration, - Once that configuration is successfully applied, the replica with the old configuration is deleted, - This process is repeated with each replica in the deployment. This model means there is zero downtime while updates are applied to the application. > [!NOTE] Since updates are applied as rolling updates, there will be different application > versions running at the same time until the update is completed, so make sure your > applications are able to run multiple versions in parallel. ![Replicas status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-replica-status.png) Once the configuration is successfully applied and deployed, a message appears at the top of the page. ![Configuration applied successfully status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-config-applied-success.png) The application status, configuration identifier, date, and other information is updated in the status box. The new configuration is displayed at the top of the **Config changes** list, along with a **Last successful** label to indicate that it’s the last configuration successfully deployed. If the updates to the configuration fail to deploy, you get an `Desired configuration wasn’t applied` message, and the **Configuration status** displays an `Update failed` label. The configuration is displayed in the **Config changes** history without a label. ![Configuration failed to apply status for a Mule app in the Runtime Manager UI](/mulesoft/current/en-us/runtime-fabric/2.11/_images/app-versioning-update-failed.png) In cases of failure, the deployment attempts to roll back to the last successful version of the configuration, but in certain situations, the rollback may not succeed. The status of the configuration displays `Update failed`. If it’s the first deployment of the application the rollback version won’t be defined and in case of a failed deployment, it remains in the failed status. ## Recommendations when Deploying Stateful Mule Apps - MuleSoft supports [persistent gateway](https://docs.mulesoft.com/runtime-fabric/2.11/persistence-gateway) for higher availability of applications requiring shared storage. - When using Mule [clustering](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters), a rolling update with a Mule runtime version that has a Hazelcast version change will generate a scenario when, at a certain point of time, the cluster will have more than a member with different Hazelcast versions. This may lead to application failure with a Hazelcast serialization error if the Hazelcast versions are incompatible. To prevent this kind of error, use the Recreate update strategy. ## Roll Back to a Previous Successful Configuration If you deploy a configuration that has issues, you can roll back to a previous successful version of the configuration. 1. In the **Config changes** history, select the version to which to roll back. 2. Click **Deploy**. The configuration moves to the top of the list in the **Config changes** history and displays the new deployment date. It retains its original identifying hash.