Pega Infinity '25 — Why Kubernetes Replaced the VM

If you've been working with Pega for a few years, you've probably deployed it on a virtual machine — or at least worked on a system that ran that way. In Pega Infinity '25, that world is officially over. Pega has made Kubernetes the only supported deployment model. No VMs. No exceptions.

In this article, we're going to break down exactly why that happened, what the new architecture looks like, and what it means for you as a Pega developer.

Why Should You Care About This?

Before going further, let's answer the most important question — so what?

Here's the reality. If your client is on Pega '23 or '24 and planning to upgrade, they're moving to a Kubernetes environment. If you're sitting in an LSA interview and the architect asks you to walk through the deployment architecture — this is what they're expecting you to know. And if you're working on any client-managed Pega deployment going forward, understanding Kubernetes is no longer optional. It's the job.

The Old Way — Think of a VM Like a Rented Apartment

Before we touch any technical terms, let's use an analogy. Think of a VM — a virtual machine — like a rented apartment in a big building. You get your own space. You install what you need. It works.

But there are problems:

Can't easily grow — If you need more space, you can't just expand. You have to move or wait for someone to build an extension.
Shared risk — If the building's plumbing breaks, everyone suffers. Resource contention affects every tenant.
Expensive to replicate — Want a disaster recovery environment in another city? You have to manually set up the whole building again from scratch.
Manual migration — Moving between environments is a costly, time-consuming process.

That's VM-based deployment. Functional. But rigid, expensive, and slow to scale.

What Actually Broke With VM-Based Pega Deployments

Let's make this concrete — specifically for Pega. In VM-based deployments, several real problems emerged:

The VM Reality:

Patching required a maintenance window — downtime. Someone had to call clients and say "the system will be unavailable on Sunday from 2am."
Hazelcast — Pega's clustering technology — had a notorious problem called split-brain, where nodes in a cluster couldn't agree on who was the master, causing failures that were very hard to diagnose.
Scaling up for month-end processing meant manually spinning up new VMs, installing the app server, and configuring Pega — all by hand.
Every environment needed its own OS + App Server setup, making deployments inconsistent and error-prone.
Upgrades were high-risk, multi-day events.

What Banking and Financial Services Clients Expected:

Zero-downtime patching
Self-healing when nodes fail
Auto-scale during peak load (e.g. month-end BFS batch processing)
Consistent, repeatable deployments across environments

For banking clients processing millions of transactions, the VM model wasn't good enough. Something had to change.

The New Way — Think of Kubernetes Like a Smart Shipping Port

Now think of Kubernetes as a smart shipping port. Instead of apartments, your application lives in a container — a standardised, portable box. The port — Kubernetes — manages all the containers. It knows which containers are healthy, which ones failed, how many are needed right now, and where to put them.

One container fails? Kubernetes automatically spins up a replacement.
End of financial year with heavy batch loads? Kubernetes scales up automatically.
Same container in dev and prod? Yes — the identical container that runs in your development environment runs in production. No more "but it worked on my machine."

Pega's Official Decision: Infinity '25 is Kubernetes-Only

This is the official statement from Pega's own documentation:

"Starting in Pega Platform '25, Pega no longer supports deploying on virtual machines."

That's it. No VM path. No hybrid option. No gradual sunset.

If you're upgrading to Pega '25, you're deploying on Kubernetes. Pega provides the platform exclusively as a Docker image. And with this change, Hazelcast — which handled clustering in older versions — has been completely removed and replaced with Kubernetes-native mechanisms. This is a hard line in the sand.

The Pega Platform '25 Deployment Architecture

Everything sits inside a Kubernetes cluster. Here's how to read the official architecture:

Layer 1 — Access (top)

Users and browsers connect through an Ingress / Load Balancer into the Kubernetes cluster boundary.

Layer 2 — Pega Application (inside the cluster)

The cluster is organised into namespaces:

Namespace: mypega
- Pega Web Nodes (1..n) — interactive user processing
- Pega Batch Nodes (1..n) — background processing
- Installer Job (one-time, runs on initial deploy)
Namespace: srs
- Search and Reporting Service (SRS) — (1..n)
Namespace: constellation
- Constellation Service (1..n)
Pega Diagnostic Centre (PDC) — external, managed by Pega Cloud Services

Layer 3 — External Services (client-provided, outside the cluster)

