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.

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​