CloudHub Runtime Continuous Updates | MuleSoft Documentation
# CloudHub Runtime Continuous Updates
Because CloudHub is an integration platform as a service (iPaaS), it manages operating system and Mule runtime engine patching, enabling you to focus on developing and updating your applications.
CloudHub applies security patches as needed to ensure that your application is secure and, once per month, it updates Mule to maintain the stability of your application.
Patch updates use blue-green deployment, which ensures zero downtime.
CloudHub applies continuous updates to all three MuleSoft-managed deployment platforms:
  * US cloud
  * EU cloud
  * MuleSoft Government Cloud


## Security Updates
MuleSoft regularly runs scans to identify security vulnerabilities in Mule runtime engine, JVM, and the underlying operating system, and then automatically applies security patches based on the following SLA:
Severity Level | Severity Definition | Patch Applied Within  
---|---|---  
Critical  
## Monthly Date-Patch Updates
Once per month, MuleSoft releases a _date-patch update_ , which includes backward-compatible bug fixes to address any issues discovered in Mule runtime engine. The monthly date-patch update might include security patches if the scheduled date is within the security SLA.
The format of the version number for these updates is:
_Major_._Minor_._Patch_ - _Date_
Here’s an example version number, including the patch date:
`4.2.2 - 05-04-2020`
The monthly patches update applications only to the latest date patch for the patch version. They do not change the patch version number.
Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term Support (LTS). The Mule runtime versioning schema for the new release channels is:
_Major[numeric] . Minor[numeric] . Patch[numeric] : Build[numeric] Channel[e for edge, nothing for LTS]_
Some examples of these values are: `4.5.0:1e` for Edge, and `4.6.0:1` for LTS.
### Update Schedule
The schedule for date-patch updates is:
  * In the first full week of the month, MuleSoft releases the date patch.
  * In the third full week of the month, MuleSoft automatically applies the date patch that was released in the first week of the month.
Applications in environments other than production are updated during the week. Production applications are updated on the weekend.
All releases occur in GMT-3 time. All automatic updates occur in the local time zone of the app’s deployment region. For example, CloudHub applies updates to apps deployed in the Asia-Pacific (Sydney) region in the AEST time zone and to apps deployed in the US West region in the PST time zone.   
---  
When an automatic update occurs, the audit log for your app contains an entry by user `Anypoint Staff`, which shows the date and time an update occurred and whether it was successful.
If the update is successful, no action is required. See Zero-Downtime Restart Limitations.


If your application does not support zero-downtime updates or requires a manual update, you can apply the date patch released in the first full week of the month in week 1 or week 2. See Update the Runtime Version Manually.
To update multiple applications, use the CloudHub API. See Update Multiple Apps to the Latest Runtime Release.
## Live Patching
CloudHub uses kernel live patching in the underlying VMs to apply the latest security and critical bug patches to the OS. You do not have to restart the CloudHub application between the monthly patching cycles.
CloudHub applications must be running 90-day-old or newer releases to be live-patched. The CloudHub live patching process checks the application to ensure that it has enough memory and CPU available to live patch. If there is not enough capacity, it skips the patching and retries at a later time.  
---  
### Determine if an Application Has Been Live-patched
You can check your application logs to determine if an application has been live patched.
## Edge and LTS Releases for Mule
Starting with Mule 4.5, MuleSoft introduces two new release channels, Edge and Long-term Support (LTS). Both release channels are available in all our deployment models: Anypoint Runtime Fabric, CloudHub, CloudHub 2.0, and Hybrid Standalone. Consider the following factors to determine the approach that best suits your requirements ahead of the Mule 4.4 End of Standard Support.
Channel Type | Release Cadence | Differentiators | Support Coverage  
---|---|---|---  
Up to three times per year | 
  * Includes new features on a frequent release cadence with shorter maintenance coverage.
  * Versions are not FedRAMP approved.

|  For versions 4.9 and later:
  * Standard Support until one month after the next Edge version is released
  * 3 months of Extended Support

For version 4.8:
  * 5 months of Standard Support
  * 3 months of Extended Support

For versions 4.5 to 4.7:
  * 4 months of Standard Support
  * 4 months of Extended Support

  
