Behind the Scenes: How Maintaining Cloud Native Buildpacks Powers Platforms Like Heroku

Most developers never see the 11 pack releases we shipped in the last 14 months as pack CLI maintainers. That’s actually a good sign—it means the infrastructure just works. When a critical vulnerability emerges requiring an immediate upgrade, the fix is shipped within days.

Here’s what most developers don’t see: that same security patch now protects every buildpack user across Heroku, Google Cloud, Openshift, VMware Tanzu, and thousands of internal platforms.

The daily work of platform maintenance

As maintainers of pack CLI, the entry point to Cloud Native Buildpacks (CNBs), our work lives in that invisible layer between developers and infrastructure. The routine looks like this: daily Slack monitoring, triaging GitHub issues, reviewing community pull requests, and participating in weekly Cloud Native Community Foundation (CNCF) working group meetings.

In the last 14 months, we’ve shipped 27 releases across CNB projects (11 for pack, 16 for buildpacks/github-actions), reviewed 65+ community PRs, and implemented two major features: Execution Environments and System Buildpacks. That’s roughly one release every 5-6 weeks, each bringing bug fixes, security patches, or new capabilities.

The work includes unglamorous but critical tasks: migrating Windows CI from Equinix LCOW to GitHub-hosted runners, upgrading from docker/docker to moby/moby client, and shipping FreeBSD binaries for broader platform support. When multi-arch builds needed the --append-image-name-suffix flag or when the Platform API 0.14 lifecycle restorer had issues, those fixes went out to everyone.

There are no flashy demos; instead this is invisible infrastructure work that proves its worth when an emergency security patch ships or a build completes in 30 seconds instead of failing after 5 minutes.

How upstream open source creates downstream value

Here’s where it gets interesting: Heroku has funded our maintainer work, but the benefits ripple across the entire cloud-native ecosystem. This bidirectional value is what makes open source infrastructure so powerful.

Take System Buildpacks, a feature we recently implemented:

• For Heroku, it means they can curate platform defaults while giving users flexibility with third-party buildpacks.
• For Google Cloud Run, it solves its buildpack composition problem.
• For internal platform teams, it eliminates the manual Procfile buildpack overhead that’s been a pain point for years.

That one newly implemented feature created universal benefit.

Or consider Execution Environments, another major feature we shipped this year. This enables Heroku to support test environments for CI products while also helping any platform operator who needs consistent build configurations across development, CI, and production. The code lives upstream in the CNCF project, battle-tested by multiple companies, and maintained collaboratively.

The CNCF governance model ensures no single company can control the direction. Companies like Heroku, Google, and VMware collaborate on infrastructure so they can compete on developer experience. When we fix a multi-arch publishing bug or add FreeBSD support, everyone benefits immediately.

Real innovation happens in production

The features we’re shipping aren’t theoretical, they solve real problems in production:

• Build Observability (RFC 0131): Platform operators need metrics and tracing to optimize costs and troubleshoot failures. Coming in Q3 2026, this will provide comprehensive visibility into build performance across the ecosystem.
• OCI Image Annotations (RFC 0130): Enterprise compliance requires metadata tracking. We’re making it zero-config so platforms can meet SOC2, FedRAMP, and other regulatory requirements without manual overhead.
• Removing Kaniko dependency: Supply chain security isn’t just buzzwords, it’s actively removing unmaintained dependencies from critical infrastructure to reduce risk.

Each feature starts with a production requirement, gets refined through community discussion, and ships as a standard that everyone can rely on.

Why this model works

At KubeCon EU 2025, the biggest question during our presentation “Buildpacks: Pragmatic Solutions to Quick and Secure Image Builds” wasn’t about technical implementation—it was about sustainability. How do we keep critical open source infrastructure maintained?

Companies like Heroku invest in dedicated maintainer teams, and get battle-tested technology that serves their needs while contributing to the commons. The ecosystem gets features driven by real production requirements, not academic speculation, and developers get reliable infrastructure that just works.

That’s the true impact of open source maintainership: 65+ PRs reviewed, 27 releases shipped, 2 major features delivered, and the countless invisible fixes that keep platforms running smoothly.

Join the conversation at KubeCon EU 2026

The evolution of Cloud Native Buildpacks continues, and there is no better place to see where we’re headed next than at KubeCon EU 2026.

If you want to dive deeper into the future of the project, don’t miss the upcoming session:

Buildpacks: Towards 1.0, AI, and Other Things
Thursday March 26, 2026 14:30 – 15:00 CET
Aidan Delaney, Bloomberg

This talk covers the road to 1.0, focusing on the stability and technical components (Lifecycle, Platform, and Builder) necessary for a production-ready foundation. Aidan will also showcase how the ecosystem is integrating AI and Machine Learning to simplify the deployment of AI-driven applications.

Visit the Buildpacks Project booth

The community will be out in full force! Stop by the CNB booth, P-3B in the Project Pavilion (map), to meet the maintainers, ask questions, and learn more about the “invisible” infrastructure powering your code. We’d love to see you there!