Skip to main content
In this lesson we cover Cloud Native Buildpacks: what they are, the components in the buildpack ecosystem, how they work together, and how to use the Pack CLI to produce OCI-compliant images directly from application source code. At a high level there are two primary components:
  • Buildpacks — modular programs that detect, compile, and package source code into an OCI-compliant image.
  • Builders — packaged images that bundle buildpacks with metadata, a build image, and a run image to automate choosing and running the correct buildpacks.
Below we explain each component, show how Pack orchestrates them, and provide the typical build flow used to create an image.

​
Buildpacks

Buildpacks are responsible for detecting whether they apply to a codebase, performing build-time work, and producing the layers and configuration that become part of the final OCI image. Typical responsibilities include setting environment variables, installing runtimes and dependencies, running build or compilation steps, and configuring the application entrypoint. Responsibilities of a buildpack: Buildpacks implement a small lifecycle (commonly including detect and build scripts). The detect phase decides applicability by inspecting the source tree (language files, config files, or other indicators). If detect succeeds, the build phase runs and creates the layers and configuration for the final image.
A slide titled "Components - Buildpacks" showing a Buildpacks logo on the left and a diagram on the right where Source Code is converted into an OCI-compliant Image. The slide includes a small "© Copyright KodeKloud" notice at the bottom left.

​
Builders

A builder packages an ordered list of buildpacks together with two base images: Think of a builder as a pre-configured, shareable build environment. Developers point Pack at a builder, and the builder (together with Pack) decides which buildpack(s) to run for the provided source.
A slide titled "Components - Builder" showing a developer icon with a speech bubble reading "What Buildpack do I use?". Below are four buildpack option cards illustrated with logos for Node.js, Go, Python, and Ruby.
Key points about builders:
  • The build image provides the ephemeral environment to run buildpack logic (install tools, compile code, produce layers).
  • The run image is a small runtime base that receives the built layers to produce the final application image.
  • Builders are distributed as container images and can be pushed to registries so teams can standardize and share build environments.

​
How Pack and a Builder create an image

When you run Pack with a builder, Pack orchestrates the builder lifecycle to produce an OCI image. For example, given a builder named my-builder that includes buildpacks such as Node.js, Python, Java, and Ruby, you can build a Python application in the current directory with:
High-level flow when this command runs:
  1. Pack pulls the builder image and prepares the build environment using the builder’s build image.
  2. Pack loads the builder’s ordered list of buildpacks.
  3. For each buildpack in order, Pack executes the buildpack detect script:
    • If detect fails, Pack moves to the next buildpack.
    • If detect succeeds, that buildpack is selected (or contributes to the build depending on the builder composition).
    • Example detect checks: Node buildpacks check for package.json; Python buildpacks check for requirements.txt, pyproject.toml, or other Python-specific indicators.
  4. The selected buildpack(s) run their build scripts inside the build image. Build scripts typically:
    • Install the runtime (for example, Python),
    • Install application dependencies (for example, pip install from requirements.txt),
    • Produce layers for the final image and set the container entrypoint/start command.
  5. Pack assembles the final OCI image by combining the builder’s run image with the produced layers, then tags the image (e.g., sample-app).
Detect logic varies by buildpack and builder. For Python, modern buildpacks commonly detect pyproject.toml or requirements.txt; always consult the specific buildpack’s documentation for exact detection rules.

​
Summary

  • Buildpacks encapsulate the logic to transform source code into OCI images through detect and build lifecycle phases.
  • Builders bundle ordered buildpacks plus build and run images so developers can build without selecting individual buildpacks manually.
  • Pack invokes the builder lifecycle: it runs detect(s), executes build(s) inside the build image, and constructs the final image using the run image plus buildpack-produced layers.
  • Builders are distributable container images, enabling teams to standardize and share build environments.
Links and References

Watch Video