Cloud Native Buildpacks graduates in the CNCF

The first time I deleted a Dockerfile and let a buildpack take over, I felt weirdly guilty. Two years of hand-tuned base images, JVM heap flags and multi-stage caches, replaced by one CI action. That first build was slower. Every one after was faster. I have been waiting for the wider ecosystem to say out loud that this pattern is done cooking, and this week it did.

The graduation, in one paragraph

The Cloud Native Computing Foundation announced on August 11 that Cloud Native Buildpacks has reached graduated status. In CNCF terms that puts the project alongside the household names: stable governance, wide production use, and the security posture the foundation wants before it stamps a project as safe to build a stack on. The announcement cites 535 contributors across 164 organizations and more than 20 adopters, with DigitalOcean, GitLab, Google, HashiCorp, Spring and VMware by Broadcom on the list. Bloomberg and Heroku by Salesforce are credited as active maintainers.

What buildpacks actually do on a build agent

A buildpack is a small program that inspects your source tree, decides whether it can build it, and if it can, produces an OCI-compliant image. The announcement calls out automatic detection for Java, Python, Go, Node.js and Ruby. You do not write a Dockerfile. You point the tool at the repo, and it works out that pom.xml means a JVM stack, or package.json means Node, and assembles the image accordingly.

The bits worth naming: intelligent layering, so a code change rebuilds a small slice instead of the whole image. JVM tuning that reads the container's memory limit at boot. SBOM creation as part of the build. And image rebasing, which lets you swap the base OS layer under a running image without a full rebuild. That last one is why security teams like this pattern. When a CVE lands in the base, you rebase, and existing digests stay traceable rather than moving under everyone's feet.

Where the friction goes

The developer-experience story is mostly about what you stop doing. You stop writing multi-stage Dockerfiles. You stop copying the same COPY, apt-get, useradd boilerplate between repos. You stop maintaining a "golden base image" pipeline whose only job is to keep openssl current. The CNCF release cites deployments spanning 500+ applications where teams reduced vulnerability resolution times "from weeks down to hours" by rebasing instead of rebuilding, and that matches what I have heard from platform folks running Paketo in production.

Rough edges I would not paper over

Buildpacks are opinionated, and their opinions leak. Native binaries with unusual link flags fight the detect step. Monorepos with mixed languages need explicit builders or a per-service config. The first cold build on a fresh runner is slower than a Dockerfile because detection walks candidate buildpacks in order. And if you like squeezing the last 30 MB out of an image, you will find the layered output chunkier than a hand-tuned distroless stage. None of this is disqualifying. It is the honest cost of trading Dockerfile control for a source-to-image contract.

How other tools solve the same problem

Source-to-image is a crowded corner, and Cloud Native Buildpacks is one option among several. A short, honest tour:

• Docker with a Dockerfile and BuildKit. Still the default in most CI pipelines. Nothing else gives you the same fine control over layers, stages and cache mounts. If your build genuinely needs that control, stay here.
• ko, for Go services. Compiles a Go binary and layers it into a base image without a builder at all. For a Go-only shop, ko is honestly the better fit than buildpacks: the whole toolchain is one binary and one flag.
• Jib, for JVM services. Google's Maven and Gradle plugin does the JVM half of what buildpacks do, from inside your existing build tool.
• Google Cloud Buildpacks and Heroku Buildpacks. Both implement the Cloud Native Buildpacks spec, so the pattern is portable across clouds. Heroku's is the lineage.
• Nixpacks. Railway's take, similar spirit, different ecosystem. Popular in PaaS-style flows.
• Buddy. A CI/CD platform with a buildpack action alongside Dockerfile, Kaniko and buildx steps in the same pipeline. If you want the CNCF workflow without wiring up pack on a self-hosted runner, buddy.works is one way. If your team already has a mature BuildKit setup on GitHub Actions, staying put is the calmer answer.

A minimal pipeline step, roughly:

- action: "Build with buildpacks"
  type: "BUILDPACKS"
  builder: "paketobuildpacks/builder-jammy-base"
  image_name: "$REGISTRY/myapp:$EXECUTION_ID"
  trigger_time: "ON_EVERY_PUSH"

The resulting image ships with the usual OCI digest of the form sha256:<digest>, and if you turn on SBOM output you get a spec-compliant attestation next to it.

What I am watching next

Whether graduation nudges more CI platforms to ship a maintained buildpack step rather than a pack wrapper users glue on themselves. The DX only really lands when the platform owns the builder cache. I am also watching whether the rebasing story shows up in postmortems the way image scanning did a few years ago. The day a team can honestly say "we rebased 500 images in an afternoon" and mean it is the day this pattern stops being niche.

I am not deleting my Dockerfiles this week. I am, quietly, thinking about which repo to try it on first.