AEM and Kubernetes in Production: A Practical Operations Guide

Running Adobe Experience Manager in Kubernetes can provide repeatable deployments, controlled scaling and a consistent platform for development teams. It also introduces a layer of operational complexity: AEM has distinct author and publish roles, repository state, dispatcher caching, JVM requirements and integration dependencies that cannot be treated like ordinary stateless web services.

For Australian organisations, the decision often sits between a managed Adobe service and a self-managed AEM 6.5 estate hosted in a local cloud region. Teams in Sydney, Melbourne, Brisbane and Perth may need to balance data residency, latency, enterprise procurement and a limited pool of engineers with deep AEM and Kubernetes experience. A sound design begins by matching the platform to those practical constraints.

Define the AEM Container Boundary

AEM author, publish and dispatcher tiers should be modelled as separate workloads. Authors manage content and operational activity, while publish instances serve visitor traffic. Dispatcher usually sits closer to the edge, working with a web server and cache rules before requests reach publish. Combining every role in one container makes scaling, security and incident response harder.

The AEM application image should be immutable. Build the application package, OSGi configurations, dispatcher configuration and approved dependencies through a controlled pipeline, then promote the same image through testing and production. Runtime settings such as secrets, service endpoints and environment-specific values belong in Kubernetes configuration objects or an external secrets manager rather than inside the image.

A self-managed deployment also needs a clear support position. Confirm that the chosen AEM version, Java runtime, container base image and hosting pattern align with Adobe’s supported configurations and internal risk requirements. If the organisation is already adopting AEM as a Cloud Service, Kubernetes may be more appropriate for adjacent services than for recreating the managed AEM platform.

Build Reproducible Images and Releases

A production container should use a lean, patched base image and run with a non-root user where the AEM distribution permits it. Pin image versions and dependency checksums, scan every build for vulnerabilities, and retain an auditable record of the package set. Australian businesses subject to regulated industry controls will usually need evidence of who approved an image and when it entered production.

Separate code deployment from content deployment. Application bundles, editable templates and front-end assets can move through a CI/CD pipeline, while mutable content remains in the repository and follows an approved replication or content-package process. A release strategy that overwrites repository data as part of every pod replacement can cause difficult recovery scenarios.

Use readiness and liveness probes carefully. A process may be alive while AEM is still warming caches, registering OSGi services or opening repository indexes. Readiness should represent the ability to serve the intended role, whereas liveness should detect a genuinely stuck process. Overly aggressive probes can create a restart loop during a normal deployment.

The CIRCUIT speaker archive is useful background for finding AEM practitioners and technical perspectives on architecture, integrations and platform engineering. Those viewpoints can help a delivery team compare container patterns with established AEM deployment practices.

Design Kubernetes Workloads Around State

Kubernetes excels at replacing failed containers, but AEM’s repository makes careless replacement dangerous. Oak storage, binaries, indexes and repository consistency require deliberate handling. A common production approach keeps the repository on reliable persistent storage and treats the AEM pod as replaceable only when the storage, identity and startup process have been designed together.

For author environments, a small number of carefully managed replicas may be preferable to automatic horizontal scaling. Publish environments can scale more readily when they are configured for the selected topology and use a content distribution method that keeps instances aligned. Replication agents, flush agents, shared storage and external asset systems need testing under pod restarts and rolling updates.

Persistent volumes should be backed by storage with suitable latency, throughput, snapshot support and failure behaviour. A Sydney-based deployment serving users in New South Wales may choose an Australian cloud region for latency and residency reasons, while a national retailer may need a second region or recovery site to serve stores and customers during a regional outage. The design should document what happens to content authoring during a storage or region failure.

Avoid assuming that a StatefulSet solves all repository concerns. It can provide stable identity and storage claims, but it does not automatically make AEM clustering, replication or backup safe. The Kubernetes abstraction must be supported by AEM-specific recovery procedures and tested restore points.

Control Traffic, Scaling and Availability

Use an ingress controller or gateway to terminate TLS, apply request policies and route traffic to the correct service. Dispatcher should retain its role in AEM caching and request filtering, with cache invalidation connected to content activation. A cloud load balancer can distribute requests across publish pods, but it cannot correct a faulty dispatcher rule or an inconsistent publish repository.

