AEM Author And Publish Configuration Differences Explained
Adobe Experience Manager separates content creation from content delivery through two distinct environments: Author and Publish. Although both use the same AEM platform, they serve different users, carry different security assumptions, and require different operational settings.
Author is the controlled workspace where editors create pages, manage assets, launch workflows, and review changes. Publish is the public-facing tier that serves approved content to visitors, applications, and connected channels. Treating the two instances as interchangeable can create performance problems, security exposure, or broken deployment processes.
The most reliable AEM implementations make these differences explicit in code, OSGi configuration, dispatcher rules, and deployment procedures. Understanding the boundary also helps Java developers, front-end teams, and architects diagnose issues that appear only after content moves between environments.
Different roles in the AEM topology
An Author instance is designed for authenticated users and content operations. It commonly includes authoring consoles, workflow models, translation tools, project dashboards, inbox notifications, and administrative interfaces. Its traffic pattern is usually unpredictable but internal, with bursts caused by editorial activity, package installation, indexing, or asset processing.
A Publish instance has a simpler objective: deliver approved content quickly and safely. It should expose only the endpoints and components required by visitors or consuming applications. Publish servers are frequently placed behind a dispatcher and CDN, where cache rules, request filtering, and load balancing become part of the delivery configuration.
Content usually moves from Author to Publish through replication agents or an equivalent deployment mechanism. Code, OSGi settings, and repository structure should move through a controlled release pipeline instead of being changed manually on each server. This separation keeps editorial actions from becoming accidental production configuration changes.
Repository content and replication behavior
Author contains working content, versions, drafts, annotations, permissions, and workflow state. Publish generally contains the subset of pages, assets, and tags intended for delivery. A page can exist on Author for days before an editor activates it, while a deleted or deactivated page must also be removed from the public tier.
Replication agents are therefore central to the Author configuration. They define where content is sent, how activation is triggered, and how transport credentials are managed. Flush agents can notify a dispatcher or caching layer that a path has changed, allowing stale responses to be removed after publication.
Publish should not be configured as though it were another editorial workspace. Replication listeners, reverse replication, and author-only workflow services can create unnecessary processing or unexpected repository changes when enabled without a clear purpose. In a standard delivery architecture, Publish receives approved material and serves it; it does not originate the editorial lifecycle.
Projects that use React or another front-end framework also need to account for this boundary. The React SPA Editor guide illustrates how authoring overlays and application delivery interact, especially when components must remain editable on Author while rendering efficiently on Publish.
Configuration differences at a glance
AEM uses OSGi services, repository nodes, run modes, environment variables, and deployment packages to control behavior. The same service may exist on both tiers but require different values. For example, an email service might be active on Author for workflow notifications but disabled on Publish, where outbound administrative mail is unnecessary.
Run-mode-aware files are a practical way to express these distinctions. Configurations can be targeted to author, publish, development, staging, or production combinations, depending on the AEM version and deployment model. Teams should keep environment-specific values such as passwords, hostnames, and API keys outside source-controlled defaults whenever the platform supports secure secret injection.
| Area | Author configuration | Publish configuration |
|---|---|---|
| Primary users | Editors, administrators, developers | Anonymous visitors and consuming applications |
| Access control | SSO, author groups, administrative permissions | Minimal public access with protected operational endpoints |
| Replication | Agents, activation triggers, dispatcher flush | Usually receives replicated content |
| Caching | Often limited or bypassed for fresh editorial views | Dispatcher and CDN caching are central |
| Workflows | Enabled for review, approval, translation, and assets | Usually restricted to delivery-related processing |
| Debugging | Higher logging for editorial and integration diagnosis | Conservative logging to protect performance and disk |
| External services | Authoring tools, notifications, search, DAM integrations | Public APIs, analytics collection, delivery integrations |
| Maintenance | Indexing, package installation, content operations | Rolling restarts, cache management, traffic protection |
The comparison is a starting point rather than a universal template. A publish tier may need specialized workflows, and some implementations use separate preview or personalization services. The important principle is that every enabled service should have a documented purpose on the tier where it runs.
OSGi services and environment-specific values
OSGi configuration is one of the most common sources of Author-versus-Publish defects. A service may be active on both tiers, but its endpoint, credentials, scheduler interval, or processing mode can differ. Search connectors, SMTP services, analytics integrations, asset processing workers, and HTTP clients all need environment-aware values.
Author often connects to systems used by internal teams, such as identity providers, translation vendors, product information systems, or testing APIs. Publish should use production endpoints and tightly scoped credentials. A configuration that points Publish toward a development system can expose private data or make public requests fail unpredictably.
Schedulers deserve particular care. Scheduled jobs for link checking, report generation, DAM processing, or content cleanup may be useful on Author but waste resources on every Publish node. If a job must run in production, designate one responsible instance or use a coordination strategy so a cluster does not execute the same task repeatedly.
Logging follows the same rule. Detailed DEBUG logging can accelerate troubleshooting on Author, while verbose logging across a busy Publish farm can consume storage and reveal request details. Use targeted loggers, bounded retention, and temporary changes that are reverted after diagnosis.
Dispatcher, caching, and security controls
Dispatcher configuration is closely tied to the Publish role. Filters should reject administrative paths, repository internals, unsupported selectors, dangerous extensions, and unexpected HTTP methods. The goal is to allow valid delivery requests while preventing visitors from reaching authoring consoles or exposing implementation details.
Cache rules also differ from editorial expectations. Author pages must reflect drafts, permissions, and recent edits, so caching is commonly disabled or limited for authenticated users. Publish responses can be cached aggressively when content is public and stable, but activation and deactivation must trigger correct invalidation.
Personalization, cookies, query parameters, and authorization headers can reduce cache efficiency or cause one visitor’s response to be served to another. Teams should define which inputs vary the response and encode that logic in dispatcher and CDN policies. A cache hit that serves the wrong content is a functional and privacy failure, not merely a performance issue.
Security hardening should include separate credentials, restricted network paths, TLS validation, least-privilege service users, and removal of sample content. Publish should expose only required interfaces, while Author should be reachable only through trusted networks or a secure access layer. Administrative endpoints should never depend on obscurity alone.
SPA delivery and integration concerns
Single-page applications add another layer to the environment split. Author needs editor-friendly component models, placeholder behavior, in-context editing, and access to authoring metadata. Publish needs clean JSON or HTML responses, predictable client-library delivery, and cacheable assets without exposing editorial controls.
An Angular implementation may follow a different integration pattern from React, but the operational distinction remains. The Angular SPA walkthrough provides useful context for connecting a front-end application to AEM while preserving a workable authoring experience.
API permissions must be tested independently on both tiers. An endpoint available to authenticated authors may need to be unavailable to anonymous visitors, even when the same component uses it. CORS policies, referrer restrictions, token handling, and response caching should be reviewed as part of the deployment rather than added after a production incident.
Front-end assets can also behave differently. Development builds may use source maps and unminified files on Author, while Publish should receive optimized, fingerprinted resources. Client library categories, dependency order, and cache-busting values must remain consistent after activation so that a page does not reference assets that exist only on the authoring server.
A practical deployment checklist
A reliable release process compares the intended state of both tiers before and after deployment. Validate OSGi configurations, run modes, service users, replication agents, dispatcher filters, cache invalidation, and integration endpoints. Then test a representative page, asset, API request, and deactivation path from an external viewpoint.
Use these checks to keep the environments aligned without making them identical:
- Store shared configuration in version control and isolate secrets by environment.
- Confirm that Author-only consoles, workflows, jobs, and integrations are disabled or restricted on Publish.
- Test activation, update, deletion, and dispatcher invalidation with realistic content paths.
- Review Publish access logs and cache headers for accidental exposure or ineffective caching.
- Document every service that intentionally differs between Author, Publish, staging, and preview.
A useful review should include developers, system administrators, security owners, and content operations. Historical conference material and community discussions, including the ICF Olson background, reflect the cross-functional nature of AEM work: configuration choices affect editorial usability, application behavior, infrastructure cost, and public reliability at the same time.
Designing for predictable operations
The strongest AEM deployments make environment differences visible rather than relying on tribal knowledge. Naming conventions for run-mode folders, automated configuration validation, deployment smoke tests, and infrastructure documentation reduce the chance that an Author setting silently reaches Publish.
Observability should also distinguish the tiers. Track replication queues on Author, response time and cache hit ratios on Publish, failed integrations on both where relevant, and resource-heavy jobs wherever they run. Alerts should identify whether a problem affects content creation, content transport, or public delivery.
As AEM architectures expand into headless delivery, mobile applications, microservices, and analytics platforms, the Author-Publish boundary becomes more important. Each consumer needs an intentional contract for authentication, caching, content freshness, and failure handling. A clear separation makes those contracts easier to secure and maintain.
Review your current run modes, OSGi settings, replication path, dispatcher rules, and front-end integration against these principles, then turn the findings into automated deployment checks before the next release.