June 24, 2026

FAQ on AEM as a Cloud Service

1. Which environments come with AEM as a Cloud Service?

Four types:

  • Production — for business practitioners
  • Stage — performance and quality tests before changes go to production
  • Development — for developers implementing AEM applications
  • Demonstration — training, demos and proofs of concept. It is simplified to a single author node; the others have at least two author nodes.

2. Which program types are available?

Two program types were initially available: AEM Sites as a Cloud Service and AEM Assets as a Cloud Service.

3. What does an AEM as a Cloud Service license include?

Code repository (Git)1
Baseline image (Sites or Assets)1
Stage and production environment set (1:1)0 or 1
Non-production environments (development or demonstration)0 to N
Pipeline per environment0 or 1

The author tier contains all Sites and Assets functionality for all programs, but Assets programs do not have a publish tier by default.

4. What changed in author, publish and replication?

Author and publish. Both tiers are always accessed through a load balancer, and the publish tier always has a CDN in front of it.

Replication. Author-to-publish replication now uses Sling Content Distribution, which distributes Sling resources between Sling instances. The API works at the path level, and distribution agents distribute specific paths between instances. It uses a pipeline service that runs on Adobe I/O, outside AEM.

The replication agents of earlier AEM versions are no longer used or provided, which can affect:

  • custom workflows that push content to replication agents, for example of preview servers;
  • replication agent customizations that transform content;
  • reverse replication from publish back to author.

5. Are all the old run modes still available?

No. Run modes are defined by service (author, publish) and environment type (dev, stage, prod), following the pattern <service>.<environment_type> — for example author.dev or publish.prod. The supported OSGi configuration folders are:

  • config — the default, applies to all AEM services
  • config.author — all AEM author services
  • config.author.dev, config.author.stage, config.author.prod
  • config.publish — all AEM publish services
  • config.publish.dev, config.publish.stage, config.publish.prod
  • config.dev, config.stage, config.prod — all services of that environment

The OSGi configuration with the most matching run modes wins.

6. How do we develop locally when AEM is in the cloud?

  • The AEM as a Cloud Service Quickstart — a standalone .jar installer of the latest AEM code base with the same functional and API surface. It is a simple author environment where most extensions can be developed and tested, though it does not include every AEM Sites and Assets feature.
  • The Dispatcher SDK — an image-based process for testing and validating dispatcher configurations locally.

7. Which new terms should we know?

  • AEM as a Cloud Service — the cloud-native way of running AEM applications
  • AEM image — a deployable artifact containing the AEM product code together with the customer code
  • Golden master — the AEM publish tier
  • Orchestration engine — scales the author and publish services as needed
  • Asset microservices — cloud-based asset processing for renditions, PDF processing, subasset handling, text extraction and more (see AEM Assets as a Cloud Service)

8. Which user roles exist?

Cloud Manager defines four roles that govern access to specific features:

  • Business Owner — defines KPIs, approves production deployments
  • Program Manager — sets up the team, reviews status
  • Deployment Manager — runs stage and production deployments
  • Developer — develops and tests custom application code, works with Git

Content authors do not interact with Cloud Manager; they can reach AEM through the program switcher after navigating from Experience Cloud.

9. How do we upgrade from an existing AEM version?

Planning

  • Assess cloud readiness: find the areas that need refactoring for AEM as a Cloud Service (source code vs deprecated features, the new path structure), then estimate the plan.
  • Plan resources: identify people, form the team, map roles and responsibilities.
  • Establish KPIs so the team focuses on what matters most.

Execution

  • Onboard: get familiar with the service and deploy the code to it.
  • Integrate: connect Git and deploy, transfer content, refactor code — using tools where possible, such as the Asset Workflow Migration tool, the Dispatcher Converter and the modernization tools.
  • Configure user roles and other settings in the Admin Console.

After go-live

  • Clean up temporary files
  • Review best practices for continuous development
  • Manage logs

10. How do we troubleshoot?

With the Developer Console, CRXDE Lite and the environment logs.

11. What does the local development SDK contain?

  • Quickstart JAR — the AEM runtime
  • Java API JAR — all Java APIs allowed for developing against AEM as a Cloud Service (previously the Uber JAR)
  • Javadoc JAR — the Javadocs for the API JAR
  • Dispatcher tools — for developing against the dispatcher locally

12. How have maintenance tasks become simpler?

Customers barely need to configure maintenance tasks any more, and can focus on application-level concerns while Adobe runs the infrastructure. Customers own the configuration of only these:

  • ad-hoc task purge
  • workflow purge
  • project purge

13. What are mutable and immutable content in AEM as a Cloud Service?

  • /apps and /libs are immutable: they cannot be created, updated or deleted after AEM starts (at run time). Any attempt to change them at run time fails.
  • Everything else in the repository — /content, /conf, /var, /home, /etc, /oak:index, /system, /tmp and so on — is mutable and can change at run time.
  • Oak indexes are mutable at run time.
  • /oak:index configurations are part of the code package, not the content package.

More in the AEM as a Cloud Service tutorials.

Posted by