self-hosted-configuration.md

title: Self-Hosted configuration
description: Self-Hosted configuration usable in config file, CLI or environment variables

Self-Hosted configuration options

You can only use these configuration options when you're self-hosting Renovate.

Please also see Self-Hosted Experimental Options.

!!! note Config options with type=string are always non-mergeable, so mergeable=false.

allowCustomCrateRegistries

allowPlugins

allowPostUpgradeCommandTemplating

Let's look at an example of configuring packages with existing Angular migrations.

module.exports = {
  allowedPostUpgradeCommands: ['^npm ci --ignore-scripts$', '^npx ng update'],
};

In the renovate.json file, define the commands and files to be included in the final commit.

The command to install dependencies (npm ci --ignore-scripts) is needed because, by default, the installation of dependencies is skipped (see the skipInstalls global option).

{
  "packageRules": [
    {
      "matchPackageNames": ["@angular/core"],
      "postUpgradeTasks": {
        "commands": [
          "npm ci --ignore-scripts",
          "npx ng update {{{depName}}} --from={{{currentVersion}}} --to={{{newVersion}}} --migrate-only --allow-dirty --force"
        ]
      }
    }
  ]
}

With this configuration, the executable command for @angular/core looks like this:

npm ci --ignore-scripts
npx ng update @angular/core --from=10.0.0 --to=11.0.0 --migrate-only --allow-dirty --force

If you wish to disable templating because of any security or performance concern, you may set allowPostUpgradeCommandTemplating to false. But before you disable templating completely, try the allowedPostUpgradeCommands config option to limit what commands are allowed to run.

allowScripts

allowedPostUpgradeCommands

A list of regular expressions that decide which commands in postUpgradeTasks are allowed to run. If this list is empty then no tasks will be executed.

For example:

{
  "allowedPostUpgradeCommands": ["^tslint --fix$", "^tslint --[a-z]+$"]
}

autodiscover

When you enable autodiscover, by default, Renovate runs on every repository that the bot account can access. You can limit which repositories Renovate can access by using the autodiscoverFilter config option.

autodiscoverFilter

You can use this option to filter the list of repositories that the Renovate bot account can access through autodiscover. It takes a minimatch glob-style or regex pattern.

If you set multiple filters, then the matches of each filter are added to the overall result.

If you use an environment variable or the CLI to set the value for autodiscoverFilter, then commas , within filters are not supported. Commas will be used as delimiter for a new filter.

# DO NOT use commas inside the filter if your are using env or CLI variables to configure it.
RENOVATE_AUTODISCOVER_FILTER="/myapp/{readme.md,src/**}"

# in this example you can use regex instead
RENOVATE_AUTODISCOVER_FILTER="/myapp/(readme\.md|src/.*)/"

Minimatch:

{
  "autodiscoverFilter": ["project/*"]
}

The search for repositories is case-insensitive.

Regex:

All text inside the start and end / will be treated as a regular expression.

{
  "autodiscoverFilter": ["/project/.*/"]
}

You can negate the regex by putting an ! in front. Only use a single negation and don't mix with other filters because all filters are combined with or. If using negations, all repositories except those who match the regex are added to the result:

{
  "autodiscoverFilter": ["!/project/.*/"]
}

autodiscoverNamespaces

You can use this option to autodiscover projects in specific namespaces (a.k.a. groups/organizations/workspaces). In contrast to autodiscoverFilter the filtering is done by the platform and therefore more efficient.

For example:

{
  "platform": "gitlab",
  "autodiscoverNamespaces": ["a-group", "another-group/some-subgroup"]
}

autodiscoverTopics

Some platforms allow you to add tags, or topics, to repositories and retrieve repository lists by specifying those topics. Set this variable to a list of strings, all of which will be topics for the autodiscovered repositories.

For example:

{
  "autodiscoverTopics": ["managed-by-renovate"]
}

baseDir

By default Renovate uses a temporary directory like /tmp/renovate to store its data. You can override this default with the baseDir option.

For example:

{
  "baseDir": "/my-own-different-temporary-folder"
}

bbUseDevelopmentBranch