Annual:
  * February

| 
  * Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

|  For version 4.6 and later:
  * A minimum of 18 months of Standard Support
  * A minimum of 6 months of Extended Support
|  For versions 4.9 and later:
  * Standard Support until one month after the next Edge version is released
  * 3 months of Extended Support

For version 4.8:
  * 5 months of Standard Support
  * 3 months of Extended Support

For versions 4.5 to 4.7:
  * 4 months of Standard Support
  * 4 months of Extended Support

  
Annual:
  * February

| 
  * Includes new features introduced in prior Edge releases, along with new features introduced in the February Edge release. This release is maintained for an extended period over being the first to adopt new capabilities.

|  For version 4.6 and later:
  * A minimum of 18 months of Standard Support
  * A minimum of 6 months of Extended Support

  
In February, both Edge and LTS release with the same underlying version, including a minor Mule runtime version and new features.
To review the new support policy that aligns with the new release periods and types of releases, see MuleSoft Support Policy.
The monthly patching process remains unchanged. See Update Patches to Mule.   
---  
## Edge Channel
Starting with Mule 4.5, MuleSoft releases Edge versions up to three times a year. Use the Edge channel if you want to stay on top of the latest features and feel comfortable with a more frequent release cycle and auto-app upgrade cycle. The Edge channel includes the latest features and innovations available on the MuleSoft platform.
## LTS Channel
Starting with Mule 4.6, MuleSoft releases Long-Term Support (LTS) versions annually in February. If you are on Mule 4.4, you are not required to upgrade to Mule 4.6. However, because Mule 4.5 releases in October 2023, Standard Support for Mule 4.4 ends in October 2024, followed by the End of Extended Support in October 2025.
For CloudHub and CloudHub 2.0 customers, once Standard Support for Mule 4.4 ends, if you want to deploy new apps, you must do so on Mule 4.6 LTS or Mule 4.8 Edge.
Use the LTS channel if you want to avoid maintaining new versions frequently. The LTS channel adopts new capabilities after they have been introduced via Edge releases.
## Switch from an Edge Version to an LTS Version
You can switch from an Edge version to an LTS version and vice versa. However, when moving from Edge to LTS, you must choose a later LTS version. For example, if you choose Mule 4.6 LTS and you want to implement a specific new feature released on Mule 4.7 Edge, you can opt into that Edge release, then merge into Mule 4.9 LTS once it is available. MuleSoft does not support apps that are switched from Edge to an older LTS version. For example, switching an app from Mule 4.7 Edge to Mule 4.6 LTS might result in losing some of the new features in the older LTS version.
## Mule Runtime Release Cadence Support
The following table shows the Mule runtime release cadence support for CloudHub:
Mule Version | Release Date | Java Version | End of Standard Support | End of Extended Support  
---|---|---|---|---  
February 2025 | August 2026 | February 2027  
4.9 Edge | February 2025 | November 2025 | February 2026  
4.8 Edge | October 2024 | 8, 11, and 17 | March 2025 | June 2025  
4.7 Edge | June 2024 | 8, 11, and 17 | October 2024 | February 2025  
February 2024 | 8, 11, and 17 | February 2026 | October 2026  
4.6 Edge | February 2024 | 8, 11, and 17 | June 2024 | October 2024  
4.5 Edge | October 2023 | 8 and 11 | February 2024 | June 2024  
MuleSoft provides an extended support window for version 4.6 LTS due to its compatibility with Java 8, 11, and 17.   
---  
If you are a CloudHub or a CloudHub 2.0 customer and you want to create or test Mule 4.6 applications in Anypoint Studio, the Studio version required is the next upcoming release in March. Meanwhile, MuleSoft enables you to deploy new apps in Mule runtime 4.5e version via API, Mule Maven plugin, and Anypoint Platform CLI starting February 14 until April 19. Auto-upgrade from Mule 4.5 Edge to Mule 4.6 Edge for CloudHub and CloudHub 2.0 applications will be performed in April instead of February. See Temporary changes to auto-upgrade and new app deployment for Mule 4.5 Edge.   
---  
## Deployment Models and Application Lifecycle Management
Application lifecycle management depends on the deployment model.
Action | CloudHub  
---|---  
Deploy net new apps | Deploy to the latest minor-patch version available under Standard Support of each channel.  
Auto-upgrade |  Patches: Monthly auto-patching upgrade when a new patch version is available. See patching schedule for CloudHub and CloudHub 2.0. Channels: All apps are auto-upgraded to the latest minor version within their respective channels (Edge or LTS) during the monthly patching schedule of the month when previous version goes out of Standard Support.
  * Edge: auto-upgrade occurs six weeks after the version reaches its End of Standard Support.
  * LTS: auto-upgrade occurs six weeks after the version reaches its End of Standard Support.

  
