A buildpack is software that transforms application source code into runnable artifacts
by analyzing the code and determining the best way to build it.
The lifecycle is a binary responsible for orchestrating buildpacks.
A buildpack group is a list of individual buildpacks that are designed to work together to build an application.
The concept of targets is used to identify compatibility between buildpacks and base images.
Learn strategies for caching layers at build-time for future re-use.
Dependency layers are semantically meaningful layers that are contributed by one or more buildpacks during the build phase, one for each dependency.
A buildpack package refers to the process of packaging buildpacks for distribution as OCI images or OCI-compatible tar files.
A component buildpack is a buildpack containing /bin/detect and /bin/build executables and that implements the Buildpack Interface.
A composite buildpack, also sometimes called a “meta buildpack”,
is a buildpack that does not contain any ./bin/detect or ./bin/build binaries,
but instead references other buildpacks in its buildpack.toml via the [[order]] array.
This is useful for composing more complex detection strategies.
An image extension is software that generates Dockerfiles that can be used to extend base images for buildpacks builds.
A build plan is a toml file that is the output of the detect phase, in which each component buildpack or image extension may express the dependencies it requires and the dependencies it provides.