By default, Renovate will use a repository's "main branch" (typically called main or master) as the "default branch".

Configuring this to true means that Renovate will detect and use the Bitbucket development branch as defined by the repository's branching model.

If the "development branch" is configured but the branch itself does not exist (e.g. it was deleted), Renovate will fall back to using the repository's "main branch". This fall back behavior matches that of the Bitbucket Cloud web interface.

binarySource

Renovate often needs to use third-party tools in its PRs, like npm to update package-lock.json or go to update go.sum.

Renovate supports four possible ways to access those tools:

• global: Uses pre-installed tools, e.g. npm installed via npm install -g npm.
• install (default): Downloads and installs tools at runtime if running in a Containerbase environment, otherwise falls back to global
• docker: Runs tools inside Docker "sidecar" containers using docker run.
• hermit: Uses the Hermit tool installation approach.

Starting in v36, Renovate's default Docker image (previously referred to as the "slim" image) uses binarySource=install while the "full" Docker image uses binarySource=global. If you are running Renovate in an environment where runtime download and install of tools is not possible then you should use the "full" image.

If you are building your own Renovate image, e.g. by installing Renovate using npm, then you will need to ensure that all necessary tools are installed globally before running Renovate so that binarySource=global will work.

The binarySource=docker approach should not be necessary in most cases now and binarySource=install is recommended instead. If you have a use case where you cannot use binarySource=install but can use binarySource=docker then please share it in a GitHub Discussion so that the maintainers can understand it. For this to work, docker needs to be installed and the Docker socket available to Renovate.

cacheDir

By default Renovate stores cache data in a temporary directory like /tmp/renovate/cache. Use the cacheDir option to override this default.

The baseDir and cacheDir option may point to different directories. You can use one directory for the repo data, and another for the cache data.

For example:

{
  "baseDir": "/my-own-different-temporary-folder",
  "cacheDir": "/my-own-different-cache-folder"
}

cacheHardTtlMinutes

This experimental feature is used to implement the concept of a "soft" cache expiry for datasources, starting with npm. It should be set to a non-zero value, recommended to be at least 60 (i.e. one hour).

When this value is set, the npm datasource will use the cacheHardTtlMinutes value for cache expiry, instead of its default expiry of 15 minutes, which becomes the "soft" expiry value. Results which are soft expired are reused in the following manner:

• The etag from the cached results will be reused, and may result in a 304 response, meaning cached results are revalidated
• If an error occurs when querying the npmjs registry, then soft expired results will be reused if they are present

cacheTtlOverride

Utilize this key-value map to override the default package cache TTL values for a specific namespace. This object contains pairs of namespaces and their corresponding TTL values in minutes. For example, to override the default TTL of 60 minutes for the docker datasource "tags" namespace: datasource-docker-tags use the following:

{
  "cacheTtlOverride": {
    "datasource-docker-tags": 120
  }
}

checkedBranches

This array will allow you to set the names of the branches you want to rebase/create, as if you selected their checkboxes in the Dependency Dashboard issue.

It has been designed with the intention of being run on one repository, in a one-off manner, e.g. to "force" the rebase of a known existing branch. It is highly unlikely that you should ever need to add this to your permanent global config.

