kubeflow/kubeflow: the gateway repository behind the Kubeflow AI platform

What kubeflow/kubeflow actually contains

The first surprise for anyone arriving from a search engine is the repository layout. The top level holds .github/, .gitignore, CONTRIBUTING.md, LICENSE, OWNERS, README.md, ROADMAP.md and logo/. There is no operator, no controller and no install manifest in this tree. The README states the role plainly: "This repository serves primarily as a gateway to Kubeflow subprojects and shared project metadata." Development happens in the individual subproject repositories.

So kubeflow/kubeflow is a landing page with version control. It carries the project charter, the governance pointers and the logo assets. If you were hoping to clone it and run a make target that brings up a cluster, this is the wrong repository. The value it delivers is orientation: it tells you that Kubeflow is split into Subprojects, an Ecosystem, a Packaged Distribution and a Community Distribution, and that you can consume any subproject on its own rather than the whole stack.

That framing matters for evaluation. Judging Kubeflow by this repository alone would be misleading in both directions. You cannot assess code quality here because there is almost no code. You also cannot judge the project as abandoned, because the work is elsewhere. The last push to this repository was on 2026-08-21, and the most recent release entry is a redirect published on 2026-04-29, which is consistent with a metadata repository rather than a shipping component.

Who the Kubeflow distribution is built for

The README names three audiences: AI practitioners, platform administrators, and teams of developers. Those are not interchangeable, and the split explains most of the confusion around the project.

Platform administrators are the primary consumer. The pitch is that an AI platform team can build on Kubeflow by taking each subproject independently or by deploying the entire Kubeflow Community Distribution. That sentence assumes a platform team exists, with the budget to run a Kubernetes cluster and the mandate to maintain it. Topics on the repository include google-kubernetes-engine, minikube and kubernetes, which reflects that deployment target range from a managed cloud cluster down to a local one.

Practitioners come second. They get notebooks, pipelines and training jobs, but only through tools the platform team has stood up. The repository topics list jupyter, notebook, tensorflow and ml, which sketches the day-to-day surface: interactive notebooks, TensorFlow workloads, and the pipeline machinery that moves a notebook experiment toward something repeatable.

If you are a solo data scientist with a laptop and a CSV file, none of this is aimed at you. The cost of the platform is real and the README does not pretend otherwise.

How the pieces fit together at runtime

The architecture described in the README is compositional rather than monolithic. Kubeflow is a set of Kubernetes-native projects, each covering a stage of the AI lifecycle, with a link out to a page describing the Kubeflow landscape in the AI lifecycle. The Community Distribution bundles them; the subprojects can be installed on their own.

That is the mechanism to understand before you plan an install. Nothing in this repository schedules a pod. The scheduling happens in the subproject controllers, which are ordinary Kubernetes operators watching custom resources. A pipeline run becomes a graph of pods. A notebook becomes a pod with a persistent volume attached. A training job becomes a set of worker pods coordinated by a job controller. The Kubernetes API server is the single control plane for all of it, which is the actual argument for choosing Kubeflow over a separate ML platform: your existing RBAC, namespaces, resource quotas, node pools and monitoring apply to machine learning workloads without a second identity system.

The trade-off is equally structural. Every capability is a controller that must be installed, versioned and upgraded. The README's claim that the distribution is composable and modular is accurate, and it also means you own the composition. There is no single binary that hides the moving parts.

One consequence worth flagging: because these are Kubernetes-native projects, a failure in the cluster is a failure in your ML platform. Node pressure, a bad CNI upgrade or an expired certificate stops experiments. Teams used to a managed notebook service often underestimate that coupling.

Installing Kubeflow and running a first notebook

This repository gives no install commands. It points to the official documentation at kubeflow.org, and the documentation is where installation lives. The README links to the introduction page under /docs/started/introduction/ and to the architecture page under /docs/started/architecture/, and the topics list minikube and google-kubernetes-engine as the environments people use.

Because kubeflow/kubeflow contains no manifests, there is no command in this repository to copy. The documentation is the only source for the install sequence, and it is the page to open before touching a cluster. What the repository does establish is the shape of the decision: you need a working Kubernetes cluster first, and the topics list points at minikube for local work and google-kubernetes-engine for cloud work.

Once a cluster exists, the documented flow applies the distribution manifests published separately from this repository, then waits for the control plane pods to become ready. Readiness is the gate, not the apply command returning. The related searches include the phrase kubeflow manifests, and that is the artifact you want rather than anything in this tree.

