採用とエコシステム

誰が使っているか

以下の組織はすべて出典付きだ。公開出典のない採用例は省く。

組織	ユースケース	出典
Heroku (Salesforce)	次世代基盤 "Fir" が CNB を全アプリでデフォルト採用。Heroku は専任メンテナチームに投資。	Heroku Fir
DigitalOcean	App Platform は Dockerfile が無いとき CNB でビルドし、言語を検出して buildpack でビルドする。	DigitalOcean docs
Greenhouse, Salesforce, VMware	CNCF Incubation 時点の本番ユーザとして明記。	CNCF

buildpacks/pack で GitHub API により 2026-06-24 に計測。

CNCF Incubation 承認 (2020-11-18) は 15 を超える本番ユーザと複数組織からの committer を挙げている。

参照プロジェクト: buildpacks/lifecycle (ビルドエンジン)、buildpacks/spec (Buildpack / Platform / Distribution / Image Extension API)、buildpacks/rfcs (設計プロセス)。
buildpack 提供元: Paketo Buildpacks、Heroku CNB、Google Cloud buildpacks。builder / stack は paketobuildpacks/builder-jammy-base 等のイメージとして配布される。
Kubernetes 連携: kpack が CRD で CNB lifecycle を駆動。Tekton 連携 (buildpacks/tekton-integration) と GitHub Actions 連携 (buildpacks/github-actions) がある。
プラットフォーム統合: Heroku Fir、DigitalOcean App Platform、Google Cloud。

代替	本質的な差
Dockerfile + BuildKit	最も汎用だが、ベースイメージのパッチ・レイヤ最適化・SBOM を自前で書く。CNB は buildpack が検出と依存解決を担い、rebase で Dockerfile なしにベースを差し替えられる。
Google Jib	JVM 専用で Docker デーモン不要。CNB は共有 builder / stack 契約で多言語を扱う。
ko	Go 専用で非常に高速。CNB は言語非依存。
kaniko	Dockerfile をクラスタ内でデーモンレスにビルド。CNB は Dockerfile を書かない。image extension が内部で kaniko を使うのは別話。
OpenShift Source-to-Image	思想は近いが Red Hat / OpenShift 寄り。CNB は OCI 標準・rebase・分散 buildpack エコシステムの面で広い。
nixpacks (Railway)	自動検出の UX は近いが Nix ベースで CNB 仕様ではない。

核心の差は、ベンダ中立な platform-to-buildpack 契約と OCI レイヤ rebase だ。OS パッチは run イメージを rebase するだけで全アプリに反映でき、単一 builder で Dockerfile を書かずに多言語を扱える。