Contact Us 1-800-596-4880

CloudHub 2.0 Operating System Patch Updates

Because CloudHub 2.0 is an integration platform as a service (iPaaS), it manages operating system patching for you, enabling you to focus on developing and updating your applications.

CloudHub 2.0 applies security patches as needed to ensure that your application is secure.

Patch updates use blue-green deployment for applications that use the Rolling Update deployment model, which ensures zero downtime for applications that support it.

CloudHub 2.0 applies continuous updates to two MuleSoft-managed deployment platforms:

  • US cloud

  • EU cloud

CloudHub 2.0 Infrastructure 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.

Clustered Replicas and Rolling Updates

When running Mule in a cluster, a rolling update with a Mule runtime version that has a Hazelcast version change can result in multiple members of the cluster with different Hazelcast versions. This might cause application failure, with a Hazelcast serialization error, if the different Hazelcast versions are incompatible.

To prevent this kind of error, use the Recreate update strategy.

Schedule Infrastructure Upgrades (Optional)

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.

Schedule the Upgrade via Runtime Manager

  1. From Anypoint Platform, select Runtime Manager > Private Spaces.

    If an upgrade is available for a private space, the Upgrade Available status appears under the Infra Status column.

  2. Click Schedule an Upgrade.

  3. Select the date on which you want your private space to upgrade.
    Upgrades occur at 00:00 UTC on the date you select.

  4. Select the checkbox to confirm that you agree to upgrade early.

  5. Click Upgrade.

After applying the upgrade, you can check the status under the Infra Status column.

Opt-in Early Infrastructure Upgrades (Optional)

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.

This upgrade is irreversible. Ensure that you understand the impact of the upgrade and choose when to trigger the upgrade based on your organization’s needs before applying it in a production environment.

Apply the Opt-in Upgrade via Runtime Manager

  1. From Anypoint Platform, select Runtime Manager > Private Spaces.

    If an upgrade is available for a private space, the Upgrade Available status appears under the Infra Status column.

  2. Click Upgrade available.

  3. Click Upgrade now and opt in to the early upgrade.

  4. Click Upgrade.

After applying the upgrade, you can check the status under the Infra Status column.

Schedule or Apply the Upgrade via API

You can upgrade a private space using the Upgrade Private Space API. For more information, see the Upgrade Private Space API documentation in Exchange.

Monthly Date-Patch Updates

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.

Update Schedule

  • 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 during the first week of the month.

    • Applications in environments other than production are updated during the week.

    • Production applications are updated on the weekend.

When an automatic update occurs, the audit log for your application adds 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. If your application does not support zero-downtime updates or requires a manual update, you can manually 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.

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 Recommended Customer Profile Differentiators Support Coverage

Edge

Three times per year:

  • February

  • June

  • October

  • CloudHub and CloudHub 2.0

  • Includes new features on a frequent release cadence with shorter maintenance coverage.

  • Versions are not FedRAMP approved.

For versions 4.5 to 4.7:

  • 4 months of Standard Support

  • 4 months of Extended Support

For version 4.8 and later:

  • 5 months of Standard Support

  • 3 months of Extended Support

LTS

Annual:

  • February

On-premises:

  • Hybrid Standalone

  • Runtime Fabric

  • 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.

  • Versions are FedRAMP approved.

For version 4.6 and later:

  • 18 months of Standard Support

  • 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 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.

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 2.0:

Mule Version Release Date Java Version End of Standard Support End of Extended Support

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

4.6 LTS

February 2024

8, 11, and 17

August 2025

February 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

Deployment Models and Application Lifecycle Management

Application lifecycle management depends on the deployment model.

Action CloudHub and CloudHub 2.0 Runtime Fabric Hybrid Standalone

Deploy net new apps

Deploy to the latest minor-patch version available under Standard Support of each channel.

Deploy to any patch version of Mule runtime available under Standard or Extended Support. By default, the latest version of Mule runtime is selected.

Deploy while versions are in support period.

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: six weeks of opt-in time before auto-upgrade occurs.

  • LTS: apps are auto-upgraded six months after a new minor version becomes available.

Applications aren’t auto-upgraded by MuleSoft without customer-initiated actions.

No auto-upgrade capabilities

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

Always available

Using the Mule Upgrade Tool

Rollback

Available to the previously used version

Available to the previously used version

Available to the previous used version using the Mule Upgrade Tool.

