Container-Based Liferay Deployments Docker & Kubernetes Guide

Introduction

Containerization isn't a trend for Liferay teams anymore. It's no longer a future trend. Docker delivers consistency across environments, while Kubernetes helps applications scale and stay resilient. Together, they change how enterprise portals are shipped, updated, and maintained.

This guide is for teams actively running or planning to run Liferay DXP on containers, from the basics of pulling the official image to wiring up a production-grade Kubernetes cluster with CI/CD.

Why Liferay + Containers Make Sense

Liferay is a stateful, Java-based platform. Portal properties, OSGi modules, document library, database connections, there are a lot of moving parts. That's exactly why containerization pays dividends here.

• Environment parity : Dev, QA, UAT, and Prod all run the same image. "Works on my machine" disappears as an excuse.
• Faster onboarding : New developers can get a Liferay environment up and running with a single Docker command instead of spending hours on setup.
• Easier upgrades : Move to a new image version, test it, and roll back quickly if something doesn't work as expected.
• Run it anywhere : The same container can be deployed on AWS, Azure, Google Cloud, or your own infrastructure without major changes.

Getting Liferay Running in Docker

Liferay publishes official images on Docker Hub under two repositories :

• liferay/dxp - Enterprise (includes a 30-day trial key).
• liferay/portal - Community Edition.

Quickstart :

docker run -it -m 8g -p 8080:8080 liferay/dxp:2026.q1.7-lts

Access at http://localhost:8080. Default login: test@liferay.com / test.

• As part of your production setup, create role-based accounts and stop relying on the default admin user.

Image Variants to Know

The slim variant is built for production Kubernetes setups, it connects to an external Elasticsearch or OpenSearch 2 instance instead of embedding one in the same JVM.

Configuring the Container

Liferay maps Docker environment variables directly to portal.properties. No need to mount config files just to change basic settings.

1docker run -it -m 8g -p 8080:8080 \
2
3-e LIFERAY_JDBC_PERIOD_DEFAULT_PERIOD_URL=jdbc:mysql://db:3306/lportal \
4
5-e LIFERAY_JVM_OPTS="-Xms4g -Xmx4g" \
6
7-v $(pwd)/liferay-data:/opt/liferay \
8
9liferay/dxp:2026.q1.7-lts

Key mount path: /opt/liferay - scripts dropped here execute before Liferay starts. Modules placed in /opt/liferay/deploy are hot-deployed at runtime.

Kubernetes: The Production Standard

Docker helps package and run applications, but it doesn't manage things like scaling, failover, or application updates. That's where Kubernetes comes in.

What Kubernetes Brings to Liferay Deployments

• Automatic scaling : When traffic increases, Kubernetes can start additional Liferay instances and reduce them again when demand returns to normal.
• Automatic recovery : If a Liferay instance stops responding or crashes, Kubernetes detects it and starts a replacement.
• Smooth updates : New versions can be rolled out gradually without taking the portal offline, making updates far less disruptive.
• Resource management : CPU and memory limits help ensure one service doesn't consume more than its fair share of cluster resources.
• Built-in security controls : Access permissions, secrets, and network policies can all be managed centrally within Kubernetes.

Core Architecture for Liferay on Kubernetes

A production Liferay cluster typically involves :

1Namespace: liferay-prod
2
3├ Deployment: liferay-portal (2+ replicas)
4
5├ Deployment: elasticsearch (or OpenSearch)
6
7├ Deployment: mysql / postgres
8
9├ Service: liferay-portal (ClusterIP + Ingress)
10
11├ PersistentVolumeClaim: liferay-data
12
13├ PersistentVolumeClaim: liferay-search-pvc
14
15├ ConfigMap: liferay-portal-config
16
17└ Secret: liferay-db-creds

• Persistent storage is non-negotiable. When a container restarts, everything in its ephemeral filesystem is gone. Database, document library, OSGi configs, all need PersistentVolumeClaims mapped to a durable backend.

Sample Deployment Snippet

