What AEM Is

Why this matters

Before any code, you need a mental model of what AEM actually is. AEM is not a website framework in the way Next.js is. It is a content repository with an application server bolted on top and an authoring UI in front of it. Almost every confusing thing you will meet in the next 39 days makes sense once you accept that everything — pages, components, configuration, your own code's settings, even users — is stored as a tree of nodes in one repository.

The three ways to build with AEM Sites

Adobe now offers three quite different delivery models, and the documentation mixes them freely, which is a common source of confusion:

• Edge Delivery Services — content authored in documents (Google Docs, Word) or the Universal Editor, served from Adobe's edge as static-ish HTML. Extremely fast, very different development model (plain JS "blocks", no Java).
• Headless / API-first — content modelled as Content Fragments and delivered over GraphQL or REST to an app you build separately.
• Traditional AEM — server-side rendered pages built from components, running on the AEM Java stack, deployed as a Maven project. This is what the AEM Project Archetype generates, and it is the track this course follows.

The runtime tiers

A traditional AEM installation is not one server. It is at least two, and in Cloud Service, three:

• Author — where content authors log in and edit. Interactive, stateful, protected. Never public.
• Publish — a separate instance holding a copy of only the content that has been published. This is what real visitors hit.
• Preview — a Cloud Service addition: a publish-like tier where authors can see published-shaped content before it goes live.

In front of publish sits the Dispatcher, an Apache HTTP Server module that caches rendered HTML and blocks requests that should never reach AEM. In front of that, on Cloud Service, sits Adobe's CDN. A visitor's request is answered by the first layer that can answer it, so most requests never touch Java at all.

Visitor → CDN → Dispatcher → Publish → repository. Author sits off to the side and pushes content to publish through replication.

What "as a Cloud Service" changes

AEM as a Cloud Service (AEMaaCS) is the same product with the operational model rewritten. Adobe runs the infrastructure: instances autoscale, are patched continuously, and are replaced rather than upgraded. The consequences land directly on how you develop:

• You cannot hot-fix production. There is no CRXDE Lite writing to /apps on a running production instance — /apps is immutable at runtime.
• All code and config ships through Cloud Manager CI/CD pipelines, which enforce quality gates.
• Instances are disposable, so nothing durable may live on local disk.
• Version skew is gone but so is version choice — you track Adobe's continuous releases, which is why deprecated APIs matter.

The older self-managed forms (on-premise, and Adobe Managed Services) still exist and much of the documentation covers all of them. Watch the "Applies to" banner at the top of each Experience League page.