CloudHub 2.0 Operating System Patch Updates

As a container-based platform, CloudHub 2.0 applies infrastructure fixes and security patches as needed to ensure the infrastructure is secure and up-to-date. Patch updates use rolling upgrade deployment (when selected as the deployment model) and can include operating system changes or changes to internal software. An update rotates, drains, and replaces the underlying hosts gradually to ensure zero downtime when using the Rolling Update deployment model. During the upgrade, the Mule application might be restarted onto a new secure host. If the Mule worker is not running with multiple replicas or is using the Recreate deployment model, it experiences slight downtime.

When an update is available, CloudHub 2.0 includes it in Production environments as the default for new private spaces. The existing infrastructure patching schedule occurs in the same maintenance window as CloudHub 2.0 Runtime patches. Infrastructure and runtime updates might cause your applications to restart.

Anypoint VPNs used in CloudHub 2.0 are upgraded continuously. Whenever a new update is available, the VPN is patched within the service-level agreement. If the Anypoint VPN is not set up as high availability or if the non-high-availability VPN is not set up with two tunnels, downtime is expected.

Schedule infrastructure upgrades earlier than the scheduled patching process, between the Release Available and the Auto-Update dates stated in the monthly updates table. This way, you can choose a date in the future that better suits your organization’s needs.

On average, this upgrade takes between thirty to sixty minutes to complete. If your upgrade is queued, it can take longer than thirty minutes. The impact of the upgrade process on running applications is consistent with the auto-patching behavior described in the previous sections.

You can modify or delete your scheduled upgrade if it is not already in progress, as indicated by the Queued status. If you cancel the schedule and do not create another or opt in to an earlier upgrade, the upgrade occurs during the mandatory patching window.

Opt in to apply infrastructure upgrades earlier than the scheduled patching process, between the Release Available and the Auto-Update dates stated in the monthly updates table. This way, you can choose the time that better suits your organization’s needs.

On average, this upgrade takes between thirty to sixty minutes to complete. If your upgrade is queued, it can take longer than thirty minutes. The impact of the upgrade process on running applications is consistent with the auto-patching behavior described in the previous sections.

In the first full week of each 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 monthly patches update applications only to the latest date patch for the patch version. They do not change the patch version number.

The format of the version number for these updates to 4.3.x or 4.4.x versions is:

Major.Minor.Patch : Date

Here’s an example version number, including the patch date:

4.4.0:20211015

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.

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.

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.

Starting with Mule 4.5, MuleSoft releases Edge versions in February, June, and October. 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.

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.

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.

The following table shows the Mule runtime release cadence support for CloudHub 2.0:

Application lifecycle management depends on the deployment model.

The version naming convention depends on the deployment model you are using. A version increments:

Application lifecycle management depends on the deployment model.

The version naming convention depends on the deployment model you are using. A version increments:

When a new runtime version is available:

MuleSoft applies the updates automatically, based on the published schedules. If you want, you can update them manually at your convenience.

If you select the Edge release channel, a banner appears indicating the date of the next automatic update.

The Infra Status column in the Private Space page shows the status of infrastructure upgrades for your private space.

MuleSoft regularly runs scans to identify security vulnerabilities in JVM and the underlying operating system, and then automatically applies security patches based on the following SLA:

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.