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:Documentation Index
Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
Use this file to discover all available pages before exploring further.
- 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.
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:| Responsibility | Purpose | Example |
|---|---|---|
| Detection | Determine whether this buildpack should run for the current source | Look for package.json (Node), requirements.txt or pyproject.toml (Python) |
| Runtime install | Install language runtime or system tools needed at runtime | Install Python, Node.js, or JVM |
| Dependency install | Install application dependencies | pip install -r requirements.txt, npm install |
| Build / compile | Run build or compilation steps | Transpile, compile, or optimize static assets |
| Layer production | Produce filesystem layers to be added to the final image | Cache dependencies, application code, and build artifacts |
| Entrypoint configuration | Configure the container start command | Set CMD/ENTRYPOINT or runtime start script |
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.

Builders
A builder packages an ordered list of buildpacks together with two base images:| Builder Component | Role | Notes |
|---|---|---|
| Ordered buildpacks | Determines which buildpacks are considered and their precedence | Order matters — some builders include multiple buildpacks to support polyglot apps |
| Build image | Environment where buildpack lifecycle scripts run and create layers | Contains compilers, package managers, and tools used during build |
| Run image | Minimal base image used for the final application image | Receives the layers produced during build; optimized for runtime size |

- 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 namedmy-builder that includes buildpacks such as Node.js, Python, Java, and Ruby, you can build a Python application in the current directory with:
- Pack pulls the builder image and prepares the build environment using the builder’s build image.
- Pack loads the builder’s ordered list of buildpacks.
- For each buildpack in order, Pack executes the buildpack
detectscript:- If
detectfails, Pack moves to the next buildpack. - If
detectsucceeds, 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 forrequirements.txt,pyproject.toml, or other Python-specific indicators.
- If
- The selected buildpack(s) run their
buildscripts inside the build image. Build scripts typically:- Install the runtime (for example, Python),
- Install application dependencies (for example,
pip installfromrequirements.txt), - Produce layers for the final image and set the container entrypoint/start command.
- 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.
- Official Buildpacks: https://buildpacks.io/
- Pack CLI documentation: https://buildpacks.io/docs/tools/pack/
- Open Container Initiative (OCI): https://opencontainers.org/
- Kubernetes documentation (concepts & images): https://kubernetes.io/docs/