Cloud Foundry vs OpenShift

What Cloud Foundry is

Cloud Foundry is an Apache-licensed, openly governed application-platform ecosystem. Developers push supported application code through the cf CLI and platform API; operators provide routing, buildpacks, container scheduling, identity, logs, quotas and service integrations. The software has no license fee, but a production foundation still requires infrastructure, load balancers, DNS/TLS, databases, blob stores, monitoring, backups, updates and skilled operations—or a separately priced commercial distribution or managed provider. Certification verifies required core components for a specific program year; it is not the same as generic API compatibility or an uptime guarantee.

What OpenShift is

Red Hat OpenShift is an enterprise Kubernetes application-platform family, not a single hosting plan. Self-managed editions range from Virtualization Engine and Kubernetes Engine through Container Platform and Platform Plus; managed services run with AWS, Microsoft, Google or IBM under different billing and responsibility models. The advertised $0.076 per hour floor is based on a 4-vCPU three-year reservation and still requires a minimum worker configuration, so it is not a complete cluster price. Trials and a developer sandbox exist, while production cost includes subscriptions or service fees plus infrastructure, storage, networking and operations.

What Cloud Foundry is built to do

cf push workflow

Stages supported source or artifacts with buildpacks and schedules application instances.

Organizations and spaces

Scopes applications, routes, services, quotas and role-based access for multiple teams.

Service broker model

Provisions and binds managed services through the Open Service Broker API.

UAA identity

Provides OAuth-based platform identity with configurable LDAP and SAML federation.

What OpenShift is built to do

Enterprise Kubernetes

Runs containerized workloads on a security-focused Kubernetes and RHEL CoreOS foundation.

Developer platform

Adds console, Operators, build and deployment workflows, GitOps, pipelines, serverless and service mesh by edition.

Hybrid deployment

Supports validated on-premises, cloud and edge infrastructure with consistent APIs and operational patterns.

Managed services

Offers jointly or vendor-managed OpenShift services on major public-cloud platforms with product-specific SLAs.

Choose Cloud Foundry if

• Large application portfolios that conform to buildpack or supported container workflows
• Organizations prioritizing consistent developer experience across infrastructure choices
• Internal platforms with dedicated owners for upgrades, security, observability and disaster recovery

Skip Cloud Foundry if

• The organization has only a few simple services and no platform-operations capacity
• Applications require privileged hosts, unusual kernels or infrastructure-level control
• The selected distribution has no verified lifecycle, support, certification or backup responsibility

Choose OpenShift if

• Regulated or large multi-team Kubernetes estates needing a supported platform and lifecycle
• Hybrid-cloud application portfolios where consistent APIs and deployment controls justify the overhead
• Organizations choosing a managed service to transfer defined control-plane, patching and monitoring duties

Skip OpenShift if

• A handful of simple applications do not justify a minimum multi-node cluster and platform team
• The budget treats the advertised reserved vCPU rate as the complete production price
• The team has not selected an edition and documented the exact provider/customer responsibility matrix

Cloud Foundry: pros & cons

• Developer abstraction: A consistent cf push workflow hides much of the infrastructure configuration from application teams.
• Open governance and source: Foundation projects use open contribution, design and governance processes.
• Infrastructure choice: Cloud Foundry can be deployed on multiple IaaS environments or consumed through commercial offerings.
• Platform controls: UAA identity, RBAC, orgs, spaces, quotas, routing, logs and service brokers provide multi-team governance.
• Free software has real operating cost: Production topology, infrastructure, upgrades, security and recovery need a platform team.
• Provider experience varies: Buildpacks, services, extensions, support, certification and pricing differ among distributions.
• State remains external: Databases and bound services need their own durability, credential and restore strategy.
• Not general compute: The opinionated application model is a poor fit for workloads needing unrestricted hosts or unusual system dependencies.

OpenShift: pros & cons

• Deployment choice: Run supported self-managed editions across data center, public cloud and edge, or buy a managed cloud service.
• Integrated platform: Kubernetes, RHEL CoreOS, developer console, Operators, GitOps, pipelines and service mesh can form one supported stack.
• Enterprise support model: Paid editions add Red Hat lifecycle, security and support around tested platform combinations.
• Open upstream path: OKD provides the community Kubernetes distribution that powers OpenShift, with Apache-licensed project components.
• Real cost is multi-part: Worker minimums, infrastructure, storage, networking, subscriptions and operations exceed the headline unit rate.
• Operational burden varies sharply: Self-managed customers own platform and infrastructure, while managed-service responsibility matrices still leave customer duties.
• Edition complexity: Platform Plus, Container Platform, Kubernetes Engine, Virtualization Engine and cloud services bundle different capabilities.
• Cluster overhead is significant: Small applications may be cheaper and simpler on a basic PaaS or managed container runtime.