Usually yes. A scheduled lockfile refresh updates the exact versions you install, including indirect dependencies, without changing the ranges you declared. It picks up patched transitive packages that normal update pull requests may never touch. Run it weekly or monthly, review the diff, and consider automerging when tests pass.
What lockfile maintenance actually does
A manifest says what you accept, such as a range of versions. A lockfile records what you actually installed. Over time the lockfile ages even though your manifest still allows newer versions.
In the documentation of one update bot, lockfile maintenance deletes the lockfile and runs the package manager again. The package manager writes a new lockfile with every dependency at the newest version that still satisfies your manifest constraints. The tool commits that result and opens a pull request. Your declared dependencies stay as they were. The same page calls this probably the lowest risk update to automerge, and its default schedule is before 4 am on Monday, with the feature off until you enable it.
Why it helps security
Most packages in a tree are indirect. You never named them, so a tool that only bumps direct dependencies may leave them alone for years. If a patched version of an indirect package exists and your declared ranges allow it, a refresh picks it up. That can close advisories without a single manifest edit. Our post on fixing a vulnerable transitive dependency covers cases where a refresh is not enough.
It also has limits. If an indirect package is pinned by something above it, the refresh will not move it. And a refresh cannot cross a range boundary. A major version outside your declared range needs a real manifest change.
Pros and cons
| Benefit | Cost |
|---|---|
| Picks up patched indirect packages | Many version changes in one pull request |
| No change to declared ranges | A bad release in the range can still break you |
| One pull request replaces many small ones | Review of a large lockfile diff is hard |
| Easy to automate | Needs good tests before automerge |
How to run it well
- Pick a cadence. Weekly suits active projects. Monthly suits quiet ones.
- Schedule it outside working hours, so CI load and notifications stay low.
- Read the diff for new packages. A refresh can add an indirect package that was not there before, so scan for unfamiliar names.
- Run your normal tests plus a dependency scan on the pull request.
- Automerge only when your tests are meaningful. The bot's documentation is clear that automerge needs required checks to be useful.
- Keep a record of which refreshes were merged so you can bisect if something breaks.
Different from a version bump
A refresh is not the same as an upgrade pull request for one package. It does not explain why a version moved and it does not carry a changelog for one project. That is why a large refresh deserves a scan, not just a green build. Compare the before and after dependency lists, and check for new licenses and new maintainers of anything you did not have before.
Try it yourself
Click through it at your own pace, or open it full screen.
Open the inventory and compare direct and indirect packages, which shows how much of your tree a lockfile refresh actually moves.
Quick check
Does a refresh change my package.json or equivalent?
In the documentation we read, no. It leaves dependency definitions unchanged and refreshes the lockfile within your constraints.
Can a refresh introduce a bad package?
It can pull in a new release that fits your range, so scan the result and review newly added packages before merging.
Safeguard builds an SBOM and dependency inventory from manifests and lockfiles and uses reachability analysis to show which flagged packages your code calls. Policies and gates can check a refresh pull request before merge. Fix pull requests are off by default, with every category on Manual. Try a free scan.
Sources
- Update bot documentation: automerge and lockfile maintenance
- Update bot documentation: configuration options, lockfile maintenance
Last reviewed: 19 October 2026.
