Mule 4.12 Edge leaves standard support this month. Upgrade to 4.13 before CloudHub does it for you

Mule 4.12 Edge leaves standard support this month. On CloudHub and CloudHub 2.0, MuleSoft will move every app still on it to the newest Edge version six weeks later, whether you've tested it or not. Upgrade your 4.12 apps to 4.13 yourself in the window, on a date you pick, and check the few 4.13 behaviour changes before you do.

Nothing stops working on the day standard support ends. What changes is who decides when your apps move. On CloudHub and CloudHub 2.0, MuleSoft applies the Edge upgrade during a monthly patch window, so the change lands on its calendar, not yours. If an integration behaves differently on 4.13, you find out in production during that window.

There's a second catch for anyone who planned to escape to the long-term support channel. MuleSoft only supports switching from Edge to a later LTSdefinitionLong-term support. These Mule versions get at least 18 months of standard support, and nobody upgrades your apps to a new minor version behind your back. version, and the newest LTS is still 4.9. Moving a 4.12 Edge app back to 4.9 LTS isn't a supported path, so for most teams the real choice is between upgrading to 4.13 yourself or letting the auto-upgrade do it.

Runtime Fabric and on-premises (hybrid standalone) estates aren't auto-upgraded, so nothing changes on its own there. They still drop to extended support in November and after February 2027 they get no more patches, only limited end-of-life technical help. An app nobody upgrades just keeps running on an old, unpatched runtime.

For engineers: the auto-upgrade only moves the minor version. Monthly auto-patching inside a minor version (4.12.5 to 4.12.6, say) is a separate process, and in November 2026 MuleSoft runs it as self-upgrade only for CloudHub and CloudHub 2.0. CloudHub also won't auto-upgrade an app when the target version is incompatible with its configuration, such as a TLS or Java change. Both 4.12 and 4.13 run on Java 17, so that safety net doesn't apply here.

Most apps will move from 4.12 to 4.13 with nothing more than a regression run, because both are on Java 17 and a minor version keeps backward compatibility. The changes above are the ones that can still bite. Error handling is the one we'd test first: an on-error block that matched the raw connector error type might now see a remapped type instead, and the flow takes a different path.

Mule uses feature flags tied to each app's minMuleVersion setting in mule-artifact.json. Leave that value at 4.12 and a few 4.13 changes stay off for the app: the new Cache scope format, the Kryo allowlist and the per-flow OpenTelemetry counters. It doesn't stop the error-mapping, JSON schema, header or OpenTelemetry key-name changes, so test those whatever value you set. Raise it later, app by app, once you've tested what changes.

Watch the other direction too. The runtime refuses to deploy an app whose minMuleVersiondefinitionThe line in mule-artifact.json that says which runtime an app needs at minimum. Mule also reads it to decide which newer behaviours that app gets. is later than the runtime itself. Once an app says 4.13.0, rolling it back onto 4.12 fails. Keep the old build artifact if rollback is part of your plan, and know that 4.12 can't read cache entries written in the new format.

Read the table one way and the Edge channeldefinitionMuleSoft's fast track for the Mule runtime. You get up to three new versions a year and short support on each, and CloudHub upgrades these apps for you whether you're ready or not. looks like hard work: 4.13 gives you about five months of standard support before the same thing happens again. Edge versions from 4.9 onward get standard support until one month after the next Edge release, then three months of extended support. If your team can't retest every few months, that's an argument for a later LTS once one exists.

Edge releases come up to three times a year, so this comes round again soon. The teams that cope treat the runtime upgrade as a routine change with a script, so nobody has to remember how it went last time.

We made these three up to show common setups. None of them is a real customer, but you'll probably recognise one.

We build and run MuleSoft integrations on Anypoint Platform and move apps between runtime versions and channels. For the 4.12 deadline we can build the inventory, test the risky flows on 4.13 and run the production moves inside the window. See our MuleSoft services, hire MuleSoft engineers for your own team, or start with an assessment of your integration estate. Our API integration practice covers the wider design and governance work.