PaaS Support Coverage
PaaS (Cloud Native) Quotas and Limitations
This article covers the quotas and limitation policies for Liferay PaaS (Cloud Native):
- Overview
- Infrastructure Definition
- Environment Quotas
- Production and Non-Production Pod Limitations
- Consumption Quotas
- Application Plane Limitations
- Managed Services
- Platform Services (Included)
- Compatibility Matrix
- License Activation
- Responsibility Boundary
1) Overview
Liferay PaaS is the managed cloud deployment option where Liferay manages infrastructure, security, and scalability on the customer's behalf. It builds on Cloud Native Experience and Cloud Provider Ready (GCP Ready), adding Liferay-managed infrastructure, managed services, and consumption-based resources. Customers deploy and manage their Liferay DXP application through a GitOps workflow. Liferay PaaS is currently available on Google Cloud Platform (GCP) only.
Each customer receives a dedicated GCP project and a dedicated regional Kubernetes cluster, ensuring full isolation of compute, networking, storage, and managed services. Customers do not have direct access to the GCP Console or underlying cloud infrastructure.
About Quotas and Limitations
This document describes two types of constraints:
Key Terms
For Cloud Native base terminology (Pod, Production Pod, Non-Production Pod, Cluster, Namespace, Environment, Activation Key), see the Cloud Native Quotas and Limitations. The following additional terms are specific to Liferay PaaS:
Term |
Definition |
Standard Machine Type |
A general-purpose infrastructure tier with baseline resource Quotas as further specified below. |
High-Performance (HP) Machine Type |
A performance-tuned infrastructure tier with premium resource Quotas, including a different compute node family, enhanced database offering, and larger default sizings. |
Consumption Metric |
A usage-based measurement of a Quota tracked against applicable allocations and reconciled quarterly. |
Client Extension |
A custom application or microservice deployed alongside Liferay DXP within the PaaS infrastructure, consuming dedicated RAM and vCPU allocations. |
Scope
This document describes quotas and limitations for Liferay PaaS subscriptions. It does not cover Liferay Cloud Native (customer-managed) or Liferay SaaS, which are separate deployment options with their own quotas. For Liferay Cloud Native quotas, see the Cloud Native Quotas and Limitations.
Regional Pricing: All infrastructure, environment, pod, and consumption quota pricing may vary by GCP region. Contact your Liferay Account Executive for region-specific pricing details.
2) Infrastructure Definition
Each PaaS subscription is provisioned with dedicated infrastructure resources within the customer's GCP project. The resource specifications differ between Standard and High-Performance machine types.
Resources are scoped at two levels:
Disaster Recovery (DR) is provisioned in a separate dedicated GCP project and cluster; any Per Account quotas apply independently to the DR project.
2.1 Compute (Per Environment)
Component |
Standard |
High-Performance |
Machine type |
n2-custom-28-32768: 2 instances |
c3d-standard-30: 2 instances |
Specs |
28 vCPUs / 32 GiB RAM |
30 vCPUs / 120 GiB RAM |
Confidential GKE Nodes |
— |
Enabled |
2.2 Database (Per Environment)
Component |
Scope |
Standard |
High-Performance |
Instance type |
Per Environment |
Db-standard-4 (PostgreSQL) |
Db-perf-optimized-n8 (PostgreSQL) |
Storage |
Per Environment |
100 GiB SSD |
200 GiB SSD |
Configuration |
Per Environment |
Single instance |
High Availability & Data Cache |
2.3 Search Persistent Disk (Per Environment)
Persistent disk is provisioned for the managed search service. Sizing depends on the search topology configured for the environment.
Component |
Scope |
Standard |
High-Performance |
Elasticsearch |
Per Environment |
200 GiB Zonal SSD |
200 GiB Zonal SSD |
2.4 Object Storage (Per Environment)
Component |
Scope |
Standard |
High-Performance |
Cloud Storage |
Per Environment |
1 TiB |
1 TiB |
Transfer within GCP |
Per Environment |
250 GiB (guideline; not billed as a consumption metric) |
250 GiB (guideline; not billed as a consumption metric) |
2.5 Networking
Component |
Scope |
Standard |
High-Performance |
Load balancing |
Per Environment |
Global, 4 forwarding rules |
Global, 4 forwarding rules |
NAT Gateway |
Per Account |
3 instances (100 GiB processed) |
3 instances (100 GiB processed) |
Traffic |
Per Environment |
200 GiB inbound / 200 GiB outbound |
200 GiB inbound / 200 GiB outbound |
2.6 Content Delivery / CDN (Per Environment)
Component |
Scope |
Standard |
High-Performance |
Data transfer |
Per Environment |
100 GiB (North America) |
1 TiB (North America) |
Cache fill |
Per Environment |
100 GiB |
1 TiB |
Cache lookup requests |
Per Environment |
30 million |
30 million |
2.7 Operations
Component |
Scope |
Standard |
High-Performance |
Logs (ingested) |
Per Environment |
200 GiB |
1 TiB |
Cloud Build |
Per Account |
E2-medium (machine type) |
E2-medium (machine type) |
Cloud Build is provided for customers to build their Liferay application. Customers may also bring their own CI/CD pipeline and build process.
3) Environment Quotas
3.1 Environment Types
Liferay PaaS provisions Liferay-managed deployment environments on Liferay Cloud Infrastructure based on the deployment environments purchased by Customer. Production, UAT, and Non-Production environments are dedicated Kubernetes Namespaces with their own infrastructure resources within the customer's primary GCP project. Disaster Recovery (DR) is provisioned in a separate dedicated GCP project and cluster, independent from the primary; Per Account quotas apply independently to the DR project.
Environment Type |
Description |
Intended Use |
Production |
Production-grade infrastructure with full managed services, HA configuration, and automated backups. |
Live production traffic. |
UAT |
Pre-production environment for acceptance testing and staging. |
Staging, user acceptance testing. |
Non-Production |
Development and testing environment with reduced infrastructure footprint. |
Development, QA, CI/CD validation. |
Disaster Recovery |
Separate dedicated GCP project and cluster, independent from the primary. Per Account quotas apply independently. |
Business continuity, failover. |
3.2 What's Included Per Environment
Each PaaS environment includes the following Liferay-managed services. For detailed infrastructure sizing by machine type (Standard vs High-Performance), see Section 2) Infrastructure Definition.
Resource |
Description |
Managed Database |
PostgreSQL database instance provisioned and operated by Liferay. |
Managed Search |
Managed Elasticsearch service operated by Liferay. |
Object Storage |
Cloud-backed document library storage for backups and documents. |
Observability |
Grafana dashboards with metrics and log streaming for monitoring and troubleshooting. |
Backup |
Automated database snapshots and document library backups with configurable retention. |
TLS |
Automated TLS certificate provisioning and renewal. |
Ingress |
HTTPS routing, SSL termination, and load balancing. IPv4 and IPv6 (dual-stack) supported at the load balancer. |
4) Production and Non-Production Pod Limitations
Resource Encapsulation Hierarchy
Liferay PaaS organizes resources in an encapsulation hierarchy:
Infrastructure > Environments > Pods
For example, if a customer needs to run more Pods or larger workloads that exceed the infrastructure's included compute capacity, they can purchase additional CPU and Memory to expand the infrastructure ceiling. Additional capacity is available as described in Section 5) Consumption Quotas.
Liferay PaaS inherits all Cloud Native pod-level limitations identically. Pods run within environments and are subject to the infrastructure resource ceiling defined in Section 2. In summary:
For the complete pod limitation model, concurrency examples, counting rules, and enforcement details, see the Cloud Native Quotas and Limitations.
5) Consumption Quotas
Each PaaS environment includes a Quota of various Consumption Metrics. Usage beyond default Quota amounts can be ordered and purchased on a pre-committed basis, or billed as overage consumption.
5.1 Included Consumption Allocations
Metric |
Definition |
Included (Standard) |
Included (HP) |
Additional Capacity Unit |
Client Extensions RAM |
Additional RAM (in GiB) allocated to run Client Extensions within the Liferay Cloud Infrastructure. |
2 GiB |
4 GiB |
Per GiB |
Client Extensions vCPU |
Additional vCPUs allocated to run Client Extensions within the Liferay Cloud Infrastructure. A vCPU is a virtual processor to which a physical CPU is assigned, in whole or in part. For the avoidance of doubt, in the event of simultaneous multithreading in the same physical CPU, each thread will be considered a vCPU. |
3 vCPU |
6 vCPU |
Per vCPU |
Storage |
Data (in GiB) stored in the Backup service and Document Library service provided through Liferay Cloud Infrastructure. |
1 TiB |
1 TiB |
100 GiB |
Database Storage |
Data (in GiB) used by the SQL database instance provisioned as part of Liferay Cloud Infrastructure, including database data (including metadata) and any replicas deployed for high-availability configurations. |
100 GiB |
100 GiB |
100 GiB |
Traffic / Networking |
Data transferred in and out of the customer application's environment, by load balancer response to end users, external integrations, and services in different zones of the same region. |
1 TiB/month |
2 TiB/month |
100 GiB |
Logs |
Volume of log data (in GiB) pertaining to the Customer Application ingested by Liferay's Cloud Infrastructure. This can include logs from default services, custom services, or Liferay's Cloud Platform itself. |
300 GiB |
1 TiB |
30 GiB |
6) Application Plane Limitations
Liferay PaaS separates the Customer's solution into two layers: the infrastructure plane (managed by Liferay) and the application plane (accessible to Customer). Customers deploy and manage Liferay DXP applications into Kubernetes through GitOps, with the following limitations on what can be configured at the application level.
6.1 Kubernetes Application Limitations
The following Kubernetes-native capabilities are not available to customers. These are locked out to prevent misconfiguration that could impact cost, availability, or supportability.
6.2 Platform-Exposed Capabilities
Certain platform capabilities are exposed to customers through managed custom resource definitions (CRDs). These provide controlled access to specific features without requiring direct Kubernetes access:
6.3 Management Plane Limitations
Liferay PaaS provides customers with access to Argo CD, Grafana, and Git. Customers do not have access to the underlying cloud infrastructure, Kubernetes CLI (kubectl), or GCP Console.
Argo CD
Aspect |
Detail |
Access level |
Read-only + Sync. Changes are made through Git, not through the Argo CD UI. |
Customization |
Not supported. Argo CD configuration, settings, plugins, and application definitions are managed by Liferay. |
Grafana
Aspect |
Detail |
Access level |
Read-only. Customers cannot create or modify dashboards, data sources, or alerting configurations. |
Logs visibility |
Container logs from Liferay pods are available. Kubernetes platform-level logs are not exposed. |
Metrics visibility |
Liferay-defined metrics are exposed. Customer-customized metrics are not supported. |
Authentication
Argo CD and Grafana authenticate through Liferay's identity provider (Okta) with MFA enforcement.
6.4 Platform Access Limitations
Capability |
Status |
Shell access (kubectl exec) |
Not supported |
Kubernetes CLI (kubectl) |
Not supported |
GCP Console access |
Not supported |
CDN |
Included (managed; not customer-configurable) |
Site-to-Site VPN / mTLS |
Not available |
Private Service Connect / Interconnect |
Not available |
7) Managed Services
Each applicable PaaS environment includes fully managed infrastructure services provisioned and operated by Liferay. The following sections describe what is included and the scope of each service.
7.1 Database
Aspect |
Detail |
Included |
Fully managed database instance within the dedicated GCP project. |
Supported engines |
PostgreSQL. |
High Availability |
Regional instances with automatic failover. |
Backups |
Automated snapshots managed by Liferay. |
Included storage |
100 GiB per environment (Standard and HP). Additional capacity available as a consumption add-on. |
7.2 Search
Aspect |
Detail |
Included |
Managed Elasticsearch service provisioned and operated by Liferay. |
Scope |
Search is a fully managed service. Customer customization of plugins, security settings, or cluster topology is not supported. |
Liferay Enterprise Search |
Available as an add-on subscription. |
7.3 Storage (Document Library)
Aspect |
Detail |
Included |
Cloud-backed object storage for document library and backup artifacts. |
Included allocation |
1 TiB per environment (Standard and HP). Additional capacity available as a consumption add-on. |
Hot deploy |
OSGi modules, Client Extensions, and themes can be uploaded directly to the extensions bucket; Liferay auto-detects and deploys without pod restart. |
7.4 Backup
Aspect |
Detail |
Database backups |
Automated database snapshots managed by Liferay. |
Document library backups |
Automated copies of document library to cloud storage. |
Retention |
30-day default retention. |
Restore |
Point-in-time recovery available. Restore status visible in Grafana. |
7.5 Observability
Aspect |
Detail |
Metrics |
Pre-built Grafana dashboards for Liferay DXP, pod resources, JVM, request performance, and database health. |
Logs |
Container logs from Liferay software Pods available in Grafana. Kubernetes platform-level logs are not exposed. |
Retention |
Up to 13 months for metrics. Log retention configurable separately. |
Included log allocation |
300 GiB (Standard), 1 TiB (HP). Additional capacity available as a consumption add-on. |
8) Platform Services (Included)
Liferay PaaS includes the following platform services as part of the managed offering.
Capability |
Notes |
Build pipeline |
Liferay provides a managed build pipeline. Customers may also use their own CI/CD pipeline to produce builds. |
Build storage |
Builds can be stored on GAR (container images) or GCS (workspace builds). |
Migration tooling |
Tooling for uploading database and document library content to the PaaS environment. |
Backup and restore tooling |
Blue/green restore operation tooling for managed backup and recovery workflows. |
Helm charts |
Liferay application Helm charts are available via OCI registry. The platform will pull the image and apply to their application environments. |
Customers are responsible for providing and operating their own Git repository for environment configuration and promotion workflows.
9) Compatibility Matrix
Liferay PaaS inherits the Cloud Native compatibility matrix with the following PaaS-specific adjustments for the initial GCP Ready release:
For the full compatibility matrix (DXP version, application server, image strategy, JDK, golden path scope, and support boundaries), see the Cloud Native Quotas and Limitations.
10) License Activation
Liferay provisions the license for each customer upon environment provisioning. The license.xml is deployed automatically as part of the initial setup.
For details on Virtual Cluster Key types and licensing model, see the Cloud Native Quotas and Limitations.
11) Responsibility Boundary
Liferay PaaS separates responsibilities between the customer and Liferay.
11.1 Customer Responsibilities
11.2 Liferay Responsibilities
- Overview
A "Quota" is an allocation of a resource, a default amount of which is included in a single subscription. Most quotas are adjustable - customers may purchase additional capacity as consumption add-ons. To request a quota increase, contact Liferay Sales.
A "Limitation" is a defined platform configuration that reflect architectural decisions designed to ensure platform stability, security, and supportability. Limitations are fixed and not adjustable.
Per Environment: Provisioned independently for each environment (Production, UAT, Non-Production). Quotas apply per environment.
Per Account: Shared across all environments within the customer's GCP project. Quotas apply to the account as a whole.
Infrastructure (defined in Section 2) represents the total computational resource ceiling for the customer's dedicated GCP project.
Environments (Production, UAT, Non-Production) are provisioned within the primary project, each as a dedicated Kubernetes Namespace with its own allocated resources. DR is provisioned in a separate project/cluster and has its own infrastructure ceiling.
Pods run within environments and are constrained by the environment's share of the infrastructure's computational resources (CPU, memory, storage, networking).
Production Pods: Each Namespace supports up to 1, 3, 5, 7, or 9 concurrently running Production Pods, determined by the number of Production Pods purchased.
Non-Production Pods: The Non-Production Environment, if applicable, supports an unlimited number of Pods per namespace, restricted to 5 concurrent authenticated users accessing the DXP instance.
PodDisruptionBudget
TopologySpreadConstraints
PodAffinity / AntiAffinity
Taints / Tolerations
HPA (Horizontal Pod Autoscaler)
VPA (Vertical Pod Autoscaler)
Custom metrics
Custom Helm charts
Application registration through Git configuration
Custom domain management through Gateway and HTTPRoute resources
Environment creation and deletion through Git-based environment configuration
Database engine: PostgreSQL.
Customization Boundary: Modifications outside of supported configuration values will make your Liferay PaaS deployment out of support.
Deploy and promote releases through Git
Monitor application health through Argo CD, Grafana
Manage environment configuration through Git
Develop and deploy Client Extensions within allocated quotas
Monitor consumption metrics against included allocations via the Customer Portal
Provision and manage the dedicated GCP project and regional Kubernetes cluster
Provision license upon environment setup
Operate and maintain managed database, search, storage, backup, and observability
Provide and maintain build pipeline and build storage
Provide and update Cloud Native tooling and GCP Ready packages
Manage infrastructure-level security, OS patching, and Kubernetes version upgrades
Support the platform and managed services at the applicable support tier