Dependabot can keep a project's dependencies moving, but an update bot is only useful when its pull requests fit the time you have to review them. A small project can start with weekly checks, a clear owner for incoming pull requests, and a few carefully chosen groups instead of a daily stream of individual updates.
This guide shows how to configure Dependabot version updates for a repository, reduce avoidable pull-request noise, and enable security updates separately. Dependabot proposes changes in pull requests; you still need to review the change and run the checks your project relies on before merging.
Understand the two kinds of updates
Dependabot version updates look for newer releases, including releases that do not fix a known vulnerability. You configure them in .github/dependabot.yml. The file is committed to the default branch and defines the package ecosystems, manifest locations, and schedule to monitor.
Security updates are pull requests for vulnerable dependencies that have a fix available. They are driven by Dependabot alerts and repository security settings. A dependabot.yml file can customize some details, but adding the file alone does not turn on alerts or security updates.
The distinction matters when you tune schedules or groups: a slower version-update schedule should not be treated as a security response policy. For the wider pull-request process around reviewing changes and checks, see our guide to practical Git and GitHub workflows for small projects.
Check your repository before adding a configuration
Before editing YAML:
- Confirm the package manager and directory. Dependabot needs a supported ecosystem and the location of its manifest or dependency files. In a monorepo, add a separate update entry for each relevant ecosystem and location.
- Commit the lockfile when your package manager uses one. A lockfile helps Dependabot see resolved, including transitive, versions and lets the update include the corresponding lockfile change.
- Use the default branch. Store the file at
.github/dependabot.yml(or.github/dependabot.yaml) in the repository's default branch. - Check access to private dependencies. If Dependabot cannot reach a private registry or dependency source, it may be unable to resolve or update packages. Configure registry access using GitHub's documented repository settings and secret-handling guidance rather than committing credentials.
- Check ecosystem support. GitHub maintains a list of supported ecosystems, repository types, and file formats. Confirm your package manager and lockfile are supported before relying on automated updates.
Start with a weekly configuration
For a small web project with npm dependencies and GitHub Actions workflows, a practical starting point is:
version: 2
updates:
- package-ecosystem: "npm"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5
groups:
development-dependencies:
dependency-type: "development"
update-types:
- "minor"
- "patch"
- package-ecosystem: "github-actions"
directory: "/"
schedule:
interval: "weekly"
open-pull-requests-limit: 5
Save the file as .github/dependabot.yml and commit it to the default branch. Change the ecosystem and directory to match your repository. For example, a project with dependencies in /frontend and /backend needs entries that point to those locations; a root-level example will not automatically cover every folder in a monorepo.
The example checks weekly and caps the number of open version-update pull requests per ecosystem. It groups minor and patch updates for development dependencies into one pull request, while leaving major updates and production dependencies outside that group. This keeps routine tool updates together without hiding a major change among smaller updates. Grouping is an option, not a guarantee that those changes work together: run the project's tests against the complete grouped diff.
For projects with several update locations, use the directories option where supported or add entries for the locations you maintain. Keep each entry specific: a correct ecosystem paired with the wrong directory can leave a project without the updates you expected.
Tune the number and timing of pull requests
Choose a schedule that gives you a predictable review window. Weekly is a reasonable starting point for a project that does not need to track every release immediately; daily checks may suit a project with frequent releases and someone available to review them. You can also set the day, time, and timezone for a scheduled check.
Dependabot applies a three-day default cooldown to version updates, giving a new release time to stabilize before it is considered. The default cooldown does not apply to security updates. GitHub lets you customize cooldowns for version updates when you need a longer wait for selected dependencies or release types.
Use groups to combine related updates when reviewing them together is safe. For example, combining development dependencies with only minor and patch updates can reduce the number of routine pull requests. Keep major updates, production dependencies, or packages with separate test and release procedures in their own pull requests until you have evidence that grouping them is manageable. Security updates are separate from version updates; if you choose to group security pull requests, configure that behavior explicitly and verify the resulting scope.
An open-pull-request limit helps prevent version updates from piling up faster than you can review them. Lowering the limit does not resolve stale pull requests, so set aside a recurring time to merge, close, or investigate them. If updates stop appearing, check the configuration and Dependabot status in the repository's dependency graph settings, as well as any unresolved Dependabot errors.
Use ignore rules for exceptions, not as a maintenance strategy
An ignore rule can prevent matching version updates, such as major updates for a dependency that currently needs a compatibility change. Keep the rule as narrow as possible: identify the specific package and update type, record why it is being skipped, and assign someone to revisit the decision.
Avoid broad rules that ignore whole ecosystems or all major releases. They can conceal work indefinitely, and ignoring an update does not fix a vulnerability or make an outdated dependency safe. When an allow rule and an ignore rule match the same dependency, GitHub documents that the ignored dependency takes precedence. Review the full rule set whenever you add an exception.
Enable security updates separately
For security updates, enable the dependency graph, Dependabot alerts, and Dependabot security updates in the repository's security settings. GitHub says security updates are triggered for dependencies in the graph when an alert has a fix available; the dependency also needs to be represented in a manifest or lockfile for an update pull request.
When security updates are enabled, Dependabot can try to open pull requests for existing alerts that have an available patch. Review the resulting queue rather than assuming that enabling the feature only affects future alerts. If you need to prioritize which alerts get pull requests, GitHub documents auto-triage rules as an alternative to enabling automatic security updates for every eligible alert.
The open-pull-requests-limit setting in the example is for version updates; do not use it as a cap on security work. Security updates may also be grouped, but they are not automatically combined with version-update groups. Keep an eye on alert status and the security update pull requests themselves.
Give the pull requests an owner and a check
Dependabot pull requests need the same review path as other dependency changes. Use the reviewers or assignees options when a particular person or team should be notified; GitHub requires assignees to have repository access. You can also use your existing review rules and code ownership where they fit the changed files.
Before merging an update:
- Read the pull request summary and linked release notes or advisory.
- Check what changed in the manifest and lockfile, including transitive changes.
- Run the tests and build that cover the affected package or workflow.
- Look for breaking changes, new permissions, or behavior changes in a major update.
- Keep security fixes moving through the normal review process without waiting for the next version-update schedule.
Do not enable automatic merging simply to make a queue disappear. If you later automate merges, start with narrow, low-risk updates and require the relevant status checks. A passing check is evidence about the tests that ran, not proof that a dependency is compatible with every use of your application.
Common reasons updates do not appear
- The configuration is invalid: check YAML indentation, the
version: 2field, and required ecosystem, directory, and schedule values. - The wrong directory is configured: make sure the path contains the manifest and lockfile for that package manager.
- A dependency source is private: configure access to the registry or repository so Dependabot can resolve it.
- The ecosystem or file is unsupported: confirm the exact manager and file format in GitHub's supported-ecosystems reference.
- The update is intentionally filtered: inspect
ignore,allow, groups, and the open-pull-request limit. - The project uses another dependency-management integration: check whether it must be disabled before enabling Dependabot.
GitHub's Dependabot status and error details can help distinguish a configuration problem from an update that is blocked by package compatibility or missing access.
A sustainable rollout for a small project
Start with the package manager that matters most, add GitHub Actions if you maintain workflows, and begin with a weekly schedule. Let a few update pull requests arrive before adding more ecosystems or grouping rules. Use tests to decide which routine changes can be grouped; keep higher-risk updates easy to inspect.
Then enable security updates after confirming the dependency graph and alerts are working. Set a recurring review time, assign the pull requests to an owner, and remove exceptions when the underlying compatibility issue is fixed. The goal is not to merge every update immediately; it is to keep routine maintenance visible and make security fixes straightforward to act on.