Liferay DXP Cloud: Complete Guide to SaaS, PaaS & Self-Hosted Deployments
Introduction
When a business decides to adopt Liferay DXP, one of the first and most critical decisions is: how do you deploy it?
Liferay offers three deployment models: SaaS, PaaS, and Self-Hosted, and each comes with a different level of control, responsibility, and cost. Picking the wrong one can slow your team down, inflate your budget, or lock you into constraints you didn't see coming.
This guide breaks down all three options clearly, so you can make the right call for your organisation.
Why Your Deployment Model Matters More Than You Think
It's not just an infrastructure decision. Your deployment model directly affects :
- How fast you can go live.
- How much your team can customise the platform.
- Who is responsible when something breaks.
- What your upgrade path looks like.
- Your total cost of ownership over 3–5 years.
Getting this right from the start saves significant rework later.
The Three Liferay Deployment Options at a Glance
| SaaS | PaaS | Self-Hosted | |
|---|---|---|---|
| Infrastructure managed by | Liferay | Liferay | You |
| DXP upgrades managed by | Liferay | You | You |
| Customisation depth | Client Extensions only | Full (OSGi + Client Extensions) | Full |
| Time to go live | Fastest | Moderate | Slowest |
| DevOps overhead | None | Low–Medium | High |
| Best for | Speed + simplicity | Control + cloud comfort | Max control / compliance |
1) Liferay SaaS : Fully Managed DXP
Liferay SaaS is a fully managed, cloud-hosted version of Liferay DXP. Liferay handles everything, infrastructure, updates, security patches, and backups. You focus on building experiences.
What's included :
- Production (PRD) + Test (UAT) environments
- Liferay handles all upgrades, security updates, and maintenance within the SaaS service.
- Managed database, Elasticsearch, file storage, and web server
- Client Extension environments for custom development
- Liferay Cloud Console for monitoring
Customisation boundary : Liferay SaaS abstracts the underlying infrastructure, so custom OSGi module deployment is supported but generally not recommended by Liferay.
All customisation happens through Client Extensions, decoupled services and frontend extensions that don't modify the core, aligning with Liferay's cloud-friendly development approach.
| Works Well For | Watch Out For |
|---|---|
| Fast go-live with minimal setup | OSGi / .jar module deployment supported if required |
| Teams without dedicated DevOps | Limited control over upgrade timing |
| Predictable, all-in subscription cost | Strict compliance needs may not be met |
| Always on the latest Liferay version | Complex integrations require more API work |
2) Liferay PaaS : Cloud Infrastructure, Your Application
Liferay PaaS is the middle ground, Liferay manages the cloud infrastructure, but your team manages DXP upgrades, hotfixes, and customisations.
What's included :
- Managed cloud infra (web server, database, search, backups)
- Auto-scaling, auto-failover, and load balancing
- Built-in Jenkins-based CI/CD pipeline
- Pre-configured Liferay Workspace via GitHub repository
- DEV, TEST, UAT, PRD, and DR environments via Cloud Console
Customisation boundary : Full Liferay customisation, OSGi modules, custom applications, fragments, APIs, and Client Extensions. Just keep in mind that DXP upgrades and hotfixes remain your team's responsibility.
| Works Well For | Watch Out For |
|---|---|
| Migrating from older Liferay with existing modules | DXP upgrades still fall on your team |
| Full platform flexibility without managing servers | Requires Liferay dev + DevOps knowledge |
| Teams comfortable with Liferay module development | Higher cost compared to SaaS |
3) Liferay Self-Hosted, Maximum Control
With Self-Hosted, Liferay provides only the DXP software. Everything else, servers, databases, search, security, backups, and upgrades, is entirely your responsibility.
You can run Self-Hosted on-premises, on a private cloud (AWS, Azure, GCP), or via Kubernetes using Liferay's Cloud Native Experience (CNE) toolkit.
CNE comes in two variants :
- Kubernetes Ready : Works on any CNCF-certified Kubernetes cluster. Your team connects external services manually.
- Cloud Provider Ready (e.g., AWS Ready) : Includes Terraform scripts to automate your full cloud foundation. Less effort, faster setup.
| Works Well For | Watch Out For |
|---|---|
| Regulated industries with data residency requirements | Highest operational and maintenance overhead |
| Organisations with existing enterprise infrastructure | Requires strong in-house DevOps and server admin |
| Government, banking, healthcare with compliance mandates | Longest time before going live |
| Full infrastructure and operational control | All upgrades, patches, and security are on you |
Detailed Comparison : Responsibility Split
Who manages what across each model :
| Responsibility | SaaS | PaaS | Self-Hosted |
|---|---|---|---|
| Physical infrastructure | Liferay | Liferay | You |
| Web server (Tomcat) | Liferay | Liferay | You |
| Database | Liferay | Liferay | You |
| Search (Elasticsearch) | Liferay | Liferay | You |
| Backups | Liferay | Liferay | You |
| DXP upgrades | Liferay | You | You |
| Infrastructure patching | Liferay | Liferay | You |
| DXP patching | Liferay | You | You |
| Custom code deployment | Client Extensions only | Modules + Client Extensions | Full |
| CI/CD pipeline | Provided (limited) | Jenkins (provided) | You build it |
What Does It Actually Cost?
Liferay doesn't publish fixed pricing, quotes are customised based on your environments, scale, and support tier. Here's a realistic way to think about it:
SaaS → Subscription only. No infra cost. Lowest entry point.
PaaS → Subscription + cloud infra usage + DXP engineering effort.
Self-Hosted → DXP license + your own infra + ongoing internal IT cost.
The hidden cost most teams miss :
In Self-Hosted and PaaS, the real expense isn't the license, it's the engineering hours spent on upgrades, patch cycles, and infrastructure maintenance year after year. SaaS significantly reduces that overhead.
- Capabilities may vary based on subscription and cloud agreement.
Migrating to a New Deployment Model
If you're on an older Liferay version (7.2, 7.3, 7.4) and evaluating migration :
Moving to SaaS
- Audit all existing customisations, OSGi modules will not carry over.
- Rebuild eligible customisations as Client Extensions.
- This is a re-architecture, not a lift-and-shift.
Moving to PaaS
- Most existing modules and customisations can migrate with manageable effort.
- If upgrading to Jakarta-based releases (2025.Q3+), plan for javax.* → jakarta.* migration.
- Configure the provided Jenkins CI/CD to match your release workflow.
Moving to Self-Hosted via CNE
- Choose Kubernetes Ready or Cloud Provider Ready based on your cloud strategy.
- Use Liferay's Helm charts and Terraform scripts to set up your foundation.
- Plan infrastructure provisioning well in advance of go-live.
Which Deployment Should You Choose?
Go with SaaS if you're starting fresh, want to move fast, and can work within Client Extensions for customisation.
Go with PaaS if you have an existing Liferay implementation with custom modules that need to carry forward, and you want cloud infrastructure managed for you.
Go with Self-Hosted if data sovereignty, compliance regulations, or full stack control is a hard requirement for your organisation.
The Bottom Line
There's no universally "best" Liferay deployment. What we consistently see at IGNEK across implementations :
- Teams that pick SaaS and try to over-customise hit a wall fast
- Teams that pick Self-Hosted without DevOps capacity get buried in maintenance
- PaaS is often the preferred choice for enterprises with existing Liferay customisations.
The deployment model you choose today shapes your platform for the next 3–5 years. Choose based on where you are, not where you hope to be.
