Skip to content

Adoption & Ecosystem

Who uses it

Each organisation below is cited. Adopters without a public source are omitted.

OrganisationUse caseSource
Heroku (Salesforce)Next-generation "Fir" platform adopts CNB by default for all apps; Heroku funds a dedicated maintainer team.Heroku Fir
DigitalOceanApp Platform builds with CNB when no Dockerfile is present, detecting the language and building with buildpacks.DigitalOcean docs
Greenhouse, Salesforce, VMwareNamed as production users at the time of CNCF Incubation.CNCF

Adoption signals

Measured on buildpacks/pack via the GitHub API on 2026-06-24.

  • Stars: 2,939
  • Forks: 345
  • Open issues: 169
  • Contributors: about 164 (including anonymous)
  • Repository created: 2018-06-25

The CNCF Incubation approval (2020-11-18) cited more than fifteen production users and committers from multiple organisations.

Ecosystem

  • Reference projects: buildpacks/lifecycle (build engine), buildpacks/spec (Buildpack, Platform, Distribution, and Image Extension APIs), and buildpacks/rfcs (design process).
  • Buildpack providers: Paketo Buildpacks, Heroku CNB, and Google Cloud buildpacks. Builders and stacks ship as images such as paketobuildpacks/builder-jammy-base.
  • Kubernetes integration: kpack drives the CNB lifecycle through CRDs; there are Tekton (buildpacks/tekton-integration) and GitHub Actions (buildpacks/github-actions) integrations.
  • Platform integration: Heroku Fir, DigitalOcean App Platform, and Google Cloud.

Alternatives

AlternativeDiffers by
Dockerfile + BuildKitMost general, but you write base-image patching, layer optimisation, and SBOM yourself. CNB has buildpacks do detection and dependency resolution, and can swap the base via rebase with no Dockerfile.
Google JibJVM-only and needs no Docker daemon. CNB is multi-language over a shared builder and stack contract.
koGo-only, very fast. CNB is language-agnostic.
kanikoBuilds a Dockerfile in-cluster without a daemon. CNB writes no Dockerfile; image extension uses kaniko internally as a separate concern.
OpenShift Source-to-ImageSimilar source-to-image idea, but Red Hat and OpenShift oriented. CNB is broader on OCI standards, rebase, and a distributed buildpack ecosystem.
nixpacks (Railway)Similar auto-detect UX but Nix-based and not the CNB specification.

The core distinction is a vendor-neutral platform-to-buildpack contract plus OCI layer rebase: an OS patch lands across every app by rebasing the run image, and one builder handles many languages without a Dockerfile.

Sources

  1. TOC Approves Cloud Native Buildpacks from Sandbox to Incubation (CNCF)
  2. Planting New Platform Roots in Cloud Native with Fir (Heroku)
  3. How Maintaining Cloud Native Buildpacks Powers Platforms Like Heroku
  4. App Platform Buildpack References (DigitalOcean)
  5. Getting Started / How to Use Paketo Builders (Paketo Buildpacks)
  6. buildpacks/pack repository