Note: Dependabot version updates are currently in beta and subject to change. To use the beta feature, check in a configuration file to tell Dependabot which dependencies to maintain for you. For details, see "Enabling and disabling 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.
You enable Dependabot version updates by checking a 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 "Enabling and disabling version updates."
If you enable security updates, Dependabot also raises pull requests to update vulnerable dependencies. For more information, see "About Dependabot security updates."
Dependabot and all related features are covered by GitHub's Terms of Service.
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.
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, then further pull requests are opened up to a maximum of five (you can change this limit).
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.
You can configure version updates for repositories that contain a dependency manifest or lock file for one of the supported package managers. For some package managers, you can also configure vendoring for dependencies. For more information, see "Configuration options for dependency updates."
When running security or version updates, some ecosystems must be able to resolve all dependencies from their source to verify that updates have been successful. If your manifest or lock files contain any private dependencies, Dependabot must be able to access the location at which those dependencies are hosted. Organization owners can grant Dependabot access to private repositories containing dependencies for a project within the same organization. For more information, see "Managing security and analysis settings for your organization."
Currently, Dependabot version updates doesn't support manifest or lock files that contain any dependencies hosted in private registries, or in private GitHub repositories that belong to a different organization than the dependent project. Additionally, Dependabot doesn't support private GitHub dependencies for all package managers. See the details in the table below.
The following table shows, for each package manager:
- The YAML value to use in the dependabot.yml file
- The supported versions of the package manager
- Whether dependencies in private GitHub repositories are supported
- Whether vendored dependencies are supported
|Package manager||YAML value||Supported versions||Private repositories||Vendoring|
|git submodule||N/A (no version)||✓|
|GitHub Actions||N/A (no version)||✓|
|Gradle||N/A (no version)||✓|
|Maven||N/A (no version)||✓|
 Dependabot doesn't run Gradle but supports updates to the following files:
build.gradle.kts (for Kotlin projects).
 Dependabot doesn't run Maven but supports updates to
 Dependabot doesn't run the NuGet CLI but does support most features up until version 4.8.
For package managers such as
poetry, you need to use the
pip YAML value. For example, if you use
poetry to manage your Python dependencies and want Dependabot to monitor your dependency manifest file for new versions, use
package-ecosystem: "pip" in your dependabot.yml file.
If your repository already uses an integration for dependency management, you will need to disable this before enabling Dependabot. For more information, see "About integrations."
You can filter your notifications on GitHub to show Dependabot version updates. For more information, see "Managing notifications from your inbox."