This version of GitHub Enterprise Server was discontinued on 2024-09-25. No patch releases will be made, even for critical security issues. For better performance, improved security, and new features, upgrade to the latest version of GitHub Enterprise Server. For help with the upgrade, contact GitHub Enterprise support.

About Dependabot version updates

You can use Dependabot to keep the packages you use updated to the latest versions.

Who can use this feature?

Dependabot version updates is available for the following repositories:

  • All repositories on GitHub Enterprise Server

In this article

Note: Your site administrator must set up Dependabot updates for your GitHub Enterprise Server instance before you can use this feature. For more information, see "Enabling Dependabot for your enterprise."

You may not be able to enable or disable Dependabot updates if an enterprise owner has set a policy at the enterprise level. For more information, see "Enforcing policies for code security and analysis for your enterprise."

About Dependabot version updates

Dependabot takes the effort out of maintaining your dependencies. You can use it to ensure that your repository automatically keeps up with the latest releases of the packages and applications it depends on.

For information on the supported repositories and ecosystems, see "Dependabot supported ecosystems and repositories."

You enable Dependabot version updates by checking a dependabot.yml configuration file into your repository. The configuration file specifies the location of the manifest, or of other package definition files, stored in your repository. Dependabot uses this information to check for outdated packages and applications. Dependabot determines if there is a new version of a dependency by looking at the semantic versioning (semver) of the dependency to decide whether it should update to that version. For certain package managers, Dependabot version updates also supports vendoring. Vendored (or cached) dependencies are dependencies that are checked in to a specific directory in a repository rather than referenced in a manifest. Vendored dependencies are available at build time even if package servers are unavailable. Dependabot version updates can be configured to check vendored dependencies for new versions and update them if necessary.

When Dependabot identifies an outdated dependency, it raises a pull request to update the manifest to the latest version of the dependency. For vendored dependencies, Dependabot raises a pull request to replace the outdated dependency with the new version directly. You check that your tests pass, review the changelog and release notes included in the pull request summary, and then merge it. For more information, see "Configuring Dependabot version updates."

If you enable security updates, Dependabot also raises pull requests to update vulnerable dependencies. For more information, see "About Dependabot security updates."

When Dependabot raises pull requests, these pull requests could be for security or version updates:

  • Dependabot security updates are automated pull requests that help you update dependencies with known vulnerabilities.
  • Dependabot version updates are automated pull requests that keep your dependencies updated, even when they don’t have any vulnerabilities. To check the status of version updates, navigate to the Insights tab of your repository, then Dependency Graph, and Dependabot.

Dependabot signs its own commits by default, even if commit signing is not a requirement for the repository. For more information about verified commits, see "About commit signature verification."

Before you enable Dependabot updates, you must configure your GitHub Enterprise Server instance to use GitHub Actions with self-hosted runners. GitHub Actions is required for Dependabot version updates and Dependabot security updates to run on GitHub Enterprise Server. For more information, see "Enabling Dependabot for your enterprise."

Frequency of Dependabot pull requests

You specify how often to check each ecosystem for new versions in the configuration file: daily, weekly, or monthly.

When you first enable version updates, you may have many dependencies that are outdated and some may be many versions behind the latest version. Dependabot checks for outdated dependencies as soon as it's enabled. You may see new pull requests for version updates within minutes of adding the configuration file, depending on the number of manifest files for which you configure updates. Dependabot will also run an update on subsequent changes to the configuration file.

Dependabot may also create pull requests when you change a manifest file after an update has failed. This is because changes to a manifest, such as removing the dependency that caused the update to fail, may cause the newly triggered update to succeed.

To keep pull requests manageable and easy to review, Dependabot raises a maximum of five pull requests to start bringing dependencies up to the latest version. If you merge some of these first pull requests before the next scheduled update, remaining pull requests will be opened on the next update, up to that maximum. You can change the maximum number of open pull requests by setting the open-pull-requests-limit configuration option.

For more information, see "Customizing dependency updates."

If you've enabled security updates, you'll sometimes see extra pull requests for security updates. These are triggered by a Dependabot alert for a dependency on your default branch. Dependabot automatically raises a pull request to update the vulnerable dependency.

About automatic deactivation of Dependabot updates

When maintainers of a repository stop interacting with Dependabot pull requests, Dependabot temporarily pauses its updates and lets you know. This automatic opt-out behavior reduces noise because Dependabot doesn't create pull requests for version and security updates, and doesn't rebase Dependabot pull requests for inactive repositories.

The automatic deactivation of Dependabot updates only applies to repositories where Dependabot has opened pull requests but the pull requests remain untouched. If Dependabot hasn't opened any pull requests, Dependabot will never become paused.

An active repository is a repository for which a user (not Dependabot) has carried out any of the actions below in the last 90 days:

  • Merge or close a Dependabot pull request on the repository.
  • Make a change to the dependabot.yml file for the repository.
  • Manually trigger a security update or a version update.
  • Enable Dependabot security updates for the repository.
  • Use @dependabot commands on pull requests.

An inactive repository is a repository that has at least one Dependabot pull request open for more than 90 days, has been enabled for the full period, and where none of the actions listed above has been taken by a user.

When Dependabot is paused, GitHub adds a banner notice:

  • To all open Dependabot pull requests.
  • To the UI of the Settings tab of the repository (under Code security and analysis, then Dependabot).
  • To the list of Dependabot alerts (if Dependabot security updates are affected).

Additionally, you will be able to see whether Dependabot is paused at the organization-level in the security overview. The paused status will also be visible via the API. For more information, see "REST API endpoints for repositories."

As soon as a maintainer interacts with a Dependabot pull request again, Dependabot will unpause itself:

  • Security updates are automatically resumed for Dependabot alerts.
  • Version updates are automatically resumed with the schedule specified in the dependabot.yml file.

Dependabot also stops rebasing pull requests for version and security updates after 30 days, reducing notifications for inactive Dependabot pull requests.

About notifications for Dependabot version updates

You can filter your notifications on GitHub to show notifications for pull requests created by Dependabot. For more information, see "Managing notifications from your inbox."