Dora NodaOn August 11, 2026, Cloud Native Buildpacks became a graduated CNCF project — eight years after entering the Sandbox in October 2018, via Incubating in November 2020, joining Kubernetes and Envoy in the foundation's top maturity tier. At graduation the project counted 535 contributors across 164 organizations and more than 20 production adopters, including Bloomberg, DigitalOcean, GitLab, Google, HashiCorp, Heroku by Salesforce, Spring, and VMware by Broadcom.
Here is the verdict for anyone running a platform that turns git pushes into running containers: graduation is a governance bet, not a speed bet. It certifies that the builder your whole fleet depends on won't follow one vendor's roadmap into maintenance mode — but it guarantees nothing about build minutes or image megabytes. Those you still have to earn, with layer-cache locality on your own build nodes.
If that sounds abstract, the cautionary tale already happened. Railway put Nixpacks — the open-source builder that powers Coolify and Dokploy defaults to this day — into maintenance mode and moved its own default to Railpack, a single-vendor successor. Every fleet that built its deploy pipeline on Nixpacks auto-detection woke up to a builder whose roadmap now belongs to someone else's migration plan. That is exactly the failure mode a Graduated stamp is designed to price out.
Eight years in three acts
Buildpacks started at Heroku in 2011 as the mechanism behind git push heroku main: detect the language, install dependencies, compile, and produce a runnable slug — no Dockerfile required. Heroku open-sourced the model in 2012, and Cloud Foundry and Google App Engine carried it forward. "When Heroku open-sourced the original Buildpacks project in 2012, our goal was to simplify application packaging across any ecosystem," said Terence Lee, co-founder and steering committee member, in the graduation announcement.
Act two began in October 2018, when the Cloud Native Buildpacks project — a ground-up rewrite around OCI images instead of slugs — entered the CNCF Sandbox. The rewrite mattered: classic buildpacks produced platform-specific output, while CNB produces standard OCI container images through a well-defined lifecycle (detect, analyze, build, export) that any platform can implement. Incubating status followed in November 2020, once real production users existed.
Act three is the graduation gauntlet, and it is worth knowing what the stamp actually required — because "Graduated" is a checklist, not a vibe. The TOC due-diligence process interviewed four production adopters (Google, Salesforce, and two more) and confirmed meaningful-scale production use with Buildpacks core to container build workflows. The project had to demonstrate a documented security process, a diverse committer base, and vendor-neutral governance. That last one bit: the graduation RFC record notes that two of the three active TOC members were employed by Salesforce/Heroku, and addressing single-vendor representation concerns was an explicit part of the graduation journey. A stamp that forces that conversation in public is doing its job.
Note the symmetry: Heroku invented buildpacks, and Heroku's new Fir stack now supports Cloud Native Buildpacks natively — CNBs replace traditional buildpacks there with standardized, composable build workflows. The idea went from one vendor's deploy magic to a cross-vendor standard and back into the vendor that started it, this time as the standard.
What the Graduated stamp actually certifies
Strip away the ceremony and graduation certifies three things a platform team can rely on:
1. A security process, not just secure code. Graduated projects must show documented vulnerability handling and a completed security review. For a component that literally assembles every container you run — fetching toolchains, compiling code, layering base images — the review trail matters more than any single audit result. As CNCF CTO Chris Aniszczyk put it in the announcement, graduation recognizes the operational consistency needed "to manage and secure modern software supply chains."
2. Production adoption at meaningful scale. Four interviewed adopters running Buildpacks as core build infrastructure, plus a public adopter list north of twenty names across finance, SaaS, and infrastructure vendors. This is the difference between "popular on GitHub" and "load-bearing at companies with compliance departments."
3. Governance that survives any single employer. The diverse-contributor requirement (535 people, 164 organizations) plus the TOC-independence scrutiny mean no one company's reorg, pivot, or acquisition quietly redirects the project. The roadmap belongs to a steering process, not a product manager.
That third point is the whole ballgame for a build step — and the next section is the receipt for why.
The cautionary tale: what happens when your builder follows one vendor
Nixpacks was the obvious choice for a generation of self-hosted PaaS builders: auto-detect the stack, emit an OCI image, no Dockerfile, generous language coverage. Coolify and Dokploy both default to it. Then Railway — Nixpacks' primary steward — put it in maintenance mode and made Railpack, its Go-and-BuildKit successor, the default for new services. Existing Nixpacks services keep working, but the project's future is fixes, not features.
Railpack itself looks technically strong: community-reported figures put Railpack images around 38% smaller for Node and up to 77% smaller for Python versus Nixpacks, with faster cold builds. Coolify shipped Railpack support as a build pack in v4.1.0 (May 2026). But note what the migration actually asks of you: trade a community builder in maintenance mode for a faster builder that carries a beta designation and belongs to one vendor's roadmap. If Railway's priorities shift again, you move again.
This is not a criticism of Railway — vendors are allowed to have roadmaps. It is the structural argument for CNB in one paragraph: a fleet's build step is the worst place for single-vendor risk, because every application on the platform inherits the builder's fate simultaneously. When your builder changes direction, you don't migrate one service, you migrate the factory. Graduation doesn't make CNB faster or smaller. It makes the factory's ownership boring — and boring ownership is the feature.
What graduation does NOT buy you: speed and size
Honesty requires the other half of the ledger. No CNCF tier graduation ever made a build faster. Here is the comparison as it stands, with each builder's genuine strengths left in:
| Dimension | Cloud Native Buildpacks | Plain Dockerfile | Nixpacks | Railpack |
|---|---|---|---|---|
| Image size | Good (tiny run images via Paketo) but builder-dependent | Best possible, if you hand-tune multi-stage builds | Larger baseline | Smallest auto-detected (38–77% under Nixpacks per community reports) |
| Cold build speed | Mid-pack; detection + lifecycle phases cost minutes | Fast with warm layer cache; slow and brittle without one | Fast cold builds | Fastest cold builds of the auto-detectors |
| Rebuild speed with warm cache | Excellent — only changed layers rebuild | Excellent — if the Dockerfile author ordered layers well | Good | Good |
| Base-image patch without app rebuild | Yes — rebasing swaps the OS layer under unchanged app layers | No — full rebuild | No — full rebuild | No — full rebuild |
| Maintenance risk | Lowest — graduated, multi-vendor governance | None — it's your file, your problem | Maintenance mode | Single vendor, beta |
| Dockerfile required | No | Yes | No | No |
Two CNB mechanics deserve unpacking because they are the actual operational payoff:
Rebasing is the killer feature Dockerfiles can't express. A CNB image stacks an OS/run layer under application layers with a recorded contract between them. When a CVE lands in the base image, the platform re-bases: it swaps the patched OS layer underneath the existing, untouched application layers. No dependency reinstall, no recompile, no waiting on the app's test suite to green-light a rebuild — every service on the fleet gets the patched base on its next build. For a platform patching dozens of tenant apps against the same base-image CVE, that is the difference between an afternoon and a fire drill.
Layer caching is where builds get fast — but only if the operator does their part. CNB's analyze phase inspects the previously built image and reuses every unchanged layer (JDK, dependency bundles, build caches). Paketo's own docs show JDK and Maven layers surviving untouched across rebuilds.
The catch: cache hits require cache locality. Layers live where the build ran, or in a registry the builder can reach quickly. A fleet that schedules each build on a random cold node with an empty local cache and a far-away registry will get slow builds out of the world's most graduated builder. Graduation certifies the mechanism; the hit rate is your runbook's job — pin builds to warm nodes or a shared registry cache, and measure it.
What this means if you run your own fleet
Three concrete takeaways for a self-hosted PaaS on owned machines:
1. Decouple the builder from any vendor's roadmap. If your deploy path is "push code, platform builds image," that builder is load-bearing for every tenant. A graduated, multi-vendor project is the only sane foundation for it — the Nixpacks episode is what the alternative costs, paid all at once on someone else's schedule.
2. Plan patching around rebasing, not rebuilding. With CNB, base-image CVE response becomes a platform operation (ship the new run image, let tenants' next builds rebase onto it) instead of N coordinated app rebuilds. Design the fleet's security runbook around that primitive from day one.
3. Treat build-cache locality as a scheduling problem. Fast CNB rebuilds need warm caches. That means build-node affinity or a fast shared layer cache, monitored hit rates, and treating a cold-cache build storm (Monday morning, everyone pushes at once) as a capacity event. The builder gives you the cache protocol; the fleet gives it a home.
The broader arc is worth naming: Heroku proved in 2011 that developers shouldn't hand-write deployment packaging. Fourteen years later, the model for doing it — detect the stack, build reproducibly, patch the base without touching the app — is a graduated open standard with 164 organizations behind it. Betting a fleet's build step on that is no longer the adventurous choice. Betting it on one vendor's builder is.
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.