Elasticsearch — for search and reporting
Kafka — for streaming and rule cache synchronisation
Cassandra — CDH only (Customer Decision Hub)
Postgres — Rules and Data database

Take time to study this diagram — it's the single most important reference for any Pega '25 deployment conversation.

The Four Kubernetes Objects You Need to Know

You don't need to be a Kubernetes engineer to understand these — but you must recognise them when they come up on a project.

1. Pod

Plain English: The smallest running unit in Kubernetes.
Pega example: One Pega node = one pod. A Pega Web node running your Constellation UI is a single pod.

2. Service

Plain English: Defines how pods find and communicate with each other — the internal network routing layer.
Pega example: How Web nodes connect to the Search and Reporting Service (SRS).

3. ConfigMap

Plain English: Configuration data that gets injected into a container at startup.
Pega example: Your prconfig.xml is injected directly into the Pega pod via a ConfigMap — no more manually managing config files on each server.

4. Ingress

Plain English: The front door to the cluster — routes external traffic to the right pods.
Pega example: The load balancer that routes a user's browser request to the right Pega Web node.

Web Nodes vs Batch Nodes — What Does Each One Do?

Inside your Pega cluster, all nodes are built from the same Docker image — but they're configured differently using Helm chart parameters. This separation is one of Kubernetes' most powerful features for Pega deployments.

Web Nodes

Exposed to the Ingress / Load Balancer
Handles interactive user traffic — logins, case submissions, task work
Node classification: Foreground / WebUser
Kubernetes objects: Replica Set + Service + Ingress + ConfigMap
Scales based on: user session load

Batch Nodes

Not exposed to the load balancer (internal only)
Handles: BackgroundProcessing, ADM scoring, Batch, RealTime, RTDG, BIX data exports, Custom tiers (1–5)
Node classification: Back-end
Kubernetes objects: Replica Set + ConfigMap only
Scales based on: background job volume

The key insight: You can scale Web nodes and Batch nodes completely independently based on actual workload — something that was extremely difficult to do with VMs.

What Sits Outside the Cluster — And Who Owns It?

One of the things that catches people out when they first look at the Pega '25 architecture is understanding what you have to bring to the table.

Pega provides (inside the cluster):

Search and Reporting Service (SRS)
Constellation Services
Traefik (optional load balancer)
EFK logging stack (optional)

You must provide (external, client-managed):

Kafka — streaming and rule cache synchronisation (replaced Hazelcast for node-to-node communication)
Elasticsearch / OpenSearch — all search and reporting functionality
Relational Database (Postgres or Oracle) — where Pega rules and data live

CDH only:

Cassandra — required only if you're running Customer Decision Hub

Note: Kafka is not optional. No Kafka = no Pega '25.

Kafka replaced Hazelcast for rule cache synchronisation across nodes. When one node saves a rule change, Kafka propagates that notification to every other node instantly. This is the technical heart of why Pega was able to eliminate Hazelcast entirely.

VM vs Kubernetes — The Definitive Comparison

	VM-Based (Pre-'25)	Kubernetes-Based ('25 onwards)
Deployment unit	Virtual Machine with OS + App Server + Pega	Docker container (Pod) with just Pega
Scaling	Manual — provision new VM, install, configure	Automatic — Kubernetes scales pods on demand
Patching	Requires maintenance window / downtime	Zero-downtime rolling update via Helm
Clustering	Hazelcast — complex, split-brain risk	Kubernetes-native + Kafka — no split-brain
Configuration	Manual prconfig.xml on each server	ConfigMap injected into container — consistent
Supported in '25	NO	YES — only option

What You Now Know

By understanding this module, you can now:

Explain why Pega moved from VMs to Kubernetes — the real client pain that drove it
Read and describe the official Pega '25 deployment architecture and its three layers
Identify the four Kubernetes objects Pega uses and what each one does in context
Articulate the difference between Web nodes and Batch nodes and when each scales
Know exactly which external services a client must provide — and why Kafka is non-negotiable

Coming up in the series:

Pega Helm Charts — Reading and configuring your deployment
Node types deep dive — When to use Custom tiers
Zero-downtime patching — How rolling updates work in practice

Wohooooo, Congratulations :) — You now understand the biggest infrastructure shift in Pega's history and can speak to it confidently in interviews, upgrade projects, and on the job.