--- title: "Cloud Native Buildpacks" description: "6 posts about Cloud Native Buildpacks, summarised, each linking to the original." --- # Cloud Native Buildpacks > 6 posts about Cloud Native Buildpacks, summarised, each linking to the original. ## Articles ### [Use Paicku to containerize and test any app with buildpacks and Node.js](https://yomu.fyi/post/use-paicku-to-containerize-and-test-any-app-with-buildpacks-and-node-j.md) - Company: [Red Hat](https://yomu.fyi/company/red-hat.md) - Author: Costas Papastathis - Published: Oct 7, 2026 - Type: Tutorial Paicku is a command-line tool and Node.js library that wraps the Pack CLI to containerize applications using Cloud Native Buildpacks. It can be installed globally via npm install -g paicku or run with npx. It downloads and configures Pack for the host OS and container runtime, eliminating manual setup. Users build images with npx paicku build, defaulting to builder paketobuildpacks/builder-ubi8-base, and can list available builders with the suggest command. The Node.js librarys createPaicku function provides a build method returning an image object with run and stop for integration tests; an example test builds an app, starts the container, and asserts HTTP 200. Paicku detects Docker or Podman and supports any language a builder supports, such as Node.js and Java, by only changing the application path. ### [Behind the Scenes: How Maintaining Cloud Native Buildpacks Powers Platforms Like Heroku](https://yomu.fyi/post/behind-the-scenes-how-maintaining-cloud-native-buildpacks-powers-platf.md) - Company: [Heroku](https://yomu.fyi/company/heroku.md) - Author: Juan Bustamante - Published: Mar 17, 2026 - Type: Explainer Maintaining the pack CLI and Cloud Native Buildpacks (CNBs) is presented as invisible infrastructure work supporting platforms including Heroku, Google Cloud, OpenShift, VMware Tanzu, and internal systems. Over the last 14 months, maintainers shipped 27 releases—11 for pack and 16 for buildpacks/github-actions—reviewed more than 65 community pull requests, and delivered Execution Environments and System Buildpacks. The work also covered Windows CI migration, a docker/docker to moby/moby client upgrade, FreeBSD binaries, multi-architecture publishing, and a Platform API 0.14 lifecycle-restorer fix. System Buildpacks address platform composition and defaults, while Execution Environments support consistent configurations across development, CI, and production. The post argues that company-funded maintainers and CNCF collaboration turn production requirements into shared infrastructure, with planned build observability, OCI image annotations, and Kaniko removal as further examples. ### [OpenTelemetry, Kubernetes, and Fir: Putting it All Together](https://yomu.fyi/post/opentelemetry-kubernetes-and-fir-putting-it-all-together.md) - Company: [Heroku](https://yomu.fyi/company/heroku.md) - Author: Ken W. Alger - Published: Jul 9, 2025 - Type: Explainer Modern cloud-native applications span distributed microservices and dynamic environments, making performance diagnosis and failure analysis dependent on observability. The post explains how Fir, Heroku’s next-generation platform, combines Kubernetes infrastructure with OpenTelemetry to provide standardized visibility while hiding Kubernetes complexity behind Heroku’s interface. Fir runs on AWS EKS, uses OCI images and Cloud Native Buildpacks, and includes a Heroku OpenTelemetry Collector that gathers telemetry from applications, the Heroku router, and the Heroku API. OpenTelemetry’s APIs, SDKs, Collector, and OTLP support logs, metrics, and traces, with drains routing data to dashboards, CLI logs, or external observability platforms. The text also distinguishes OTLP gRPC and HTTP transports, noting gRPC efficiency and features versus HTTP’s firewall compatibility, and presents Fir’s open standards as a way to support scaling, hybrid environments, and reduce lock-in. ### [More Predictable Shared Dyno Performance](https://yomu.fyi/post/more-predictable-shared-dyno-performance.md) - Company: [Heroku](https://yomu.fyi/company/heroku.md) - Author: Michael Friis - Published: Apr 11, 2023 - Type: Announcement Heroku describes a year-long effort to make CPU access more predictable for shared dynos in the Common Runtime. Previously, individual dynos could burst CPU use relatively freely when capacity was available, improving utilization but sometimes allowing misconfigured or malicious “noisy neighbors” to cause response-time spikes or H12 timeouts. The platform introduced improved resource isolation for eco, basic, standard-1X, and standard-2X Dynos, limiting bursts while preserving the ability to burst and aiming for fairer access to shared CPU resources. The change does not alter the number of dynos per instance, and Performance, Private, and Shield type Dynos are excluded because they run on dedicated instances. ### [Simpler Fly deployments for NodeJS, Rails, Go, and Java](https://yomu.fyi/post/simpler-fly-deployments-for-nodejs-rails-go-and-java.md) - Company: [Fly.io](https://yomu.fyi/company/fly-io.md) - Published: Feb 10, 2020 - Type: Announcement flyctl now supports building and deploying NodeJS, Rails, Go, and Java applications to Fly with two commands. The feature uses Cloud Native Buildpacks from buildpacks.io, turning an application into a Docker image during deployment without requiring users to understand Buildpacks. Cloud Native Buildpacks are described as an evolution of Heroku and Cloud Foundry systems, but are not compatible with their older buildpacks. After installing the latest flyctl, users can initialize an app with flyctl init --builder cloudfoundry/cnb:bionic and run flyctl deploy, then open it with flyctl open. Buildpack support complements Dockerfile-based image builds, while listed builders provide different language coverage and image sizes; the post recommends heroku/buildpacks:18 for its wider coverage. ### [Turn Your Code into Docker Images with Cloud Native Buildpacks](https://yomu.fyi/post/turn-your-code-into-docker-images-with-cloud-native-buildpacks.md) - Company: [Heroku](https://yomu.fyi/company/heroku.md) - Author: Terence Lee - Published: Apr 3, 2019 - Type: Explainer The post presents Cloud Native Buildpacks (CNB) as an alternative to hand-written Dockerfiles for turning application source code into Docker images. It argues that Dockerfiles make developers manage language runtimes, system packages, dependency caching, cleanup, and repeated maintenance, creating a leaky abstraction between application and deployment concerns. CNB uses app-aware buildpacks to detect a project’s language from files such as Gemfile or pom.xml, reuse work from previous builds, download dependencies, prepare the application, and export an OCI-compliant image. The beta buildpacks.io tooling provides pack build and a Heroku builder supporting Ruby, Node.js, Java, Python, PHP, and Go; pack rebase can update an image’s toolchain without rebuilding it. The stated conclusion is that this approach reduces operational complexity while retaining compatibility with Docker tooling and the broader container ecosystem.