configuration-options.md

title: Configuration Options
description: Configuration Options usable in renovate.json or package.json

Configuration Options

This document describes all the configuration options you may configure in a renovate.json file or within a "renovate" section of your package.json. Any config you define applies to the whole repository (e.g. if you have a monorepo).

Also, be sure to check out Renovate's shareable config presets to save yourself from reinventing any wheels.

If you have any questions about the below config options, or would like to get help/feedback about a config, please post it as an issue in renovateapp/config-help where it will be promptly answered.

allowedVersions

A semver range defining allowed versions for dependencies

name	value
type	string

Use this - usually within a packageRule - to limit how far to upgrade a dependency. For example, if you wish to upgrade to angular v1.5 but not to angular v1.6 or higher, you could defined this to be <= 1.5 or < 1.6.0:

  "packageRules": [{
    "packageNames": ["angular"],
    "allowedVersions": "<=1.5"
  }]

assignees

Assignees for Pull Requests

name	value
type	array of strings
default	[]

Must be valid usernames.

automerge

Configure if Renovate should merge passing PRs itself..

name	value
type	boolean
default	false

By default, Renovate raises PRs but leaves them to someone/something else to merge them. By configuring this setting, you can enable Renovate to automerge branches or PRs itself, therefore reducing the amount of human intervention required.

Usually you won't want to automerge all PRs, for example most people would want to leave major dependency updates to a human to review first. In that case you will want to embed this setting inside major, minor, or patch configuration options. For example, you could add this to your renovate.json to automerge only non-major updates:

  "automerge": true,
  "major": {
    "automerge": false
  }

Also note that this option can be combined with other nested settings, such as dependency type. So for example you could elect to automerge all devDependencies only this way:

  "devDependencies": {
    "automerge": true
  }

Warning: GitHub currently has a bug where automerge won't work if a GitHub Organization has protected their master branch, and there is no way to configure around this. Hence, automerging will try and fail in such situations. This doc will be updated once that bug/limitation is fixed by GitHub.

automergeType

Type of automerge approach to use.

name	value
type	string
valid values	"branch-merge-commit", "branch-push" or "pr"
default	"pr"

Renovate will default to automerging after creating PRs, but you can override that to automerge without PRs. There are two ways to merge branch upgrades: merge commits, and branch push.

Merge commits will employ the standard GitHub "merge commit" API, just like when you merge a PR with merge commit setting. The downside of this approach is that you will end up with merge commits and not a nice clean default branch!

Branch push employs GitHub's low-level git API to push the Renovate upgrade directly to the head of the base branch (e.g. master) to maintain a "clean" history. The downside of this approach is that it implicitly enables the rebaseStalePrs setting because otherwise we would risk pushing a bad commit to master. i.e. Renovate won't push the commit to base branch unless the branch is completely up-to-date with master and has passed tests, which means that if the default branch is getting updated regularly then it might take several rebases from Renovate until it has a branch commit that is safe to push to master.

baseBranches

An array of one or more custom base branches to be renovated. Default behaviour is to renovate the default repository branch.

name	value
type	list
default	[]

If left default (empty) then the default branch of the repository is used.

For most projects, this should be left as default. An example use case for using this setting is a project who uses the default master branch for releases and a separate branch next for preparing for the next release. In that case, the project may prefer for Pull Requests from Renovate to be opened against the next branch instead of master.

If instead the project needs both master and next to be renovated, then both should be put into the baseBranches array.

It's possible to add this setting into the renovate.json file as part of the "Configure Renovate" onboarding PR. If so then Renovate will reflect this setting in its description and use package file contents from the custom base branch instead of default.

bazel

Configuration specific for bazel WORKSPACE updates.

name	value
type	object
default	{}

branchName