TLDR
- All buildpacks turn application source code into a production-ready container image without a Dockerfile. The key differences between them are the base Linux OS, ecosystem, and support conditions.
- Only one provider on the list currently offers a hardened builder for buildpacks.
Buildpacks can make containerization boring in a good sense. You skip the most “interesting” part of writing the Dockerfile and run one command like pack build. As a result, you get an OCI image with a non-root user, an SBOM, and a layer structure meticulously designed by the buildpack creators.
But the buildpacks world is not boring at all. There are eight offerings of buildpacks. Two of them aren't Cloud Native Buildpacks — they implement the original format, introduced by Heroku in 2011 and adopted by Cloud Foundry. Among the CNB implementations, some wrote the specification and some redistribute the largest implementation with a different base image and a support contract.
In this article we look at how buildpacks world is organized — specifications, implementations, distributions — and review all the offerings so that you can choose the solution that fits your stack and requirements.
Classic buildpacks vs Cloud Native Buildpacks
First, it is important to distinguish between two major categories: Classic Buildpacks and Cloud Native Buildpacks (CNB).
Classic Buildpacks were the first ones. Heroku initiated the project in 2011, and then they were adopted by Cloud Foundry and some other platforms like Google App Engine. A classic buildpack runs inside a platform's staging process and produces a slug/droplet or a platform-specific artifact that can be run by a certain PaaS.
Classic buildpacks introduced the idea of automatically transforming application source into a runnable artifact. Cloud Native Buildpacks standardized and redesigned that process around images in the format defined by the Open Container Initiative (OCI).
The Cloud Native Buildpacks project was initiated by Pivotal and Heroku in 2018, and it joined the Cloud Native Computing Foundation (CNCF) the same year. A CNB build produces an OCI image that runs on any container runtime, includes an SBOM, and offers more advanced caching techniques, answering modern requirements to containerized workloads.
These are the specs. From here, we go into implementations.
The independent implementations
Paketo
Paketo is the reference implementation of the CNB specification. It is licensed under Apache 2.0 and covers the widest language and ecosystem set on the list: Java and the JVM ecosystem, Java native images, Node.js, Python, Go, Ruby, PHP, .NET Core, NGINX and Apache HTTPD. As for the JVM, the project publishes examples for Java, Kotlin, Scala, Clojure through Leiningen, Maven and Gradle builds, executable JARs and WARs, Spring Boot, and GraalVM Native Image.
You can choose a builder with a specific base OS. The builder's base OS determines the build environment, and the run image determines the OS foundation of the resulting application image. Choose one that is compatible with your native dependencies and that meets your runtime security, support, and compliance requirements.
Builders are available for Ubuntu 26.04 Resolute, Ubuntu 24.04 Noble, Ubuntu 22.04 Jammy, and Red Hat UBI 8, 9 and 10. In addition to that, there are variants of the underlying OS in terms of the filling:
- Full includes the common C libraries like ImageMagick and exists only on Jammy.
- Base gives you a broad language set without these libraries.
- Tiny and Java Tiny couple an Ubuntu build image with a scratch run image, which starts from an empty filesystem, and then adds only the runtime components the application needs, such as glibc, certificates, and the JRE. The final image has no shell in it.
- Static does the same for statically linked binaries.
Every option also comes as a buildpackless variant, where build and run images have no buildpacks. This is intended for teams that assemble their own buildpacks.
What Paketo doesn't have is a support contract option. There are third-party providers, but the Paketo project itself is community based.
Heroku
Heroku ships buildpacks in both formats, Classic and CNB. The choice partly depends on the Heroku platform generation: Cedar is Heroku’s older generation, and Fir is its newer cloud-native platform architecture. Classic buildpacks are the default for the Cedar generation and support Ruby, Node.js, Clojure, Python, Java, Gradle, JVM, Grails 3.x, Scala, Play 2.x, PHP, Go and .NET. Fir required Cloud Native Buildpacks, and a Cedar app has to migrate its stack to cnb to use them.
The CNB set is a bit smaller: .NET, Go, Java, Node.js, PHP, Python, Ruby and Scala. Java and Scala share heroku/buildpacks-jvm. In addition, there are buildpacks for Procfiles, Debian packages and frontend web apps.
Builders are versioned by Ubuntu release as heroku/builder:22, :24 and :26. 24 and 26 are available for arm64 and amd64.
You can use Heroku’s buildpacks outside of its platform because pack build --builder heroku/builder:26 myapp acts like any other builder. But the support is offered within the platform. Heroku backs its official buildpacks when you reference them by heroku/ at the latest stable release.
If you use the Google ecosystem, you might have already used Google's buildpacks without realizing that because they are the build system behind App Engine and Cloud Functions. Google buildpacks are also a standalone, CNB-compatible implementation under Apache 2.0. They are targeted primarily to Cloud Run, GKE, Anthos and Compute Engine running Container-Optimized OS. But GKE can run images produced by any CNB implementation.
Language support covers Node.js, Python, Go, Java, Ruby and PHP. There’s also an OS-only option if you want only the base image without anything on top. Google's Ubuntu 22.04 images are used as the base OS for the builders that work with pack, kpack, Tekton, and Skaffold.
You can use them on your own clusters, they are not tied to the Google ecosystem functionally. But if you need support, these buildpacks are officially supported only when used with Google Cloud products.
Built on Paketo
CNB is a specification, Paketo is an implementation of this specification. And then there is further division. There are three vendors who provide Paketo-based builders/distributions, combining Paketo buildpacks with their own components like runtime, base OS, etc.
So Paketo gives a solid foundation that you can use as is. Alternatively, you can look into vendor offerings if you have specific requirements to base images, maintenance, support, or integration with the existing platform.
BellSoft
BellSoft offers a hardened builder for Paketo buildpacks, which produces container images based on BellSoft Hardened Images with low-to-zero CVEs at release time, continuous patching, and SLA for patches.
The base OS is Alpaquita Linux, available with musl and glibc libc — bellsoft/buildpacks.builder:musl and glibc —- for x86-64 and arm64.
BellSoft’s builder covers six runtimes: Java on Liberica JDK Lite (LTS 8, 11, 17, 21 and 25, plus the latest JDK), GraalVM Native Images through Liberica Native Image Kit, Node.js, Python, Go, and Ruby. For Java applications, Liberica JDK Lite coupled with Alpaquita Linux can reduce the container image memory footprint by at least 30% as compared to standard OpenJDK images.
BellSoft’s builder is available for free with optional commercial support.
Red Hat
Red Hat offers a Paketo-based builder with Red Hat UBI as a base OS. As the installation of Red Hat rpm requires root, Red Hat developed Image extensions, a feature that permits privileged operations an rpm install requires. On top of that came the UBI Node.js and Java extensions, a UBI base stack, and UBI builder images: UBI 8 and UBI 9 for Java and Node.js, UBI 10 for Node.js. From there a UBI builder handles a project like any other Paketo builder.
Note that extensions are still experimental in the specification, so you need to enable pack config experimental true. Red Hat describes the components as working their way through the hardening process. No commercial support offering for the builder is documented.
Broadcom Tanzu
Tanzu Buildpacks are the commercial Paketo distribution, packaged for Tanzu Build Service. Multiple languages and ecosystems are supported: Go, Java, Java Azure (uses Microsoft OpenJDK and includes integrations intended for Azure environments), Java Native Image, .NET Core, .NET Framework in beta, Node.js, Python, Ruby and a Web Servers buildpack. In addition, Procfile, HTTPD, NGINX and PHP are available through Tanzu Build Service dependencies. The base OS options are Bionic and Jammy in Base, Full and Tiny variants, Jammy Static, and also a Windows Server Core stack for .NET Framework workloads.
The CVE management is documented: Broadcom targets updates for high and critical CVEs within two business days of the upstream patch, while low and medium severity vulnerabilities land into a monthly release. Tanzu Buildpacks are a paid offering. While the upstream Paketo versions are free,this distribution is available at the Broadcom Support Portal with Broadcom support attached.
Built before the specification
Cloud Foundry
Cloud Foundry offers classic buildpacks for Binary, Go, Hosted Web Core, Java, .NET Core, NGINX, Node.js, PHP, Python, R, Ruby and Staticfile. Applications are staged against a Cloud Foundry stack, a prebuilt Linux or Windows root filesystem that supplies the underlying OS environment.
Cloud Foundry supports both classic buildpacks and CNB, whose scopes are divided quite clearly: if a capability is missing from the classic buildpacks, you should look into Paketo for the CNB equivalent. One example is GraalVM Java Native Image, which exists only as a CNB.
SAP
SAP BTP provides classic Cloud Foundry buildpacks rather than CNB, with cflinuxfs4 used as the application runtime stack. Three of them are SAP-managed and come with SAP enterprise support: sap_java_buildpack, sap_nodejs_buildpack and sap_python_buildpack. All the other options are community buildpacks, including Go, PHP, Ruby, .NET Core, Staticfile, binary and the upstream Java and Node.js ones.
The Java buildpack has generations. SAP Java Buildpack 2 is current, whereas SAP Java Buildpack 1, TomEE 7, Tomcat 9 and Memory Calculator V1 are deprecated. SAP buildpacks are free to use, but only as part of the platform.
Scanning the Buildpack Builders: What the CVE Count Means
Security teams often request a scan of a chosen builder and might be surprised with the result showing dozens of CVEs. At this point, it is important to understand where these CVEs come from and how they affect the final image.
Let’s use a CNB builder as an example. A CNB builder is an image containing buildpacks, a build-time base image, lifecycle, and a reference to a run image. The run image becomes a base for the final image, which can also contain launch layers contributed by buildpacks. A builder may contain vulnerabilities in its build-time OS, build tooling, lifecycle, or included buildpacks. But many of those components never get into the final image. Therefore, the application image must be scanned separately.
That doesn’t make the builder’s CVE irrelevant. But one has to consider the following when assessing the builder's security. New vulnerabilities are discovered continuously. But if we continue using Paketo as an example, they are also patched continuously by the project maintainers. Upstream Paketo buildpacks are frequently — approx. once a week — updated with new patches. One CVE can be patched today, another is discovered tomorrow. Security is a continuous process for all software projects.
What matters is where a vulnerable component is located, whether it reaches the runtime image, whether it is exploitable in your case, and how quickly the provider patches and republishes affected components.
Take BellSoft’s Hardened Builder for Paketo buildpacks. It uses BellSoft Hardened Images for the build and runtime base image while also incorporating upstream Paketo buildpacks. In our scans, replacing the Ubuntu Jammy base removes thousands of OS-level findings, and the remaining findings come largely from components included by the upstream buildpacks. The resulting application image can still contain zero known CVEs.
So when comparing builders, don’t compare CVE counts alone. Check the build and run images, scan the produced application image, and examine the provider’s update and remediation policy.
Making the call
So how do you choose a suitable offering? In some cases, the platform decides for you. App Engine and Cloud Functions builds go through Google's buildpacks, and the same applies to Heroku's CNBs on Fir. On SAP BTP you get three supported buildpacks and community options. Cloud Foundry uses classic buildpacks by default, whereas Paketo Cloud Native Buildpacks require separate integration.
If you are not bound by the platform and your target is an OCI image on Kubernetes, the key questions you need to answer are about the base image and accountability.
Paketo is the baseline and can be a good choice if you're comfortable relying on the upstream project for the patches, fixes, other updates, and community support.
BellSoft’s hardened builder is a good choice if supply chain security requirements are a priority because it adds continuous vulnerability management under SLA, provenance, and SBOMs while keeping the standard Paketo workflow. The hardened builder is designed as a drop-in replacement for Paketo builders.Therefore, teams can migrate without changing their application build process or retraining developers on a different buildpack ecosystem.
If your organization is standardized on RHEL you can consider using the UBI builders with the experimental extension enabled.
If you already have a contract with Broadcom, Tanzu Buildpacks may be an optimal choice. The defined CVE remediation timelines are a good enterprise bonus, and Tanzu is the only provider supporting Windows containers.
In addition, there are a few constraints to consider. GraalVM Native Images is supported by CNB, which means Paketo, BellSoft or Tanzu. Windows containers mean Tanzu. If your workload is in R, the only provider that ships it is Cloud Foundry.
I recommend you read more about the offerings you are interested in, try them out with your application, and compare the results in terms of image size and CVE count. That can be a good starting point.
The comparison table
|
Paketo |
Heroku |
|
BellSoft |
Red Hat |
Broadcom Tanzu |
SAP |
Cloud Foundry | |
|---|---|---|---|---|---|---|---|---|
|
Classification |
Reference CNB implementation |
Independent vendor implementation |
Independent vendor implementation |
Paketo-based |
Paketo-based |
Commercial Paketo distribution |
Cloud Foundry classic, platform-specific |
Independent classic buildpacks implementation |
|
CNB buildpacks* |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
No |
Through Paketo |
|
Classic Cloud Foundry buildpacks** |
No |
Yes |
No |
No |
No |
No |
Yes |
Yes |
|
Supported languages and ecosystems |
Java/JVM, Java Native Image, Node.js, Python, Go, Ruby, PHP, .NET Core, NGINX, Apache HTTPD**** |
CNB: .NET, Go, Java, Node.js, PHP, Python, Ruby, Scala. Classic: all of the above plus Clojure, Gradle, JVM, Grails, Play |
Node.js, Python, Go, Java, Ruby, PHP, OS-only |
Java, Java Native Image, Python, Go, Ruby, Node.js |
Java, Node.js |
Go, Java, Java Azure, Java Native Image, .NET Core, .NET Framework (beta), Node.js, Python, Ruby, PHP, web servers (NGINX, Apache HTTPD) |
SAP-managed: Java, Node.js, Python. Community: Go, PHP, Ruby, .NET Core, Staticfile, binary |
Classic: Java/JVM, Go, .NET Core, Node.js, PHP, Python, Ruby, R, NGINX, HWC, Staticfile, binary. CNB: through Paketo |
|
Base OS |
Ubuntu Resolute 26.04, Noble 24.04, Jammy 22.04; UBI 8-10 (developed with Red Hat contributions); scratch |
Ubuntu 22.04, 24.04, 26.04 |
Ubuntu 22.04 (google-22 image family) |
Alpaquita Linux (build image), BellSoft Hardened Images (run image) |
Red Hat UBI 8-10 through the Paketo UBI builders |
Ubuntu Bionic and Jammy (Base, Full, Tiny), Jammy Static, Windows Server Core |
cflinuxfs4, through SAP BTP |
cflinuxfs4 and Windows stacks (classic buildpacks) |
|
Free to use*** |
Yes |
Yes |
Yes |
Yes |
Yes |
Upstream yes; product requires entitlement |
Included with the platform |
Yes |
|
Commercial support |
Third-party only |
Heroku platform support |
Google Cloud products only |
Direct commercial support with an SLA |
None documented |
Broadcom Support |
SAP BTP support, SAP-managed buildpacks only |
Through CF distributions |
|
Hardened buildpacks |
No |
No |
No |
Yes |
No |
No |
No |
No |
* Cloud Native Buildpacks (CNBs) are the newer standardized system governed by the Cloud Native Buildpacks project.
** Classic buildpacks are the original format developed by Heroku and Cloud Foundry. They produce platform-specific artifacts. SAP calls its offering a Cloud Foundry buildpack; based on the staging lifecycle and deployment configuration, it belongs to the classic Cloud Foundry model rather than the Cloud Native Buildpacks model.
*** Free to use means the buildpack software or builder carries no licence fee. It does not mean the cloud platform, compute, registry or support is free. SAP buildpacks are free to use only as part of the SAP platform. Heroku and Cloud Foundry CNBs are free to use anywhere; their classic buildpacks are technically free too, but they are platform-specific and built for Heroku- and CF-compatible platforms.
**** Not every builder supports every language. For the Java buildpack, Paketo provides tested examples for Java, Kotlin, Scala, Clojure through Leiningen, Maven and Gradle applications, executable JARs and WARs, Spring Boot, and GraalVM Native Image.
