Decoding CNCF Tools [Part 2]: Is this the End of Dockerfiles?

What is BuildPacks?

Buildpacks is a technology that converts the application code into images (OCI-compliant container images). They analyze the source code, detect dependencies, and package everything into efficient and secure images.

What is OCI Standard Image?

It is the image that follows the OCI (Open Container Initiative) standard with the standards set for the packaging, distributing, and running container images across the different container runtimes like Docker, contained, CRI-O, Podman, etc.

Images complying with the OCI standards should contain an Image Manifest, Image Configuration, and Image Layers.

How does BuildPack detect the tech stack underneath?

Each build pack has a detect script that checks for the specific files or configurations in the source code.

When you run the pack build, the lifecycle execution runs the detect phase (parallel checks for the detection file criteria) and if a match is found then the corresponding buildpack is selected and used for building the images.

If the detection fails then the build process stops with an error and to resolve this we can explicitly specify the buildpack

pack build my-app --buildpack gcr.io/paketo-buildpacks/python

Why not replace DockerFile with BuildPacks !?

No, we cannot, Buildpacks automate and standardize container image creation, they don’t fully replace Dockerfiles in every scenario.

However, for many use cases, Buildpacks can be a better alternative to Dockerfiles.

• Wanting the Automated Builds & Best Practices Built In

• Needing the Secured patched base image without manual updates.

Buildpacks can be avoided for the following scenarios where

• Requires full control over image creation

• Custom OS Packages are needed.

• Hand Optimizing of Image layers is expected.

No, but Buildpacks will replace Dockerfiles for many common cases.
In enterprise and cloud-native environments, Buildpacks are the future.
In custom DevOps workflows, Dockerfiles remain relevant.

Example in Action!

Prerequisites

• AWS Account

• Inbound Rules: Open Port 8080

• Docker Installation

Installing Packs

It's a CLI Tool maintained by the CNB Project to support the use of BuilPacks!
Currently, we are moving with the Linux Ubuntu Installation

sudo add-apt-repository ppa:cncf-buildpacks/pack-cli
sudo apt-get update
sudo apt-get install pack-cli

pack --version

Creating a Sample NodeJs Application

# Create my-python-app dir
mkdir node-app && cd node-app

# Initialize NodeJs App
npm init -y

# Install Express
npm install express

# Create the server.js
const express = require("express");
const app = express();

const PORT = process.env.PORT || 8080;

app.get("/", (req, res) => {
  res.send("🚀 Hello from Buildpacks-powered Node.js!");
});

app.listen(PORT, () => {
  console.log(`Server is running on port ${PORT}`);
});

# Modify the package.json
"scripts": {
  "start": "node server.js"
}

Build the Image using Buildpacks

pack build node-app --builder paketobuildpacks/builder:base

Breaking down the command here

pack: CLI Tool that automatically detects, compiles, and packages the app into the container

build: It detects the Techstack Underneath and fetches appropriate build packs to handle dependencies & generates the OCI Compliant Container Images.

my-python-app: It will be the image name generated after the build.

--builder: It specifies which builder image to use. Where in the builder images contain Base OS Layer + Set of Buildpacks + Logic for compiling and Packaging Apps.

paketobuildpacks/builder:base: If the default Buildpack is not set then the paketo Buildpack is set to be the default buildpack

It has Full Ubuntu OS installed & supports the detection of Python (requirements.txt), NodeJs(package.json), Java(pom.xml / build.gradle), and GO(go.mod).

Some of the Other noteworthy Buildpacks are as follows

• Google Cloud Buildpacks: Best Suited for GKE, CLoud Run and App Engine

• Heroku Buildpacks: Best Suited for Heroku Apps

• Salesforce Buildpacks: Best Suited for Salesforce Hyperforce

• VMWare Buildpacks: Best Suited for CloudFoundry or Tanzu

While building it will look something like this

Cross Verify if the image is created

Run the container

docker run -p 8080:8080 node-app

Check out for the Application Running!

# Checkout in Dashboard
http://<YOUR-EC2-PUBLIC-IP>:8080

Limitations of BuildPacks

• There is a lack of fine-grained control over choosing the base image like using the Alpine, Slim Images, etc, layer by layer optimizations cannot be performed.

• Not all the Applications are auto-detectable; as buildpack depends upon the detection phase(scripts) if the project doesn't match the expected file structure.

• Buildpacks are relatively newer as compared to the DockerFile so less community support and fewer resources to graze upon.

• Images created by the Builpacks are relatively bigger in size than the DockerFile images created which increase deployment time, bandwidth usage.

• If we want to extend/modify the Buildpacks it requires knowledge of CNB (Cloud Native Buildpacks) & more expertise than writing a Dockerfile.

Congratulations you made it to the last !! Stay ahead; Subscribe to the EzyInfra Knowledge Base for more DevOps wisdom.

Conclusion

Both Buildpacks and Dockerfiles have their place—Dockerfiles offer control, while Buildpacks simplify builds. The future leans toward automation, security, and developer productivity, with teams adopting a hybrid approach based on their needs.

EzyInfra.dev – Expert DevOps & Infrastructure consulting! We help you set up, optimize, and manage cloud (AWS, GCP) and Kubernetes infrastructure—efficiently and cost-effectively. Need a strategy? Get a free consultation now!