pinup: why I replaced my Renovate runner with a Go binary

01 — Renovate ran. That was the problem

My setup was not small. Seven scan partitions every hour, a fast lane for my own releases, a default.json of 88 KB with 25 custom managers. Every hourly run cost 40 minutes of wall time and 128 runner minutes. On top of that came a Node sidecar for the apk datasource that Renovate does not have.

The real cost was something else. The failures were silent. An automatic config migration wrapped the fileMatch regexes twice. After that, not a single custom manager ran. A group rule compared the Composer name, but Renovate matched the internal package name. The group never applied, and the merge requests fought over the same composer.lock. Another lock file was not updated for a whole year.

None of these failures turned a job red. Renovate was green every time. I found them because expected updates did not arrive, not because anything told me.

02 — A plan before the first byte is written

Renovate tells you what it did. It does not tell you what it did not do, or why. That is the gap pinup closes.

Every run first produces a machine-readable plan. pinup whatif stops there, pinup run carries on. Every held-back update carries its reason in the plan, the rule that holds it, and the moment the hold lifts.

lodash 4.17.20 -> 4.17.21  ready
redis 20.13.4 -> 28.1.0  dependencyDashboardApproval packageRules[3]

The first line becomes a branch on the next run. The second names the rule that holds the major and where it lives. With --now, pinup plans for another moment. That is how I check a schedule or a minimumReleaseAge without waiting for it.

What a version label does not tell you

pinup sees two more things I was missing. A tag whose digest changed is not an update. For latest that is normal. For v2.10.0 a published version was rewritten, and the plan says which of the two it saw.

For Helm charts, an analyzer asks what actually changed: the app version, values keys that are gone, subcharts, and the images the chart sets itself. Those images are in no file of my repository, so nothing else would have pinned them. The result is an effective label next to the declared one. The stricter of the two decides automerge.

03 — Switching without changing a line of configuration

pinup reads the existing renovate.json: extends, presets, packageRules, custom regex managers, schedules, minimumReleaseAge, lock-file maintenance, postUpgradeTasks, OSV alerts and the dependency dashboard. pinup migrate reports, key by key, what a configuration uses and what pinup supports.

Branch names and merge request titles are the same as Renovate's. pinup adopts open branches. The switch did not create a single duplicate merge request.

Compare first, then switch

Before the switch, pinup ran in shadow mode. Run after run, it compared its plans with the merge requests Renovate had open. A control repository that must differ keeps the comparison from confirming itself. I switched only once the two agreed.

Clean room instead of a fork

Renovate is AGPL-3.0. I could keep the configuration language, but not read the code. So pinup is a clean-room rebuild. I ran the pinned Renovate container and rebuilt its behaviour from recorded input and output pairs. Those pairs are now the test suite. pinup itself is Apache-2.0, like all my Go tools.

04 — What changed, measured

The hourly run across all repositories now takes 10.6 instead of 40 minutes of wall time, and 75 instead of 128 runner minutes. pinup has no runtime and two third-party dependencies. The Node sidecar is gone.

The chain behind it matters more. On 25 September I measured it end to end, on a real release of this blog:

Just under an hour from tag to production, without me stepping in. A second release landed in the meantime. pinup moved the still-open deploy MR up to it instead of opening a second one.

Conclusion

pinup does not replace Renovate's configuration language, it replaces its runner. The rules stay. Operations get cheaper and, above all, more honest: when an update does not come, the plan says why. For me that was the real reason. The saved runner minutes are the bonus.

Code, releases and documentation are on GitHub. An overview with a quickstart is on the pinup project page.