1# key values: full manifest includes namespace, selector, volumes
2spec:
3  replicas: 2
4  template:
5    spec:
6      containers:
7      - name: liferay
8        image: liferay/dxp:2026.q1.7-lts-slim
9        resources:
10          requests: { memory: "6Gi", cpu: "2000m" }
11          limits:   { memory: "8Gi", cpu: "4000m" }
12        volumeMounts:
13        - name: liferay-data
14          mountPath: /opt/liferay/data/document_library

Writing all of this from scratch, namespaces, PVCs, ingress, secrets, resource limits, is doable. It's also roughly 400 lines of YAML you'll have to maintain, version, and debug every time something changes. That's the problem Liferay's official tooling is built to solve.

Liferay's Cloud Native Experience (CNE)

The CNE is Liferay's answer to "how do we standardize this?" question. Instead of assembling your own manifests, you get production-tested blueprints with the right defaults encoded already.

It includes :

• Helm charts for Kubernetes orchestration, configure memory, replicas, database connections, and health checks as code
• Terraform scripts for provisioning managed services (RDS, OpenSearch, object storage) on AWS, Azure, and GCP
• Argo CD integration for GitOps-driven deployments, every change traced to a Git commit

For AWS EKS specifically, a single Helm install deploys a full production stack :

1helm install liferay liferay/liferay-dxp \
2
3--namespace liferay-prod \
4
5--values custom-values.yaml

CI/CD in Practice

Containerized deployments make it much easier to automate the release process. A typical workflow starts with a code commit, builds a Docker image, publishes it to a registry, and then deploys the updated version to Kubernetes before running validation checks.

1Code Commit → Build Workspace → Build Docker Image → Push to Registry → Deploy to Kubernetes → Smoke Test

Liferay PaaS includes built-in CI/CD support through Jenkins. A push to GitHub, GitLab, Bitbucket, or Azure DevOps can automatically trigger a build and deployment. Deployment behavior is controlled through configuration variables such as LCP_CI_DEPLOY_BRANCH and LCP_CI_DEPLOY_TARGET.

Teams running their own infrastructure often use GitHub Actions or Jenkins to build Docker images and deploy them directly to Kubernetes clusters.

1# .github/workflows/liferay-deploy.yml
2- name: Build and push Docker image
3  uses: docker/build-push-action@v4
4  with:
5    context: .
6    push: true
7    tags: your-registry/liferay-dxp:${{ github.sha }}
8
9- name: Deploy to Kubernetes
10  run: |
11    kubectl set image deployment/liferay-portal \
12      liferay=your-registry/liferay-dxp:${{ github.sha }} \
13      -n liferay-prod

• Tag images with the Git commit SHA, not latest. It makes rollbacks deterministic and audits painless.

Watch-Out Zone

Choose Your Deployment Path

Use Docker + Docker Compose if :

• You're setting up a local dev environment or a quick staging instance.
• The team is not yet Kubernetes-fluent.
• You need something running in under an hour.

Use Kubernetes (self-managed) if :

• You need auto-scaling and high availability.
• Your team manages its own infra and has Helm/kubectl experience.
• You're on-prem or in a private cloud.

Use Liferay CNE (Helm + Terraform) if :

• You're on AWS, Azure, or GCP
• You want Liferay-tested blueprints with GitOps baked in.
• You want managed services (RDS, OpenSearch) wired without manual config.

Use Liferay PaaS if :

• Infrastructure is not your concern.
• You want built-in CI/CD, backups, and monitoring managed for you.

Where Do You Go From Here?

Container-based Liferay deployments aren't a future goal, the tooling is mature, Helm charts are official, and marketplace listings are live. The question is whether your team's process reflects that.

Start with Docker for local parity. Move to Kubernetes with the CNE Helm charts when your deployment needs greater reliability, scalability, and operational control. Wire in a CI/CD pipeline so every commit to your portal codebase becomes a testable, deployable artifact.

The infrastructure should run itself. Your team's energy belongs on the portal.