The CNCF Landscape, Counted

The CNCF landscape has 2,417 entries. That number is the reason people call it overwhelming, and it is also misleading: most of those entries are member companies and products that merely run on Kubernetes. The part that is actually governed by the foundation is smaller and countable, and it is what this post maps.

Everything below comes from landscape.yml in the cncf/landscape repository, read on 2 September 2026. Counts move, so treat them as a snapshot rather than a constant.

Index #

• How big it actually is
  • When they arrived
• What the maturity levels mean
• The projects, by category
  • App Definition and Development
  • Inference
  • Observability and Analysis
  • Orchestration & Management
  • Platform
  • Provisioning
  • Runtime
  • Serverless
  • Wasm
• How the foundation actually works
• Getting in, if you are new here
• What I would actually pick

How big it actually is #

The gap between 2,417 and 227 is the first thing worth internalising. Being on the landscape means someone filled in a YAML entry. Being a CNCF project means the Technical Oversight Committee voted you in and you accepted the obligations that come with it.

When they arrived #

Acceptance year of every project the foundation has ever taken in, archived ones included.

2020 and 2021 are the spike, and they are the reason the landscape image became a meme. The intake has since settled around thirty a year. The 2026 row is partial, since the year is not over.

What the maturity levels mean #

There are three active levels and one terminal state. They are not a quality ranking of the code. They describe how much external evidence a project has accumulated, and how much the foundation is willing to stake on it.

The levels are gates, not a schedule, and the data shows how slow the real pace is. Median time from acceptance to incubating is 1.4 years across 79 projects. From incubating to graduated, 2.2 years across 38. End to end, the median project takes 3.0 years to graduate, and the slowest took 7.8.

This is the practical reading for someone choosing a tool. Sandbox means the foundation finds the idea worth hosting, not that anyone runs it at scale. Incubating means other companies already depend on it. Graduated means the project survived an audit and does not belong to a single vendor. The 28 archived projects are the honest part of the record: OpenTracing, Service Mesh Interface, rkt and others were all once the obvious answer.

The projects, by category #

Every active CNCF project, grouped the way the landscape groups them. The level column is the foundation’s, the repository is the one the landscape points at, and the last column is what the thing is for.

App Definition and Development #

Application Definition & Image Build

Continuous Integration & Delivery

Database

Streaming & Messaging

Inference #

Framework

Observability and Analysis #

Chaos Engineering

Continuous Optimization

Feature Flagging

Observability

Orchestration & Management #

API Gateway

Coordination & Service Discovery

Remote Procedure Call

Scheduling & Orchestration

Service Mesh

Service Proxy

Platform #

Certified Kubernetes - Distribution

Certified Kubernetes - Installer

Provisioning #

Automation & Configuration

Container Registry

Key Management

Security & Compliance

Runtime #

Cloud Native Network

Cloud Native Storage

Container Runtime

Serverless #

Installable Platform

Wasm #

Application Frameworks

Orchestration & Management

How the foundation actually works #

The CNCF sits under the Linux Foundation. It does not write the code and it does not direct the projects. What it sells to a project is neutrality, and the services that come attached to it.

Neutral ownership is the substance of the deal. When a project is donated, the trademark, the domain and the repositories move to the foundation. The company that started it keeps its engineers and loses its veto. That is the whole reason a competitor is willing to send a maintainer.

Around that sit the services: cloud and CI credits, independent security audits, design and documentation help, legal support, and the events. KubeCon is the visible one, and it funds a good deal of the rest.

Three bodies matter, and they do different jobs:

• The Technical Oversight Committee, elected, votes projects in, moves them between levels, runs the due diligence and can archive a project. Its meetings and its votes happen in public, in the cncf/toc repository.
• The Technical Advisory Groups do the domain work. There is one for security, one for observability, one for network, one for storage, one for app delivery, one for contributor strategy, and so on. They review projects on the TOC’s behalf, publish whitepapers, and are open to anyone who wants to sit in.
• The Governing Board handles budget and membership. It has no say over which project graduates.

What it does not do is run the projects. Maintainers are not appointed by the foundation, roadmaps are not approved by it, and a company paying for a platinum membership does not thereby get a commit bit. The obligations flow the other way: a project has to document its governance, adopt a code of conduct, publish a security disclosure process, take contributions under a DCO or CLA, and sit an annual review.

Getting in, if you are new here #

The path that works is not the one that looks official. It is roughly this.

Start from something you already run. Contribution follows use. Reading the landscape looking for a project to help is backwards, and it shows in the first pull request.

Do not start with Kubernetes core. It has thousands of contributors, long review queues, and enough process to need its own website. A sandbox or incubating project with four maintainers will notice you within a week, and you will learn the same skills with a shorter feedback loop.

Go to the community meeting before you write anything. Nearly every project has a public weekly or fortnightly call on the CNCF calendar, with an agenda in a document anyone can add to. Two meetings will teach you more about what the project actually needs than a month of reading the roadmap.

Then take the small, unglamorous work. The good first issue and help wanted labels exist, but the more reliable opening is the thing you tripped over yourself: documentation that lied, an error message that explained nothing, a missing example, a bug you can reproduce reliably. Maintainers notice a clean reproduction faster than they notice a refactor.

The ladder is written down. Contributor, reviewer, approver, maintainer. Every project keeps it in its governance file, with the criteria attached. It is a matter of time and demonstrated judgement, not of asking.

There are also programs built for exactly this. LFX Mentorship runs in terms and pays a stipend, with projects posting what they need help with. The CNCF takes part in Google Summer of Code as an umbrella organisation. KubeCon has scholarships, and the New Contributor Workshop is aimed at people who have never opened a pull request against any of this. Attending a TAG meeting costs nothing and is the fastest way to see the shape of a whole domain.

One distinction worth keeping straight: certifications (KCNA, CKA, CKAD, CKS) prove that you can operate the ecosystem, and they are a decent on-ramp to using it. They are not contribution, and no maintainer will read them.

If what you have is a project rather than time, the door is the cncf/sandbox repository. Applications are public, reviewed in batches by the TOC, and the rejected ones are as instructive to read as the accepted ones.

What I would actually pick #

This part is opinion, not data. It is what I would reach for today, based on what I have run and on what the market has quietly converged on. The archived list above is the reason I hedge: plenty of confident recommendations from 2019 are now tombstones.

What I would not rush into: a service mesh, until mTLS or per-request routing is a stated requirement rather than a diagram. Multi-cluster orchestration, until one cluster has actually run out. Backstage, until someone is funded to own the portal, because an abandoned catalogue is worse than none. And the whole AI adjacent shelf, which is where most of the recent sandbox intake landed and where I expect the next round of archives to come from.

The general rule I use: graduated projects for anything on the critical path, incubating where the blast radius is contained, and sandbox only for things I am willing to rip out. That maps almost exactly onto how much of my own time each level has cost me.