Stage 4 · Provision
Production Containers
Buildpacks
Build images with Cloud Native Buildpacks, pack CLI, builders, build plans, and rebasing.
What Are Buildpacks?
Cloud Native Buildpacks automatically detect your application's language and framework, then produce an optimized container image without a Dockerfile. They handle dependency installation, compilation, and runtime configuration. Buildpacks produce reproducible, compliant images following best practices.
How Buildpacks Work
Buildpacks execute in two phases: detect and build. The detect phase identifies the application type by examining files (package.json, go.mod, pom.xml). The build phase compiles the application and produces layers. Each buildpack contributes layers for dependencies, compiled code, and configuration.
# What buildpacks look for:
# Node.js: package.json
# Go: go.mod
# Java: pom.xml, build.gradle
# Python: requirements.txt, Pipfile
# Ruby: Gemfile
# Buildpacks create:
# - A launch layer (executable)
# - A cache layer (dependencies)
# - A config layer (runtime metadata)Buildpacks analyze your project structure and select the appropriate buildpack. They use heuristics like file existence and content to determine the language and framework.
Using pack CLI
# Install pack
brew install buildpacks/tap/pack # macOS
# Build an image
pack build myapp
# Build with a specific builder
pack build myapp --builder paketobuildpacks/builder-jammy-base:latest
# Build with environment variables
pack build myapp --env NODE_ENV=production
# List available builders
pack builders suggest
# Inspect a builder
pack builder inspect paketobuildpacks/builder-jammy-base:latestpack build detects your application, selects buildpacks, and produces an image. The builder provides the build environment and buildpack selection logic.
Builders
A builder is a container image that includes buildpacks and a build environment. Different builders are optimized for different use cases. Paketo builders are the most commonly used, providing comprehensive language support.
| Builder | Description | Best For |
|---|---|---|
| paketobuildpacks/builder-jammy-base | Ubuntu-based, minimal | Production images |
| paketobuildpacks/builder-jammy-full | Ubuntu-based, full stack | Development |
| heroku/buildpacks:20 | Heroku-compatible | Heroku migration |
| gcr.io/buildpacks/builder | Google buildpacks | GCP workloads |
Build Plans
# Override buildpack versions
pack build myapp \
--buildpack paketobuildpacks/node-engine@1.0.0 \
--buildpack paketobuildpacks/npm@1.0.0
# Use a buildpack.toml configuration
pack build myapp --buildpack ./buildpack.toml
# Skip specific buildpacks
pack build myapp --buildpack !heroku/nodejs-engineBuild plans let you customize which buildpacks run and their configuration. You can pin versions, exclude buildpacks, or add custom buildpacks for specialized needs.
Rebasing
Rebasing is a fast way to update an image's base layers without rebuilding. When a new base image is available, rebasing replaces the base layers while preserving the application layers. This is much faster than a full rebuild.
# Rebase an image to a new base
pack rebase myapp
# Rebase with a specific buildpack image
pack rebase myapp --image myregistry.com/myapp:rebased
# The rebase operation:
# 1. Downloads the new base image layers
# 2. Replaces the old base layers in the image
# 3. Preserves application layers on top
# 4. Pushes the updated imageRebasing is instant compared to a full build. It is useful for security patches — when the base image gets a CVE fix, rebase all dependent images to pick up the patch.
Buildpacks eliminate Dockerfile maintenance. They enforce best practices automatically: non-root users, proper layer ordering, cache optimization. Use them when you want consistent, compliant images without managing Dockerfiles.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.