Note: Dependabot security and version updates are currently in private beta and subject to change. Please contact your account management team for instructions on enabling Dependabot updates.
About self-hosted runners for Dependabot updates
You can help users of your GitHub Enterprise Server instance to create and maintain secure code by setting up Dependabot security and version updates. With Dependabot updates, developers can configure repositories so that their dependencies are updated and kept secure automatically. For more information, see "Enabling Dependabot for your enterprise."
To use Dependabot updates on your GitHub Enterprise Server instance, you must configure self-hosted runners to create the pull requests that will update dependencies.
Prerequisites
Before you configure self-hosted runners for Dependabot updates, you must:
- Configure your GitHub Enterprise Server instance to use GitHub Actions with self-hosted runners. For more information, see "Getting started with GitHub Actions for GitHub Enterprise Server."
- Enable Dependabot alerts for your enterprise. For more information, see "Enabling Dependabot for your enterprise."
Configuring self-hosted runners for Dependabot updates
After you configure your GitHub Enterprise Server instance to use GitHub Actions, you need to add self-hosted runners for Dependabot updates.
System requirements for Dependabot runners
Any VM that you use for Dependabot runners must meet the requirements for self-hosted runners. In addition, they must meet the following requirements.
- Linux operating system
- x64 architecture
- Git installed
- Docker installed with access for the runner users:
- We recommend installing Docker in rootless mode and configuring the runners to access Docker without
root
privileges. - Alternatively, install Docker and give the runner users raised privileges to run Docker.
- We recommend installing Docker in rootless mode and configuring the runners to access Docker without
The CPU and memory requirements will depend on the number of concurrent runners you deploy on a given VM. As guidance, we have successfully set up 20 runners on a single 2 CPU 8GB machine, but ultimately, your CPU and memory requirements will heavily depend on the repositories being updated. Some ecosystems will require more resources than others.
If you specify more than 14 concurrent runners on a VM, you must also update the Docker /etc/docker/daemon.json
configuration to increase the default number of networks Docker can create.
{
"default-address-pools": [
{"base":"10.10.0.0/16","size":24}
]
}
Network requirements for Dependabot runners
Dependabot runners require access to the public internet, GitHub.com, and any internal registries that will be used in Dependabot updates. To minimize the risk to your internal network, you should limit access from the Virtual Machine (VM) to your internal network. This reduces the potential for damage to internal systems if a runner were to download a hijacked dependency.
Adding self-hosted runners for Dependabot updates
-
Provision self-hosted runners, at the repository, organization, or enterprise account level. For more information, see "About self-hosted runners" and "Adding self-hosted runners."
-
Set up the self-hosted runners with the requirements described above. For example, on a VM running Ubuntu 20.04 you would:
- Verify that Git is installed:
command -v git
- Install Docker and ensure that the runner users have access to Docker. For more information, see the Docker documentation.
- Install Docker Engine on Ubuntu
- Recommended approach: Run the Docker daemon as a non-root user (Rootless mode)
- Alternative approach: Manage Docker as a non-root user
- Verify that the runners have access to the public internet and can only access the internal networks that Dependabot needs.
- Verify that Git is installed:
-
Assign a
dependabot
label to each runner you want Dependabot to use. For more information, see "Using labels with self-hosted runners." -
Optionally, enable workflows triggered by Dependabot to use more than read-only permissions and to have access to any secrets that are normally available. For more information, see "Troubleshooting GitHub Actions for your enterprise."