AEM Cloud Manager CI/CD Pipelines and Quality Gates: Every Threshold, and What Blocks a Release

On AEM as a Cloud Service, Cloud Manager is not one deployment option among several. It is the only path to production. You cannot copy a package onto a server, you cannot hot-fix a running instance, and you cannot skip a failing gate because the campaign launches tomorrow.

Teams arriving from Jenkins usually understand this in principle and discover it in practice the first time a release stops on a Security Rating. This page sets out the pipeline types and every published threshold, so it is not a surprise.

Pipeline types

Cloud Manager pipelines fall into two categories, and within them four kinds of deployment.

Production pipelines deploy to stage and then production, and run the full set of gates including performance testing.

Non-production pipelines deploy to development environments or run code quality checks without deploying at all — a code-quality-only pipeline is a useful pull-request gate.

Within those, what you are deploying matters:

• Full-stack — the AEM application, front-end code and configuration together.
• Front-end — front-end code only, deployed to the CDN without an AEM build. Much faster, and the right choice for most visual changes.
• Config — configuration only: CDN rules, log forwarding, environment variables. Minutes rather than an hour.
• Web tier — Dispatcher and Apache configuration, deployable independently.

Splitting these properly is the single biggest lever on release velocity. Teams that run everything through one full-stack pipeline wait an hour to change a CSS file.

The three-tier failure model

Cloud Manager classifies every finding into one of three severities:

Severity	What it does
Critical	Causes an immediate failure of the pipeline
Important	Causes the pipeline to enter a paused state, with an override available
Info	Informational only, no impact on pipeline execution

The "Important" tier is where process discipline gets tested. An override is available, someone with authority can click it, and after six months of overriding you have a codebase nobody can measure. Treat an override as an incident with a ticket, not as a button.

Every published code quality threshold

The code quality gate combines SonarQube analysis, content package examination with OakPAL, and Dispatcher validation, scanning against more than 100 rules.

Metric	Severity	Threshold
Security Rating	Critical	Must be B or better — below B fails the pipeline immediately
Reliability Rating	Important	Must be C or better
Maintainability Rating	Important	Must be A (remediation cost ≤ 5%)
Test coverage	Important	Minimum 50%
Skipped unit tests	Info	Flagged if > 1
Open issues	Info	Flagged if > 0
Duplicated lines	Info	Flagged if > 1%
Cloud Service compatibility	Info	Flagged if issues exist

Source: Adobe's Cloud Manager code quality testing documentation. Verified 15 September 2026.

Three observations from doing this repeatedly:

The 50% coverage gate is the one that bites legacy codebases. A ten-year-old AEM project migrating to the cloud typically arrives somewhere in the teens. Getting to 50% is real work and it belongs in the migration plan, not in the week before go-live.

Security Rating is the only Critical gate, and it is absolute. No override. A single blocker-severity security finding stops the release.

Maintainability must be A, which is stricter than most teams expect — it allows a technical-debt remediation cost of no more than 5%.

The other gates

Security testing runs AEM's own security health checks against the deployed instance.

Performance testing runs on production pipelines against stage, applying load and asserting page performance and error rates. Long-running or memory-leaking code that survived on a restarted 6.5 instance will show up here.

What catches teams migrating from Jenkins

• Gate debt is invisible until the first cloud release. SonarQube findings that were advisory for years become the thing between you and production. Run a code-quality-only pipeline against your existing codebase early in the migration — before you have committed to a go-live date.
• Build time is now a release-velocity problem. Cloud Manager builds are opinionated and time-boxed. A Maven build with slow or non-reproducible steps stops being an annoyance and starts being the reason a hotfix takes ninety minutes.
• You cannot hot-fix. There is no server to log into. Every fix is a pipeline run, which makes build time and pipeline splitting operational concerns rather than developer conveniences.
• Custom CI/CD wraps Cloud Manager; it does not replace it. The Cloud Manager API lets you trigger pipelines from GitHub Actions or elsewhere, and that is worth doing for orchestration and visibility. The gates still run and still decide.
• Environment configuration is code now. CDN rules, log forwarding and environment variables deploy through config pipelines. Anything configured by hand is drift waiting to be discovered.

How to clear a stuck pipeline properly

1. Read the actual finding, not the summary. The gate report links to the specific rule and the offending line.
2. Fix the code where the finding is real — most Security Rating blockers on AEM codebases are genuine: unescaped output in HTL, path traversal in servlets, hard-coded credentials.
3. Mark it as a false positive in SonarQube where it truly is one. This is legitimate and it persists, unlike an override.
4. Raise coverage with tests that assert behaviour. Tests written to move a percentage without asserting anything pass the gate and teach the team that the gate is theatre.
5. Only then consider an override, with a ticket and an owner.

What we do

Pipeline architecture and splitting, quality-gate remediation on legacy codebases migrating to the cloud, build-time reduction, Cloud Manager API integration with GitHub Actions, and config and web-tier pipeline setup. Usually as part of a migration, sometimes as a standalone remediation for teams already on Cloud Service whose releases have slowed to a crawl.

See Adobe Experience Manager services, or our broader DevOps consulting services and CI/CD pipeline optimization work.

Common questions

Can we use Jenkins or GitHub Actions instead of Cloud Manager?

You can use them to orchestrate and to trigger Cloud Manager pipelines through its API, and many teams should. You cannot use them to deploy to AEM as a Cloud Service directly. Cloud Manager is the only deployment path and its gates always run.

Can we turn the quality gates off?

No. Important-severity gates can be overridden per run. The Critical gate — Security Rating below B — cannot.

What test coverage does Cloud Manager require?

50% minimum, at Important severity. Below that the pipeline pauses and requires an override.

Why is our build so slow?

Usually a Maven build inherited from a 6.5 project: unnecessary modules, non-reproducible steps, heavy front-end work inside the AEM build that belongs in a separate front-end pipeline. Splitting front-end and config deployments out is the first fix.

How do we debug a failure with no server access?

Log forwarding to a stack you can query, configured through a config pipeline, plus the pipeline's own build and test logs. Set this up before go-live — retrofitting observability during an incident is how a two-hour problem becomes a two-day one.

What is the difference between a full-stack and a front-end pipeline?

A full-stack pipeline builds and deploys the AEM application, front-end code and configuration together. A front-end pipeline deploys front-end code to the CDN only, without an AEM build, and completes in a fraction of the time. Most visual changes should go through the latter.

---

Related reading: Adobe Experience Manager services · AEM cloud migration · Edge Delivery Services · AEM 6.5 end of life