AEM as a Cloud Service Tutorial: What It Is, How It Differs, Where to Start
AEM as a Cloud Service explained: how it differs from AEM 6.5, author, publish and preview, environments and RDEs, the local SDK, Cloud Manager pipelines, logs, and a learning path.
Rewritten in October 2026, checked against Adobe's AEM as a Cloud Service documentation and release notes.
AEM as a Cloud Service is the cloud-native version of Adobe Experience Manager. Adobe runs it, keeps it on the latest version, and scales it with traffic. It is not AEM 6.5 hosted by Adobe; that was Adobe Managed Services. Under the hood it is a different runtime, with immutable code images, an autoscaling publish farm, a new publishing pipeline and a built-in CDN, and Cloud Manager is the only way to deploy to it.
This page explains the parts you need to understand before you build anything, then gives a learning path and answers common questions.
How it differs from AEM 6.5
| AEM 6.5 (on premises or Managed Services) | AEM as a Cloud Service | |
|---|---|---|
| Updates | Service packs you install | Maintenance updates that can ship daily and monthly feature releases, applied by Adobe, not optional |
| Code | Can change at runtime: Package Manager, Web Console | /apps and /libs are immutable; code and OSGi configurations come only from Git through Cloud Manager |
| Scaling | A topology you size yourself | An author cluster and a publish farm of at least two pods each, with publish scaled automatically |
| Publishing | Replication agents | Sling Content Distribution and a pipeline service outside AEM; publishers subscribe to content queues |
| Assets | DAM Update Asset workflow | Asset microservices outside AEM |
| CDN | Your own | An Adobe-managed CDN included |
| Logins | Local users, LDAP, SAML | Adobe IDs through the Admin Console |
| Java | Java 8 or 11 | Java 21 runtime |
Two of these changes catch every team moving from 6.5. First, the OSGi Web Console is gone. Its place is taken by the read-only Developer Console, and a configuration change means a commit and a pipeline run. Second, there are no replication agents to configure. The Replication Java API still works, with two built-in targets, publish and preview, but reverse replication is not supported. More detail is in the FAQ on AEM as a Cloud Service.
Author, publish and preview
- Author is where content is created. It runs as a cluster of at least two pods sharing one repository.
- Publish serves the site. It is a farm of at least two pods, each with its own copy of published content and its own Apache and Dispatcher, behind the CDN. More pods are added under load.
- Preview is a single node for checking content before it goes live, at
preview-p<program>-e<environment>.adobeaemcloud.com. Content is sent there with thepreviewreplication agent.
How these pieces fit together, with the repository and the CDN, is drawn out in AEM architecture.
Programs and environments
A company's account (the tenant) holds programs, usually one per solution: Sites, Assets or Forms. Each program has one Git repository and a set of environments:
- Production and Stage, always as a pair. Stage is sized like production and is where automated tests run before every production deployment.
- Development environments, which run the same software but are not sized for performance tests.
- A Rapid Development Environment (RDE), which every program gets. You deploy to it from your laptop in seconds, without a pipeline:
aio aem:rde:install <package>installs bundles, content packages, OSGi configurations and Dispatcher configuration. It is meant for one developer at a time.
Sandbox programs are for training, demos and proofs of concept. They come with one development environment, hibernate after eight hours without activity, and have no SLA.
The local SDK
The AEM as a Cloud Service SDK gives you a local AEM to develop against. It has four parts: the QuickStart JAR, the Java API JAR (com.adobe.aem:aem-sdk-api, which replaces the old Uber Jar), a Javadoc JAR, and the Dispatcher Tools. To run it, rename the QuickStart to aem-author-p4502.jar or aem-publish-p4503.jar and start it with java -jar; the file name sets the run mode and the port. Adobe recommends Java 21. The software is downloaded from Adobe's Software Distribution portal.
The SDK is close to the cloud but not identical:
- publishing is simulated with old-style replication agents;
/appsand/libsare writable locally, unlike in the cloud;- asset microservices, the CDN and the Developer Console exist only in the cloud, and some Sites and Assets features are missing.
Update the SDK after each monthly release. An update replaces the local instance, so keep your test content in packages.
The Dispatcher Tools include a validator that only accepts directives the cloud supports, and a Docker image that runs the Dispatcher on your machine in front of the local publish instance.
Cloud Manager and pipelines
Code reaches the cloud only through Cloud Manager pipelines. A production pipeline builds the code, runs unit tests and code quality checks, builds images, deploys to stage, runs functional, UI and experience-audit tests there, and then deploys to production with a rolling update and no downtime. A run takes roughly 20 to 50 minutes. There are also faster pipelines for front-end code, for Dispatcher configuration only, and for configuration files such as CDN rules and log forwarding.
The code quality gate runs SonarQube and OakPAL rules. Critical issues fail the pipeline outright, for example a security rating below B. Important ones pause it until a deployment manager overrides them, for example test coverage below 50%. Since 14 April 2026, code that still uses APIs Adobe has scheduled for removal, such as Guava or Log4j 1, also fails the quality gate. The Java side of this is covered in Java in AEM.
Logs
- Download logs from the environment in Cloud Manager, or use the Adobe I/O CLI:
aio cloudmanager:tail-logandaio cloudmanager:download-logs. - Logs are kept for seven days. For longer retention, set up log forwarding to Splunk, Datadog, Elasticsearch or OpenSearch, Azure Blob Storage or an HTTPS endpoint.
- Log levels are set in an OSGi configuration deployed through a pipeline. Adobe suggests DEBUG on development, WARN on stage and ERROR on production.
- Locally, the logs are in
crx-quickstart/logs:error.log,request.logandaccess.log.
Edge Delivery Services and the Universal Editor
Adobe now recommends Edge Delivery Services as the starting point for new AEM projects. Edge Delivery replaces the publish tier and Core Components with pages rendered at the edge from plain HTML, CSS and JavaScript kept in GitHub. Content comes from the Universal Editor on AEM author, or from Word, Google Docs or Adobe's Document Authoring. A site can mix the two: some pages on Edge Delivery, the rest on classic AEM Sites, under one domain.
The Universal Editor is AEM's newer visual editor. It works for Edge Delivery sites and for headless apps, and Adobe says it intends it to replace the Page Editor eventually. For headless projects, see the AEM headless tutorial.
Where AEM 6.5 stands
- Adobe Managed Services support for AEM 6.5 ended on 31 August 2026.
- Service pack 26, planned for 19 November 2026, is the last for AEM 6.5. Core support for AEM 6.5 on premises ends on 28 February 2027.
- For teams that keep running AEM themselves, the successor is AEM 6.5 LTS, generally available since 7 March 2025, on Java 17 or 21.
A learning path
- Understand the model. Read this page, the architecture overview and the FAQ.
- Set up locally. Install Java 21, Maven and Node.js, then the SDK QuickStart and the Dispatcher Tools, following Adobe's "Local Development Environment Setup".
- Build a site the classic way. Adobe's WKND tutorial, "Getting Started with AEM Sites", covers the project archetype, Core Components, editable templates, client libraries and HTL.
- Try content as data. Model Content Fragments and read them through GraphQL.
- Try Edge Delivery Services. Adobe's "Get started with Edge Delivery Services and Universal Editor" tutorial, or the tutorials on aem.live.
- Deploy for real. Push to the program's Git repository, run a pipeline, then use the RDE for fast iterations.
- Learn Assets. See AEM Assets as a Cloud Service.
Without a production program of your own, use a sandbox program if your company has one. The document-based Edge Delivery Services tutorial on aem.live needs only a GitHub account and a Google Drive or SharePoint folder.
Common questions
How often is AEM as a Cloud Service updated?
Maintenance updates can arrive daily and feature releases arrive monthly, on a published schedule. Adobe applies them to development first, then stage and production. You cannot skip them.
Can I install packages with Package Manager?
Only content packages, for mutable areas such as /content and /conf. Code and OSGi configurations must go through Git and a pipeline.
How do I work faster than a pipeline allows?
Use the Rapid Development Environment, which takes a deployment in seconds.
Is AEM as a Cloud Service the same as Adobe Managed Services?
No. Managed Services was AEM 6.5 hosted by Adobe, and it ended for 6.5 in August 2026. AEM as a Cloud Service is a different, continuously updated product.
More AEM tutorials
More in Tutorial series
- HTL in AEM: The HTML Template Language (Sightly) Tutorial
HTL expression syntax, display contexts, all 12 block statements and their priority, examples, and the full HTL reference.
- AEM Tutorial Series: Learn AEM Step by Step
An ordered AEM learning path based on AEM 6.4: what AEM is, installation, architecture, environments, consoles, authoring, packages, components, templates, assets and workflows.
- AEM 6.4 and 6.5 Tutorials
AEM 6.4 and 6.5 tutorials in one place: features, consoles, templates, core components, component patterns, content fragments, content services, personalization and upgrades.
- Useful AEM Consoles in AEM 6.4 (with URLs)
Every useful AEM console and its URL: admin, site admin, DAM, CRXDE Lite, Package Manager, OSGi web console, query debugger, dumplibs, JMX and more.