Dependabot options reference

Detailed information for all the options you can use to customize how Dependabot maintains your repositories.

This article provides reference information for the configuration options available in the dependabot.yml file. Use these options to customize how Dependabot monitors package ecosystems, schedules updates, and creates pull requests. For an overview of the dependabot.yml file and how it works, see About the dependabot.yml file.

All options marked with a icon also change how Dependabot creates pull requests for security updates, except where target-branch is used.

Required keys

Optionally, you can also include a top-level registries key to define access details for private registries, see Top-level registries key.

# Basic `dependabot.yml` file with
# minimum configuration for two package managers

version: 2
updates:
  # Enable version updates for npm
  - package-ecosystem: "npm"
    # Look for `package.json` and `lock` files in the `root` directory
    directory: "/"
    # Check the npm registry for updates every day (weekdays)
    schedule:
      interval: "daily"

  # Enable version updates for Docker
  - package-ecosystem: "docker"
    # Look for a `Dockerfile` in the `root` directory
    directory: "/"
    # Check for updates once a week
    schedule:
      interval: "weekly"

For a real-world example of a dependabot.yml file, see Dependabot's own configuration file.

allow

Use to define exactly which dependencies to maintain for a package ecosystem. Often used with the ignore option. For examples, see Controlling which dependencies are updated by Dependabot.

Dependabot default behavior:

• All dependencies explicitly defined in a manifest are kept up to date by version updates.
• All dependencies defined in lock files with vulnerable dependencies are updated by security updates.

When allow is specified Dependabot uses the following process:

1. Check for all explicitly allowed dependencies.

2. Then filter out any ignored dependencies or versions.

   If a dependency is matched by an allow and an ignore statement, then it is ignored.

dependency-name (allow)

For most package managers, you should define a value that will match the dependency name specified in the lock or manifest file. A few systems have more complex requirements.

dependency-type (allow)

update-types (allow)

update-types only affects version updates, not security updates.

Specify which semantic versions (SemVer) to allow.

SemVer is an accepted standard for defining versions of software packages, in the form x.y.z. Dependabot assumes that versions in this form are always major.minor.patch. The update-types value is a list of one or more strings.

• Use version-update:semver-patch to allow patch releases.
• Use version-update:semver-minor to allow minor releases.
• Use version-update:semver-major to allow major releases.

When update-types is omitted from an allow rule, all update types are allowed for that rule.

You can combine update-types with dependency-name or dependency-type to further narrow allowed updates. For examples of how you can combine these options, see Controlling which dependencies are updated by Dependabot.

assignees

Specify individual assignees for all pull requests raised for a package ecosystem. For examples, see Customizing Dependabot pull requests to fit your processes.

Dependabot default behavior:

• Pull requests are created without any assignees.

When assignees is defined:

• All pull requests for version updates are created with the chosen assignees.
• All pull requests for security updates are created with the chosen assignees, unless target-branch defines updates to a non-default branch.

Assignees must have write access to the repository. For organization-owned repositories, organization members with read access are also valid assignees.

commit-message

Define the format for commit messages. Since the titles of pull requests are written based on commit messages, this setting also impacts the titles of pull requests. For examples, see Customizing Dependabot pull requests to fit your processes.

Dependabot default behavior:

• Commit messages follow similar patterns to those detected in the repository.

When commit-message is defined:

• All commit messages follow the defined pattern.
• All commit messages follow the defined pattern, unless target-branch defines updates to a non-default branch.

prefix

• Used for all commit messages unless prefix-development is also defined.
• Value can be up to 50 characters.
• Dependabot inserts a colon after the prefix before adding the main commit message when the value ends with a letter, number, closing parenthesis, or closing bracket.
• End the value with a whitespace character to stop a colon being added.

prefix-development

Supported by: bundler, composer, mix, maven, npm, pip, and uv.

• Used only for commit messages that update dependencies in the Development dependency group.
• Otherwise, the parameter behaves exactly as the prefix parameter.

include

• Supports only the value scope
• When defined any prefix is followed by the type of dependencies updated in the commit: deps or deps-dev.

