Dora NodaOn July 17, 2026, Cloud Native Buildpacks moved to CNCF's Graduated maturity level — the same tier as Kubernetes, Prometheus, and Envoy, reserved for projects the foundation considers stable enough to build a company on. It took eight years to get there: accepted into CNCF in October 2018, promoted to Incubating in November 2020, and now Graduated after six more years of committers, adopters, and a third-party security audit piling up evidence.
If your build pipeline already runs pack build or a buildpacks-based platform, the honest first reaction is: didn't this already work? Google Cloud Run has built on Cloud Native Buildpacks since 2019. Heroku's own buildpack model predates the CNCF spec entirely. A graduation announcement doesn't ship a new feature, and it doesn't fix a bug you were hitting last week. So it's worth being precise about what actually changed on July 17 — and, just as importantly, what a platform team betting its build layer on CNB gets from this milestone that it didn't already have.
What "Graduated" actually required — not a vibe, a checklist
CNCF's three maturity tiers (Sandbox, Incubating, Graduated) aren't marketing labels; each step up requires clearing a specific, published bar, and the project's graduation application shows exactly which boxes Buildpacks had to check:
- Committers from at least two independent organizations, with no single vendor able to unilaterally steer the project. Buildpacks' leadership spans four Technical Oversight Committee members across three organizations — Salesforce, VMware by Broadcom, and Bloomberg — plus eight team leads, a structure the TOC verified wasn't dependent on any one company staying interested.
- A completed, independent third-party security audit, with critical findings resolved before graduation. Buildpacks worked with Quarkslab and the Open Source Technology Improvement Fund (OSTIF) on that audit; the moderate- and low-severity findings that came back were tracked to resolution rather than shipped as known gaps.
- An OpenSSF Best Practices badge, CNCF's baseline for "this project follows documented, auditable security and release practices" rather than ad hoc maintainer judgment call.
- Documented evidence of production adoption at the scale CNCF expects for the top tier — not a handful of hobby projects, but named organizations running it as infrastructure. The application lists Google's Cloud Run (buildpacks-based builds since August 2019), Salesforce's Hyperforce platform (since August 2024), and VMware/Broadcom's Tanzu Buildpacks (since October 2024), alongside Bloomberg as a documented adopter.
- A CNCF Technical Oversight Committee supermajority vote, the final governance gate that graduation applications for every project — Kubernetes, Prometheus, this one — have to clear.
None of that is about whether the pack CLI works correctly. It's an audit of whether the governance around the spec is durable — whether the project would survive one company losing interest, whether its security posture has been checked by someone with no stake in the answer, and whether enough independent, named production users exist that "adoption" isn't a claim you have to take on faith.
What graduation does not change
This is the part worth being blunt about, because it's the trap a graduation announcement makes it easy to fall into: the technical capability was already there. Cloud Native Buildpacks' detect → build → export lifecycle, its API versioning scheme, its stack/builder model — all of that has been stable and running in production for years before July 2026. Google didn't wait for Graduated status to put Cloud Run's build path on it in 2019. Salesforce didn't wait to put Hyperforce on it in 2024. If you're evaluating whether the spec itself is production-ready, graduation isn't new evidence — it's a formalization of evidence that already existed.
So if you're choosing a build layer today and the honest question is "does this actually work at scale," the graduation announcement adds nothing you couldn't already verify by reading the adopter list. What it adds is narrower and, for a platform team, arguably more useful:
| Incubating (pre–July 2026) | Graduated (post–July 2026) | |
|---|---|---|
| Spec stability | Already versioned, already in prod | Unchanged |
| Governance | 2+ org rule enforced, but a newer bar | Same rule, six more years of evidence it held |
| Security posture | Self-reported | Independently audited by Quarkslab/OSTIF, OpenSSF badge earned |
| Bus-factor risk | Plausible, not yet stress-tested at CNCF's top-tier bar | Explicitly verified by TOC vote |
| API change velocity | Normal incubating-project pace | CNCF's expectation is a slower, more conservative pace at Graduated — the project has more to lose by breaking compatibility |
What actually changes for a platform team
Three concrete things shift, and they're organizational and procurement-shaped, not technical:
The governance-risk line item on a build-vs-buy evaluation gets to go from "assumed fine" to "independently verified." If you're a platform engineering team writing an internal RFC for why your git-push pipeline should detect and build with Cloud Native Buildpacks instead of hand-rolled Dockerfile generation, "CNCF Graduated" is now a citable fact rather than a judgment call you're making yourself. That matters more than it sounds like it should, because RFCs get reviewed by people who don't have time to read the buildpacks spec — they read the maturity tier.
Some compliance and procurement checklists literally gate on this. Enterprise vendor-risk questionnaires increasingly ask "is your build/deploy toolchain built on CNCF Graduated or Incubating projects" as a proxy for supply-chain governance maturity. A platform whose build layer was sitting on an Incubating project didn't fail that question, but it required an explanation. Now it doesn't.
The published expectation of API conservatism is a real signal for anyone building automation against the spec. CNCF Graduated projects are expected to change their public interfaces more slowly and more deliberately than Incubating ones — not a formal guarantee, but a real cultural and process expectation the TOC holds projects to. If you've built tooling (CI detection scripts, custom buildpack orders, builder image pipelines) against the pack CLI or the Buildpacks platform API, that's one fewer axis of "will this get out from under me" to worry about.
What doesn't shift: your actual build times, your actual image sizes, your actual CVE-patch cadence. Those were already determined by which buildpacks and base images you picked — Paketo's stacks, for instance, carry their own 48-hour SLA for High/Critical CVE patches independent of CNCF's maturity ladder, and that SLA didn't move on July 17.
If you're not on Cloud Native Buildpacks yet
The more common real-world question isn't "does this change anything for teams already committed to CNB" — it's "does this tip the build-tool decision for teams that aren't." A platform choosing between Cloud Native Buildpacks, a hand-rolled Dockerfile pipeline, or one of the newer zero-config builders like Railpack or Nixpacks is making that call on build speed, image size, and language-detection coverage — none of which graduation touches. Railpack still produces smaller images for some language ecosystems; Dockerfile still gives you full manual control CNB deliberately trades away for zero-config convenience. Graduation doesn't settle any of those trade-offs, and a benchmark from June won't read differently in August because of a governance vote.
What graduation does settle is the longer-horizon question underneath the benchmark: if you standardize your build pipeline on this spec today, will the project still be here, still governed by more than one company, still getting its security posture checked, in three years? That's the question a maturity tier answers and a build-time comparison can't. For a team picking a build layer to run for the next several years — not just the next quarter — that's a real input, even though it's not the one a "which builder is fastest" spreadsheet captures.
Where this lands for a self-hosted, git-push PaaS
bex's own build path today runs the same lifecycle this graduation is about: a git push triggers detect → build → export against Cloud Native Buildpacks, producing an OCI image without asking a tenant to write a Dockerfile. That choice was made on the technical merits of the spec — years before this graduation — and nothing about July 17 changes the pipeline itself.
What it does change is the confidence someone can have citing that choice. "We build on Cloud Native Buildpacks, a CNCF Graduated project with an independent security audit and production use at Google, Salesforce, and Bloomberg" is a materially different sentence in a security review than "we build on a spec from a CNCF project," even though the underlying pipeline hasn't moved an inch. For a platform whose whole pitch is that you can self-host it and still trust the supply chain — no closed SaaS build service, no opaque vendor build farm — that's exactly the kind of governance evidence worth having in writing rather than asserted.
The honest summary: graduation is a maturity label on infrastructure that already worked, applied by a process specifically designed to catch the difference between "worked in practice" and "would keep working if the org backing it changed its mind." For a spec several major platforms — including this one — already bet a build pipeline on, that's a real de-risking event. It's just not a new capability, and treating it as one misses what actually happened on July 17.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, built on the same Cloud Native Buildpacks lineage that just reached CNCF's top maturity tier. Star the repo on GitHub or deploy your first app today.
