Author and Publish

Two services, deliberately separated

AEM runs authoring and delivery on separate instances with separate repositories. This is not a scaling trick — it is the security and safety model. Work in progress, unpublished drafts, internal comments and the whole authoring UI simply do not exist on the server the public can reach. If publish is compromised, the attacker gets published content, which is public anyway.

• Author — full authoring UI, workflows, versioning, all content including drafts. Behind authentication, typically IP-restricted or behind SSO.
• Publish — a stripped runtime holding only replicated content. No authoring UI. Horizontally scaled: many publish instances behind a load balancer.
• Preview — Cloud Service only. A publish-shaped tier authors can replicate to first, to see exactly how content will render before the public does.

Replication: how content crosses the gap

Content moves from author to publish by replication. When an author presses Publish, the author instance serialises the relevant subtree and sends it to each publish instance, which writes it into its own repository. Key consequences:

• Publish content is a copy, not a live view. Until you publish, the change does not exist downstream.
• Replication is per-subtree. Publishing a page publishes that page's jcr:content — it does not automatically publish the images, experience fragments or tags it references.
• Unpublish (deactivate) is the reverse: it removes content from publish while leaving it intact on author.

Publishing options an author actually sees

• Quick Publish — publishes immediately with no confirmation step. Fast and dangerous; it does not show you the references.
• Manage Publication — the considered path. Lets you publish or unpublish, include references, schedule for later, and route through a workflow for approval.
• Publish Tree — replicates an entire branch. Powerful and easy to misuse: it can push hundreds of pages, including ones someone else was still working on.

What this means for you as a developer

Your code does not travel by replication. Code and immutable configuration reach publish through the Cloud Manager pipeline, which deploys the same package to both tiers. Replication moves content. Keeping those two paths straight in your head prevents a lot of confusion later: when a component renders differently on publish, ask first whether the difference is code (pipeline) or content (replication).

Author-only behaviour is also something you write deliberately. Components can check whether they are running in author or publish via the WCM mode, and the authoring UI's edit overlays only exist on author. Anything that depends on being in author mode must degrade gracefully on publish.