cooldown

Defines a cooldown period for dependency updates, allowing updates to be delayed for a configurable number of days. The cooldown option is only available for version updates, not security updates.

This feature enables users to customize how often Dependabot generates new version updates, offering greater control over update frequency. For examples, see Optimizing the creation of pull requests for Dependabot version updates.

Dependabot default behavior:

• Check for updates according to the schedule defined via schedule.interval.
• Apply a default cooldown period of 3 days to version updates, even when cooldown is not configured. A new version is not considered for a version update until 3 days after its release. This default cooldown does not apply to security updates.

You can configure the cooldown option to customize these default cooldown periods and control which dependencies they apply to. When cooldown is defined:

1. Dependabot checks for updates according to the defined schedule.interval settings.
2. Dependabot checks for any cooldown settings.
3. If a dependency’s new release falls within its cooldown period, Dependabot skips updating the version for that dependency.
4. Dependencies without a cooldown period, or those past their cooldown period, are updated to the latest version as per the configured versioning-strategy setting.
5. After a cooldown ends for a dependency, Dependabot resumes updating the dependency following the standard update strategy defined in dependabot.yml.

Configuration of cooldown

You can specify the duration of the cooldown using the options below.

The table below shows the package managers that support cooldown. The default-days option is supported for all package managers listed, while semver-major-days, semver-minor-days, and semver-patch-days are supported only where indicated.

directories or directory

Required option. Use to define the location of the package manifests for each package manager (for example, the package.json or Gemfile). Without this information Dependabot cannot create pull requests for version updates. For examples, see Defining multiple locations for manifest files.

• Use directory to define a single directory of manifests.

• Use directories to define a list of multiple directories of manifests.

• Define directories relative to the root of the repository for most package managers.

• For GitHub Actions, use the value /. Dependabot will search the /.github/workflows directory, as well as the action.yml/action.yaml file from the root directory.

• For Dev containers, use the value /. Dependabot will search the .devcontainer.json, .devcontainer/devcontainer.json, and .devcontainer/<anything>/devcontainer.json files from the root directory.

If you need to use more than one block in the configuration file to define updates for a single target branch of an ecosystem, you must ensure that all values are unique and there is no overlap in directories defined.

enable-beta-ecosystems

Not currently in use.

groups

Define rules to create one or more sets of dependencies managed by a package manager, to group updates into fewer, targeted pull requests. For examples, see Optimizing the creation of pull requests for Dependabot version updates.

Dependabot default behavior:

• Open a single pull request for each dependency that needs to be updated to a newer version for version updates and for security updates.

When groups is used to define rules:

• All updates for dependencies that match a rule are combined in a single pull request.
• If a dependency matches more than one rule, it's included in the first group that it matches.
• Any outdated dependencies that do not match a rule are updated in individual pull requests.

dependency-type (groups)

Supported by: bundler, composer, mix, maven, npm, and pip.

By default, a group will include all types of dependencies.

• Use development to include only dependencies in the "Development dependency group."
• Use production to include only dependencies in the "Production dependency group."

group-by (groups)

Use groups.<group-name>.group-by to specify how Dependabot should group updates across multiple directories in a monorepo.

• Type: String
• Accepted values: dependency-name
• Applies to: Configurations with multiple directories specified

When set to dependency-name, Dependabot will create a single pull request for each dependency update across all specified directories, rather than separate pull requests per directory.

Limitations of cross-directory grouping

When using group-by: dependency-name:

• All directories must use the same package ecosystem (for example, all npm or all bundler)
• Applies to version updates only
• If directories have incompatible version constraints for a dependency, Dependabot will create separate pull requests

For examples showing the use of group-by, see Optimizing the creation of pull requests for Dependabot version updates.

patterns and exclude-patterns (groups)

Both options support using * as a wild card to define matches with dependency names. If a dependency matches both a pattern and an exclude-pattern, then it is excluded from the group.

update-types (groups)

By default, a group will include updates for all semantic versions (SemVer). SemVer is an accepted standard for defining versions of software packages, in the form x.y.z. Dependabot assumes that versions in this form are always major.minor.patch.

