For a library, leave Dependabot on its default, auto, which uses widen: it loosens your allowed range to include the new version instead of forcing everyone up. Use increase when a security fix means old versions must no longer be allowed. Apps default to increase.
What the strategies mean
GitHub's Dependabot options reference lists the values for versioning-strategy. It is available for bundler, cargo, composer, helm, mix, npm, pip, pub and uv.
| Value | What it does to your manifest |
|---|---|
auto | Default. Treats apps and libraries differently |
increase | Raises the minimum version to match the new release |
increase-if-necessary | Leaves the range alone if it already allows the new version, otherwise widens it |
widen | Widens the range to include both old and new versions |
lockfile-only | Only updates lockfiles, ignoring updates that need manifest changes |
The documentation gives an example. Starting at version 1.0.0 with the constraint ^1.0.0, a new 1.2.0 gives ^1.2.0 under increase, but stays ^1.0.0 under increase-if-necessary and widen. A new 2.0.0 gives ^2.0.0 under increase and increase-if-necessary, and >=1.0.0 <3.0.0 under widen.
Why libraries default to widen
A library's manifest is a promise to downstream users about which versions it works with. Raising the lower bound every time a dependency releases shrinks that promise and can cause version conflicts in your users' projects, since two libraries may need different ranges of the same package.
Widening keeps the promise broad. Your CI tests the newest version, and your users keep flexibility.
When a library should raise the lower bound
Security is the exception. If an advisory says every version below 2.4.1 is vulnerable and your code can reach the flaw, a range that still allows 2.3.0 lets a user's resolver pick a vulnerable release. In that case raise the minimum deliberately.
Steps:
- Read the advisory and confirm the first patched version.
- Decide whether your library is actually affected. If it never calls the vulnerable code, you may not need to force the floor up (see the related post on publishing an advisory when a dependency is vulnerable).
- If affected, raise the lower bound in the manifest, run tests, and ship a patch release.
- Note the change in the release notes so users know why the floor moved.
You can do step 3 by hand, or set increase for a single ecosystem entry in a short window and then revert to auto.
A starter config
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5
This leaves versioning-strategy at auto. Security update pull requests have their own limit of 10 that this option does not control, according to the same reference.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a fix being available is a separate fact from whether your range allows it.
Quick check
What is the default versioning strategy for a library?
widen, chosen by auto. For applications auto uses increase.
Does widen make my library less secure?
Not by itself. It keeps ranges broad, so a vulnerable old version stays allowed until you raise the floor. Do that when an advisory affects code you use.
Safeguard can map which of your dependencies are reachable and open fix pull requests, which are off by default and every category starts on Manual. You can start with the free scan.
Sources
- GitHub docs, Dependabot options reference: https://docs.github.com/en/code-security/dependabot/working-with-dependabot/dependabot-options-reference
Last reviewed: 19 October 2026.
