# Kubeflow Community Distribution, and the manifests that assemble a platform > This repository is the set of Kubernetes manifests that install the Kubeflow Platform as a whole, with the official components, the Central Dashboard and the common services, in one kustomize tree. It is run by the community distribution maintainers, released twice a year, and it is mostly YAML. **kubeflow/community-distribution** — Kubeflow Community Distribution - Repository: https://github.com/kubeflow/community-distribution - Website: https://www.kubeflow.org/docs/started/installing-kubeflow/#kubeflow-manifests - Stars: 1,045 · Forks: 1,072 - Language: YAML - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/kubeflow-community-distribution ## One repository that installs the whole platform This repository helps you to install the Kubeflow Platform in popular Kubernetes clusters such as Kind, Minikube, Rancher, EKS, AKS and GKE. The manifests include all the Kubeflow components, Pipelines and KServe among them, the Kubeflow Central Dashboard, and the other applications that make up the platform. That last part is the reason this repository exists as a separate project. Kubeflow is not one application. It is a set of independently developed components, each with its own upstream repository, its own working group and its own release cycle, and there has always been the question of what a coherent, installable set of them looks like. This repository is the answer, and it is the answer in the form of manifests. The audience is stated with unusual precision. It is used and adapted around the world by small and large enterprises alike that have strict legal, security and multi-tenancy requirements for their machine learning platforms. It is also beneficial for academic users wanting to explore the end-to-end capabilities of the platform and contribute to it. That combination of audiences explains the design. An enterprise with legal and multi-tenancy requirements wants a versioned, auditable set of manifests with a known support window, and that is a different artefact from the bleeding edge of a dozen upstream projects. A student wants to click one button and see the whole thing work, which is what the same manifests give them. The primary language of the repository is YAML, the licence is Apache-2.0, and the repository is owned by the Community Distribution Maintainers, with a committee charter, a CNCF Slack channel, and biweekly meetings with a commentable agenda. ## Three directories, three owners, one kustomize tree The repository is organised under three main directories, and the table that describes them is the clearest statement of the project's governance model. The applications directory holds Kubeflow's official components, maintained by the respective Kubeflow working groups. The common directory holds common services, maintained by the Manifests working group. And the experimental directory holds third-party integrations and platform experiments, with Ray and security improvements given as examples. That division is a maintenance boundary, not a technical one. A component in applications is owned by the group that develops it upstream, so a change to the manifests here is a change to how a component is deployed rather than a change to the component. A change in common is owned by the working group responsible for the platform's shared plumbing. And experimental is explicitly the place where things are not yet settled, which is what stops a Ray integration or a security experiment from becoming a de facto part of the platform. Everything is deployable with kustomize, and in addition experimental Helm charts for selected components are available under experimental/helm. You can choose to deploy the entire platform or individual components, and that choice is the practical difference between this repository and the per-component installation instructions. The top level also carries the files you would expect from a project with this much governance: an OWNERS file, a ROADMAP.md, a SECURITY.md, a CONTRIBUTING.md, a pre-commit configuration, a yamllint configuration, a shellcheck configuration, an architecture.svg diagram, and both AGENTS.md and CLAUDE.md. ## The version matrix, and the resource numbers nobody publishes The repository periodically synchronizes all official Kubeflow components from their upstream repositories, and it publishes a matrix showing the git version included for each component along with the rough resource requirements. The requirements are calculated as the maximum of actual usage and configured requests for CPU and memory, and as the storage requirements from the persistent volume claims. The numbers are the interesting part, because they let you size a cluster before you install anything. Kubeflow Pipelines is the heaviest on memory and storage at 970 millicores of CPU, 3552 mebibytes of memory and 35 gigabytes of storage. Knative is the heaviest on CPU at 1450 millicores with 1038 mebibytes and no storage, and Istio is 750 millicores with 2364 mebibytes. KServe is 600 millicores and 1200 mebibytes, and Kubeflow Hub is 510 millicores with 2112 mebibytes and 20 gigabytes of storage. The light end is comfortable. The Trainer is 8 millicores and 143 mebibytes, the Spark Operator is 9 millicores and 41 mebibytes, and Dex and cert-manager are smaller still. The point of publishing this is that the two heaviest items, Pipelines and the platform's networking and serving layers, are also the ones an operator is most likely to be surprised by. A 35 gigabyte storage requirement for one component is the kind of thing that turns a demo into a provisioning request. The matrix is presented for the master branch, and it also carries the upstream revision for each component, from Trainer at v2.3.0 and Notebooks at v1.11.0 through to Istio at 1.31.1 and Knative at v1.23.0, so the whole stack is versioned in one place. ## Two releases a year, and six months of community support The release policy is stated plainly, and it is unusual enough to be worth quoting in full. For a stable and conservative experience, the project recommends using the latest stable release, while also saying you should consult the more up-to-date documentation in the master branch. The two statements are not in conflict, and the reason is that the documentation lives in the branch that is always current while the releases are the conservative artefacts. The plan is to cut 2 releases per year, for example 26.03 and 26.10 before each KubeCon EU and NA. That is a calendar version scheme, and the recent tags follow it: 26.03.1, released 2026-06-15, with 26.03.1-rc.2 from 2026-06-05 and 26.03.1-rc.1 from 2026-05-25 before it. So the release candidates come weeks ahead of the final, and the patch suffix carries the fixes after the initial cut. The support window is the line to note. The project tries to BEST-EFFORT support each release for 6 months as community, and there is commercial support available if needed, through a link to the commercial providers in the Kubeflow ecosystem. That combination defines the contract. Two releases a year, six months of community support on each, and a commercial option behind it. An organisation that cannot tolerate a six month window is pointed at the commercial providers, and one that can, gets a platform that tracks upstream components twice a year with a known end of life for each version. ## Continuous integration that actually installs the platform The project supports the master branch as an installable option, with instructions for installing it and providing feedback, and the reason that is safe to say is the continuous integration workflow. The workflow runs end-to-end installation and tests on pull requests and pushes to the master branch, in the upstream community-distribution repository, and the project links the full Kubeflow integration test workflow for details. There is a badge for its build check status in the header of the project description. That is a meaningful distinction for a repository that is entirely manifests. A change to a YAML file cannot be unit tested in any interesting way, so the only real check is whether the platform still installs and the components still come up, and a project that runs that on every pull request is doing the expensive, boring work that makes master safe to install. The OpenSSF Best Practices badge in the header is the other signal, and it points at the same thing from the process side rather than the code side. For an adopter, the practical arrangement is that master is where the feedback goes and where the documentation is current, and the stable release is what a production cluster should run, with the version matrix telling you exactly which upstream revisions that release contains. ## Repository hygiene, and the pieces around the manifests Beyond the manifests, the repository carries the working parts of a project that has to be operated by other people. The pre-commit configuration is paired with a yamllint configuration and a shellcheck configuration, which is the right combination for a repository whose content is mostly YAML and whose scripts are shell. Linting the manifests before they are committed catches the class of error that would otherwise become a failed install in somebody else's cluster, and the pre-commit hook puts that check where it is cheap to run. There is a tests directory, a scripts directory, a proposals directory for larger changes, a releases directory, an example directory with a kustomization.yaml, and an architecture.svg that documents the shape of the platform as a diagram rather than as prose. The AGENTS.md and CLAUDE.md files are the newest addition and worth noticing, because they are the kind of file that tells a coding assistant how to work in the repository. For a project whose content is machine edited YAML with a large set of conventions, giving an assistant a written description of those conventions is a way of keeping a large body of contributions consistent. The licence is Apache-2.0, the default branch is master, and the last push was on 2026-10-15 with the repository not archived, so the manifests are being updated between releases rather than only at release time. ## Conclusion Adopt the Kubeflow Community Distribution if you want the whole Kubeflow Platform, components and dashboard together, deployed with kustomize on a supported Kubernetes flavour, and you are prepared to own the upgrade path. Do not adopt it if you only need one component, since the repository also supports installing them individually and a full platform install carries a large resource footprint, with Pipelines alone asking for 970 millicores, 3552 mebibytes and 35 gigabytes of storage. Before you install, read the version matrix for the component revisions and resource requirements, and check the release you pick against the six month community support window. ## FAQ ### What does the Kubeflow Community Distribution repository contain? It contains the manifests for installing the Kubeflow Platform, including the official components such as Pipelines and KServe, the Kubeflow Central Dashboard, and the common services. It is organized under three directories: applications for official components, common for shared services, and experimental for third-party integrations and platform experiments. ### How often is Kubeflow Community Distribution released? The project plans to cut 2 releases per year, for example 26.03 and 26.10 before each KubeCon EU and NA. The recent tags are 26.03.1 from 2026-06-15, with the 26.03.1 release candidates before it. ### How long is a Kubeflow Community Distribution release supported? The project tries to BEST-EFFORT support each release for 6 months as community, and points to commercial support from providers in the Kubeflow ecosystem if a longer commitment is needed. ### Which Kubernetes platforms can Kubeflow Community Distribution be installed on? The repository says it helps you install the Kubeflow Platform in popular Kubernetes clusters such as Kind, Minikube, Rancher, EKS, AKS and GKE. ### What resources does a full Kubeflow install need? The published matrix gives per component requirements as the maximum of actual usage and configured requests. Kubeflow Pipelines is the heaviest at 970 millicores of CPU, 3552 mebibytes of memory and 35 gigabytes of storage, while Knative asks for 1450 millicores and Istio for 750 millicores and 2364 mebibytes. ## Sources - [kubeflow/community-distribution on GitHub](https://github.com/kubeflow/community-distribution) - [License: Apache-2.0](https://github.com/kubeflow/community-distribution/blob/master/LICENSE) - [Project website](https://www.kubeflow.org/docs/started/installing-kubeflow/#kubeflow-manifests) - [README](https://github.com/kubeflow/community-distribution/blob/master/README.md) - [Releases](https://github.com/kubeflow/community-distribution/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kubeflow-community-distribution