Back to blog

CloudHub 2.0 CI/CD: publish once to Exchange, promote without rebuild

2026-09-17

On CloudHub 2.0, Mule Maven Plugin deploy pulls the artifact from Anypoint Exchange — same pattern as Runtime Fabric. First you publish the GAV to Maven Facade v3, then cloudhub2Deployment / -DmuleDeploy installs that same binary on a Shared Space or Private Space. Build once = one artifact / one version; deploy many = mvn mule:deploy with env-specific properties / secureProperties — without mvn clean package on UAT and PROD.

What this piece is not: a copied CloudHub 1.0 pipeline with cloudHubDeployment, a user password in YAML, and a rebuild per environment. It is a failure-mode guide for platform / DevOps / integration leads on Azure DevOps or GitHub Actions (common in EU enterprise).

Below: why CH2 breaks a CH1-shaped pipeline, pitfall cards (symptom → cause → docs → pattern), an ADO/GHA sketch, a checklist, and AEO-ready FAQ.

Why CH2 breaks a pipeline copied from CH1

Exchange-first is not optional

Docs: The application is already published in Exchange and Facade v3 in distributionManagement (Deploying Apps with the Mule Maven Plugin — Before You Begin). Classic error: No application with the provided GAV could be retrieved from Exchange.

EU org: Facade URL https://maven.eu1.anypoint.mulesoft.com/api/v3/organizations/ORGANIZATION_ID/maven (region per Publish and Deploy Exchange Assets Using Maven).

cloudHubDeployment ≠ cloudhub2Deployment

CH2 requires a cloudhub2Deployment element with provider=MC and target = Shared Space region (e.g. Cloudhub-US-East-1, Cloudhub-EU-West-1) or a Private Space name. A CH1 profile (cloudHubDeployment, workers/region) will not work as “the same pom” on CH2.

Runtime twin: Deploy Applications to CloudHub 2.0 Using the Mule Maven Plugin.

Pitfall #1: User/pass instead of a Connected App

Symptom: people passwords in Variable Groups / GitHub Secrets; MFA blocks CI; account rotation breaks the pipeline; “who deployed?” audit is unreadable.

Cause: docs samples still show username/password, but for CI/CD Connected Apps (client_credentials) are the recommended path. Password grant exposes credentials and conflicts with MFA (Connected Apps for Developers).

Docs: Connected App in Maven: connectedAppClientId, connectedAppClientSecret, connectedAppGrantType=client_credentials; required scope Design Center Developer (ch2-deploy-maven — Authentication). Exchange: username ~~~Client~~~, password clientId~?~clientSecret (to-publish-assets-maven).

Pattern: Connected App (least privilege per BG/env) → settings.xml server or explicit connectedApp* in the POM. Zero user passwords in YAML.

Pitfall #2: Missing scopes → 403 after a “successful” deploy

Symptom: the app appears in Runtime Manager, but Maven exits 403 (often on a domains / status-verification path).

Cause: often missing Read Applications on the correct Business Group + Environment. Deploy can succeed; plugin status verification fails (Help: 403 Connected App CH2; Minimum Permissions for CI/CD).

Pattern: before the first pipeline, a scopes checklist per BG and environment (Create Applications, Manage Settings, Manage Application Data, Read Applications + Design Center Developer). Sandbox dry-run. Optional skipDeploymentVerification only as a temporary workaround — not a permissions “fix”.

Pitfall #3: Rebuild on UAT/PROD

Symptom: every environment runs mvn clean package/deploy; binary drift; different timestamps / dependency resolution; “it worked on DEV”.

Docs: mvn clean deploy -DmuleDeploy or mvn mule:deploy — To deploy the artifact without rebuilding it (ch2-deploy-maven — Deploy).

Pattern: CI = build + MUnit + flatten + publish a stable GAV to Exchange. CD = mule:deploy for that same GAV; env diffs = properties / secureProperties only.

Pitfall #4: Secrets in YAML / properties wipe the UI

Symptom: after redeploy, Runtime Manager properties disappear; Key Vault “doesn’t land”; some secrets are missing despite a POM “add-on”.

Docs: if the POM contains either properties or secureProperties, CH2 uses only that set — no merge with Runtime Manager; missing keys are removed (ch2-deploy-maven).

Pattern: deploy POM = full desired state or omit both elements for a “binary only” redeploy. Azure Key Vault / GitHub Environments → secureProperties in CD. Treat every promotion as a complete config snapshot, not a delta.

Pitfall #5: Old Mule Maven Plugin + LTS / Java 17

Symptom: LTS cannot be selected; releaseChannel/javaVersion ignored; default EDGE/Java 8 against org policy.

Docs: releaseChannel = NONE|EDGE|LTS (default EDGE); javaVersion = 8|17 (default 8). LTS is not for plugin ≤4.1.0 — upgrade to ≥4.1.1. After Mule 4.4 SS EOL (Oct 2024): new apps → 4.6 LTS or 4.8 Edge. Deprecated include 3.0.0–3.1.7 and 3.8.3 (ch2-deploy-maven).

Pin at publish (2026-09-17): official release notes list mule-maven-plugin 4.10.1 (14 Jul 2026) as latest in the index — security/bug fixes over 4.10.0; Java 8/11/17/21; Maven 3.9.0–3.9.15 (4.10.1 Release Notes, plugin release index). Docs samples still show 3.7.1 — do not copy the snippet version; pin ≥4.1.1 (prefer current latest from release notes).

Pattern: pin plugin 4.10.1 (or newer from release notes on cutover day); set releaseChannel + javaVersion explicitly in CD.

${revision} / flatten and SNAPSHOT

Exchange requires a unique GAV for stable; SNAPSHOT overwrites development state — avoid SNAPSHOT on PROD (ch2-deploy-maven — Exchange Snapshot Assets, to-publish-assets-maven). CI-friendly versions (${revision}) → resolve (e.g. flatten-maven-plugin) before publish. Do not mix maven-deploy-plugin with mule-maven-plugin when publishing to Exchange.

Sketch: Azure DevOps and GitHub Actions (same Maven contract)

Stage ADO GitHub Actions
CI Build + MUnit → flatten → publish Exchange Build job → publish Exchange
CD Release stages + Variable Groups + Key Vault → mule:deploy Environment jobs + approvals → mule:deploy
Auth Connected App secrets Connected App secrets
Ban User/pass, rebuild per env, SNAPSHOT on PROD Same

Do not copy happy-path YAML 1:1 — the failure-mode checklist above matters more than a template.

How-to video (oEmbed verified 2026-09-17): #01: Anypoint CloudHub2.0 | Deploying… using Mule Maven Plugin (Mule Ace Academy) — publish Exchange → deploy Shared Space. Ops adjacency (HA/cluster): CloudHub 2.0 Part II… (Sanjeev Tripathi).

CH2 CI/CD checklist (order)

  1. Connected App (client_credentials) + scopes per BG/env (including Read Applications).
  2. Facade v3 in distributionManagement (correct region).
  3. POM: cloudhub2Deployment (provider=MC, target, applicationName, replicas/vCores).
  4. mule-maven plugin 4.10.1 (min ≥4.1.1); explicit releaseChannel / javaVersion when LTS/Java 17.
  5. Flatten / resolve ${revision} before Exchange publish.
  6. CI: publish once a stable GAV (no SNAPSHOT on PROD).
  7. CD: mvn mule:deploy without rebuild; full properties/secureProperties set or neither.
  8. Smoke: Runtime Manager status + no 403 on verification.

FAQ

1. Does CloudHub 2.0 deploy require publishing to Anypoint Exchange?

Yes — for the Maven path. Docs require the application to already be in Exchange (Facade v3) before you run CH2 deploy.

2. How does cloudhub2Deployment differ from cloudHubDeployment?

cloudHubDeployment is the CH1 model (workers/region). CH2 uses cloudhub2Deployment with provider=MC and a Shared/Private Space target.

3. Why prefer a Connected App over username/password in CI/CD?

A Connected App works programmatically (client_credentials), does not need user MFA, and keeps people passwords out of YAML. Docs require among others the Design Center Developer scope.

4. What does build once, deploy many look like?

CI: mvn clean deploy (publish to Exchange). CD: mvn mule:deploy without rebuilding the artifact; environment diffs = properties.

5. What are flatten / ${revision} for?

So CI-friendly versions are resolved before publish — Exchange must not receive a literal ${revision}. Stable GAV must be unique.

6. Where should UAT/PROD secrets come from?

From a vault / Key Vault / GitHub Environments → secureProperties in CD. Remember: presence of properties or secureProperties in the POM replaces (does not merge) Runtime Manager config.

7. Why does the pipeline get 403 after a “successful” deploy?

Often missing Read Applications — the app is deployed, but the plugin cannot verify status. See Help on 403 Connected App CH2.

8. When do I need Mule Maven Plugin ≥ 4.1.1? What pin today?

When you want releaseChannel (LTS/EDGE) and javaVersion (8/17) via Maven — LTS is unsupported on plugin ≤4.1.0. At publish (2026-09-17) pin 4.10.1 from official release notes (not 3.7.1 from docs snippets).

9. Is SNAPSHOT allowed on CloudHub 2.0 production?

Docs discourage it: snapshot assets can change after deploy — avoid on production; use for DEV/test iterate + redeploy.

Soft CTA

Building a CH2 pipeline (ADO / GitHub Actions) and want a review of Exchange-first, Connected App scopes, and build once without a PROD rebuild? Solita is a Nordic MuleSoft partner with delivery from Poland (EU-shoring) — we help shape the Maven contract and the failure-mode checklist. No “#1” claims and no marketing YAML clones.

Sources

Documentation

Help

How-to video (oEmbed 2026-09-17)