CNE Kubernetes Ready: Deploying Liferay DXP on OpenShift Developer Sandbox

The Red Hat Developer Sandbox provides a free OpenShift environment for validating Kubernetes Ready deployments with the liferay-default Helm chart.

Deploy Liferay DXP on the OpenShift Developer Sandbox, configure routing through an OpenShift Route, and verify access through the public sandbox hostname.

The deployment uses a Route-first approach: create the OpenShift Route before installing Liferay so the final hostname exists by the time Liferay initializes the database on first boot.

Prerequisites

Install these tools locally:

Tool	Purpose
`oc`	Interact with the OpenShift cluster
Helm 3.8+	Install the `liferay-default` chart

Note

Helm 3.8 or later is required because the chart is distributed as an OCI artifact.

Create the OpenShift Developer Sandbox

Open the Red Hat Developer Sandbox sign-up page.
Sign in with a Red Hat account.
Click Start your sandbox.
Open the OpenShift web console after provisioning completes.

The free sandbox tier includes these resource limits:

Resource	Limit
Memory	7 GiB per project
CPU	1 dedicated vCPU
Storage	5 GiB persistent volumes
Session duration	30 days, renewable

The example OpenShift overlay values fit within these limits.

Log In to the Cluster from the CLI

In the OpenShift console, click your username and select Copy login command.
Click Display Token.

Copy the generated oc login command and run it locally:

oc login --token=sha256~... \
   --server=https://api.<sandbox>.openshiftapps.com:6443

Confirm the active project:
```
oc project
```

The terminal displays your sandbox project name.

Create the Route Before Installing Liferay

The OpenShift Route assigns a public hostname immediately after creation, even if no backend Service exists.

You must run this step before Liferay starts because the system writes the hostname into the Liferay database during first boot. If you use the incorrect hostname at that moment, the system persists it and later requests through the Route fail with a NoSuchVirtualHostException error.

Save this manifest as route.yaml:

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: liferay-default
spec:
  to:
    kind: Service
    name: liferay-default
  port:
    targetPort: http
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

Apply the Route:
```
oc apply -f route.yaml
```

Store the generated hostname:

ROUTE_HOST="$(oc get route liferay-default \
   -o jsonpath='{.spec.host}')"

echo "$ROUTE_HOST"

The terminal displays a hostname similar to this address:

liferay-default-your-user-dev.apps.rm3.7wse.p1.openshiftapps.com

Note

The Route returns HTTP 503 until the Liferay Service becomes available later in the deployment.

Configure the Liferay Virtual Host

Liferay requires the final OpenShift Route hostname before the first startup completes. Otherwise, the default company initializes with localhost as its virtual host.

The example liferay-network ConfigMap injects the required hostname into the Liferay environment.

Save this manifest as liferay-network-cm.yaml, replacing REPLACE_WITH_ROUTE_HOST with the value stored in $ROUTE_HOST:

apiVersion: v1
kind: ConfigMap
metadata:
  name: liferay-network
data:
  LIFERAY_COMPANY_PERIOD_DEFAULT_PERIOD_VIRTUAL_PERIOD_HOST_PERIOD_NAME: REPLACE_WITH_ROUTE_HOST
  LIFERAY_COMPANY_PERIOD_DEFAULT_PERIOD_VIRTUAL_PERIOD_HOST_PERIOD_SYNC_PERIOD_ON_PERIOD_STARTUP: "true"

Apply the ConfigMap:
```
oc apply -f liferay-network-cm.yaml
```

Verify the ConfigMap:

oc get configmap liferay-network -o yaml

The ConfigMap provides these properties:

Property	Purpose
`company.default.virtual.host.name`	Sets the OpenShift Route hostname
`company.default.virtual.host.sync.on.startup=true`	Reapplies the hostname on startup

Important

Create the ConfigMap before the first Liferay startup. Liferay writes the default company virtual host into the database during initialization. If the hostname is still localhost at that point, requests through the Route fail with a NoSuchVirtualHostException error until you correct the company configuration manually.

Install the Liferay Helm Chart

The chart is published as an OCI artifact:

oci://us-central1-docker.pkg.dev/liferay-artifact-registry/liferay-helm-chart/liferay-default

Save this overlay as values-openshift.yaml:

podSecurityContext: {}
securityContext: {}

volumeClaimTemplates:
  - metadata:
      name: liferay-persistent-volume
    spec:
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 5Gi

resources:
  requests:
    cpu: 500m
    memory: 4Gi
  limits:
    cpu: 1000m
    memory: 6Gi

startupProbe:
  failureThreshold: 180
  initialDelaySeconds: 120

readinessProbe:
  failureThreshold: 6
  initialDelaySeconds: 60

livenessProbe:
  failureThreshold: 6
  initialDelaySeconds: 120

customEnvFrom:
  x-liferay-network:
    - configMapRef:
        name: liferay-network

Install the chart with the OpenShift overlay values:

helm upgrade -i liferay \
   oci://us-central1-docker.pkg.dev/liferay-artifact-registry/liferay-helm-chart/liferay-default \
   -f values-openshift.yaml

OpenShift Overlay Configuration

The values-openshift.yaml overlay adjusts the Helm chart configuration for the OpenShift Developer Sandbox environment.

This table explains the overlay configuration entries:

Configuration	Purpose
Leaves `securityContext` empty	OpenShift `restricted-v2` SCC assigns runtime UIDs dynamically
Reduces request and limit resources	Fits within the sandbox memory and CPU caps (7 GiB / 1 vCPU)
Relaxes health probes	Accommodates slower cold starts on constrained resources
References the `liferay-network` ConfigMap	Injects the Route hostname into the Liferay environment

Watch the Deployment

Watch pod startup progress:
```
oc get pod -w
```

The pod progresses through several initialization phases before becoming ready.

Stream the Liferay logs:
```
oc logs -f liferay-default-0
```

Verify that the startup message appears:

Server startup in [...] milliseconds

Initial startup takes 5 to 15 minutes because the sandbox environment features limited CPU and memory resources.

Verify the Deployment

Open the Route hostname in a browser:
```
https://$ROUTE_HOST/
```
Click Sign In.
Use the default administrator account credentials:

Field Value

Email test@liferay.com

Password Extract from the Kubernetes Secret

Field	Value
Email	`test@liferay.com`
Password	Extract from the Kubernetes Secret

Retrieve the generated password:

oc extract secret/liferay-default \
   --keys=LIFERAY_DEFAULT_PERIOD_ADMIN_PERIOD_PASSWORD \
   --to=-

Complete the initial password reset flow.

After login, the Liferay Control Panel loads successfully.

Pause the Deployment

The sandbox environment remains active even when the pod stops.

Scale the StatefulSet to zero replicas when the environment is idle:

oc scale statefulset liferay-default --replicas=0

Scale it back up later:

oc scale statefulset liferay-default --replicas=1

Cold startup takes several minutes.

Clean Up the Deployment

Remove the Helm release:

helm uninstall liferay

Delete the persistent volume claim separately:

oc delete pvc liferay-persistent-volume-liferay-default-0

Note

Helm preserves persistent volumes by design to prevent accidental data loss. You must remove the PVC manually to fully reset the environment.

Capability:

Cloud

DXP Self-Hosted Installation, Maintenance, and Administration

Resource Type:

Official Documentation

Deployment Approach:

Liferay PaaS

Liferay Self-Hosted

Capabilities

View All Capabilities

Product

Education

Knowledge Base