Dependabot Updates Reach General Availability on GitHub Enterprise Server

GitHub Enterprise Server (GHES) 3.5 brings Dependabot updates to general availability. While Dependabot alerts have been part of GHES for years, the ability to automatically update dependencies by generating pull requests was a long-standing request from enterprise customers. That capability now ships in 3.5, and GHES administrators can enable it alongside GitHub Actions.

What Dependabot covers on GHES

Dependabot on GHES consists of three distinct services:

  • Dependabot alerts: Notify you as soon as vulnerabilities are detected in your dependencies.
  • Dependabot security updates: When an exposure is found, open a pull request that upgrades the dependency to the next non-vulnerable version.
  • Dependabot version updates: Open pull requests to keep dependencies current, reducing both vulnerability exposure and the risk of being locked into outdated versions.

Prerequisites for Dependabot updates

Before enabling Dependabot updates, your GHES instance must meet the following requirements:

  • Run GHES 3.5 or higher. Although Dependabot updates are available on 3.3 and 3.4, 3.5 is the lowest recommended release for general availability support.
  • Enable GitHub Actions on your GHES instance.
  • Set up one or more Linux virtual machines for self-hosted Actions runners, which execute the logic behind Dependabot updates. Install Docker on each runner VM.
  • Configure the self-hosted runners with the dependabot label.

Cluster configurations are not currently supported for Dependabot updates, since GitHub Actions is not available in clustered environments. Additionally, air-gapped installations cannot use Dependabot updates: the runners need internet access to fetch dependency data.

Configuring self-hosted runners

To add a runner to the pool, follow GitHub's standard self-hosted runner setup and run the commands that GHES provides for your virtual machine. When you run ./config.sh, you'll be prompted to assign a label and a group:

"

Use the dependabot label to mark a runner as available for Dependabot update jobs. Optionally, runner groups can help manage access. If you use repository- or organization-level runner groups, be sure the Dependabot runners belong to the group and all target repositories have access to it:

"

Enabling Dependabot on the server

From the site admin Management Console, navigate to Security and enable these two features:

  • Dependency graph
  • Dependabot updates

Note that enabling Dependabot on your server will require a brief restart, so plan for a short downtime window. The same UI also shows the option to manage the dependabot runners:

"

After that, connect your GHES instance via GitHub Connect in the Settings area. Make sure you enable both Dependabot settings plus GitHub Connect:

  • Enable GitHub Connect for your enterprise.
  • Enable Dependabot security updates at the organization or repository level.
  • Enable Dependabot alerts — security updates require alerts to be on.
  • A recommended step: turn off notification for security alert notices during the initial rollout so your developers aren't flooded.
"

Testing updates on a repository

Once Dependabot is configured, test it on a repository by navigating to Settings → Security and Analysis and enabling Dependabot security updates. The same setting can be applied at the organization level.

Dependabot version updates require a .github/dependabot.yml configuration file in each repository you want to keep updated. To verify that security updates are functioning, you can introduce a known vulnerable dependency, for example a requirements.txt with this content:


pillow>= 2.4.0, < 5.3.1

Committing that file triggers both a Dependabot alert and a security update pull request.

How GHES implements Dependabot differently

On GitHub.com, Dependabot's analysis runs on internal infrastructure that predates GitHub Actions. For GHES, GitHub needed a way to run the analysis without straining the availability of the appliance, while working across different instance configurations and plugging into each repository's CI. The solution was to package the containers as GitHub Actions jobs. Dependabot runs inside self-hosted Actions runners, meaning you can watch pull requests be created and inspect the logs using the same interface you already know from other Actions.

/

Two limitations accompany this approach: Dependabot jobs cannot be rerun manually the way other Actions can, and Dependabot on GHES works only with self-hosted runners.