Buildpacks

Turn application source code into production-ready OCI images without writing a Dockerfile.

• Category: App Definition & GitOps
• CNCF maturity: Incubating
• Language: Go
• License: Apache-2.0
• Repository: buildpacks/pack
• Documented at commit: 2df3b8c (v0.40.7)

What it is

Cloud Native Buildpacks (CNB) is a specification and a set of tools that transform source code into a runnable OCI container image. You point a CLI at an application directory, and it detects the language, fetches dependencies, and produces an image, with no Dockerfile involved.

The ecosystem has three layers. The pack CLI in this repository is a developer-facing platform implementation. It does not build images itself. It starts a builder image and the lifecycle binaries as containers and drives the detect, analyze, restore, build, and export phases. The actual build logic lives in language-specific buildpacks, and the reference build engine lives in a separate repository, buildpacks/lifecycle.

CNB exists to unify a buildpack ecosystem that had fragmented across Heroku, Cloud Foundry, Google App Engine, and others. The standard defines a vendor-neutral platform-to-buildpack contract on top of the OCI image format, so the same buildpack runs anywhere and a base image can be swapped through layer rebase.

When to use it

• You want repeatable container images from source without maintaining a Dockerfile per service.
• You operate many services in several languages and want one builder to cover them.
• You need to patch the OS layer across a fleet by rebasing the run image instead of rebuilding every app.
• It is a weaker fit when you need fine-grained control of every image layer, in which case a hand-written Dockerfile with BuildKit is more direct.
• It is a weaker fit for a single-language shop already served by a focused tool such as Jib (JVM) or ko (Go).

In this deep-dive

• History: origin, milestones, and why it exists.
• Architecture: components and how a build flows.
• Adoption & Ecosystem: who runs it and what surrounds it.
• Internals: the code paths that matter, read from source.
• Getting Started: install and a first working setup.

Sources

1. TOC Approves Cloud Native Buildpacks from Sandbox to Incubation (CNCF)
2. Cloud Native Buildpacks site
3. Buildpacks Go Cloud Native, Turning Source Code into Docker Images (Heroku)
4. Standardizing Heroku Buildpacks with CNCF (Salesforce Engineering)
5. Planting New Platform Roots in Cloud Native with Fir (Heroku)
6. How Maintaining Cloud Native Buildpacks Powers Platforms Like Heroku
7. App Platform Buildpack References (DigitalOcean)
8. Getting Started / How to Use Paketo Builders (Paketo Buildpacks)
9. buildpacks/pack repository
10. buildpacks/lifecycle repository
11. buildpacks/spec repository
12. Basic App tutorial (buildpacks.io docs)
13. buildpacks/rfcs repository