Korifi Brings cf Push to Kubernetes: The Forgotten Git-Push PaaS, Compared

Open any 2026 "self-hosted Heroku alternative" roundup and you will meet the same four names: Coolify, Dokku, CapRover, Dokploy. Every one of them is a fine answer to "I have a VPS and a git repo." And every one of those roundups forgets the platform with the deepest git-push pedigree in the industry — the one whose push command has deployed enterprise workloads since 2011 and now runs natively on Kubernetes. That platform is Korifi, the Cloud Foundry Foundation's reimplementation of the cf push experience as Kubernetes custom resources, and its absence from the comparison tables is a gap in the tables, not in Korifi.

Here is the core deliverable of this post, up front: the comparison the roundups keep skipping.

The one-paragraph verdict for readers in a hurry:

• Pick Korifi if you already run Kubernetes and want twelve-factor, multi-tenant cf push ergonomics with a service catalog — especially if your team speaks Cloud Foundry.
• Pick Dokku, Coolify, or CapRover if your whole estate is one VPS and you want deploys today with near-zero operator overhead.
• Pick a Kubernetes-native Render-compatible layer if your workloads arrive through Render APIs or AI agents rather than the cf CLI.

Everything below is the evidence behind that table: what Korifi actually is under the hood, where its Marketplace model beats hand-wired backing services, where its enterprise lineage still taxes the operator, and why it deserves a seat at every 2026 comparison.

What Korifi Actually Is: The CF API on Kubernetes CRDs​

Korifi is not a theme on top of Kubernetes and not a distribution of Cloud Foundry. It is a reimplementation of the Cloud Foundry V3 API whose backend is Kubernetes custom resources instead of the BOSH-managed VM estate that classic CF required. Developers keep the interface they have used for over a decade — cf push, orgs, spaces, routes, services, tasks — while everything underneath becomes standard Kubernetes objects on a standard cluster.

The build path is the clearest expression of that heritage. With Korifi you do not bring a Dockerfile: cf push uploads application bits, and Korifi stages them into OCI images with kpack and Paketo buildpacks — the Cloud Native Buildpacks lineage, not hand-rolled Dockerfiles. Since v0.9.0, teams with existing images can also push a prebuilt container image through the same cf push flow, which matters for migration: legacy pipelines that already produce images get an on-ramp without restaging every build on day one.

Networking, identity, and observability are all borrowed from the CNCF shelf rather than reinvented. Ingress runs through Envoy via Contour, authentication and authorization integrate with Kubernetes RBAC so any cluster user can be added to Korifi, and app container metrics flow through metrics-server back to developers. Housekeeping that operators used to script themselves — automatic cleanup of unused resources, for example — has been folding into releases as the project marches toward full CF developer-experience parity.

Two recent additions close the biggest historical gaps. Korifi 0.13.0, released in November 2024, introduced the Cloud Foundry Marketplace for Korifi: platform operators and developers can discover and deploy pre-built applications and services — databases, message queues — from a catalog, with support for the Open Service Broker API and compatibility with any service that ships a Helm chart. Around the same arc, a first-time-user installer and Stratos console integration lowered the two classic CF barriers: getting the platform running, and seeing it in a browser instead of living entirely in the CLI.

The strategic point is what Korifi removes. The main historical objection to Cloud Foundry was never the developer experience — cf push was always beloved — it was that adopting CF meant maintaining a separate BOSH estate alongside everything else. Earlier bridges like KubeCF converted BOSH manifests into Helm charts but kept BOSH semantics. Korifi swaps the whole VM layer for Envoy, kpack, and Paketo on a conformant cluster, which is why the Foundation positions it as the migration path for CF workloads moving to Kubernetes rather than as yet another installer for the old world.

Where the Marketplace Beats Hand-Wired Backing Services​

Backing services are where single-box PaaS ergonomics quietly fall apart, and they are where Korifi's broker lineage shows its strength. The canonical flow is three commands:

cf marketplace
cf create-service postgres mini orders-db
cf bind-service orders-app orders-db

cf marketplace lists the catalog your platform team curates. cf create-service provisions a real instance with a plan (mini, not "whatever the compose file says this week"). cf bind-service injects credentials into the app's environment through the standard VCAP_SERVICES contract and restages the app. Developers never touch connection strings, never edit YAML to add a database, and never learn that the postgres instance is a Helm release three namespaces over.

