Once Renovate's Managers are done scanning files and extracting dependencies, they will assign a datasource to each so that Renovate then knows how to search for new versions. You do not need to ever configure/override Datasources directly, but you may use them in packageRules to configure other aspects of Renovate's behavior, e.g.

  "packageRules": [
      "datasources": ["npm"],
      "packageNames": ["lodash"],
      "automerge": true

Supported Datasources

Supported values for datasource are: cdnjs, clojure, crate, dart, docker, galaxy, git-refs, git-submodules, git-tags, github-releases, github-tags, gitlab-tags, go, gradle-version, helm, hex, jenkins-plugins, maven, npm, nuget, orb, packagist, pod, pypi, repology, ruby-version, rubygems, sbt-package, sbt-plugin, terraform-module, terraform-provider.

Cdnjs Datasource

Identifier: cdnjs

Clojure Datasource

Identifier: clojure

Crate Datasource

Identifier: crate

Dart Datasource

Identifier: dart

Docker Datasource

Identifier: docker

Default configuration:

  "additionalBranchPrefix": "docker-",
  "commitMessageTopic": "{{{depName}}} Docker tag",
  "major": {
    "enabled": false
  "commitMessageExtra": "to v{{#if isMajor}}{{{newMajor}}}{{else}}{{{newVersion}}}{{/if}}",
  "digest": {
    "branchTopic": "{{{depNameSanitized}}}-{{{currentValue}}}",
    "commitMessageExtra": "to {{newDigestShort}}",
    "commitMessageTopic": "{{{depName}}}{{#if currentValue}}:{{{currentValue}}}{{/if}} Docker digest",
    "group": {
      "commitMessageTopic": "{{{groupName}}}",
      "commitMessageExtra": ""
  "pin": {
    "commitMessageExtra": "",
    "groupName": "Docker digests",
    "group": {
      "commitMessageTopic": "{{{groupName}}}",
      "branchTopic": "digests-pin"
  "group": {
    "commitMessageTopic": "{{{groupName}}} Docker tags"

Galaxy Datasource

Identifier: galaxy

Git Refs Datasource

Identifier: git-refs

Git Submodules Datasource

Identifier: git-submodules

Default configuration:

  "pinDigests": false

Git Tags Datasource

Identifier: git-tags

Github Releases Datasource

Identifier: github-releases

Github Tags Datasource

Identifier: github-tags

Gitlab Tags Datasource

Identifier: gitlab-tags

Go Datasource

Identifier: go

Gradle Version Datasource

Identifier: gradle-version

Helm Datasource

Identifier: helm

Hex Datasource

Identifier: hex

Jenkins Plugins Datasource

Identifier: jenkins-plugins

Maven Datasource

Identifier: maven

Npm Datasource

Identifier: npm

Nuget Datasource

Identifier: nuget

Orb Datasource

Identifier: orb

Packagist Datasource

Identifier: packagist

Pod Datasource

Identifier: pod

Pypi Datasource

Identifier: pypi

Repology Datasource

Identifier: repology


Repology supports looking up package versions from a wide variety of package repositories and can be used in combination with regex managers to keep dependencies up-to-date which are not specifically supported by Renovate.

To specify which specific repository should be queried when looking up a package, the lookupName has to contain the repository identifier and the package name itself, separated by a slash. As an example, alpine_3_12/gcc would look for a binary or source package called gcc within the alpine_3_12 repository.

A list of all supported repositories can be found on the Repology homepage. To determine the correct identifier, click on a repository of your choice and make note of the identifier in the URL:<identifier>

As an example, the Alpine Linux 3.12 repository points to and therefor has the repository identifier alpine_3_12.

Please note that as of today, the Repology API endpoint /tools/project-by does not support a small subset of repositories. You can manually double-check on their website if your desired repository is supported and otherwise raise a request on their side. This datasource will also print a debug message Repology does not support tools/project-by lookups for repository if the given repository is unsupported.

Usage Example

A real world example for this specific datasource would be maintaining system packages within a Dockerfile, as this allows to specifically pin each dependency without having to manually keep the versions up-to-date. This can be achieved by configuring a generic regex manager in renovate.json for files named Dockerfile:

  "regexManagers": [
      "fileMatch": ["^Dockerfile$"],
      "matchStrings": [
        "#\\s*renovate:\\s*datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?\\sENV .*?_VERSION=(?<currentValue>.*)\\s"
      "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"

Now you may use regular comments in your Dockerfile to automatically update dependencies, which could look like this:

FROM alpine:3.12.0@sha256:a15790640a6690aa1730c38cf0a440e2aa44aaca9b0e8931a9f2b0d7cc90fd65

# renovate: datasource=repology depName=alpine_3_12/gcc versioning=loose
ENV GCC_VERSION="9.3.0-r2"
# renovate: datasource=repology depName=alpine_3_12/musl-dev versioning=loose

RUN apk add --no-cache \
    gcc="${GCC_VERSION}" \

It is often wise to use the loose versioning for distribution packages as the version number usually does not strictly match the semver specification which is used by default. Now whenever the OS package for gcc of Alpine Linux 3.12 is being updated, Renovate will automatically adjust the value of the environment variable to the newest version.

Ruby Version Datasource

Identifier: ruby-version

Rubygems Datasource

Identifier: rubygems

Sbt Package Datasource

Identifier: sbt-package

Sbt Plugin Datasource

Identifier: sbt-plugin

Terraform Module Datasource

Identifier: terraform-module

Terraform Provider Datasource

Identifier: terraform-provider