Optimizing Resources with Environment Auto-Pause

The Cloud platform monitors environment activity to detect idle periods. During inactivity, it scales down non-production environments (i.e, UAT and Dev) to reduce resource consumption and costs.

As part of this process, environments transition through three states: Normal, Deactivation Threshold, and Inactive. The Inactive state corresponds to a paused environment, where services are stopped and modifications are blocked until the environment is resumed.

Normal: The environment is active, and all replicas run as configured.

Deactivation Threshold: When the environment reaches the idle threshold, a grace period begins. An alert is sent to admins stating the deactivation time (a few hours by default) if no activity occurs.

Inactive: All cloud stack and custom service replicas are scaled to 0 (except VPN). The environment remains accessible in the Console, but with restricted actions.

How the Platform Determines Idleness

The Cloud platform determines if a Liferay environment is idle by continuously monitoring key workload metrics over a defined time window.

An environment is considered idle when multiple signals such as request rate, session creation rate, connection rate, and CPU usage remain within their defined thresholds. Any workload activity resets the idle timer and keeps the environment in the Normal state.

A Kubernetes controller evaluates these metrics using data from Prometheus or the Kubernetes Metrics API and records the result as an Idle condition in Liferay. This idleness state is stored in the environment’s database record and exposed as a metric, allowing the platform to track changes over time and take further actions when the idle state changes.

Effects of Inactivity

When an environment is in the Inactive state, the following behaviors apply:

Deployment restrictions: Deployment attempts through the Console or CLI (including the lcp CLI) fail with an error. In the Console, inactive environments appear grayed out and cannot be selected during the deployment flow.
End-user experience: Visitors to the site URL see a maintenance-style page.
Service persistence: Critical infrastructure, such as the VPN workload, remains running to preserve management connectivity.

The Deactivation Workflow

When an environment reaches the deactivation threshold, users receive alerts and can revert the process manually to keep the environment active. Otherwise, the environment deactivates and can be resumed later.

Admins receive status updates in several locations:

Email and Console Alerts: Notifications are sent when an environment is approaching deactivation, when it’s deactivated, and when it has been successfully activated.
Status Indicators: The current state (e.g., “Inactive”) appears in the Projects list, the Services overview, and the Environment Settings.
Activity Log: All state changes appear in the Activities tab for auditing.

Canceling Deactivation Manually

Open the project environment that is scheduled for deactivation.
Navigate to Settings.

Tip

You can click Go to Settings in the deactivation warnings to navigate directly to Settings.
Under Status, a message with the deactivation date appears. Click Keep It Active.

Resuming an Environment

Follow these steps to bring an environment back to a Normal state.

Open the inactive project environment.
Navigate to Settings.

Tip

You can click Go to Settings in the deactivation warnings to navigate directly to Settings.
Under Status, switch the toggle to Active

An Activating... message appears during the activation process. You can leave or close the page while the process is ongoing. When the process completes, the toggle switches to Active.
Once activated, admins receive a confirmation alert and email.