Self-upgrade |  The auto-upgrade takes place during a fixed patching schedule after the version’s standard support ends. See patching schedule for CloudHub and CloudHub 2.0.
  * Edge: six weeks
  * LTS: six months

  
Rollback | Available to the previously used version  
Restart apps  
Keep running applications | Until End of Extended Support  
End of Extended Support | Shutdown running apps. Starting with Mule 4.7, CloudHub and CloudHub 2.0 applications in the Edge or LTS channels that are still running End of Life versions will undergo a forced upgrade to the latest version during the monthly upgrade window (See upgrade window for CloudHub and CloudHub 2.0).  
Retirement | Mule apps do not reach End of Life because they are always auto-upgraded.  
Supportability | All Mule apps are under Standard Support.  
## Mule Runtime Version Naming Changes
The version naming convention depends on the deployment model you are using. A version increments:
  * MAJOR when a release includes features that introduce breaking changes and backward incompatibility.
  * MINOR when a release includes all new features keeping backward compatibility with previous minors.
  * PATCH when a release includes bug fixes and security updates that include upgrades to libraries with reported vulnerabilities. We build a new runtime and do a full validation test.
  * BUILD when a release includes changes related to Image/AMI, including OS changes, OS security updates, and changes in products outside the runtime. It doesn’t include any runtime changes.


### CloudHub
The Mule runtime versioning schema for the new release channels is:
_Major[numeric] . Minor[numeric] . Patch[numeric] : Build[numeric] Channel[e for edge, nothing for LTS]_
Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they are represented as:
  * Edge: 4.6.0:1e
  * LTS: 4.6.0:1


CloudHub requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema.
Here are examples of the version numbers:
  * Edge: 4.5.0:1e
  * Edge: 4.6.0:1e
  * LTS: 4.6.0:1
### CloudHub
The Mule runtime versioning schema for the new release channels is:
_Major[numeric] . Minor[numeric] . Patch[numeric] : Build[numeric] Channel[e for edge, nothing for LTS]_
Each February, MuleSoft releases both an Edge and an LTS release with the same _Major.Minor_ version. To distinguish the versions, they are represented as:
  * Edge: 4.6.0:1e
  * LTS: 4.6.0:1


CloudHub requires regular OS updates, hence the addition of the build enumeration in the full runtime version schema.
Here are examples of the version numbers:
  * Edge: 4.5.0:1e
  * Edge: 4.6.0:1e
  * LTS: 4.6.0:1


Mule runtime does not introduce a semVer increment if there is a month with no fixes.
Here is an example of the versioning schema using different patch and builds:
Hybrid Standalone | CloudHub - AMI / CloudHub 2.0 / Runtime Fabric - Docker image  
---|---  
Release Date | Description | Patch/Build | Mule Runtime | Runtime Manager/Maven/API Tag for New Deployment  
Oct 3, 2023 | First release of 4.5.0 | 0th patch and 1st build | 4.5.0:1e  
Nov 7, 2023 | Second release of 4.5 | 1st patch and 1st build | 4.5.1:1e  
Nov 7, 2023 | Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric | 1st patch and 2nd build | Not Available | 4.5.1:2e  
Nov 7, 2023 | OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric | 1st patch and 3rd build | Not Available | 4.5.1:3e  
Dec 5, 2023 | Second patch version of 4.5 | 2nd patch and 1st build | 4.5.2:1e  
Jan 2, 2024 | Hot fix for a Mule runtime regression | 3rd patch & 1st build | 4.5.3:1e  
Feb 6, 2024 | Release of new minor | 0th patch and 1st build | 4.6.0:1e (Edge) / 4.6.0:1 (LTS)  
The Mule runtime versioning schema uses the following conventions:
  * Patch number in schema
    * In the schema `4.5.X:2e`, the patch number is the X.
    * The patch number starts from `0`, introducing a new minor version.
    * The patch number increments when the release introduces new code changes, including hotfixes to regressions or other bug fixes.
  * Build number in schema
    * In the schema `4.5.1:Ye`, the build number is Y.
    * The build number starts from `1`, introducing the first AMI or Docker image build of the patch.
    * The build number increments whenever the release introduces a new build of the AMI or Docker image for the same Mule runtime version. This increment does not indicate code changes to Mule runtime.