• Use patch to include patch releases.
• Use minor to include minor releases.
• Use major to include major releases.

For examples, see Controlling which dependencies are updated by Dependabot.

ignore

Use with the allow option to define exactly which dependencies to maintain for a package ecosystem. Dependabot checks for all allowed dependencies and then filters out any ignored dependencies or versions. So a dependency that is matched by both an allow and an ignore will be ignored. For examples, see Controlling which dependencies are updated by Dependabot.

Dependabot default behavior:

• All dependencies explicitly defined in a manifest are kept up to date by version updates.
• All dependencies defined in lock files with vulnerable dependencies are updated by security updates.

When ignore is used Dependabot uses the following process:

1. Check for all explicitly allowed dependencies.

2. Then filter out any ignored dependencies or versions.

   If a dependency is matched by an allow and an ignore statement, then it is ignored.

dependency-name (ignore)

For most package managers, you should define a value that will match the dependency name specified in the lock or manifest file. A few systems have more complex requirements.

versions (ignore)

Use to ignore specific versions or ranges of versions. If you want to define a range, use the standard pattern for the package manager. For example:

• npm: use ^1.0.0
• Bundler: use ~> 2.0
• Docker: use Bundler version syntax
• NuGet: use 7.*
• Maven: use [1.4,)

For examples, see Controlling which dependencies are updated by Dependabot.

update-types (ignore)

Specify which semantic versions (SemVer) to ignore. SemVer is an accepted standard for defining versions of software packages, in the form x.y.z. Dependabot assumes that versions in this form are always major.minor.patch.

• Use version-update:semver-patch to include patch releases.
• Use version-update:semver-minor to include minor releases.
• Use version-update:semver-major to include major releases.

insecure-external-code-execution

Supported by: bundler, mix, and pip.

Allow Dependabot to execute external code in the manifest during updates. For examples, see Allowing external code execution.

Dependabot default behavior:

• When you give Dependabot access to one or more registries, external code execution is automatically disabled to protect your code from compromised packages.
• Version updates may fail without the ability to execute code.

When you allow insecure-external-code-execution:

• Dependabot will execute code in the manifest as part of the version update process.
• The code has access to only the package managers in the registries associated with that updatessetting. There is no access allowed to any of the registries defined in the top level registries configuration.
• This should enable the update to succeed but also could allow a compromised package to steal credentials or gain access to configured registries.

Supported value: allow.

labels

Specify your own labels for all pull requests raised for a package manager. For examples, see Customizing Dependabot pull requests to fit your processes.

Dependabot default behavior:

• All pull requests have a dependencies label.
• An additional label for the ecosystem or language is added to each pull request, including when you define only one package manager. For example: java for Gradle updates and submodules for git submodule updates.
• If semantic version (SemVer) labels are present in the repository, they will be applied automatically to indicate the type of version update (major, minor, or patch).
• Dependabot creates these default labels automatically, as necessary in your repository.

When labels is defined:

• The labels specified are used instead of the default labels.
• SemVer labels (if present in the repository) will still be applied in addition to any custom labels defined.
• If any of these labels is not defined in the repository, it is ignored.
• You can disable all labels, including the default labels, using labels: [ ].

Setting this option will also affect pull requests for security updates to the manifest files of this package manager, unless you use target-branch to check for version updates on a non-default branch.

milestone

Associate all pull requests raised for a package manager with a milestone. For examples, see Customizing Dependabot pull requests to fit your processes.

Dependabot default behavior:

• No milestones are used.

When milestone is defined:

• All pull requests for the package manager are added to the milestone.

Supported value: the numeric identifier of a milestone.

multi-ecosystem-groups

Define groups that span multiple package ecosystems to get a single Dependabot pull request that updates all supported package ecosystems. This approach helps reduce the number of Dependabot pull requests you receive and streamlines your dependency update workflow.

Dependabot default behavior:

• Create separate pull requests for each package ecosystem that has dependency updates.

When multi-ecosystem-groups is used:

