Every organization that runs containers at scale eventually notices the same thing: hundreds of Dockerfiles, written by hundreds of people, drifting in different directions. One pins a base image, another does not. One runs as root. One still ships a compiler in production. Cloud Native Buildpacks offer a different answer to that sprawl, and their CNCF graduation is a reasonable prompt to evaluate them properly.

The graduation, briefly

The CNCF announced the graduation of Cloud Native Buildpacks on August 11, 2026. The project joined CNCF as a Sandbox project in October 2018, and its lineage goes back further: Heroku open-sourced its original buildpacks in 2012, and Pivotal and Heroku jointly created the cloud native version in January 2018.

Graduation followed a third-party security review by Quarkslab and the Open Source Technology Improvement Fund, an OpenSSF Best Practices badge, and adoption of the CNCF Code of Conduct. The announcement counts 535 contributors across 164 organizations and names adopters including Bloomberg, DigitalOcean, GitLab, Google, HashiCorp, Heroku, Spring, and VMware by Broadcom. It also quotes a large financial-services deployment spanning more than 500 applications where vulnerability resolution dropped from weeks to hours through centralized buildpack patching. That is a project-supplied case study, so treat it as an illustration of the mechanism, not a benchmark you should expect to reproduce.

How buildpacks differ from Dockerfiles

A Dockerfile is an imperative script: you list the steps, and the resulting layers are whatever those steps produce. A buildpack is a detect-and-build program. It inspects your source, decides whether it applies (a Node.js buildpack looks for a package manifest, for example), installs the runtime and dependencies, and assembles an OCI image. The Buildpacks documentation describes several concepts worth knowing:

  • Builder. A bundle of buildpacks plus the base images. A central team maintains it, which the documentation frames as a way to concentrate container build best practices in a specialized team.
  • Run image. The base image for the final application image.
  • Rebase. Swap the base image layers of an existing application image for an updated one without rebuilding the application. This is the mechanism behind the fast patching claim above.
  • SBOM output. Builds can emit a software bill of materials describing the components in the image.
  • Reproducibility. The same source built with the same builder is intended to produce the same image.
  • pack CLI. The main local tool, which also integrates into CI systems.

The difference in one line: Dockerfiles give each team total control and total responsibility; buildpacks give a platform team control and take some from application teams.

Where buildpacks win

Fleet-wide patching

If a base OS package or language runtime has a vulnerability, the Dockerfile world requires every owning team to notice, rebuild, test, and redeploy. With buildpacks, the platform team updates the builder or run image, and applications can be rebased. Whether rebase is safe depends on ABI compatibility between old and new base layers, so the mechanism suits OS-level patches well and language-runtime changes less so. Test your own applications before trusting it broadly.

Consistency and policy

Because the platform team owns the builder, “non-root by default,” approved base images, and standard labels are properties of the build, not code-review suggestions. Auditing becomes easier when there are ten builder versions in circulation instead of ten thousand hand-written scripts.

Developer experience for common stacks

For a typical web service in a mainstream language, a developer can produce a working image without knowing container internals. That lowers the barrier for teams whose expertise is in application code.

Where Dockerfiles still win

  • Unusual build requirements. Custom system libraries, multi-stage builds that compile native code, or unusual base images are often easier to express directly.
  • Fine-grained layer and size control. Highly tuned minimal images, such as a static binary on an empty base, are a Dockerfile strength.
  • Existing investment. Thousands of working, understood Dockerfiles are an asset. Migrating them for its own sake is a poor use of engineering time.
  • Ecosystem familiarity. Nearly every engineer can read a Dockerfile. Buildpack debugging, when detection or a layer fails, requires understanding builder internals.

An evaluation plan

Run a bounded pilot instead of a policy change.

  1. Pick two or three representative services, one that is simple and one that is awkward, in your most common language.
  2. Build them with a public builder using pack, and compare image size, build time, and cache behavior against your current Dockerfile output.
  3. Check runtime behavior, including user, filesystem permissions, and startup, since defaults differ.
  4. Examine the SBOM and provenance output and see whether it feeds your existing vulnerability scanning.
  5. Test a rebase after applying a base image update, then run your integration tests.
  6. Decide who owns the builder. This is the real commitment. A builder is a product with a maintenance schedule, and it needs an owner and a release process.
  7. Wire it into CI and measure pipeline changes.

If the pilot succeeds, adopt buildpacks for the well-trodden paths and keep Dockerfiles for exceptions. Most organizations end up with both, and that is a sensible outcome. Standardizing on one path for 80 percent of services and allowing a documented escape hatch for the rest beats forcing uniformity.

The takeaway

Graduation signals that the project’s governance, security review, and adoption are established. It does not prove buildpacks fit your workloads. Their value is greatest where you have many similar services, a platform team willing to own a builder, and a patching process that currently depends on application teams acting on tickets. If that describes you, a pilot is inexpensive and the potential payoff, centralized and fast base-layer patching, is concrete. If your fleet is a small number of heavily customized images, your Dockerfiles are probably fine.