A dependency update bot is a service that reads your manifests and lockfiles, looks up newer versions of each dependency, and opens a pull request for each change or group of changes. It automates the finding and the editing. It does not decide whether an update is safe for your product.
What a bot does, step by step
- It scans the repository for manifest files such as package.json, requirements files or build files, plus lockfiles.
- It asks the package registry which newer versions exist for each dependency.
- It filters those against your rules: which packages to include, which update types to skip, how long to wait after release.
- It creates a branch with the edit, opens a pull request, and lets your normal CI run.
- It waits. A person, or an auto-merge rule, decides what happens next.
Common settings from the documentation of one widely used hosted bot show the shape of the control surface: a schedule interval (daily through yearly, or a cron expression), a limit on open version-update pull requests (5 by default), groups that combine updates into one pull request, a cooldown that delays brand new releases (3 days by default if unset), and ignore and allow rules by name or update type. Renovate-style bots expose a similar set, including a default cap of 10 open pull requests and an automerge option that is off by default.
Two kinds of update
Most bots separate two jobs. Version updates keep you current. Security updates react to a published advisory for a version you use. They deserve different handling: you may want slow, batched, delayed version updates and fast, immediate security updates. At least one documented bot applies its cooldown only to version updates, not to security updates, and keeps a separate, fixed limit for security pull requests.
What a bot cannot judge
A bot compares version numbers. It does not know:
- Whether the change breaks your code, which is what your tests are for.
- Whether the new release is trustworthy. A freshly published version can be malicious or broken, which is why delay settings exist.
- Whether the package is still maintained.
- Whether the vulnerable code is reachable from your application.
That last point is why many teams pair a bot with analysis that ties advisories to actual call paths.
Choosing what to automate
| Task | Automate? | Why |
|---|---|---|
| Finding newer versions | Yes | Pure lookup |
| Opening pull requests | Yes | Saves editing time |
| Running tests on them | Yes | Your CI already does this |
| Merging patch updates with strong tests | Maybe | Depends on test quality |
| Merging majors or 0.x minors | No | Needs human reading |
Getting started safely
Start with one repository, a weekly schedule and a small open pull request limit. Watch how many you merge unchanged. If most are merged without edits, group them. If many fail CI, your tests or your version ranges need attention before you add automation.
Try it yourself
Click through it at your own pace, or open it full screen. See the dependency list a bot works from, including transitive packages that your manifest never names directly.
Quick check
Does a bot replace code review?
No. It replaces the manual search for new versions and the file editing. Someone or something still has to judge whether a change is safe.
Should I let it open as many pull requests as it wants?
Usually not. A cap keeps review realistic. The default for one documented bot is 5 open version-update pull requests.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
