51ºÚÁϲ»´òìÈ

Release notes for Cloud Manager 2025.9.0 in 51ºÚÁϲ»´òìÈ Experience Manager as a Cloud Service release-notes

Learn about the release of Cloud Manager 2025.9.0 in AEM (51ºÚÁϲ»´òìÈ Experience Manager) as a Cloud Service.

See also the current release notes for 51ºÚÁϲ»´òìÈ Experience Manager as a Cloud Service.

Release dates release-date

The release date for Cloud Manager 2025.9.0 in AEM as a Cloud Service is Thursday, September 4, 2025.

The next planned release is Thursday, October 2, 2025.

What’s new what-is-new

  • Manually renew 51ºÚÁϲ»´òìÈ-managed domain validation certificates

    You can now manually renew 51ºÚÁϲ»´òìÈ-managed Domain Validation (DV) certificates from Cloud Manager or the Public API to refresh certificates proactively.

    SSL certificate renew

  • Support now added for Azure DevOps for private repositories

    Documentation updates include configuration steps for Bring Your Own Git with Azure DevOps and pull request validation. See Add External Repositories in Cloud Manager.

  • Pull request checks for private repositories

    Cloud Manager now supports config pipelines with private repositories across GitHub, Bitbucket, Azure DevOps, and GitLab. See Pull Request Checks for Private Repositories.

Beta programs private-beta-program

Participate in Cloud Manager’s beta programs to get exclusive access to upcoming features before their general release.

The following opportunities are currently available:

One-click rollback for pipeline deployments one-click-rollback

Quickly revert to a previous deployment if the latest customer source code is not working as expected—no need to rerun the full pipeline or manually revert commits.

Restore customer source code from the Environments card Environments card above showing the Restore > Previous code deployed option for a selected environment.

Restore previous code deployed dialog box
In the Restore previous code deployed dialog box, review the currently deployed version and the version you want to restore, then click Confirm.

Restoring activation
Cloud Manager rolls the environment back to the earlier build, keeps content and configuration intact, and marks the environment Restoring until deployment completes.

Source code version in use The Environment details view, as seen above, now also shows the active source-code version in use.

If you are interested in testing this new feature and sharing your feedback, send an email to restorecode@adobe.com from your email address associated with your 51ºÚÁϲ»´òìÈ ID.

See Restore the Previous Code Deployed in AEM as a Cloud Service.

See also Content Restore in AEM as a Cloud Service.

Specialized Testing Environment specialized-test-environment

Cloud Manager now supports the addition of a new environment type called Specialized Testing Environment. The environment is designed to help teams validate features under near-production conditions before going live. This environment type is distinct from Production + Stage, Development, or Rapid Development environments and offers a focused space for running advanced validation scenarios.

Recent enhancements

  • You can now configure a Specialized Testing Environment on a non-production pipeline through a simpler, more intuitive workflow. The streamlined setup speeds completion and reduces configuration errors.
  • Copy Content is now supported in Specialized Testing Environments. You can now run Copy Content safely in isolated testing environments that mirror Production.

See Add a Specialized Testing Environment.

Add environment dialog box with Specialized Testing Environment radio button selected

NOTE
51ºÚÁϲ»´òìÈ has closed beta access requests for Specialized Testing Environments, having reached a sufficient number of participants. The feature is now in preparation for general availability.

Bring Your Own Git (BYOG) gitlab-bitbucket-azure-vsts

Customers can now onboard their Azure DevOps Git repositories into Cloud Manager, with support for both modern Azure DevOps and legacy VSTS (Visual Studio Team Services) repositories.

  • For Edge Delivery Services users, the onboarded repository can be used to sync and deploy site code.
  • For AEM as a Cloud Service and 51ºÚÁϲ»´òìÈ Managed Services (AMS) users, the repository can be linked to both full-stack and frontend pipelines.

Support for additional pipeline types and pull request validation through code quality pipelines is coming soon.

See Add external repositories in Cloud Manager.

Add Repository dialog box

Frequently asked questions about BYOG

Question
Answer
How can a project switch back to the 51ºÚÁϲ»´òìÈ-managed Git repository if needed?
Switching back is straightforward. Update the pipelines to point to the 51ºÚÁϲ»´òìÈ repository and remove the external repository if it is no longer required.
Is it possible to configure different repositories for different environments (for example, non-production versus production) to allow testing in non-production first?
Yes, different repositories can be configured for separate environments. For example, the dev or code quality pipeline can point to an external repository while the production pipeline remains connected to the 51ºÚÁϲ»´òìÈ repository. Make sure that the sync job between the two repositories remains active during this configuration.
Do existing settings like IP Allow lists continue to work?
Yes, existing IP Allow lists continue to work as usual. However, if the external Git repository is protected by a firewall, the necessary 51ºÚÁϲ»´òìÈ IP addresses must be added to the allow list.
Do all GitLab repository URLs work? The repository URL in use follows the format https://gitlab_dedicated_url.com/path/repo-name.git, which differs from the example in the documentation.
Yes, any GitLab repository that supports API V3 or V4 is supported, including self-hosted GitLab URLs like the one described in Add external repositories in Cloud Manager (https://git-vendor-name.com/org-name/repo-name.git).

Manage Access Tokens manage-access-tokens

Use Manage Access Tokens in Cloud Manager to view, rename, and delete access tokens associated with external BYOG repositories, such as GitHub Enterprise, GitLab, Bitbucket, and Azure DevOps.

See Manage Access Tokens.

Add Edge Delivery config pipeline add-eds-pipeline

Config Pipelines are now supported for sites built with Edge Delivery Services, expanding this capability beyond just Cloud Service environments. You can use Config Pipelines to manage settings such as traffic filtering rules and Web Application Firewall (WAF) configurations, where applicable. See Supported Configurations.

Recent enhancement

  • Edge Delivery config pipelines now support secrets through Cloud Manager pipeline variables.

  • Edge Delivery Services pipelines now display Configuration in the Deployed Code column, enabling instant identification of configuration-only deployments.

  • Cloud Manager shows Add Edge Delivery Pipeline once a program contains at least one Edge Delivery Services site and one mapped domain. Otherwise, the option appears disabled, and a tooltip explains missing requirements.

  • The Edge Delivery tab shows a new Edge Delivery pipelines widget that lists each pipeline’s Name, Status, Repository, and Branch.

    Edge Delivery pipeline widget showing pipeline name, status, repository, and branch

  • The Filters panel adds a Delivery Type section; includes Edge delivery and Publish delivery checkboxes.

    Filter panel showing new Delivery type of Edge delivery and Publish delivery

Add Edge Delivery pipeline in Add Pipeline drop-down list Adding an Edge Delivery pipeline from the Program Overview page, Pipelines card.

Add Edge Delivery pipeline dialog box Add Edge Delivery pipeline dialog box.

See Add Edge Delivery Pipeline

If you are interested in testing this new feature and sharing your feedback, send an email to grp-aemeds-config-pipeline-adopter@adobe.com from your email address associated with your 51ºÚÁϲ»´òìÈ ID.

Bug fixes bug-fixes

There are no significant bug fixes in the September Cloud Manager release.

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab