Liferay PaaS Experience: Auto-Scaling
Configure auto-scaling by editing Helm values in your GitOps repository. This is typically a developer or platform administrator’s task rather than a general PaaS User’s.
Liferay PaaS Experience supports two mutually exclusive auto-scaling options for the Liferay StatefulSet:
- A basic Horizontal Pod Autoscaler (HPA), which scales on pod-level metrics such as CPU or memory.
- KEDA (Kubernetes Event-Driven Autoscaling), which scales on custom metric queries against Prometheus.
KEDA is the recommended option for most production deployments. Pod-level metrics aren’t always the best signal for Liferay workloads, and KEDA’s default triggers reflect Liferay’s architecture more accurately.
Auto-scaling settings live under the autoscaling value in your environment’s liferay.yaml. Nest them under liferay-default, the Helm subchart that configures the Liferay runtime. Values placed outside that key are ignored without an error:
liferay-default:
autoscaling:
enabled: false
hpa:
...
keda:
...
type: keda
Auto-scaling is disabled by default. Set enabled: true to turn it on. Once enabled, type defaults to keda on Liferay PaaS Experience, so KEDA runs with its default triggers unless you change it. Set type to hpa to use the basic Horizontal Pod Autoscaler instead.
Basic Horizontal Pod Autoscaler
A basic HPA scales the Liferay StatefulSet based on pod-level metrics such as CPU or memory. When enabled, the default HPA scales the Liferay StatefulSet when CPU utilization reaches 80%.
Consider HPA instead of KEDA when:
- You operate small or non-production environments where simple CPU- or memory-based scaling is sufficient.
- You prefer to keep the auto-scaling stack minimal and avoid the additional KEDA dependencies.
KEDA (Kubernetes Event-Driven Autoscaling)
KEDA scales workloads based on custom triggers defined as metric queries against Prometheus. Liferay supplies the Prometheus endpoint and authentication configuration for PaaS Experience environments, so you don’t configure them yourself.
Configure KEDA under the autoscaling.keda section of liferay.yaml:
| Value | Type | Required? | Default | Description |
|---|---|---|---|---|
triggers | Map | No | (see Default Triggers) | Default triggers supplied by Liferay, keyed by trigger name |
maxReplicaCount | Integer | Yes | 100 | Maximum number of replicas when scaling up |
minReplicaCount | Integer | Yes | 1 | Minimum number of replicas when scaling down |
pollingInterval | Integer | Yes | 30 | Interval (in seconds) at which each trigger is evaluated |
prometheusServerAddress | String | No | "" | Endpoint of the Prometheus backend. Liferay supplies this for PaaS Experience environments. |
triggerAuthentication | Object | No | {} | Authentication configuration for the triggers. Liferay supplies this for PaaS Experience environments. |
customTriggers | Map | No | {} | Additional triggers in the same format as the default triggers |
Default Triggers
Liferay supplies a set of default triggers designed around Liferay’s architecture, to give a more accurate indication of when the platform is under- or overloaded.
Each default trigger is a mapped key-value entry under autoscaling.keda.triggers:
| Trigger Key | Description | PromQL Query | Threshold |
|---|---|---|---|
cpu-usage-percent | CPU utilization, using KEDA’s native cpu resource scaler rather than a PromQL query | — | 80 |
hikari-active-connections | Active connections in the HikariCP JDBC connection pool | max(hikaricp_ActiveConnections{namespace="<environment-namespace>"}) | 50 |
jvm-memory-heap-used-percent | JVM heap memory used, as a percentage | max(jvm_memory_used_bytes{area="heap",namespace="<environment-namespace>"} / jvm_memory_max_bytes{area="heap",namespace="<environment-namespace>"} * 100) | 80 |
jvm-threads-current | Current JVM thread count | max(jvm_threads_current{namespace="<environment-namespace>"}) | 500 |
The chart fills in <environment-namespace> for you. Treat these thresholds as starting points rather than values tuned to your deployment: if you have changed your JVM thread pool or Hikari pool sizes, recalibrate them against your own configuration.
Custom Triggers
Use autoscaling.keda.customTriggers to add triggers or to override and disable default triggers.
To add a trigger, add an entry under autoscaling.keda.customTriggers:
liferay-default:
autoscaling:
keda:
customTriggers:
my-new-trigger:
metadata:
metricName: <unique_trigger_name>
query: <promQL_query>
threshold: <query_threshold>
To override a default trigger, reference its key and supply modifications. The example below raises the threshold for the default hikari-active-connections trigger from 50 to 60:
liferay-default:
autoscaling:
keda:
customTriggers:
hikari-active-connections:
metadata:
threshold: "60"
To disable a default trigger, reference its key and set enabled: false:
liferay-default:
autoscaling:
keda:
customTriggers:
jvm-threads-current:
enabled: false