When the control plane is up, the first real use is creating a notebook server through the central dashboard, choosing an image, and opening JupyterLab. That notebook is a pod in the cluster, and it is subject to the same quotas as everything else. Because this repository ships no example commands, treat the version-pinned documentation as authoritative and do not improvise flags from memory.

Where Kubeflow is the wrong tool

The clearest failure mode is scale mismatch. A Kubernetes cluster with an ML platform on top is a multi-tenant system. If your workload is one person training one model per week, the platform costs more attention than the model does. The README's own framing supports this: it addresses AI platform teams building for practitioners, not individuals solving a one-off problem.

A second case is teams without Kubernetes operational experience. The distribution is Kubernetes-native, which is a benefit only if someone on staff can debug a control plane. Installing is the easy part; keeping certificates, ingress, storage classes and controller versions aligned across upgrades is the ongoing work. The repository does not document an upgrade path, and the README does not document rollback at all. That silence is worth weighing before a production commitment.

A third case is a team that needs only experiment tracking. Kubeflow covers the lifecycle broadly, and if your actual gap is a comparison table of runs with metrics and artifacts, a narrower tool fits with far less infrastructure.

Finally, version selection deserves care. The release list on this repository contains a redirect entry dated 2026-04-29 and a v1.10.0 dated 2025-03-25, with v1.9.2 before it. Because this repository is metadata, those tags describe project-level releases rather than the version of any component you will install. Pin component versions from the subproject repositories and the distribution documentation.

Kubeflow compared with MLflow and Airflow

The two comparisons people search for most are Kubeflow versus MLflow and Kubeflow versus Airflow, and the differences are about scope rather than features.

MLflow is an experiment tracking and model registry layer. It records runs, parameters, metrics and artifacts, and it can run on a laptop or a single server. Kubeflow is a platform on Kubernetes that spans notebooks, pipelines and training. They overlap in the sense that a Kubeflow pipeline run can log to a tracking server, but MLflow does not schedule pods and Kubeflow does not exist to be a registry. If your question is "which runs my training job", MLflow is not in that business.

Airflow is a general workflow orchestrator. It schedules directed acyclic graphs of tasks across many domains, and it has an extensive operator ecosystem. Kubeflow Pipelines is also a DAG orchestrator, but it is built on Kubernetes primitives and is aimed at containerized ML steps, with artifacts and lineage as first-class concerns. Airflow's scheduler is its own service; Kubeflow Pipelines delegates execution to the cluster. A team already running Airflow for data engineering may reasonably keep it and add Kubeflow only for the notebook and training side, which is exactly the composability the README describes.

The honest summary: Kubeflow is the broadest of the three and the most expensive to operate. Choose it when the platform is the product. Choose MLflow when tracking is the gap. Choose Airflow when the workload is general orchestration that happens to include a training step.

Licence, maintenance and the cost of upgrading

The repository is licensed Apache-2.0, with the LICENSE file at the top level. Apache-2.0 is a permissive licence that includes an express patent grant, and it does not require you to publish modifications. That is a summary of the licence text, not legal advice; if you are redistributing a modified distribution, have counsel read the NOTICE and attribution requirements rather than relying on a summary.

Maintenance is community-led. The README states that Kubeflow is maintained by the Kubeflow Working Groups under the guidance of the Outreach Committee, the Distribution Committee and the Steering Committee, with links into the governance documentation. There is no single vendor behind the repository, which is normal for a project of this shape and also means support comes from the community, from a distribution vendor, or from your own platform team.

The repository itself is not archived and the last push was on 2026-08-21, so the metadata is current. That tells you the gateway is looked after; it says nothing about the release cadence of the subprojects, which you should check individually.

Upgrade cost is the part teams underestimate. Because the distribution is assembled from independently versioned projects, an upgrade is a compatibility exercise across controllers, CRDs and the ingress layer. The documentation is the authority on supported combinations. Budget for a staging cluster that mirrors production, and treat the CRD upgrade step as the risky one, since custom resource definitions are cluster-scoped and a botched change affects every namespace at once.

Editorial conclusion

Adopt Kubeflow if you already run Kubernetes and need notebooks, pipelines and training on the same cluster; stay away if a single laptop or a managed notebook service covers your work. Before committing, open the subproject repositories listed from kubeflow/kubeflow, since that is where the code, issues and release notes live, and confirm which distribution your platform team intends to support.

Frequently asked questions

Official sources

1. kubeflow/kubeflow on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases