Renovate CLI: automated dependency updates across npm, Docker, Go and 90+ package managers

The problem Renovate solves, and who actually needs it

Dependency drift is a maintenance tax. A repository with a pnpm lockfile, a Dockerfile, a GitHub Actions workflow and a Python requirements file has four separate update surfaces, and each one goes stale on its own schedule. Renovate's stated job is to look for references to dependencies, both public and private, and create pull requests when newer versions are available. That framing matters: the output is a pull request, not an upgraded lockfile committed behind your back.

The intended audience is teams running repositories on GitHub, GitLab, Bitbucket, Azure DevOps, AWS Code Commit, Gitea, Forgejo, Gerrit or SCM-Manager. The README flags AWS Code Commit, Gerrit and SCM-Manager as experimental, which is worth reading literally. If your platform is one of those three, you are on the edge of what the project claims to support.

Renovate claims support for over 90 package managers, spanning npm, Java, Python, .NET, Scala, Ruby, Go and Docker. That breadth is the reason to pick it over a single-ecosystem tool. It is also the reason configuration gets complicated: the more managers it detects, the more defaults apply to files you may not have thought about.

How Renovate finds package files and turns them into pull requests

The flow is detect, look up, propose. Renovate runs against a repository, discovers relevant package files automatically, and for each dependency reference checks whether a newer version exists in the corresponding registry. Where one does, it generates a pull request in that repository.

Two details in the README shape how you operate it. First, Renovate connects to private repositories and package registries, so the lookup step is not limited to public npm or Docker Hub. Second, the pull requests carry decision-support data: age, adoption, pass rates and merge confidence. Merge confidence is documented separately on the docs site, which suggests it is a distinct data source rather than something computed purely from your own repository history. Treat that as something to read up on before you rely on it for merge decisions.

The README is explicit that the most effective way to run Renovate is an automated job scheduling system that regularly runs it across all enabled repositories and responds with priority to user activity. That is a statement about scheduling, not about the tool's internals: a single ad hoc CLI invocation will not keep a fleet of repositories current, because nothing triggers the next run.

Installing Renovate and running your first scan locally

The README points to the Running Renovate documentation page for all CLI options, and to community tools for additional community-maintained ways to run it. The package.json declares two binaries, renovate and renovate-config-validator, both under dist/, which is what a package-manager install exposes on your PATH.

The README gives npx renovate as the invocation used inside a custom pipeline. That is the shortest path to a local run. Set a platform token in the environment and point Renovate at a repository; the README does not spell out a full local walkthrough, so expect to read the Running Renovate page before your first real run.

npx renovate

Before running it against anything you care about, validate your configuration. The repository ships a dedicated binary for this, and the package.json exposes it as a script named config-validator that runs node lib/config-validator.ts.

npx renovate-config-validator

If you prefer a container, the README links the renovate/renovate image on Docker Hub via its badge. The repository also contains a build:docker script (node tools/docker.ts) and a .dockerignore, so image builds are part of the project's own tooling rather than an afterthought. The README does not document the container's environment variables or entrypoint, so check the docs before assuming flags map one to one.

A minimal config lives in renovate.json at the repository root, which is also where the project keeps its own configuration.

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json"
}

The build pipeline generates renovate-schema.json, renovate-inherited-schema.json and renovate-global-schema.json through tools/generate-schema.ts. Pointing your editor at the published schema is what makes the config keys discoverable, since the README does not enumerate them.

Where Renovate is the wrong tool

The hosted community offering covers GitHub.com and Bitbucket Cloud only. If your code lives on GitLab, Bitbucket Data Center, Gitea, Forgejo or Azure DevOps, the cloud-hosted route is closed to you, and you are choosing between the self-hosted community server and a pipeline job you operate yourself. That is a real operational commitment, not a checkbox.

Licensing is the second boundary. The repository is AGPL-3.0-only, and the README's own badge links to the license file. AGPL-3.0 is a copyleft licence with a network-use clause. If you intend to embed Renovate inside a service you expose to users, the licence text is what governs that, not this article. The README does not discuss commercial relicensing terms for the CLI; it directs commercial support questions to Mend.io, which is a different subject.

The third boundary is scope. Renovate updates dependency references. It does not audit your code, and the security section of the README is about reporting bugs in Renovate itself through GitHub Security Advisories, not about scanning your dependencies for vulnerabilities. If your goal is a vulnerability report rather than a version bump, this is not that tool.

Finally, the README states that only maintainers should open Issues, and that help requests, feature suggestions and bug reports go to GitHub Discussions. Teams used to filing issues directly will find that workflow unusual.

Renovate versus Dependabot: the difference is configuration surface

The README links a bot comparison page at docs.renovatebot.com/bot-comparison, so the project itself treats Dependabot as the reference point. The practical difference is not the concept, since both open update pull requests. It is the number of ecosystems and the shape of the configuration.

Dependabot is tied to GitHub and to the ecosystems GitHub supports. Renovate lists GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo and more as platforms, and claims over 90 package managers. If your organization runs repositories on more than one forge, that platform list is the deciding factor.

The second difference is configurability. Renovate's own description is "Automated dependency updates. Flexible so you don't need to be." The flexibility is real and it is also the cost: a preset system, an inherited schema, a global schema and a config validator exist because the configuration space is large. Dependabot's configuration is smaller, which means fewer decisions and less to get wrong. A team that wants defaults and nothing else is not obviously better served by Renovate.

Maintenance, release cadence and what upgrading costs you

The last push to the default branch was on 2026-09-20, and the most recent releases listed are 44.103.6, 44.103.5 and 44.103.4, all dated 2026-09-20. Patch releases landing within hours of each other is the visible pattern. The README states the project is supported and maintained by Mend.io.

That cadence has a direct consequence for anyone self-hosting: you are not pinning to a stable line and staying there for a year. If you run the CLI through npx without pinning, you are pulling whatever the current release is. If you run the container image, the tag you choose determines how often you rebuild. The README does not document a long-term support policy, and the version string in package.json is 0.0.0-semantic-release, which tells you versions are assigned by the release tooling rather than declared in the manifest.

Upgrade cost is mostly configuration drift. Renovate's own repository carries renovate.json, and the build step regenerates three JSON schemas, so config keys can change shape between versions. Running renovate-config-validator before an upgrade is the cheap check. The README does not document a rollback procedure, so keep the previous container tag or pinned version available yourself.

Editorial conclusion

Adopt Renovate if you have more than a handful of repositories and want update pull requests generated per package file rather than per ecosystem. Skip it if you only need a single-language bot on GitHub.com and no configuration beyond defaults, since the hosted app covers that with no setup. Before rolling it out broadly, verify three things: that your platform is listed as supported or experimental, that your config passes renovate-config-validator, and how you intend to run it (hosted app, self-hosted server, or a scheduled pipeline job), because the README states the most effective setup is a job scheduling system that runs Renovate regularly and responds to user activity.

Frequently asked questions

Official sources

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