Dora NodaOn March 28, 2025, the Paketo Buildpacks team published a blog post with a two-week countdown attached: "our sponsor who was paying the bills for GCP will be halting that sponsorship." Google, which had been quietly footing the bill for hosting Paketo's container images on Google Container Registry, was pulling out. Images on gcr.io/paketo-buildpacks/* would stop updating within roughly two weeks.
If you build software on top of open-source infrastructure, this is the sentence that should make you sit up: a cloud vendor walked away from a project your build pipeline might depend on, with two weeks' notice. And yet more than a year later, in July 2026, Paketo shipped Java 26 support the same week OpenJDK vendors released it — Java 21 still the default until September, Java 25 taking over as default then, exactly on the project's normal LTS cadence. The project didn't blink.
That gap — a sponsor pulling funding versus a project shipping on schedule a year later — is the whole story worth unpacking. It's not a story about buildpacks being invulnerable. It's a story about which part of the buildpacks stack got cut, why that part was survivable, and what a team betting its own build layer on Cloud Native Buildpacks (CNB) needs to check before assuming every other part is just as safe.
Who Actually Funds What in the Buildpacks Stack
The mistake is treating "Paketo Buildpacks" or "Cloud Native Buildpacks" as one thing with one funding source. It isn't. It's four separate layers, each paid for differently, each with a different blast radius if the money disappears:
| Layer | What it is | Who pays | What happened here |
|---|---|---|---|
| Spec + lifecycle | The CNB detect/build/run contract, the lifecycle binary, pack CLI | CNCF Incubating project (accepted Oct 2018), governed by a multi-vendor Technical Oversight Committee — no single company can unilaterally redirect it | Untouched |
| Company-owned buildpack suites | e.g. heroku/buildpacks | Funded directly out of one company's product budget, because their paying product depends on it | Untouched |
| Paketo language-family buildpacks | The Java, Node.js, .NET, Go, Python, PHP, Ruby buildpacks most self-hosted platforms actually consume | Maintainer time, historically leaned on Pivotal/VMware/Broadcom engineers plus community contributors | Untouched — this is the layer that shipped Java 26 on schedule |
| Registry / hosting infra | Where the built buildpack images actually live — GCR, Docker Hub, the Buildpacks Registry | Whoever's cloud bill it lands on — in this case, a Google sponsorship paying for GCR storage and egress | This is the layer that got cut |
Google didn't withdraw from the CNCF project, didn't stop contributing code, and didn't touch the language-family buildpacks that do the actual detecting and building. What it pulled was a line item: free storage and bandwidth on Google Container Registry. That's infrastructure sponsorship, the most fungible and most easily replaced layer in the whole stack — and it's exactly why the fallout was a non-event for almost everyone.
It was a non-event specifically because Paketo had a hedge already in place. Years before the GCP sponsorship ended, the project made Docker Hub its primary publish target, with GCR kept as a secondary mirror. When the money disappeared, there was no data to save and no rebuild to do — just a reference to update: gcr.io/paketo-buildpacks/bellsoft-liberica became docker.io/paketobuildpacks/bellsoft-liberica (Docker Hub doesn't allow hyphens in namespaces, so paketo-buildpacks collapses to paketobuildpacks). Anyone using a Buildpack Registry URN instead of a hardcoded hostname — urn:cnb:registry:paketo-buildpacks/bellsoft-liberica — didn't have to change anything at all, since the registry resolves to whichever host currently serves the image.
The counterfactual is the part worth sitting with: a CI pipeline that had gcr.io/paketo-buildpacks/ baked into its build config, with no fallback, had a 14-day clock before its builds started failing on a missing image. That team's incident wasn't caused by Google's decision — it was caused by pinning a build pipeline to one company's registry hostname instead of a spec-level reference that doesn't care who's currently hosting the bits. The project surviving didn't make that mistake safe; it just meant the mistake was rare enough not to make headlines.
Why Layer One Was Never at Risk
It's worth being precise about why the spec layer sat outside the blast radius entirely, because "CNCF Incubating" is a label that gets thrown around loosely. Cloud Native Buildpacks started as a joint effort between Pivotal and Heroku in January 2018 — two companies with competing commercial platforms agreeing to share the boring, shared plumbing of turning source code into an OCI image, so they could compete on the developer experience layered on top instead of each maintaining a private detect-and-build implementation. The project joined the CNCF that October and moved to Incubating maturity in November 2020, which means governance sits with a Technical Oversight Committee modeled on the CNCF's own TOC, not with whichever company happens to be the loudest contributor that quarter.
That structure is precisely why Google walking away from a GCR sponsorship couldn't touch the spec: Google was never the sole funder of the lifecycle or the detect/build/run contract, just one of several companies (alongside Heroku, VMware/Pivotal descendants, and independent contributors) whose engineers show up to TOC meetings and merge PRs. Pull one company's infrastructure budget and the governance model doesn't even notice — there's no single point of failure to hit. Compare that to a project where one company's name is the only name on the maintainers list, and the same kind of budget conversation happening in a boardroom somewhere is an existential risk, not a two-week migration task.
The Five-Question Audit for Every Language Family You Depend On
That's the actual due-diligence exercise this incident hands you — not "is Paketo safe," but "which of the four layers above does each thing I depend on sit in, and what happens if that specific funder walks away." Run this against every language-family buildpack, base image, or build-tool dependency your platform's build layer touches:
- Who pays for the maintainer time? A CNCF-governed spec with a multi-vendor TOC survives one company leaving. A buildpack maintained by one engineer at one company, as a side project their employer tolerates, doesn't.
- Who pays for it to be reachable? Registry hosting, CDN egress, DNS — infrastructure costs are usually the cheapest layer and the first one a sponsor cuts when budgets tighten, precisely because it's the easiest to walk away from.
- Is there a foundation backstop, or one company's roadmap? "CNCF Incubating" means a TOC and a governance process outlive any single sponsor's mood. "Maintained by Google Cloud" or "maintained by Railway" means the project's future is that company's product strategy, full stop.
- Is the reference host-agnostic? A Buildpack Registry URN resolves wherever the artifact currently lives. A hardcoded
gcr.io/...ordocker.io/...string in your pipeline config is a bet on one host staying up forever. - What's the historical lead time on a funding cut? Paketo's answer was "the next two weeks." That's the realistic order of magnitude to plan around — not months of advance notice, not an instant outage, but just enough runway to fix references if you built with a fallback and none at all if you didn't.
Applied to a Cluster-API-based, git-push PaaS betting its build layer on CNB/Paketo rather than rolling its own Dockerfile pipeline: the spec and lifecycle sit safely in layer one — CNCF governance means no single vendor exit takes down the detect/build/run contract itself. The specific language-family buildpacks in active use are layer three — worth checking who's actually merging PRs on each one, since "community maintained" can mean anything from a healthy multi-company effort to one person's unpaid nights and weekends. And every reference baked into a build pipeline should be audited for question four — a registry URN if one exists, not a hostname that happens to work today.
Where This Leaves the Build-Layer Bet
This incident is really a data point in the larger question of which build layer a self-hosted git-push platform should stand on, and it's worth being explicit about how the three live options score against the framework above:
- Cloud Native Buildpacks / Paketo — CNCF-governed spec layer, multi-vendor maintenance on the language families, and now a proven track record of shrugging off a sponsor exit specifically because a fallback was already built. The risk that remains is layer three: individual language-family health varies, and that has to be checked per-buildpack, not assumed from the CNCF badge on the spec.
- Railpack — Railway's Go-and-BuildKit successor to Nixpacks, launched in beta on March 4, 2026, already picked up by Coolify and Dokploy as a build-type option. It's genuinely good engineering, but it's a single company's product with no foundation TOC behind it. If Railway's priorities shift, there's no governance backstop — just an open-source repo someone would have to fork and steer themselves.
- A hand-rolled Dockerfile pipeline — zero vendor dependency, and zero shared maintenance. Every detect-and-build edge case a buildpack ecosystem already solved becomes your team's problem to solve and keep solving, language by language, forever.
None of that makes the choice obvious in the abstract — it depends on how much you value spec-level durability against owning 100% of your build logic. But it does make the choice auditable: run the five questions above against whatever you're about to depend on, before you're the one publishing a two-week countdown.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.