• Updates across multiple package ecosystems in the same group are combined into a single pull request.
• Groups have their own schedules and can inherit or override individual ecosystem settings.

multi-ecosystem-group

Assign individual package ecosystems to a multi-ecosystem group using the multi-ecosystem-group parameter in your updates configuration.

# Basic `dependabot.yml` file defining a multi-ecosystem-group
version: 2

multi-ecosystem-groups:
  infrastructure:
    schedule:
      interval: "weekly"

updates:
  - package-ecosystem: "docker"
    directory: "/"
    patterns: ["nginx", "redis"]
    multi-ecosystem-group: "infrastructure"

  - package-ecosystem: "terraform"
    directory: "/"
    patterns: ["aws"]
    multi-ecosystem-group: "infrastructure"

open-pull-requests-limit

Change the limit on the maximum number of pull requests for version updates open at any time.

Dependabot default behavior:

• If five pull requests with version updates are open, no further pull requests are raised until some of those open requests are merged or closed.

When open-pull-requests-limit is defined:

• Dependabot opens pull requests up to the defined integer value. A large value can be set to effectively remove the open pull request limit.
• You can temporarily disable version updates for a package manager by setting this option to zero, see Disabling Dependabot version updates.

When either limit is reached, Dependabot reports an error and stops opening additional pull requests until some of the open pull requests are merged or closed. For more information, see Dependabot errors.

package-ecosystem

Required option. Define one package-ecosystem element for each package manager that you want Dependabot to monitor for new versions. The repository must also contain a dependency manifest or lock file for each package manager, see Example dependabot.yml file.

pull-request-branch-name

Configure how Dependabot generates branch names for pull requests. You can customize the separator, prefix, length, casing, word separator, and provide a custom template. For examples, see Customizing Dependabot pull requests to fit your processes.

Dependabot default behavior:

• Generate branch names of the form: dependabot/PACKAGE-MANAGER/DEPENDENCY

All options are composable. When template is set alongside simple options, the processing order is:

1. Template rendering (placeholder substitution)
2. Separator replacement (/ replaced with configured separator)
3. Word-separator replacement (_ replaced with configured word-separator)
4. Case transformation applied to content after the prefix
5. Max-length truncation

separator

Specify a character to use in place of / between branch name segments.

Supported values: "-", _, /

For example, with separator: "-": dependabot/npm_and_yarn/lodash-4.17.21 becomes dependabot-npm_and_yarn-lodash-4.17.21.

prefix

Specify a custom string to use at the start of the branch name instead of the default dependabot.

The value can be up to 50 characters.

For example, with prefix: "deps": dependabot/npm_and_yarn/lodash-4.17.21 becomes deps/npm_and_yarn/lodash-4.17.21.

max-length

Set the maximum allowed length for generated branch names.

• Minimum value: 20.
• Maximum value: 244.
• Default value: 100.
• When a branch name exceeds this limit, it is truncated and a hash suffix is appended to preserve uniqueness.

For example, with max-length: 40, a branch name like dependabot/npm_and_yarn/some-long-dependency-name-1.0.0 is truncated to 40 characters with a hash suffix.

word-separator

Specify a character to replace underscores (_) in all branch name content after the prefix—including package manager names, dependency names, group names, and directory paths.

For example, with word-separator: "-":

• npm_and_yarn → npm-and-yarn
• front_end_dir → front-end-dir

branch-name-case

Apply a case transformation to the branch name content after the prefix.

Supported values: "lowercase", "uppercase"

For example, with branch-name-case: "lowercase": dependabot/npm_and_yarn/Lodash-4.17.21 becomes dependabot/npm_and_yarn/lodash-4.17.21.

template

Define a custom branch name format using placeholders. The template gives you full control over the structure of generated branch names. For examples, see Customizing Dependabot pull requests to fit your processes.

Available placeholders depend on the update strategy:

Template validation rules:

