The core difference between IPI (Installer-Provisioned Infrastructure) and UPI (User-Provisioned Infrastructure) comes down to a single question: Who is responsible for building and managing the underlying infrastructure?
With IPI, you hand control to the OpenShift installer, which automates everything. With UPI, you build the infrastructure yourself, and the installer simply configures OpenShift on top of it.
The Architectural Blueprint Breakdown
| Feature / Dimension | Installer-Provisioned Infrastructure (IPI) | User-Provisioned Infrastructure (UPI) |
| Infrastructure Creation | Automated. The installer creates the VPCs, subnets, DNS entries, load balancers, and VMs automatically via cloud/hypervisor APIs. | Manual. You must pre-provision your own network topology, subnets, external load balancers, DNS records, and host machines. |
| Day-2 Cluster Autoscaling | Out-of-the-box. Since OpenShift created the VMs, the MachineAPI operator can scale worker nodes up or down dynamically based on pod demand. | Manual / Complex. OpenShift doesn’t have API access to control your machines. SRE teams must build external automated pipelines to add/remove raw infrastructure nodes. |
| Administrative Privileges | Very High. Requires account credentials with full permissions to spin up expensive infrastructure resources (like IAM roles, gateways, and load balancers). | Minimal. The deployment process only needs enough access to read configuration dependencies and boot the operating system layers onto existing machines. |
| Complexity | Very Low. You fill out a short config file, run openshift-install create cluster, and step away. | High. Requires a massive amount of manual configuration or maintaining custom Terraform/Ansible scripts. Prone to human networking mistakes. |
| Customization & Control | Standardized. You have limited options regarding how subnets are split, how firewalls are configured, or how storage routing operates. | Absolute. You dictate the exact network routing, corporate firewall proxy configurations, operating system storage layout, and compliance isolation boundaries. |
When to Choose IPI
“IPI if you can”
Choose IPI if you are deploying a clean-slate cluster in standard public clouds (AWS, Azure, GCP) or supported virtual hypervisors (VMware vSphere, Nutanix) and you want full automation. It saves thousands of engineering hours by giving you built-in horizontal node autoscaling and hands-free Day-2 host maintenance out of the box.
When to Choose UPI
“UPI if you must”
Choose UPI if you are forced to by organizational, security, or hardware constraints.
Common UPI forcing functions include:
- Rigid Corporate Networks: Security teams refuse to give the OpenShift installer API access to create internet gateways, route tables, or public load balancers.
- Air-Gapped Data Centers: Highly secure, disconnected environments where there are no cloud APIs to talk to.
- Complex Topology Mixes: When you need to mix bare-metal nodes and virtualized compute resources inside a single, unified cluster.
For a closer look at how these methods split when designing cluster topology, you can watch Shifts Happen: Installing OpenShift on Bare Metal: IPI vs UPI Overview. This video walks through the exact installation mechanics and shows you how to choose the right path for your specific data center footprint.