Horizontal Pod Autoscaling can respond to CPU, memory or custom metrics, yet visitor demand is often better represented by request rate, response time and queue depth. Establish sensible minimum replicas before a campaign, product launch or public-sector release. In Australia, traffic patterns around end-of-financial-year activity, major sporting events and seasonal retail promotions can change sharply within hours.

A rolling deployment should maintain enough healthy publish capacity while new pods warm up. Configure a PodDisruptionBudget, use topology spread constraints across availability zones, and reserve capacity for platform components. Resource requests that are too low invite eviction and throttling; limits that are too high can leave the scheduler unable to place replicas.

Load testing should include cache misses, asset delivery, author activation, search, authentication and slow downstream systems. Test with realistic content volumes rather than a small development repository. Measure the point at which response time degrades, then use that evidence to set scaling thresholds and capacity budgets.

Make Monitoring AEM-Aware

Infrastructure dashboards should cover pod restarts, memory pressure, CPU throttling, persistent volume latency, node health and ingress errors. AEM dashboards need a deeper view: JVM heap and garbage collection, request latency, active sessions, replication queues, Sling jobs, Oak indexes, repository size and dispatcher hit ratio.

Prometheus-compatible metrics can provide a common monitoring layer across Kubernetes and AEM infrastructure. The Prometheus monitoring session offers relevant context for tracking publisher instance health and turning application signals into actionable alerts.

Alert design should focus on user impact and recovery. A brief pod restart may be harmless, while a growing replication queue or a sudden fall in cache-hit rate can indicate a serious publishing problem. Route urgent alerts to the team responsible for AEM, Kubernetes and networking rather than sending every warning to a general operations channel.

Logs should be structured, correlated and retained according to business requirements. Include a request or trace identifier across ingress, dispatcher, publish and downstream services. Keep sensitive data out of logs, restrict access through role-based controls, and verify that time synchronisation works across nodes and external systems.

Secure the Platform and Recovery Path

Use Kubernetes namespaces, network policies and service accounts to reduce unnecessary communication. AEM publish pods should not have broad permissions over the cluster, and administrative endpoints should be restricted through private networking, identity controls and approved jump-host or VPN paths. Secrets should be rotated without rebuilding application images whenever the selected AEM configuration supports that approach.

Protect the software supply chain with signed images, dependency scanning, admission controls and a private registry. Patch the operating system, Java runtime, container engine, Kubernetes components and AEM application according to a tested schedule. For distributed Australian teams, assign clear ownership across the local platform group, offshore support and Adobe or systems integrators.

Backups must cover repository data, binaries, configuration, dispatcher rules and deployment metadata. A snapshot is useful only if it can be restored into a clean environment. Run recovery exercises that measure the actual recovery time objective and recovery point objective, including DNS changes, certificates, integrations and content replication.

A Melbourne-based financial services team may prioritise strict audit trails, while a Brisbane retailer may place greater emphasis on rapid recovery during a campaign. Both need documented runbooks for failed deployments, corrupted indexes, unavailable storage, compromised credentials and a region-wide outage. Resilience is demonstrated through rehearsal, not a diagram.

Govern Daily Operations and Growth

Give each AEM environment a defined ownership model. Product teams should own content and release intent; AEM specialists should own application behaviour; the platform team should own clusters, storage and policies. Regular reviews should examine cost, capacity, security findings, failed deployments and changes in Adobe’s support guidance.

Use progressive delivery where practical. Deploy to a small publish pool, compare error rates and latency, then expand gradually. A blue-green approach can simplify rollback when the application and repository compatibility have been verified. Never make rollback depend on an untested downgrade of repository structures or content formats.

Training matters because Kubernetes terminology can conceal AEM-specific failure modes. Developers need to understand run modes, OSGi configuration, replication and dispatcher caching, while platform engineers need familiarity with Oak, JVM tuning and AEM health indicators. The event’s technical recordings and resources can support that shared vocabulary across Java, front-end and systems teams.

Keep a service catalogue that records image versions, namespaces, dependencies, storage classes, dashboards, alert owners and recovery procedures. Review it after major releases and architecture changes. This documentation becomes especially valuable when a Perth office, Sydney operations centre and external delivery partner must coordinate during an incident.

Use the CIRCUIT app to access event resources and keep useful AEM development material close to the teams planning their next deployment. Pair that reference material with a tested Kubernetes runbook, measurable service objectives and regular recovery exercises. AEM containers can then become a controlled production platform rather than another source of operational uncertainty.