Restart apps

Always

Always

Always while the version is within the support period

Keep running applications

Until End of Extended Support

Always

Always

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).

Cannot deploy new apps

Can deploy new apps

Retirement

Mule apps do not reach End of Life because they are always auto-upgraded.

When Mule apps reach End of Life, you can still restart or redeploy them using the same runtime version the apps are currently running on.

When Mule apps reach End of Life, MuleSoft reserves the right to close the connection of the Mule runtime server to Anypoint Platform.

Supportability

All Mule apps are under Standard Support.

Supported while Mule apps are within the assigned support period.

Supported while Mule apps are within the assigned support period.

Redeployment / Applying changes / Upgrades

Supported until End of Extended Support.

Supported when a build tag is provided. If a build tag is not provided, the application defaults to the latest patch of the minor version being used. If a wrong, invalid, or unsupported build tag is provided, the deployment fails.

Supported under Hybrid Stansalone.

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, Cloudhub 2.0, and Runtime Fabric

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

Unlike the Hybrid Standalone customer profile, CloudHub, CloudHub 2.0, and Runtime Fabric require 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

Hybrid Standalone

The Mule runtime versioning changes from date-based, for example, 4.4.0-20230317 to semVer as:

Major.Minor.Patch

Here are examples of the version numbers:

  • 4.5.1

  • 4.5.2

  • 4.5.3

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

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

N/A

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

N/A

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

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.

See Also

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 2.0

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: six weeks of opt-in time before auto-upgrade occurs.

  • LTS: apps are auto-upgraded six months after a new minor version becomes available.

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

Always

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 2.0

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 2.0 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

Case

Release Date

Description

Patch/Build

Mule Runtime

Runtime Manager/Maven/API Tag for New Deployment

1

Oct 3, 2023

First release of 4.5.0

0th patch and 1st build

4.5.0

4.5.0:1e

2

Nov 7, 2023

Second release of 4.5

1st patch and 1st build

4.5.1

4.5.1:1e

3

Nov 7, 2023

Another build on same day for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 2nd build

N/A

4.5.1:2e

4

Nov 7, 2023

OS updates only for CloudHub, CloudHub 2.0, and Runtime Fabric

1st patch and 3rd build

N/A

4.5.1:3e

5

Dec 5, 2023

Second patch version of 4.5

2nd patch and 1st build

4.5.2

4.5.2:1e

6

Jan 2, 2024

Hot fix for a Mule runtime regression

3rd patch & 1st build

4.5.3

4.5.3:1e

7

Feb 6, 2024

Release of new minor

0th patch and 1st build

4.6.0

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 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:

    ch2 update available column
  • Update available and the new available updates appear in the Deployment Target tab of the Settings page for the application:

    ch2 update available field

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

Update the Runtime Version Manually

  1. Log in to Anypoint Platform.

  2. Navigate to Runtime Manager.

  3. In the Runtime Manager navigation menu, click Applications

  4. Select the application you want to update.

  5. In Settings, in the Deployment Target tab, click the Runtime Version drop-down.

  6. Select the latest build for your version.

  7. Click Deploy.
    The application redeploys with the new runtime version.

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

Banner indicating the date of automatic update for Edge release channel.

Possible Status Types for Private Space Upgrades and Updates

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

Status Description

Latest

The private space is running the latest available infrastructure version. It is currently not undergoing an infrastructure upgrade or configuration update.

Upgrade Available

An upgrade is available for the private space. You can either initiate an upgrade immediately or schedule a time for the upgrade to begin.

Upgrade Scheduled

The private space has an upgrade scheduled for a future date.

Queued

The upgrade that was scheduled or initiated is about to begin. You can no longer make changes to the schedule or interrupt the upgrade.

Upgrading

The private space is undergoing an infrastructure upgrade, either scheduled, self-triggered, or as part of a monthly infrastructure upgrade.

Updating

The private space is undergoing an update that was triggered by a configuration change.

Failed

The private space experienced a failure which can be related to a user configuration update, or to an infrastructure upgrade, either scheduled, self-triggered, or as part of a monthly infrastructure upgrade.

Degraded

The private space is in degraded state.

 — 

Unable to get the details of the private space status and the status is unknown.

Security Updates

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:

Severity Level Severity Definition Patch Applied Within

P0

Critical

7 days

P1

High

30 days

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.