Cloud Foundry on Kubernetes: The Managed PaaS for Secure and Compliant Workloads

For over a decade, cf push has been the gold standard developer experience for deploying applications at scale. Now, Cloud Foundry runs natively on Kubernetes — combining the simplicity that developers love with the operational maturity that platform teams demand. This is the story of how we got here, what went wrong along the way, and why the best version of Cloud Foundry is the one that finally broke free.

1. Why Cloud Foundry Still Matters

Kubernetes won the infrastructure war. That's not in question. But Kubernetes is an infrastructure API, not a developer experience. Ask a product engineer to deploy a Node.js app and they'll spend a week writing Dockerfiles, Helm charts, Ingress rules, HPA configs, and PodDisruptionBudgets before a single line of business logic reaches production.

Cloud Foundry solved this problem in 2011. The developer experience is three words:

$ cf push my-app

That's it. Cloud Foundry detects the language, builds the container, configures networking, provisions a route, sets up health checks, and runs rolling deployments — automatically. No YAML. No container registry. No Ingress controller. No watching kubectl logs to figure out why the pod is in CrashLoopBackOff.

This isn't nostalgia. This is what most developers actually need. The 12-factor app that talks to a database and serves HTTP traffic on a custom domain. Cloud Foundry does that in seconds. Kubernetes does it in days.

2. The Pivotal, VMware, and Broadcom Story

To understand why Cloud Foundry on Kubernetes matters now, you need to understand what happened to the commercial Cloud Foundry ecosystem. It's a cautionary tale about what happens when open-source platforms get trapped inside enterprise licensing machines.

3. Enter Korifi: Cloud Foundry Reborn on Kubernetes

Korifi is not a port. It's not a compatibility layer. It's a ground-up reimplementation of the Cloud Foundry API using Kubernetes-native primitives. Every CF concept maps directly to a Kubernetes resource:

The result: everything you know about Cloud Foundry — cf push, cf logs, cf scale, cf bind-service — works exactly the same. But underneath, it's Kubernetes all the way down. Your platform team gets standard Kubernetes tooling: Prometheus, Grafana, OPA, Falco, cert-manager, external-secrets. Your developers never see any of it.

What Korifi Eliminates

• BOSH — the notoriously complex deployment tool that required its own specialized operations team. Gone. Korifi runs on any Kubernetes cluster.
• Diego — the custom container orchestrator that predated Kubernetes. Replaced by Kubernetes Deployments and ReplicaSets.
• GoRouter — the CF-specific HTTP router. Replaced by standard Kubernetes Ingress controllers (Contour, Envoy).
• Garden — the custom container runtime. Replaced by containerd/runc, the same runtime that powers every Kubernetes cluster on Earth.
• Vendor licensing — no Pivotal, no VMware, no Broadcom. Korifi is Apache 2.0 open source, backed by the Cloud Foundry Foundation.

4. Built for Security and Compliance

Cloud Foundry didn't become the default platform for government agencies and regulated industries by accident. The architecture is inherently security-first, and Korifi preserves every one of those properties while adding Kubernetes-native security controls on top.

Why Regulated Industries Choose Cloud Foundry

When an organization operates under FISMA, FedRAMP, HIPAA, SOC 2, or PCI-DSS, the platform isn't just infrastructure — it's part of the compliance boundary. Every control, every audit log, every network policy becomes a line item in your authority to operate (ATO). Cloud Foundry was designed for this world from the ground up.

The Security Model in Practice

Consider a team deploying a healthcare application under HIPAA. Without Cloud Foundry, the compliance checklist looks like this:

# Network isolation
- Write NetworkPolicy YAML for every namespace
- Configure Calico/Cilium CNI plugin
- Test and validate every allowed traffic path

# Image security
- Build Dockerfile with approved base image
- Set up image scanning pipeline (Trivy/Snyk)
- Configure admission controller to block unscanned images
- Manage base image patching schedule

# Secrets
- Install external-secrets-operator
- Configure SecretStore for each namespace
- Write ExternalSecret manifests for each binding

# RBAC
- Define Roles and ClusterRoles
- Create RoleBindings per team
- Audit and rotate service account tokens

# Audit
- Configure API server audit policy
- Ship logs to SIEM
- Build dashboards for compliance reporting

With Cloud Foundry on Kubernetes, the same team does this:

$ cf create-org healthcare-prod
$ cf create-space patient-api -o healthcare-prod
$ cf set-space-role developer@company.com healthcare-prod patient-api SpaceDeveloper
$ cf push patient-api
$ cf bind-service patient-api patient-db

Network isolation, RBAC, secret injection, audit logging, and image security are all handled by the platform. The developer pushed code. The platform enforced policy. The auditor sees a clean control matrix.

5. Architecture: How It Works

Korifi runs as a set of Kubernetes controllers inside your cluster. There's no sidecar control plane, no external database requirement, no proprietary runtime. The architecture is deliberately simple:

Developer  ──  cf push  ──▶  CF API Server  ──▶  Kubernetes API
                                    │
                    ┌───────────────┼───────────────┐
                    ▼               ▼               ▼
              kpack          Contour       Controllers
           (build OCI       (HTTPProxy     (reconcile CF
            images)          routing)       resources)
                    │               │               │
                    ▼               ▼               ▼
              Container      Envoy         Deployments
              Registry       Proxy         & Services

The Request Flow

