What Liferay's Cloud Native Experience Actually Is

This is LR Tools’ rewrite of a post by David H Nebinger on Liferay.dev explaining Cloud Native Experience (CNE), Liferay’s answer to a tradeoff a lot of organizations running DXP have had to live with.

The tradeoff CNE is answering

Organizations hosting an enterprise platform like DXP have historically had to pick a side of a real tradeoff: full self-hosting gives complete control over infrastructure, networking, and security, but comes with heavy operational overhead — manual provisioning, hand-maintained deployment pipelines, ad hoc scaling. Fully managed cloud platforms cut that overhead, but can conflict with compliance, data-residency, or sovereignty requirements that some organizations simply can’t negotiate away. CNE is positioned as a middle path between those two extremes.

What CNE actually is

CNE isn’t “put Liferay in a container” — that part was already possible. It’s a collection of automation tooling, deployment blueprints, and operational patterns for running DXP using current cloud-native practice: GitOps workflows, infrastructure-as-code, automated scaling, and integration with managed cloud services for the pieces you’d rather not operate yourself (databases, object storage, search). Concretely, that means infrastructure defined declaratively with Terraform, application deployment packaged through Helm charts, operational changes flowing through GitOps and reconciled by Argo CD, and workloads running on Kubernetes.

The point of standardizing on this stack is that self-hosted environments left to grow organically tend to drift — infrastructure gets provisioned by hand, practices diverge between teams, and every upgrade gets riskier as environments diverge from each other. CNE’s answer is to make deployments repeatable, observable, and consistent by construction, using tooling most platform teams already have some familiarity with.

Two ways to run it

Kubernetes Ready targets organizations that want portability across any CNCF-certified Kubernetes cluster — on-prem, private cloud, or multi-cloud. It ships the core orchestration tooling and deployment blueprints, but leaves infrastructure provisioning and external service integration in your hands. This is the fit for teams under strict regulatory constraints, sovereign-cloud mandates, or existing Kubernetes expertise who’d rather bring their own cluster than adopt someone else’s.

Cloud Provider Ready goes further and automates the entire deployment foundation for a specific provider. The first example is an AWS-targeted toolkit that provisions the Kubernetes layer via Amazon EKS and wires up managed services including Amazon RDS, S3, and OpenSearch automatically. This cuts out a large amount of manual infrastructure assembly, while the infrastructure and cloud account itself still belong to you.

GitOps as the operational model

Where a traditional environment accumulates manual changes and configuration drift over time, CNE treats a Git repository as the single source of truth for both infrastructure and application configuration. Changes are committed to Git and automatically reconciled into the cluster by Argo CD — giving you version-controlled, auditable, and easily reversible deployments instead of tribal knowledge about what changed and why.

Where it fits

CNE is explicitly designed to work across regulated industries, private-cloud infrastructure, multi-cloud portability requirements, and restricted environments like AWS GovCloud. The same operational model applies whether you’re running it in your own AWS account, on a private-cloud Kubernetes cluster, on-premises, or in another regulated cloud environment.

Getting started on AWS

The setup flow is intentionally lightweight: install the required CLI tooling, configure AWS access and credentials, then create a GitOps repository containing bootstrap configuration. A single bootstrap script kicks off the rest:

bash <(curl -sL https://raw.githubusercontent.com/liferay/liferay-portal/master/cloud/scripts/bootstrap.sh)

Behind that one command sits a substantial amount of orchestration: EKS cluster creation, RDS provisioning, OpenSearch setup, Argo CD installation, networking configuration, and the other supporting platform services CNE depends on.

Where this leaves things

CNE is best understood as an evolved middle ground between pure self-hosting and a fully managed platform — automation, GitOps-driven operations, and cloud-native resiliency patterns, combined with keeping infrastructure ownership on your side of the line. Whether that means a heavily automated AWS deployment, a portable bring-your-own-Kubernetes setup, or something built around sovereign-cloud requirements, the operational model stays the same across all of them.

This article is LR Tools’ rewrite of the original post by David H Nebinger — read it on Liferay.dev for the author’s own framing, or see Liferay’s Cloud Native Experience documentation for full setup details.