Renovate CLI: two binaries, four run routes, and three experimental platforms

One package, two binaries, and a version number the tooling replaces

package.json carries version 0.0.0-semantic-release, a placeholder that the release tooling overwrites, so the version string sitting in the tree is never the version you install. The package declares type module and publishes two binaries: renovate pointing at dist/renovate.js, and renovate-config-validator pointing at dist/config-validator.js. The second binary matters during evaluation, because checking a configuration is part of the same install rather than a separate tool you have to go find and version-match. The build script chains clean, the generate steps, compile:ts, and create-json-schema, and that schema step writes renovate-schema.json, renovate-inherited-schema.json, and renovate-global-schema.json, which are the files an editor uses to flag a bad key before you ever run the bot. The repository publishes no install command anywhere in its README, so the single copy-and-paste install line you may be looking for does not exist here; you choose a deployment route instead, and each route carries a different cost. The version history also sets the pace you have to plan for: 44.206.0 shipped at 18:58:14Z on 2026-11-02, 44.206.1 followed at 22:00:06Z, and 44.206.2 landed at 22:19:59Z the same evening.

Three of the nine platforms are marked experimental and nobody is watching them

The platform list names nine targets, and three carry an experimental label: AWS Code Commit, Gerrit, and SCM-Manager. GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, and Forgejo carry no such flag. The practical gap is not the API surface but where you take a problem when a manager stops resolving a manifest. Paired with the rule that only maintainers open Issues, an experimental platform user has no tracked place to report that resolution broke, and the only channel the project names is Discussions, which is not indexed or filtered the way a ticket system is. If your organization standardizes on Gerrit or AWS Code Commit, the honest framing is that you own this integration: you read the manager documentation, you write the tests against your own manifests, and you wait on forum threads rather than on status changes. Renovate states no deprecation timeline for the experimental entries and does not say what is unfinished in them, so you cannot tell from the documentation whether the gap is authentication, result parsing, or something narrower, and you cannot tell whether the flag will ever be lifted.

The Azure DevOps extension sits outside the support boundary on purpose

Azure DevOps has two documented routes and they are not equally supported. One is the Renovate Me extension in the Visual Studio Marketplace, and the project attaches a warning to it: the extension is created and maintained personally by a Renovate developer or user, and support requests for the extension will not be answered directly in the main Renovate repository. The other is a custom pipeline whose yml definition triggers npx renovate. The difference is who answers when the job fails overnight. With the extension you depend on one person's availability plus Marketplace review cycles, and the vendor repository is explicitly not the place to ask. With the custom pipeline you own the schedule and the runner, and the only borrowed piece is the CLI. The extension is the odd one out among the pipeline options, because GitHub has the renovatebot/github-action repository and GitLab has a separate Renovate Runner project on gitlab.com, both named destinations with their own histories, while the Azure DevOps route has no project here at all. If your pipelines run on Azure DevOps, budget for owning that integration rather than treating it as a supported default.

Only maintainers open Issues, which removes your bug report

The contribution policy is unusual enough to change how you plan an adoption. The project asks that Discussions be used to get help, to suggest a feature, and to report a bug, and it states plainly that only maintainers open Issues. The bug tracker you would expect is closed to users by design, and everything a user reports lands in a forum-shaped destination instead. For a platform team that has a concrete consequence: there is no issue number to paste into an internal ticket, no per-report state you can track, and no way from the outside to confirm that a defect you reported was ever fixed. Security findings follow a separate path. A bug that may be a security problem should go through the GitHub Security Advisories process, and the project asks for enough time to investigate before it is reported anywhere else. For a conversation before filing an advisory, the contact is [email protected]. Read that as a limit on your own disclosure timeline: a weakness you find in the update path is not something you can announce on your own schedule, which changes how a security review of this bot has to be run.

Four signals gate the updates, and none of their thresholds are written down

The feature list names four signals as the information provided to help you decide which updates to accept: age, adoption, pass rates, and merge confidence. They are information for you to weigh, not a gate the README describes. The README does not define an acceptable adoption rate, does not say what a passing rate is measured against, and does not publish the merge confidence bands, nor does it say which signals are on by default and which need configuration. The effect on an evaluation is direct: you cannot predict the pull request volume your maintainers will see on the first day from reading the overview, because the README does not describe how these signals relate to the number of pull requests opened. If merge volume matters more to your team than upgrade coverage, you have to read the configuration options and the Merge Confidence data page instead, and you should treat the first week of a trial as a measurement period rather than a verdict. Automated discovery of the relevant package files is listed as a feature too, which is convenient partly because it means Renovate decides its own scope of files to touch.

Private registries only come with the server you host yourself

There are two hosted shapes and they do not cover the same platforms. The cloud-hosted Mend Renovate Community app covers GitHub.com and Bitbucket Cloud, requires no setup, and has a free community plan; on GitHub you install the Renovate Cloud-Hosted App on the org and select repos, and on Bitbucket you add the Mend App to the Workspace and add the Mend Renovate user to the projects. The self-hosted community edition covers GitHub, GitLab, and Bitbucket Data Center, and it is the only listed option described as accessing internal packages, with a paid Enterprise tier above it. The gap follows directly from those lists. GitLab.com is absent from the cloud-hosted list, and Gitea, Forgejo, Azure DevOps, AWS Code Commit, Gerrit, and SCM-Manager appear in neither. So a team on GitLab.com or Forgejo cannot take a hosted scheduler from this project; their route is the pipeline set, which means they run a runner and they hold credentials for both the forge and the registry themselves. Separately, the README feature list says Renovate connects with private repositories and package registries and links an Accessing private packages guide.

One repository, three toolchains, and a bot that updates itself

This is a TypeScript project that also carries a documentation toolchain in Python and a Renovate configuration for itself. The Node side is pinned through pnpm-lock.yaml and pnpm-workspace.yaml alongside .nvmrc and mise.toml, while the Python side is pinned through uv.lock, .python-version, and a pyproject.toml requiring Python 3.11 or newer. That pyproject is named renovate-docs and pins exactly two dependencies, mkdocs-material at 9.8.0 and mkdocs-awesome-pages-plugin at 2.10.1, so the docs site is deliberately a small thing. The consequence for someone who wants to change behavior rather than prose is that a documentation fix drags three toolchains onto a machine that only needed one. Documentation defects have their own checks: there is a fence check that runs a script named check-fenced-code, and documentation linting executes through the vitest test directory. At the root you also find renovate.json, which means the project points Renovate at its own lockfiles. For contributors, the documented entry points are the good first issues list and the contributing guidelines; no one-line local run command appears here.

Editorial conclusion

Renovate is a sensible default for teams already on GitHub.com or Bitbucket Cloud, where the free hosted app removes both the scheduler and the token handling, and where a 44.x stream put three releases out inside one day. Teams on GitLab.com, Gitea, Forgejo, or Azure DevOps should read the run options as infrastructure they own rather than a setting they import. Before committing, verify which platforms your scheduler actually covers, how the four update signals change your pull request volume, and where a defect report goes when only maintainers open Issues. The AGPL-3.0 license is a fourth item to confirm if you plan to run a self-hosted server inside a company network.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. renovatebot/renovate on GitHub