Skip to main content

AEMaaCS vs AEM 6.5

Most of this site applies to both AEM as a Cloud Service (AEMaaCS) and AEM 6.5, because they share the same core stack -- JCR (Oak), Sling, OSGi, HTL, Sling Models, Core Components. But a handful of operational and architectural differences genuinely change how you build, deploy, and debug. This page consolidates them so you do not have to rediscover them chapter by chapter.

:::note Which one am I on? If you deploy through Cloud Manager and there is no crx-quickstart folder you control, you are on AEMaaCS. If you run a JAR / installed instance you administer yourself (on-prem or AMS), you are on 6.5. AEM 6.5 also has an LTS track with extended support. :::

At a glance​

TopicAEM as a Cloud ServiceAEM 6.5
HostingAdobe-managed, auto-scaling containersSelf-managed (on-prem) or AMS
TopologyAuthor cluster + horizontally-scaled publish + CDNFixed author/publish instances you size
ReleasesContinuous (Adobe updates the runtime)Versioned service packs you install
RepositorySplit into immutable (/apps, /libs) and mutable (/content, /conf, /home)Single mutable repository
DeploymentGit + Cloud Manager pipelines onlyPackage Manager, Maven -PautoInstall, CI of your choice
Dev environmentLocal SDK + RDE; no prod filesystemFull local install; filesystem access
ReplicationSling Content Distribution (managed)Replication agents (/etc/replication)
Asset processingAsset Compute microservicesDAM Update Asset workflow
JavaAdobe-managed JDK (Java 11/17/21 class support)You choose the JDK
CRXDE LiteLocal SDK only; blocked in cloud envsAvailable everywhere
Custom OSGi configGit-deployed .cfg.json; secrets via $[secret:...]Web console or .cfg.json
DispatcherFlexible mode, validated in pipelineClassic config, manually managed

Repository mutability (the big one)​

On AEMaaCS the repository is split:

  • Immutable -- /apps and /libs are read-only at runtime and replaced only by a deployment. You cannot write to them from running code, and you cannot overlay /libs.
  • Mutable -- /content, /conf, /home, /var are writable at runtime.

Consequences for your code:

  • No runtime writes to /apps. Patterns that wrote nodes under /apps at startup must move to /conf or /var.
  • No /libs overlays. Customize via sling:resourceSuperType, render conditions, and supported extension points instead of overlaying /libs.
  • repoinit is the supported way to create service users, paths, and ACLs deterministically on every startup (see Security & Permissions).

On 6.5 the repository is a single mutable tree, so these restrictions do not apply -- which is exactly why migrated code often breaks on AEMaaCS.

Deployment & development workflow​

AEMaaCSAEM 6.5
Code path to prodGit -> Cloud Manager pipeline (build, code quality, deploy)Build package, install via Package Manager / Maven
Fast iterationRDE (Rapid Development Environment) -- push code in secondsLocal instance + mvn -PautoInstallSinglePackage
Config & secrets.cfg.json in Git; $[env:VAR] / $[secret:VAR] placeholdersWeb console or .cfg.json
Quality gateMandatory code-quality + security + (optional) UI tests in pipelineWhatever your CI enforces

See Deployment & Cloud Manager and the Cloud Manager documentation.

Publishing: replication vs content distribution​

  • AEM 6.5 uses replication agents under /etc/replication (Agent on author, Dispatcher Flush) that you configure and monitor.
  • AEMaaCS uses Sling Content Distribution through Adobe-managed infrastructure -- there are no replication agents to configure, and CDN/Dispatcher invalidation is automatic.

The authoring actions (Activate/Deactivate) and the Replicator API are the same on both. See Publishing & Replication and the AEMaaCS Replication operations reference.

Asset processing​

  • AEMaaCS: Asset Compute microservices generate renditions (fast, cloud-native, modern formats like WebP/AVIF), configured via Processing Profiles. See Asset microservices.
  • AEM 6.5: the DAM Update Asset workflow (ImageMagick/Sling) generates renditions on the instance.

See Assets & DAM.

Search & indexing​

Both use Oak indexes under /oak:index, deployed as content. The difference is the deployment contract:

  • AEMaaCS requires the <indexName>-custom-<N> naming convention so the pipeline can merge custom indexes with out-of-the-box ones with zero downtime.
  • 6.5 lets you deploy/modify indexes directly and trigger reindexing yourself.

See Search & Indexing.

Dispatcher​

  • AEMaaCS: Dispatcher config lives in your repo in flexible mode, is validated by the pipeline, and the CDN sits in front. See Dispatcher in the Cloud.
  • 6.5: you manage the Apache + Dispatcher module configuration on your own web tier.

See Dispatcher & Caching.

Security & access​

  • AEMaaCS: author login is via Adobe IMS / Admin Console (you do not manage author passwords in AEM); in-repository authorization (ACLs, groups) is still defined as usual, ideally via repoinit. CRXDE Lite and /system/console are not available in cloud environments.
  • 6.5: you manage users/passwords in AEM (or via LDAP/SAML), with full console access.

See Security & Permissions.

What stays the same​

If you are learning AEM, the overwhelming majority of skills transfer between both platforms:

  • JCR / Sling / OSGi fundamentals
  • Components: HTL, Touch UI dialogs, Sling Models, Core Components
  • Editable templates and policies
  • Content Fragments and the GraphQL API
  • Multi-Site Manager, translation, and i18n
  • The Replicator, QueryBuilder, WorkflowSession, and DAM Asset APIs

The differences are concentrated in operations and deployment, not in day-to-day component code.

See also​