Half a win: why I could only get Renovate's PHP/Composer install halfway off GitHub

01 — The obvious move: just do what worked last time

Renovate installs php and composer at runtime through containerbase, which downloads prebuilt tarballs from github.com/containerbase/*-prebuild. GitHub is IPv4-only and, under load, flaky — one bad afternoon there turned every scheduled scan red on a composer download. Textbook. I'd mirror the prebuilds into my registry, point containerbase at the mirror, done — exactly like the providers.

Two things immediately refused to be exactly like the providers.

02 — First wrinkle: these aren't artifacts, they're files

Providers became OCI artifacts in my container registry — the registry speaks the OCI protocol, so they fit. containerbase does something dumber and more constraining: a plain GET, with one knob — swap a URL prefix (URL_REPLACE). It doesn't speak OCI. It wants a plain file server at the same path shape as GitHub releases.

The nice surprise: GitLab's generic package registry is exactly that, on the same host I already run, dual-stack, and its URL .../packages/generic/<name>/<version>/<file> lines up with containerbase's <tool>-prebuild/releases/download/<ver>/<file> so cleanly that a prefix swap just falls into place. To find the exact filename containerbase wanted (which Ubuntu variant? which arch?), I pointed URL_REPLACE at a made-up host and read the error:

The probe (install-tool php 8.5.8)

# URL_REPLACE_0_TO = probe.invalid/cb/  → the error names the asset
ERROR: getaddrinfo ENOTFOUND probe.invalid
  url: "https://probe.invalid/cb/php-prebuild/releases/download/
        8.5.8/php-8.5.8-jammy-aarch64.tar.xz.sha512"

The image is Ubuntu noble — but containerbase asks for the jammy prebuild. Assume that empirically, don't guess it.

03 — Second wrinkle: you can't pre-seed a moving target

Here's the one that actually mattered. For providers I pin the versions — I decide it's aws 6.52.0, I mirror aws 6.52.0, the coupling is mine to control. Renovate runs with binarySource=install, which means it installs php and composer on demand, at whatever version each repository needs. The version set isn't mine. It's whatever 70-odd repos happen to require. Mirror one version and the first repo that needs another gets a 404 mid-scan.

Lesson one

“Just mirror it” assumes you know what “it” is. When the version set is decided by consumers, not by you, pre-seeding isn't a mirror — it's a bet.

So before writing any more code I did the unglamorous thing: read the composer.json of every managed repo and tallied what actually drives the install — config.platform.php first, then the require.php range.

73 composer.json files across development, devops, and ai-ready-platform. Every open range resolves to the newest available — one version. Only exact platform.php pins escape it.

The panic (“I'll have to mirror dozens of versions and chase every constraint change”) dissolved. The real set was tiny: php 8.5.8 (every range lands here), php 8.5.0 (five repos pin it exactly), and composer 2.10.2 (nobody pins composer). Three artifacts. The moving target barely moves — but I only knew that because I counted, instead of mirroring a guess and waiting for the 404.

With that, the rest is plumbing: a job pulls those from GitHub once and pushes them into the generic package registry; Renovate's URL_REPLACE points at it (job token as basic-auth in the URL, since containerbase won't add a header); and — because Renovate does install per-repo versions during the scan, not just once up front — the redirect stays on for the whole job. The first real scheduled scan after shipping it installed php and composer straight from the mirror, over IPv6, no 404. It works.

04 — The half: killing a dependency isn't switching pools

Which brings me to the thing I actually wanted, and didn't get. My general CI fleet is IPv6-only; a small IPv4 pool exists for the jobs that still need GitHub. Renovate lives on that IPv4 pool. The whole point of this exercise, in my head, was to get it off the pool.

It's still there. Because a Renovate scan touches GitHub for two unrelated reasons, and I only fixed one:

The download path and the metadata path look the same from a distance — both say “Renovate needs GitHub” — but they're not the same problem. One is a file you can copy once and serve forever. The other is a question you have to ask GitHub every time, and mirroring a question means running a proxy that answers it, which means running GitHub's API surface, which is not a thing I'm doing this week.

Lesson two

Removing one reason a job needs a network isn't the same as the job not needing the network. Count the reasons before you promise the pool switch.

So: half a win, honestly. The flaky, scan-reddening dependency — the download — is gone, verified in production. That was the one worth killing; it's the one that turned other people's outages into my red pipelines. Renovate stays on the IPv4 pool for now, and the doc that tracks what still needs IPv4 keeps its Renovate row, with one line struck through and one still standing.

I'll take it. Half a win that fixes the failure you actually had beats a whole win you invented to feel complete.

Conclusion

Two stories with the same starting diagnosis, two very different endings. For providers, I control the version set, so mirroring was a pure plumbing problem. For Renovate's toolchain, 73 other people's repos decide the version set, and containerbase doesn't speak OCI in the first place — together, that turns the same idea into a different task. The honest result: one flaky, scan-reddening GitHub dependency is gone, verified in production. A second one remains, because fixing it would be its own, considerably larger investment. Both findings together are worth more than a polished success story.