Contrast that with the alternatives in the table. Dokku provisions services through community plugins — excellent for a single host, but each service is a separate plugin with its own maintenance story, and everything lands on the same box. Coolify models backing services as Compose sidecars, which is flexible and exactly as robust as the YAML you wrote: you own the version pins, the volume mounts, the backup cron, and the 3 a.m. upgrade. CapRover's one-click apps are the friendliest of the three and the least uniform under the hood.

The broker model wins on three axes that only appear at scale. First, lifecycle uniformity: provision, bind, unbind, and deprovision work identically whether the backing service is postgres, Redis, or an internal API your platform team wrapped — one contract instead of N plugin CLIs. Second, credential hygiene: bindings flow through the platform's env contract rather than copy-pasted secrets, so rotation is a platform operation, not a scavenger hunt across compose files. Third, curation: the catalog is a policy surface — the platform team decides which services exist at which plans, and developers self-serve inside those rails instead of deploying whatever image they found.

An honest caveat belongs here: managed-service support via the Open Service Broker API has been the newest moving part of Korifi, and community install notes still flag it as maturing, with user-provided services filling the gaps for anything the catalog does not cover yet. That is the right shape for a 0.x project converging on parity — but if your week-one requirement is a deep catalog of production-hardened managed data services, verify the broker coverage for your specific services before committing.

Where the CF Lineage Shows: The Operator Bill​

Nothing above is free, and this is the section the roundup posts would write if they covered Korifi at all. The developer experience is twelve-factor minimalism; the operator experience is a CNCF bill of materials. A Korifi installation assumes a working Kubernetes cluster plus cert-manager for TLS lifecycle, kpack plus a container registry for staging builds, Contour/Envoy for ingress, metrics-server for app metrics, and the Korifi controllers themselves. Each dependency is mainstream and Helm-installable, but the list is real, and the minimum viable shape is a small cluster — not the single VPS that Dokku or Coolify asks for.

That floor has consequences. The org-and-space model maps onto Kubernetes namespaces and RBAC, which is exactly the right primitive for multi-tenant platform teams — and exactly the wrong amount of machinery for a solo developer deploying a side project. Buildpack stacks need updating, brokers need curating, and Day-2 work looks like operating a small platform, because that is what it is. Teams evaluating Korifi should price the operator hours alongside the cluster invoice: the platform simplifies developers' lives by moving complexity to operators, the classic PaaS bargain, and Korifi's enterprise-CF lineage means there is more complexity to move than a Compose file ever held.

Whether that bill is worth paying depends almost entirely on what you already run. If your estate is one VPS, Korifi is the wrong shape — install Coolify or Dokku and ship. But if you already operate a Kubernetes fleet, whether cloud-managed or Cluster API on owned hardware, the marginal cost of Korifi is a Helm release and some controller capacity on machines you already pay for. The comparison that matters is never Korifi versus Dokku on an empty VPS; it is Korifi versus whatever your platform team would otherwise build to give developers self-serve deploys on the fleet — raw kubectl plus wiki pages, a homegrown wrapper, or a commercial layer. Against that baseline, a maintained implementation of the most battle-tested developer API in the PaaS world starts looking inexpensive.

Why the Most Battle-Tested Git-Push UX Deserves a Seat at the 2026 Table​

So why do the roundups keep forgetting it? Three reasons, none of them technical. First, the roundups optimize for the VPS reader: every entry installs on one box in minutes, and anything requiring Kubernetes fails the premise of the article before the comparison starts. Second, the Cloud Foundry brand still carries BOSH-era baggage — readers hear "enterprise platform" and picture the heavyweight estate, not the lightweight CRD backend Korifi actually is. Third, the version number says 0.x, which scans as "beta" even though the API surface it implements has over a decade of production hardening behind it.

Here are the three profiles that should shortlist Korifi anyway. Ex-CF enterprises migrating to Kubernetes get to keep their developers' muscle memory — the same CLI, the same org/space mental model, the same buildpack supply chain — while retiring the BOSH estate. Platform teams already running a fleet get genuine multi-tenant self-serve UX with RBAC-backed isolation instead of bolting namespaces onto documentation. And regulated shops get buildpack supply-chain rigor: no hand-written Dockerfiles drifting across repositories, reproducible builds from versioned buildpacks, and a staging path that fits SBOM-shaped compliance stories far more naturally than "every team maintains its own Dockerfile."

The through-line is that cf push solved the problem every 2026 PaaS is still solving — source code in, running HTTPS service out, backing services attached — earlier and at larger scale than any of its current competitors. Korifi is that solution with the old estate swapped for the cluster you already run. The next time a comparison table lists four single-box tools and calls the market covered, ask what the Kubernetes-native row would look like. It looks like this post's first table. And its first column belongs in the conversation.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.