• All placeholders must be recognized and allowed for the update strategy in use.
• Braces must be well-formed (no unclosed { or }).
• Using {package_manager} in a multi-ecosystem group template raises a validation error because no single package manager applies.
• The rendered branch name must be a valid Git reference name. Characters such as spaces, ~, ^, :, ?, *, [, and \ are not allowed, and sequences like .. or @{ are rejected.
• For grouped and multi-ecosystem updates, a 10-character digest is automatically appended to the branch name to guarantee uniqueness. This is not user-controlled.

rebase-strategy

Disable automatic rebasing of pull requests raised by Dependabot.

Dependabot default behavior is to rebase open pull requests when Dependabot detects any changes to a version or security update pull request. Dependabot checks for changes when:

• Your schedule runs to check for version updates.
• You reopen a closed Dependabot pull request.
• You change the value of target-branch in the Dependabot configuration file, see target-branch.
• A Dependabot pull request is in conflict after a recent push to the target branch.

When rebase-strategy is set to disabled, Dependabot stops rebasing pull requests.

registries

Configure access to private package registries to allow Dependabot to update a wider range of dependencies, see Configuring access to private registries for Dependabot and Guidance for the configuration of private registries for Dependabot.

There are 2 locations in the dependabot.yml file where you can use the registries key:

1. At the top level, where you define the private registries you want to use and their access information, see Configuring access to private registries for Dependabot.
2. Within the updates blocks, where you can specify which private registries each package manager should use.

Each updates block can reference up to 100 registries from the top-level registries section.

Dependabot default behavior is to raise pull requests only to update dependencies stored in publicly accessible registries.

When the Dependabot configuration file has a top-level registries section, defining access to one or more private registries, you can configure each package-ecosystem to use one or more of these private registries.

When registries is defined for a package manager:

• Each private registry specified for a package manager is checked for version and security updates.
• Dependabot uses the access details defined in the top-level registries section.

Supported values: REGISTRY_NAME or "*"

schedule

Required option. Define how often to check for new versions for each package manager you configure using the interval parameter. Optionally, for daily and weekly intervals, you can customize when Dependabot checks for updates. For examples, see Optimizing the creation of pull requests for Dependabot version updates.

interval

Supported values: daily, weekly, monthly, quarterly, semiannually, yearly, or cron

Each package manager must define a schedule interval.

• Use daily to run on every weekday, Monday to Friday.
• Use weekly to run once a week, by default on Monday.
• Use monthly to run on the first day of each month.
• Use quarterly to run on the first day of each quarter (January, April, July, and October).
• Use semiannually to run every six months, on the first day of January and July.
• Use yearly to run on the first day of January.
• Use cron for cron expression based scheduling option. See cronjob.

By default, Dependabot randomly assigns a time to apply all the updates in the configuration file. You can use the time and timezone parameters to set a specific runtime for all intervals. If you use a cron interval, you can define the update time with a cronjob expression.

day

Supported values: monday, tuesday, wednesday, thursday, friday, saturday, or sunday

Optionally, run weekly updates for a package manager on a specific day of the week.

time

Format: hh:mm

Optionally, run all updates for a package manager at a specific time of day. By default, times are interpreted as UTC.

cronjob

Supported values: Valid cron expression in cron syntax or natural expression.

Cron syntax has five fields separated by a space, and each field represents a unit of time.

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
* * * * *

Examples : 0 9 * * *, every day at 5pm

0 9 * * * is equivalent to "every day at 9am". every day at 5pm is equivalent to 0 17 * * *.

# Basic `dependabot.yml` file for cronjob

version: 2
updates:
  # Enable version updates for npm
  - package-ecosystem: "npm"
    # Look for `package.json` and `lock` files in the `root` directory
    directory: "/"
    # Check the npm registry for updates based on `cronjob` value
    schedule:
      interval: "cron"
      cronjob: "0 9 * * *"

timezone

Specify a time zone for the time value. The default time zone is UTC.

The time zone identifier must match a timezone in the database maintained by iana, see List of tz database time zones.

target-branch

Define a specific branch to check for version updates and to target pull requests for version updates against. For examples, see Customizing Dependabot pull requests to fit your processes.

Dependabot default behavior:

• Dependabot uses the default branch for the repository, see About the default branch.

When target-branch is defined:

• Only manifest files on the target branch are checked for version updates.
• All pull requests for version updates are opened targeting the specified branch.
• Options defined for this package-ecosystem no longer apply to security updates because security updates always use the default branch for the repository.

exclude-paths

Use to specify paths of directories and files that Dependabot should ignore when scanning for manifests and dependencies. This option is useful when you want to prevent updates for dependencies in certain locations, such as test assets, vendored code, or specific files.

Dependabot default behavior:

• All directories and files in the specified directory are included in the update scan unless excluded by this option.

When exclude-paths is defined:

• All files and directories matching the specified paths are ignored during update scans for the given package-ecosystem entry.

Glob patterns are supported, such as ** for recursive matching and * for single-segment wildcards. Patterns are relative to the directory specified for the update configuration. Each ecosystem can have its own exclude-paths settings.

Example

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    exclude-paths:
      - "src/test/assets"
      - "vendor/**"
      - "src/*.js"
      - "src/test/helper.js"

# Sample patterns that can be used-

# Pattern: docs/*.json
# Matches: docs/foo.json, docs/bar.json

# Pattern: *.lock
# Matches: Gemfile.lock, package.lock, foo.lock (in any directory)

# Pattern: test/**
# Matches: test/foo.rb, test/bar/baz.rb, test/any/depth/file.txt

# Pattern: config/settings.yml
# Matches: config/settings.yml

# Pattern: **/*.md
# Matches: README.md, docs/guide.md, any/depth/file.md

# Pattern: src/*
# Matches: src/main.rb, src/app.js
# Does NOT match: src/utils/helper.rb

# Pattern: hidden/.*
# Matches: hidden/.env, hidden/.secret

In this example, Dependabot will ignore the src/test/assets directory, all files under vendor/, all JavaScript files directly under src/, and the specific file src/test/helper.js when scanning for updates.

vendor

Supported by: bundler and gomod only.

Tell Dependabot to maintain your vendored dependencies as well as the dependencies defined by manifest files. A dependency is described as "vendored" or "cached" when you store the code within your repository, see bundle cache documentation and go mod vendor documentation.

For examples, see Controlling which dependencies are updated by Dependabot.

Dependabot default behavior:

• Maintain only dependencies recorded in the manifest and lock files identified for Bundler.
• Raise security and version update pull requests that update the version numbers recorded in the manifest and lock files.
• For Go modules, any vendored dependencies are automatically identified and maintained as if vendor was enabled.

When vendor is enabled:

• Dependabot also maintains dependencies for Bundler that are stored in the _vendor/cache_ directory in the repository.
• Pull requests will sometimes contain updates to a dependency that is stored in the repository.

Supported values: true or false

versioning-strategy

Supported by: bundler, cargo, composer, helm, mix, npm, pip, pub, and uv

Define how Dependabot should edit manifest files. For examples, see Controlling which dependencies are updated by Dependabot.

Dependabot default behavior:

• Try to differentiate between app and library dependencies.
• For apps, always increase the minimum version requirement to match the new version. The increase strategy.
• For libraries, widen the allowed version requirements to include both the new and old versions, when possible. The widen strategy.

When versioning-strategy is defined, Dependabot uses the strategy specified.

For example, if the current version is 1.0.0 and the current constraint is ^1.0.0 the different strategies would raise the following updates:

New version 1.2.0

• increase: new constraint ^1.2.0
• increase-if-necessary: new constraint ^1.0.0
• widen: new constraint ^1.0.0

New version 2.0.0

• increase: new constraint ^2.0.0
• increase-if-necessary: new constraint ^2.0.0
• widen: new constraint >=1.0.0 <3.0.0

Versioning tags

• Represent stages in the software release lifecycle, such as alpha, beta, and stable versions.
• Allow publishers to distribute their packages more effectively.
• Indicate the stability of a version and communicate what users should expect in terms of features and stability.

Dependabot recognizes a variety of versioning tags for pre-releases, stable versions, and custom tags across different ecosystems.

The dependabot.yml file doesn't control the versioning tags that you can use, but you can define in configuration options such as ignore the supported versioning tags you want to ignore updates for.

Supported versioning tags

Ecosystem-specific versioning details

The following details describe how Dependabot interprets versioning for specific ecosystems.

• Bundler: Does not use a fixed set of prerelease tags. Any version segment containing a letter is treated as prerelease (for example, .alpha, .beta1, .rc2). Hyphens are normalized to .pre. internally (for example, 1.0.0-beta becomes 1.0.0.pre.beta).

• Cargo: Follows SemVer 2.0.0 conventions. Anything after - is a prerelease identifier (dot-separated, [0-9A-Za-z-]). Build metadata (+...) is allowed but ignored for precedence.

• Gradle: In addition to the qualifiers listed in the table, these aliases are recognized: pr/pre/preview→rc, eap/ea→alpha. Additional prerelease qualifiers include dev, experimental, and unstable. Qualifiers are ordered by precedence: alpha/a < beta/b < milestone/m < rc/cr < snapshot < (empty/ga/final/release) < sp. Free-form identifiers not in this list are treated as stable.

• pip/pipenv/pip-compile/poetry (PEP 440): The table lists canonical prerelease and postrelease suffixes. Aliases are also recognized and normalized (alpha→a, beta→b, c/pre/preview→rc, rev/r→post). Epoch versions (N!...) and local versions (+local) are supported; local segments are used only to break ties when the public version is identical.

• Elm: Enforces strict SemVer (MAJOR.MINOR.PATCH integers only). The Elm package registry does not allow publishing prerelease versions. Dependabot compares versions numerically.

• Go modules: Follows SemVer with a mandatory v prefix. Pseudo-versions (v0.0.0-YYYYMMDDHHMMSS-commithash) represent unreleased commits and are always treated as prerelease. The +incompatible suffix marks modules at major version 2+ without a go.mod file and does not affect version ordering.

• git submodule: Dependabot tracks the latest commit on the configured branch. There is no version comparison—updates always move the pinned SHA forward. If the submodule tracks a tag, Dependabot follows the tag's commit.

• Bazel: Follows SemVer prerelease conventions. The Bazel Central Registry (BCR) .bcr.N suffix is stripped before comparison and does not affect prerelease detection.

• Deno: Follows SemVer prerelease conventions. Build metadata (+...) is supported but ignored for version precedence.

• Bun: Follows npm-style SemVer prerelease conventions. Build metadata (+...) is supported but ignored for version precedence.

• GitHub Actions: Dependabot resolves action versions from git tags. Any tag with a SemVer prerelease identifier (anything after -) is treated as prerelease. Additionally, releases marked as prerelease via the GitHub Release API are recognized regardless of tag format.

• Julia: Follows SemVer prerelease conventions. Prerelease identifiers are case-sensitive (for example, DEV and dev are distinct).

• Hex: Follows SemVer prerelease conventions. Any identifier after - is treated as prerelease.

• Nix: Dependabot tracks flake input commits, similar to git submodules. Internally, versions are represented as pseudo-versions (0.0.0-0.N). There is no traditional version comparison—updates move forward to the latest upstream commit.

• NuGet: Follows SemVer 2.0.0 prerelease conventions. Build metadata (+...) is supported but ignored for version precedence.

• OpenTofu: Follows SemVer prerelease conventions (same as Terraform). Build metadata (including the +backport suffix) is stripped before comparison and does not affect prerelease detection.

• Rust toolchain: Uses channel-based versioning (stable, beta, nightly) rather than SemVer prerelease identifiers. Dependabot updates the pinned channel or date-stamped nightly (for example, nightly-2024-01-15) to the latest available.

• Terraform: Follows SemVer prerelease conventions. The v prefix is stripped before comparison. Build metadata (+...) is ignored for version precedence.

• Composer: Follows PHP Composer stability conventions (case-insensitive). Stability flags (@dev, @beta) in constraints are stripped before comparison. The v prefix is handled transparently.

• Conda: Follows conda version spec (similar to PEP 440). Epoch versions (N!...) and local versions (+local) are supported. Post-release (post) suffixes are recognized.

• .NET SDK: Prerelease identifiers follow the preview.N, rc.N, alpha.N pattern. Prerelease updates require allowPrerelease: true in global.json.

• Helm Charts: Follows SemVer prerelease conventions. Chart version prefixes (for example, chart-v) and build digests (+sha256:...) are stripped before comparison.

• pre-commit: Resolves hook versions from git tags. Prerelease detection uses both Gem::Version heuristic and the GitHub Release API prerelease flag. SHA-pinned hooks are also supported.

• Pub: Follows SemVer prerelease conventions. Build metadata (+...) is supported but ignored for version precedence.

• Swift: Follows SemVer prerelease conventions. Prerelease filtering is not currently applied—all versions are treated equally in comparison.

• vcpkg: Supports multiple version formats: dot-separated numeric, SemVer (without build metadata), and date-based. Port version suffix (#N) indicates packaging revisions and does not affect prerelease detection.

Versioning tag glossary

• alpha: Early version, may be unstable and have incomplete features.
• beta: More stable than alpha but may still have bugs.
• canary: Regularly updated pre-release version for testing.
• dev: Represents development versions.
• experimental: Versions with experimental features.
• latest: The latest stable release.
• legacy: Older or deprecated versions.
• next: Upcoming release version.
• nightly: Versions built nightly; often includes the latest changes.
• rc: Release candidate, close to stable release.
• release: The official release version.
• stable: The most reliable, production-ready version.

Top-level registries key

Specify authentication details that Dependabot can use to access private package registries, including registries hosted by GitLab or Bitbucket.

The value of the registries key is an associative array, each element of which consists of a key that identifies a particular registry and a value which is an associative array that specifies the settings required to access that registry. You can define up to 100 registries in the top-level registries section.

The following dependabot.yml file configures a registry identified as dockerhub in the registries section of the file and then references this in the updates section of the file.

# Minimal settings to update dependencies stored in one private registry

version: 2
registries:
  dockerhub: # Define access for a private registry
    type: docker-registry
    url: registry.hub.docker.com
    username: octocat
    password: ${{secrets.DOCKERHUB_PASSWORD}}
updates:
  - package-ecosystem: "docker"
    directory: "/docker-registry/dockerhub"
    registries:
      - dockerhub # Allow version updates for dependencies in this registry
    schedule:
      interval: "monthly"

You use the following options to specify access settings. Registry settings must contain a type and a url, and typically either a username and password combination or a token.

For in-depth information about available options, as well as recommendations and advice when configuring private registries, see Guidance for the configuration of private registries for Dependabot.

type and authentication details

The parameters used to provide authentication details for access to a private registry vary according to the registry type.

All sensitive data used for authentication should be stored securely and referenced from that secure location, see Configuring access to private registries for Dependabot.

For more information about OIDC support for Dependabot, see OpenID Connect and Configuring access to private registries for Dependabot.

url and replaces-base

The url parameter defines where to access a registry. When the optional replaces-base parameter is enabled (true), Dependabot resolves dependencies using the value of url rather than the base URL of that specific ecosystem.

scope

The scope parameter is available for npm-registry type registries. It specifies which npm scope should be associated with the registry. The value must start with @, for example @my-company. To associate multiple scopes with the same registry URL, create a separate registry entry for each scope.

When scope is provided, Dependabot generates the .npmrc configuration from your registry credentials. This generated configuration takes precedence over any committed .npmrc file or lockfile-based inference.

Priority order for npm registry resolution

When determining which registry to use for npm dependencies, Dependabot follows this priority order:

1. Credential-based generation (scope or replaces-base): If scope or replaces-base is configured on any npm-registry credential in dependabot.yml, Dependabot generates the .npmrc from those credentials. This always takes priority, overriding any committed .npmrc file.
2. Committed .npmrc in the repository: If no scope is set, Dependabot uses any .npmrc file committed to the repository.
3. Lockfile inference (transitional): If there is no scope and no committed .npmrc, Dependabot attempts to infer registry configuration from the lockfile.
4. Error generation: If none of the above methods succeed, Dependabot reports an error with guidance to add explicit configuration.