binarySource=docker is officially deprecated, pending removal in a future release

[jamietanna]

As part of Renovate 36.0.0 (2023-07-04), we started to use binarySource=install for our "slim" Docker image.

This allowed for ad-hoc installs of known tools, in a more straightforward way than using Docker images (and making sure that the Docker socket was mounted and accessible in a secure way).

As part of this new default, the usage of the previous default, binarySource=docker, was deprecated. Self-hosted administrators were asked to migrate and/or provide us feedback about their use case.

In the ~3 years since binarySource=install was the default, we've seen good success with this, and see almost 0 community requests about binarySource=docker (either because it works very well, or very few people use it)

Due to the maintenance requirement of its use, and the solid foundation of binarySource=install, we're more visibly deprecating binarySource=docker in Renovate 43 (#40026).

FAQs

Can I still use binarySource=docker in Renovate 43?

If you're using binarySource=docker, you will still be able to use it.

However, there will be a configuration validation warning when using it.

When will I no longer be able to use binarySource=docker?

We (the Renovate maintainers) have not decided when this we will remove this from Renovate.

It is likely that in Renovate 44 this will be removed, on the expectation that Renovate 44 is later in 2026, and there is no feedback from the community on keeping it available as an option.

Feedback wanted

Please feed back below if there are reasons that you use binarySource=docker and cannot use binarySource=install.

Feedback and/or overwhelming usage of the option may impact timelines or focus on maintenance.

[Chumper]

I am not advocating for keeping the docker binarySource, but just want to share our use case that is now obsolete:

We were still using the docker binarySource mainly because docker images were cached by default while the install method would require the tool to be downloaded every time.
We also used Jenkins at the time, but it would have been no problem to switch over to the install method at one point.

That said, we switched over to the install method in September last year and moved the place where tools were downloaded to into a shared filesystem.
That works for us right now and has roughly the same run times.

[viceice]

for those caching purposed i build my own renovate image with some tools preinstalled, so install-tool is most of the time a no-op

https://github.com/visualon/docker-renovate/blob/main/Dockerfile

[viceice]

i don't extend the renovate image because even the slim image is too big, we only need a few tools prepared 🙃

[juljaeg]

We are using this for multiple reasons:

1. Tools are coming from a predictable source (i.e. docker registry mirror) which eases firewall openings in corporate environments and with mirrors like Artifactory they are also stored, cached and scanned automatically.
2. We do not want to maintain versions of tools in a renovate docker image to maintain versions in our other docker images (not necessarily the same version). Things would be getting out of hand.
3. Tool runs are isolated from each other which has been easier for us e.g. with Node.js for running renovate colliding with constraints defined in the repository config (that was when setting up Renovate a few years ago - might be fixed by now).
4. It works really well - thanks for that 😄

[viceice]

1. it's still working same in install mode and it's much faster
2. you don't need to maintain anything, renovate will handle tool versions in same way in docker and install mode
3. renovate will take care to use the right tool versions. install mode will be faster because already installed tool versions can be reused right away.
4. install mode is rock solid too. were using it for years

[qerub]

I don't use binarySource=docker myself but have found it to be an interesting option to provide better isolation between the Renovate process and the tools it invokes. I know Renovate is tightening things up with new configuration options like allowedUnsafeExecutions but having guarantees (modulo vulnerabilities in/around Docker) that a tool can never access the runtime environment of Renovate itself is worth a lot. While Renovate runs tools with a heavily filtered set of environment variables, secrets are likely to be found in /proc/$pid/environ, /run/secrets, /scripts-* (if run in a GitLab CI/CD job), etc. Just my 50 öre on that we might actually loose something of value with this removal. (Please let me know if I've got anything wrong.)