Introduction to Cloud Native Buildpacks, explaining buildpacks, builders, and using Pack to produce OCI images from application source
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 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
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 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
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.
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.
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:
Copy
pack build sample-app --builder my-builder
High-level flow when this command runs:
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 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.
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.
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.
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.