Example: renovate --checked-branches=renovate/chalk-4.x renovate-reproductions/checked will rebase the renovate/chalk-4.x branch in the renovate-reproductions/checked repository.`

containerbaseDir

This directory is used to cache downloads when binarySource=docker or binarySource=install.

Use this option if you need such downloads to be stored outside of Renovate's regular cache directory (cacheDir).

customEnvVariables

This configuration will be applied after all other environment variables so you can use it to override defaults.

detectGlobalManagerConfig

The purpose of this config option is to allow you (as a bot admin) to configure manager-specific files such as a global .npmrc file, instead of configuring it in Renovate config.

This config option is disabled by default because it may prove surprising or undesirable for some users who don't expect Renovate to go into their home directory and import registry or credential information.

Currently this config option is supported for the npm manager only - specifically the ~/.npmrc file. If found, it will be imported into config.npmrc with config.npmrcMerge set to true.

detectHostRulesFromEnv

The format of the environment variables must follow:

• Datasource name (e.g. NPM, PYPI) or Platform name (only GITHUB)
• Underscore (_)
• matchHost
• Underscore (_)
• Field name (TOKEN, USERNAME, PASSWORD, HTTPSPRIVATEKEY, HTTPSCERTIFICATE, HTTPSCERTIFICATEAUTHORITY)

Hyphens (-) in datasource or host name must be replaced with double underscores (__). Periods (.) in host names must be replaced with a single underscore (_).

!!! note You can't use these prefixes with the detectHostRulesFromEnv config option: npm_config_, npm_lifecycle_, npm_package_. In addition, platform host rules will only be picked up when matchHost is supplied.

npmjs registry token example

NPM_REGISTRY_NPMJS_ORG_TOKEN=abc123:

{
  "hostRules": [
    {
      "hostType": "npm",
      "matchHost": "registry.npmjs.org",
      "token": "abc123"
    }
  ]
}

GitLab Tags username/password example

GITLAB__TAGS_CODE__HOST_COMPANY_COM_USERNAME=bot GITLAB__TAGS_CODE__HOST_COMPANY_COM_PASSWORD=botpass123:

{
  "hostRules": [
    {
      "hostType": "gitlab-tags",
      "matchHost": "code-host.company.com",
      "username": "bot",
      "password": "botpass123"
    }
  ]
}

Datasource and credentials only

You can skip the host part, and use only the datasource and credentials.

DOCKER_USERNAME=bot DOCKER_PASSWORD=botpass123:

{
  "hostRules": [
    {
      "hostType": "docker",
      "username": "bot",
      "password": "botpass123"
    }
  ]
}

Platform with https authentication options

GITHUB_SOME_GITHUB__ENTERPRISE_HOST_HTTPSCERTIFICATE=certificate GITHUB_SOME_GITHUB__ENTERPRISE_HOST_HTTPSPRIVATEKEY=private-key GITHUB_SOME_GITHUB__ENTERPRISE_HOST_HTTPSCERTIFICATEAUTHORITY=certificate-authority:

{
  "hostRules": [
    {
      "hostType": "github",
      "matchHost": "some.github-enterprise.host",
      "httpsPrivateKey": "private-key",
      "httpsCertificate": "certificate",
      "httpsCertificateAuthority": "certificate-authority"
    }
  ]
}

dockerChildPrefix

Adds a custom prefix to the default Renovate sidecar Docker containers name and label.

For example, if you set dockerChildPrefix=myprefix_ then the final container created from the containerbase/sidecar is:

• called myprefix_sidecar instead of renovate_sidecar
• labeled myprefix_child instead of renovate_child

!!! note Dangling containers are only removed when Renovate runs again with the same prefix.

dockerCliOptions

You can use dockerCliOptions to pass Docker CLI options to Renovate's sidecar Docker containers.

For example, {"dockerCliOptions": "--memory=4g"} will add a CLI flag to the docker run command that limits the amount of memory Renovate's sidecar Docker container can use to 4 gigabytes.

Read the Docker Docs, configure runtime resource contraints to learn more.

dockerSidecarImage

By default Renovate pulls the sidecar Docker containers from ghcr.io/containerbase/sidecar. You can use the dockerSidecarImage option to override this default.

Say you want to pull a custom image from ghcr.io/your_company/sidecar. You would put this in your configuration file:

{
  "dockerSidecarImage": "ghcr.io/your_company/sidecar"
}

Now when Renovate pulls a new sidecar image, the final image is ghcr.io/containerbase/sidecar instead of docker.io/containerbase/sidecar.

dockerUser

Override default user and group used by Docker-based tools. The user-id (UID) and group-id (GID) must match the user that executes Renovate.

Read the Docker run reference for more information on user and group syntax. Set this to 1001:1002 to use UID 1001 and GID 1002.

{
  "dockerUser": "1001:1002"
}

If you use binarySource=docker|install read the section below.

If you need to change the Docker user please make sure to use the root (0) group, otherwise you'll get in trouble with missing file and directory permissions. Like this:

> export RENOVATE_DOCKER_USER="$(id -u):0" # 500:0 (username:root)

dryRun

Use dryRun to preview the behavior of Renovate in logs, without making any changes to the repository files.

You can choose from the following behaviors for the dryRun config option:

• null: Default behavior - Performs a regular Renovate run including creating/updating/deleting branches and PRs
• "extract": Performs a very quick package file scan to identify the extracted dependencies
• "lookup": Performs a package file scan to identify the extracted dependencies and updates available
• "full": Performs a dry run by logging messages instead of creating/updating/deleting branches and PRs

Information provided mainly in debug log level.

endpoint

executionTimeout

Default execution timeout in minutes for child processes Renovate creates. If this option is not set, Renovate will fallback to 15 minutes.

exposeAllEnv

To keep you safe, Renovate only passes a limited set of environment variables to package managers. If you must expose all environment variables to package managers, you can set this option to true.

!!! warning Always consider the security implications of using exposeAllEnv! Secrets and other confidential information stored in environment variables could be leaked by a malicious script, that enumerates all environment variables.

Set exposeAllEnv to true only if you have reviewed, and trust, the repositories which Renovate bot runs against. Alternatively, you can use the customEnvVariables config option to handpick a set of variables you need to expose.

Setting this to true also allows for variable substitution in .npmrc files.

force

This object is used as a "force override" when you need to make sure certain configuration overrides whatever is configured in the repository. For example, forcing a null (no) schedule to make sure Renovate raises PRs on a run even if the repository itself or its preset defines a schedule that's currently inactive.

In practice, it is implemented by converting the force configuration into a packageRule that matches all packages.

forceCli

This is set to true by default, meaning that any settings (such as schedule) take maximum priority even against custom settings existing inside individual repositories. It will also override any settings in packageRules.

forkOrg

This configuration option lets you choose an organization you want repositories forked into when "fork mode" is enabled. It must be set to a GitHub Organization name and not a GitHub user account. When set, "allow edits by maintainers" will be false for PRs because GitHub does not allow this setting for organizations.

This can be used if you're migrating from user-based forks to organization-based forks.

If you've set a forkOrg then Renovate will:

1. Check if a fork exists in the preferred organization before checking it exists in the fork user's account
2. If no fork exists: it will be created in the forkOrg, not the user account

forkToken

If this value is configured then Renovate:

• forks the target repository into the account that owns the PAT
• keep this fork's default branch up-to-date with the target

Renovate will then create branches on the fork and opens Pull Requests on the parent repository.

gitNoVerify

Controls when Renovate passes the --no-verify flag to git. The flag can be passed to git commit and/or git push. Read the documentation for git commit --no-verify and git push --no-verify to learn exactly what each flag does. To learn more about Git hooks, read the Pro Git 2 book, section on Git Hooks.

gitPrivateKey

This should be an armored private key, so the type you get from running gpg --export-secret-keys --armor 92066A17F0D1707B4E96863955FEF5171C45FAE5 > private.key. Replace the newlines with \n before adding the resulting single-line value to your bot's config.

!!! note The private key can't be protected with a passphrase if running in a headless environment. Renovate will not be able to handle entering the passphrase.

It will be loaded lazily. Before the first commit in a repository, Renovate will:

1. Run gpg import (if you haven't before)
2. Run git config user.signingkey and git config commit.gpgsign true

The git commands are run locally in the cloned repo instead of globally. This reduces the chance of unintended consequences with global Git configs on shared systems.

gitTimeout

To handle the case where the underlying Git processes appear to hang, configure the timeout with the number of milliseconds to wait after last received content on either stdOut or stdErr streams before sending a SIGINT kill message.

gitUrl

Override the default resolution for Git remote, e.g. to switch GitLab from HTTPS to SSH-based. Currently works for Bitbucket Server and GitLab only.

Possible values:

• default: use HTTPS URLs provided by the platform for Git
• ssh: use SSH URLs provided by the platform for Git
• endpoint: ignore URLs provided by the platform and use the configured endpoint directly

githubTokenWarn

By default, Renovate logs and displays a warning when the GITHUB_COM_TOKEN is not set. By setting githubTokenWarn to false, Renovate suppresses these warnings on Pull Requests, etc. Disabling the warning is helpful for self-hosted environments that can't access the github.com domain, because the warning is useless in these environments.

globalExtends

Unlike the extends field, which is passed through unresolved to be part of repository config, any presets in globalExtends are resolved immediately as part of global config. Use the globalExtends field if your preset has any global-only configuration options, such as the list of repositories to run against.

Use the extends field instead of this if, for example, you need the ability for a repository config (e.g. renovate.json) to be able to use ignorePresets for any preset defined in global config.

!!! warning globalExtends presets can't be private. When Renovate resolves globalExtends it does not fully process the configuration. This means that Renovate does not have the authentication it needs to fetch private things.

includeMirrors

By default, Renovate does not autodiscover repositories that are mirrors.

Change this setting to true to include repositories that are mirrors as Renovate targets.

logContext

logContext is included with each log entry only if logFormat="json" - it is not included in the pretty log output. If left as default (null), a random short ID will be selected.

logFile

logFileLevel

migratePresets

Use this if you have repositories that extend from a particular preset, which has now been renamed or removed. This is handy if you have a large number of repositories that all extend from a particular preset which you want to rename, without the hassle of manually updating every repository individually. Use an empty string to indicate that the preset should be ignored rather than replaced.

Example:

modules.exports = {
  migratePresets: {
    '@company': 'local>org/renovate-config',
  },
};

In the above example any reference to the @company preset will be replaced with local>org/renovate-config.

!!! tip Combine migratePresets with configMigration if you'd like your config migrated by PR.

onboarding

Only set this to false if all three statements are true:

• You've configured Renovate entirely on the bot side (e.g. empty renovate.json in repositories)
• You want to run Renovate on every repository the bot has access to
• You want to skip all onboarding PRs

onboardingBranch

!!! note This setting is independent of branchPrefix.

For example, if you configure branchPrefix to be renovate- then you'd still have the onboarding PR created with branch renovate/configure until you configure onboardingBranch=renovate-configure or similar. If you have an existing Renovate installation and you change onboardingBranch then it's possible that you'll get onboarding PRs for repositories that had previously closed the onboarding PR unmerged.

onboardingCommitMessage

If commitMessagePrefix or semanticCommits values are set then they will be prepended to the commit message using the same logic that is used for adding them to non-onboarding commit messages.

onboardingConfig

onboardingConfigFileName

If set to one of the valid config file names, the onboarding PR will create a configuration file with the provided name instead of renovate.json. Falls back to renovate.json if the name provided is not valid.

onboardingNoDeps

Set this to true if you want Renovate to create an onboarding PR even if no dependencies are found. Otherwise, Renovate skips onboarding a repository if it finds no dependencies in it.

onboardingPrTitle

If you have an existing Renovate installation and you change the onboardingPrTitle: then you may get onboarding PRs again for repositories with closed non-merged onboarding PRs. This is similar to what happens when you change the onboardingBranch config option.

onboardingRebaseCheckbox

optimizeForDisabled

When this option is true, Renovate will do the following during repository initialization:

1. Try to fetch the default config file (e.g. renovate.json)
2. Check if the file contains "enabled": false
3. If so, skip cloning and skip the repository immediately

If onboardingConfigFileName is set, that file name will be used instead of the default.

If the file exists and the config is disabled, Renovate will skip the repo without cloning it. Otherwise, it will continue as normal.

optimizeForDisabled can make initialization quicker in cases where most repositories are disabled, but it uses an extra API call for enabled repositories.

A second, advanced, use also exists when the bot global config has extends: [":disableRenovate"]. In that case, Renovate searches the repository config file for any of these configurations:

• extends: [":enableRenovate"]
• ignorePresets: [":disableRenovate"]
• enabled: true

If Renovate finds any of the above configurations, it continues initializing the repository. If not, then Renovate skips the repository without cloning it.

password

persistRepoData