mrvitej.in

DevOps · CNCF daily

Buildpacks: Container Images from Source Without a Dockerfile

CNCF Graduated. Turns application source code into OCI images through a standard, layered, rebasable build process, with SBOMs and no Dockerfile to maintain.

6 min read

CNCF Graduated

  • Buildpacks
  • Paketo
  • kpack
  • Tekton
  • Spring Boot
CNCF project page

Cloud Native Buildpacks transform application source code into OCI container images without a Dockerfile. A builder detects the language, assembles the dependencies, compiles the code and exports an image whose layers are organised so that the operating system, the language runtime and the application can each be updated independently. The project addresses a familiar platform problem: hundreds of hand-written Dockerfiles drift apart, carry inconsistent base images and are slow to patch when a CVE lands. Pivotal and Heroku started the project in January 2018, building on the buildpack model Heroku introduced in 2011, and it joined the CNCF as a Sandbox project in October 2018. It moved to Incubating in November 2020 and graduated in 2026; the CNCF announced the graduation on August 11, 2026.

CNCF daily · Sprint 2, day 1 · Application Definition & Image Build

At a glance
Category Application Definition & Image Build
CNCF status Graduated. Accepted October 3, 2018 (Sandbox); Incubating November 18, 2020; graduation announced August 11, 2026 (the CNCF Landscape records July 17, 2026)
Written in Go (the pack CLI and the lifecycle)
License Apache 2.0
Core pieces pack CLI, lifecycle, builders, buildpacks, run images
Output OCI images with an SBOM, built without a Docker daemon when the lifecycle runs in a container
Main distributions Paketo Buildpacks, Google Cloud Buildpacks, Heroku Cloud Native Buildpacks

Architecture

flowchart TB
  SRC[Application source] --> PLAT[Platform<br/>pack, kpack, Tekton, Spring Boot plugin]
  PLAT --> BLD[Builder image<br/>lifecycle, buildpacks, build image]
  BLD --> DET[Detect<br/>choose buildpacks]
  DET --> ANA[Analyze and restore<br/>reuse cached layers]
  ANA --> BUILD[Build<br/>compile, fetch dependencies]
  BUILD --> EXP[Export<br/>assemble layers on the run image]
  RUN[Run image<br/>OS base layers] --> EXP
  EXP --> REG[OCI registry<br/>image, SBOM, metadata]
  REG --> REB[Rebase<br/>swap run image layers only]
Component Responsibility
Platform Anything that drives a build: pack on a laptop, kpack or Tekton in a cluster, the Spring Boot build plugins, or a cloud service.
Builder An image bundling the lifecycle, an ordered list of buildpacks and a build-time base image. Platforms select one per application.
Lifecycle Runs the phases: detect, analyze, restore, build and export. It is the reference implementation of the Platform API.
Buildpack A small unit that detects whether it applies and then contributes layers, such as a JDK, a Node.js runtime or compiled dependencies.
Run image The minimal operating system layers the final application image sits on. It is separate from the build image.
Rebase Replaces the run image layers of an existing image by editing the registry manifest, with no rebuild.

Design principle. Buildpacks move the knowledge of how to build an image from each application repository into a shared, versioned, centrally maintained component. Because the OS layer is separated from the application layers, security patches become a metadata operation across a whole fleet rather than hundreds of rebuilds.

Production reference design

A common pattern on EKS, GKE, AKS or on-premises: a platform team publishes approved builders, and CI or an in-cluster controller builds every service the same way.

  1. Build locally to confirm the result using a Paketo builder: 
    pack build registry.example.com/apps/payments-api:2.8.1 \
  --builder paketobuildpacks/builder-jammy-base \
  --env BP_JVM_VERSION=21 --publish
  2. Pin the builder in the repository with a project.toml, so every pipeline uses the same one: 
    [_]
schema-version = "0.2"

[io.buildpacks]
builder = "paketobuildpacks/builder-jammy-base"

[[io.buildpacks.build.env]]
name = "BP_JVM_VERSION"
value = "21"
  3. Run builds in the cluster with kpack (a Kubernetes controller that rebuilds images when source, buildpacks or the stack change) or with the Tekton buildpacks task, so no developer machine or privileged Docker socket is involved.
  4. Mirror builders and buildpacks into the organisation’s own registry, and sign images and SBOMs before they are promoted.
  5. Patch the OS layer fleet-wide when a base image CVE is fixed: 
    pack rebase registry.example.com/apps/payments-api:2.8.1 --publish

Typical uses are internal developer platforms, Spring Boot services (./mvnw spring-boot:build-image), and standardised image pipelines in regulated environments where every image must carry a bill of materials.

Operational considerations

  • Caching and speed: Layer and build caches make repeat builds fast, but they must persist between runs. In CI, publish the cache image or use a persistent volume, otherwise every build starts cold.
  • Trust: Builders run third-party code at build time. Use pinned digests, mirror approved builders, and review which buildpacks a builder contains.
  • Rootless builds: The lifecycle can run unprivileged in a container (kpack and Tekton do this). pack itself usually needs a container runtime on the build host.
  • Reproducibility: Pin builder and buildpack versions. Floating tags change what a “same source” build produces.
  • Fit: Buildpacks suit conventional applications in supported languages. Unusual system dependencies or custom packaging may still need a Dockerfile, or a custom buildpack.

Adoption

The CNCF graduation announcement names DigitalOcean, GitLab, Google, HashiCorp, Spring and VMware by Broadcom among the adopters, and states that the adopter base exceeds 20 organisations. Bloomberg and Heroku (Salesforce) are named as active contributors. The Spring Boot build tooling has supported Cloud Native Buildpacks since early 2020. The announcement reports 535 contributors across 164 organisations.

Alternatives

Solution Model Best suited to
Dockerfile with BuildKit Hand-written, full control Custom or unusual images
Jib Java-specific, daemonless Maven and Gradle Java projects
ko Go-specific, daemonless Go services
Source-to-Image (S2I) Builder images, OpenShift-centred OpenShift environments
Nixpacks and similar Auto-detect from source Hosted platforms and quick deployments

Strengths and limitations

Strengths Limitations
No Dockerfile to write or maintain Less control than a Dockerfile
Consistent, centrally patched images Builders and buildpacks are a supply chain to govern
Rebase patches the OS layer without a rebuild Language support depends on the chosen distribution
SBOM produced with the image Cold builds can be slower without a persisted cache
Works in clusters through kpack and Tekton Custom buildpacks need specialist knowledge

Recommendation

Adopt for platform teams that run many services in mainstream languages and want uniform, rapidly patchable images. Start with a Paketo or Google builder, pin it by digest, run builds through kpack or Tekton, and add image signing before promotion. Keep a Dockerfile path for the few applications that do not fit.

References: CNCF project page · Buildpacks documentation · Project history · CNCF graduation announcement · pack on GitHub · Paketo Buildpacks

Spotted something wrong or out of date?Suggest a correction. I review every suggestion before changing the page.