## Update the Runtime Version Manually
The **Update Available** column indicates which apps require a runtime version update. You can schedule the update to occur at your convenience.
Before updating apps in the production environment, update them in the sandbox environment and run the required tests.
### Update a Single App to the Latest Runtime Release
To update an app to the latest date patch:
  1. In the Runtime Manager navigation menu, click **Applications**.
  2. Click the name of the application you want to update to display the details pane.
  3. Access the **Settings** page for the application.
  4. Click the **Runtime** tab.
If the app requires an update, **Update available** appears in the **Runtime version** menu:
  5. Select the latest version from the **Runtime version** drop-down menu.
  6. If you want to see details about the version, click the **Read release notes** link.
  7. Click the **Apply Changes** button to update the app.


CloudHub updates the app with the version you selected and displays a message indicating success or failure.
If the app update is unsuccessful, the app remains in the **Update Available** tab. In this case, the app continues to run correctly on the previous runtime version and no action is required.
If you select the Edge release channel, a banner appears indicating the date of the next automatic update.
### Update Multiple Apps to the Latest Runtime Release
Although the Runtime Manager UI doesn’t support updating multiple apps to the latest runtime version, you can use the CloudHub API to perform a bulk update. See How to Perform a Bulk CloudHub Application Update to the Latest Runtime Releases.
Applications updated using the Bulk Update API are processed with a lower priority and may take slightly longer to update.   
---  
## Update Notification
When a new runtime version is available:
  * The **Applications** page displays an **Update Available** column that indicates if there is an update available for the application:
  * **Update available** and the new available updates appear in the **Runtime version** tab of the **Settings** page for the application:


MuleSoft applies the updates automatically, based on the published schedules. If you want, you can update them manually at your convenience.
## Zero-Downtime Restart Limitations
Zero-downtime restarts don’t work in the following cases:
  * The CloudHub application is a durable subscriber.
In this case, only one unique subscriber can be active at a time. For these applications, you must manually stop and start the application to apply the latest update.
  * The CloudHub application connects to an external dependency that is unavailable, unresponsive, or requires warmup.
In this case, CloudHub waits up to three minutes for the application to connect to any dependencies before assigning the application domain and related static IP addresses (if used) to the new version of the application.


If either case applies to your application, contact Support and your CSM account representative for information about updating the application to be cloud-ready.
## Check Your Application Status After an Update
After a new update occurs, you can check your applications status state in the **Status** column in Runtime Manager’s **Applications** tab.
You can also check your application logs to verify if your application was deployed correctly and take any remediation actions in the event of some auto-minor update-related issue. For more information, visit View Logs.
To be notified by e-mail when an error occurs after an automated update, you can create an alert.
## Failed Automated Updates
With blue-green deployments, when an automated update fails to be deployed to a new worker, the application continues to run the non-latest patch version on the currently running worker.
Possible failure reasons include but are not limited to:
  * Removing one of the application properties from the Anypoint Runtime Manager UI after deployment.
  * Incompatibility of a custom module with the latest patch version release.


Using a runtime version that is more than three months old can introduce security vulnerabilities. If your application fails to be automatically updated after two monthly patching cycles, the application is stopped and force-updated to the latest patch version. Applications that fail to start require your action to address patches.   
---  
## See Also
  * Edge and LTS Releases for Mule.
  *   *   *   *