When a developer runs cf push, here's what happens inside Korifi:

1. Source upload. The CF CLI packages the application source and uploads it to the CF API server, which stores it in a Kubernetes-managed container registry.

2. Build. Korifi creates a kpack Image resource. Kpack detects the language using Cloud Native Buildpacks, compiles the application, and produces an OCI container image. No Dockerfile needed.

3. Deploy. The Korifi controllers create a Kubernetes Deployment with the built image, configure health checks, resource limits, and environment variables (including any bound service credentials).

4. Route. Korifi creates a Contour HTTPProxy resource that maps the application's route (e.g., patient-api.apps.example.com) to the Kubernetes Service. TLS is automated via cert-manager.

5. Scale. cf scale updates the Deployment's replica count. HPA can be layered on top for auto-scaling based on CPU, memory, or custom metrics.

Every step produces Kubernetes-native resources. Your monitoring sees Pods. Your network policies see Services. Your RBAC controls see Namespaces. There's nothing proprietary to learn, debug, or replace.

6. Migrating from Pivotal/Tanzu to Korifi

If you're running Pivotal Cloud Foundry or VMware Tanzu Application Service today, the migration to Korifi is the most natural path forward. Your applications already speak Cloud Foundry. They already use cf push. They already bind to services via OSBAPI. The migration isn't a rewrite — it's a re-platform.

What Stays the Same

• CF CLI commands — cf push, cf logs, cf scale, cf env, cf bind-service all work identically
• Buildpacks — Cloud Native Buildpacks support the same languages: Java, Node.js, Go, Python, Ruby, PHP, .NET Core, static files
• Service bindings — OSBAPI service brokers work unchanged; credentials injected the same way
• Manifests — manifest.yml files port directly with minimal changes
• Org/Space structure — your existing multi-tenant hierarchy maps to Kubernetes namespaces

What Changes

• Infrastructure — BOSH-managed VMs become a Kubernetes cluster (EKS, GKE, AKS, or bare metal)
• Operational tooling — replace BOSH commands with kubectl, Helm, and Kubernetes-native observability
• Licensing — eliminate Pivotal/VMware/Broadcom commercial licenses entirely
• Buildpack format — legacy buildpacks need migration to CNB format (most already have equivalents)

7. Production-Ready: What That Actually Means

"Production-ready" is one of the most overloaded terms in infrastructure. For a platform that handles secure and compliant workloads, it means specific, non-negotiable capabilities:

High Availability

Korifi runs on multi-node Kubernetes clusters. Application instances are distributed across availability zones using pod anti-affinity rules. The CF API server itself runs as a replicated Deployment. There is no single point of failure in the request path.

Rolling Deployments

cf push performs zero-downtime rolling deployments by default. Korifi leverages Kubernetes' native rolling update strategy — new pods come up, pass health checks, and start receiving traffic before old pods are terminated. If the new version fails health checks, the rollout automatically stops.

Disaster Recovery

Application source is stored in a container registry (replicable to multiple regions). Application state lives in bound services (databases, object stores) with their own backup strategies. The platform state is Kubernetes resources — backed up via Velero or etcd snapshots. Full cluster rebuild from backup takes minutes, not days.

Observability

Korifi applications emit logs to stdout/stderr, collected by Kubernetes' log pipeline (Fluent Bit, Loki, CloudWatch). Metrics are exposed via Prometheus endpoints. Distributed tracing works via OpenTelemetry. cf logs tails the Kubernetes log stream in real time.

Multi-Tenancy

Cloud Foundry's org/space model was designed for multi-tenancy from day one. On Korifi, this maps to Kubernetes namespaces with enforced ResourceQuotas, LimitRanges, and NetworkPolicies. Tenant A cannot see, access, or affect Tenant B's workloads. This isn't a convention — it's enforced at the API server level.

8. Getting Started

Cloud Foundry on Kubernetes is ready for production workloads today. The question isn't whether the technology works — it's whether you want to run it yourself or let someone else handle the platform so your team can focus on shipping software.

Self-Managed

Install Korifi on any Kubernetes cluster. The project provides Helm charts and detailed installation guides. You'll need a platform team comfortable with Kubernetes operations, cert-manager, Contour, and kpack. Best for organizations with existing Kubernetes expertise and a dedicated platform engineering team.

Managed by Orion

Korifi Drydock is our managed Cloud Foundry on Kubernetes offering. We handle the cluster, the Korifi installation, the upgrades, the security patches, and the compliance controls. You get cf push and a production-grade platform without building a platform team.

"The best infrastructure is the kind your developers never have to think about. Cloud Foundry gave us that a decade ago. Korifi gives it back — without the vendor lock-in."

— Platform Engineering Team, Orion Digital Platforms

The Bottom Line

Cloud Foundry's developer experience was never the problem. The problem was BOSH, the licensing, and the acquisition chain that turned an open-source project into a vendor negotiation. Korifi solves all three. It runs on Kubernetes — the infrastructure standard. It's Apache 2.0 — no licenses to negotiate. And it preserves the thing that made Cloud Foundry great in the first place: the ability to go from code to production with cf push.

For teams running workloads that demand security, compliance, and auditability — healthcare, financial services, government, defense — Cloud Foundry on Kubernetes isn't just an option. It's the cleanest path to a platform that satisfies both developers and auditors.

The platform is ready. The question is whether you're still paying Broadcom for something the open-source community gives you for free.