One Sponsor Pulled the Plug and Paketo Had Two Weeks to Move Registries: The Buildpack Bus-Factor Problem

On March 28, 2025, Daniel Mikusa posted an urgent notice to the Paketo Buildpacks blog: the project's entire GCP project — the GCR registry hosting every Paketo image plus the GCP-backed CI publishing them — was scheduled to be shut down "likely within the next two week." He apologized that he could not provide an exact date, because the project did not have one itself. A single sponsor had been paying the GCP bills, and that sponsor was halting the sponsorship. Every downstream pipeline referencing gcr.io/paketo-buildpacks had roughly fourteen days to move.

Nothing had broken. No CVE, no license change, no governance fight. One budget decision, made offstage by a sponsor the announcement did not even name, forced a registry migration on one of the most depended-upon build systems in cloud native — the default container builder behind Spring Boot, Cloud Foundry, and countless pack build pipelines. The migration itself succeeded: Paketo had been dual-publishing to Docker Hub for over a year, and the images landed at docker.io/paketobuildpacks. But the incident exposed the failure mode nobody had priced in. Your build pipeline does not just depend on buildpack code. It depends on somebody continuing to pay the hosting bill for the images, and on a maintainer team with the spare capacity to move them on two weeks' notice.

The verdict up front: mirror, don't just trust​

If you run builds on Paketo — directly or through a platform that does — here is the whole answer before the evidence. There are four postures toward your builder supply chain, and only one of them survives the next sponsor decision without a fire drill.

The bottom line: mirroring is cheaper insurance than either blind trust or full vendoring. A mirror costs an afternoon and pocket change in storage, and it converts every future upstream disruption — a registry sunset, a yanked tag, a Docker Hub throttle in the middle of a deploy — from an outage into a background sync delay. Full vendoring buys more independence but charges you the maintenance the Paketo team is already struggling to staff, which is precisely the risk you were trying to escape. And blind trust is free right up until the day it invoices you in eng-days with a two-week payment term. The rest of this post is the evidence behind that verdict and the checklist that implements it.

Why a registry move is scarier than it looks​

"It was just a registry rename" undersells what downstream teams inherit from Paketo. A builder is not one image. When your pipeline says paketobuildpacks/builder-jammy-base, it inherits a whole stack of upstream commitments:

The 2025 incident hit the bottom two rows — publishing and hosting — and every row above them wobbled. Users had to rewrite image references (gcr.io to docker.io, plus paketo-buildpacks to paketobuildpacks because Docker Hub does not allow dashes in org names), and the announcement carried a quiet gotcha: the pack CLI can resolve buildpacks through the public Buildpacks Registry, but Spring Boot's build tools cannot, so the largest single downstream audience had to hand-edit references. That is what "just a registry move" looks like at the bottom of a dependency tree with Spring Boot in it.

And the next forced migration is already on the calendar. Paketo's Noble restructure deprecated the full builder and full base images entirely — Jammy Full is the last full stack, and anyone on builder-jammy-full must move to the consolidated Noble builder. The Jammy base itself (Ubuntu 22.04) leaves Canonical support in April 2027. This is not hypothetical churn: the Bionic end-of-support in 2023 forced exactly this kind of stack migration once before, with Spring having to announce it to its own users. Stack EOLs are the recurring, scheduled version of the surprise the GCP sponsor delivered unscheduled. If your builder references are unpinned tags on somebody else's registry, you will re-live March 2025 on Canonical's timetable instead of a sponsor's.

A pattern, not a one-off: the maintenance ledger​

The sponsor story would be easier to dismiss if the rest of Paketo's maintenance picture were healthy. It is not bleak, but it is thin — and the project says so itself. Paketo RFC 0063, which introduced maintenance tiers for buildpacks, opens with unusual candor: "A couple of maintainers have recently left the project, without others having stepped up to take over their responsibilities. Some of the maintainer teams are down to a single maintainer."

The tier system it proposes makes the bus factor legible:

• Tier 1 requires at least two active maintainers, timely issue/PR response, and capacity for cross-project work. Tier 1 buildpacks ship in the project-maintained builders.
• Tier 2 requires at least one active maintainer focused on critical bugs and dependency hygiene. Tier 2 buildpacks are explicitly excluded from the maintained builders.
• Tier 3 is unmaintained: no PRs or bug reports accepted, headed for archive or the paketo-community org.

Read that as an operator, not a contributor: the builders you pull are a bundle whose membership is now explicitly gated on maintainer headcount, and headcount has been falling. The community-to-official promotion path still works — Python, Ruby, and the web-servers buildpacks all graduated from paketo-community — so the governance machinery functions. What is fragile is the funding and staffing underneath it, which is exactly the layer CNCF governance does not cover. Paketo is a community project, not a CNCF project; no foundation pays its registry bills or backfills its maintainers.

Here is the contrast that makes the point sharp. In August 2026, the CNCF announced the graduation of Cloud Native Buildpacks itself: 535 contributors across 164 organizations, more than 20 adopters including DigitalOcean, GitLab, Google, HashiCorp, Spring, and VMware by Broadcom, a completed OSTIF/Quarkslab security review, and a roadmap reaching toward OCI artifacts, SBOM workflows, and WebAssembly. The specification has never been healthier. Bloomberg and Heroku engineers commit to it; enterprises report vulnerability-resolution times dropping from weeks to hours across 500-application estates by patching centrally and rebasing. The standard graduated. The single most popular implementation of that standard runs on a maintainer bench thin enough to need a triage tier — and lost its GCP project, registry hosting and GCP-backed CI alike, to one sponsor's budget review. A graduated spec does not graduate its implementations' infrastructure. Conflating the two is the exact mistake a git-push PaaS cannot afford, because a PaaS does not ship the spec. It ships the builder.

The ecosystem is responding in the way ecosystems do: by diversifying. BellSoft took its hardened, zero-CVE Paketo-compatible builder to general availability in July 2026. Heroku maintains its own cnb-builder-images, and Google documents its own Cloud Buildpacks builders — both credible exits if Paketo ever narrows further. But every one of those is another upstream with its own sponsor, its own maintainers, and its own bills. Switching builders trades one bus factor for another. Only holding your own copy removes the registry-deadline class of risk entirely.

The git-push PaaS checklist​

This is the verdict above turned into implementation steps. Each one is sized for a platform team, but every item works for a single repo with a pack build in CI.

1. Digest-pin your builders and run images. Tags float; digests do not. Pin paketobuildpacks/builder-* and the matching run image by sha256 in build config, and promote new digests deliberately after CI passes — never by surprise on a Friday. Pinning would not have avoided the GCR move, but it converts every future upstream change from silent drift into a diff you review.
2. Stand up a pull-through mirror this week. A Harbor proxy-cache project (or a plain registry mirror) in front of Docker Hub, plus the builders and run images you use cached locally. Point builds at the mirror. Size it in the tens of GB, verify it serves with upstream network cut, and you have just bought immunity to the next registry sunset and every Docker Hub throttle between now and then.
3. Calendar the stack EOLs like contract renewals. Jammy base support ends April 2027; the Noble full-builder removal is already forcing builder-jammy-full users to move. Treat each stack migration as a scheduled project with a test matrix per language, not as a tag bump. Bionic in 2023 was the rehearsal; run this one deliberately.
4. Keep a second builder working, not just documented. Pick your fallback — Heroku, Google, or BellSoft hardened — and prove one representative app builds and runs on it quarterly. A fallback you have never built against is a hope, and hopes do not survive two-week deadlines.
5. Watch the tier labels, not just the release notes. RFC 0063 puts maintenance status in READMEs and repo topics. If a buildpack your tenants rely on slides toward Tier 2 (out of the maintained builders) or Tier 3 (archived), you want that signal months before the builder that drops it — time to mirror the last good version or migrate the workload.

None of this is anti-Paketo. The project handled a two-week eviction notice about as well as an eviction can be handled, kept publishing, and told its users exactly what to change. The lesson is narrower and more durable: open-source sustainability has two ledgers, code and infrastructure, and only the code ledger gets the graduation announcements. Audit both.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Builders, registries, and deploy pipelines included, so the bus factor is yours to manage. Star the repo on GitHub or deploy your first app today.