- Installing GitLab Runner
- Updating GitLab Runner
- GPG signatures for package installation
- Manually download packages
- Upgrading to GitLab Runner 10
We provide packages for the currently supported versions of Debian, Ubuntu, Mint, RHEL, Fedora, and CentOS. You may be able to install GitLab Runner as a binary on other Linux distributions.
|Distribution||Version||End of Life date|
|Mint||sarah, serena, sonya, sylvia||April 2021|
|Mint||tara, tessa, tina, tricia||April 2023|
|Mint||ulyana, ulyssa||April 2025|
|Fedora||32||approx. May 2021|
|Fedora||33||approx. Nov 2021|
|Fedora||34||approx. May 2022|
To install GitLab Runner:
Add the official GitLab repository:
# For Debian/Ubuntu/Mint curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash # For RHEL/CentOS/Fedora curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.rpm.sh" | sudo bashDebian users should use APT pinning.
Install the latest version of GitLab Runner, or skip to the next step to install a specific version:
# For Debian/Ubuntu/Mint sudo apt-get install gitlab-runner # For RHEL/CentOS/Fedora sudo yum install gitlab-runner
To install a specific version of GitLab Runner:
# for DEB based systems apt-cache madison gitlab-runner sudo apt-get install gitlab-runner=10.0.0 # for RPM based systems yum list gitlab-runner --showduplicates | sort -r sudo yum install gitlab-runner-10.0.0-1
After completing the step above, a runner should be started and be ready to be used by your projects!
Make sure that you read the FAQ section which describes some of the most common problems with GitLab Runner.
A native package called
gitlab-ci-multi-runner is available in
Debian Stretch. By default, when installing
gitlab-runner, that package
from the official repositories will have a higher priority.
If you want to use our package, you should manually set the source of the package. The best way is to add the pinning configuration file.
If you do this, the next update of the GitLab Runner package - whether it will be done manually or automatically - will be done using the same source:
cat <<EOF | sudo tee /etc/apt/preferences.d/pin-gitlab-runner.pref Explanation: Prefer GitLab provided packages over the Debian native ones Package: gitlab-runner Pin: origin packages.gitlab.com Pin-Priority: 1001 EOF
Simply execute to install latest version:
# For Debian/Ubuntu/Mint sudo apt-get update sudo apt-get install gitlab-runner # For RHEL/CentOS/Fedora sudo yum update sudo yum install gitlab-runner
To increase user’s confidence about installed software, the GitLab Runner project provides two types of GPG signatures for the package installation method: repository metadata signing and package signing.
To verify that the package information downloaded from the remote repository can be trusted, the package manager uses repository metadata signing.
The signature is verified when you use a command like
apt-get update, so the
information about available packages is updated before any package is downloaded and
installed. Verification failure should also cause the package manager to reject the
metadata. This means that you cannot download and install any package from the repository
until the problem that caused the signature mismatch is found and resolved.
GPG public keys used for package metadata signature verification are installed automatically on first installation done with the instructions above. For key updates in the future, existing users need to manually download and install the new keys.
We use one key for all our projects hosted under https://packages.gitlab.com. You can find the details about the currently used key and technical description of how to update the key when needed in Omnibus GitLab documentation. This documentation page lists also all keys used in the past.
Repository metadata signing proves that the downloaded version information originates at https://packages.gitlab.com. It does not prove the integrity of the packages themselves. Whatever was uploaded to https://packages.gitlab.com - authorized or not - will be properly verified until the metadata transfer from repository to the user was not affected.
This is where packages signing comes in.
With package signing, each package is signed when it’s built. So until you can trust the build environment and the secrecy of the used GPG key, the valid signature on the package will prove that its origin is authenticated and its integrity was not violated.
Packages signing verification is enabled by default only in some of the DEB/RPM based distributions, so users wanting to have this kind of verification may need to adjust the configuration.
GPG keys used for packages signature verification can be different for each of the repositories hosted at https://packages.gitlab.com. The GitLab Runner project uses its own key pair for this type of the signature.
The RPM format contains a full implementation of GPG signing functionality, and thus is fully integrated with the package management systems based upon that format.
You can find the technical description of how to configure package signature verification for RPM-based distributions in the Omnibus GitLab documentation. The GitLab Runner differences are:
The public key package that should be installed is named
The repository file for RPM based distributions will be named
/etc/yum.repos.d/runner_gitlab-runner.repo(for the stable release) or
/etc/yum.repos.d/runner_unstable.repo(for the unstable releases).
The DEB format does not officially contain a default and included method for signing packages.
The GitLab Runner project uses
dpkg-sig tool for signing and verifying signatures on packages. This
method supports only manual verification of packages.
apt-get update && apt-get install dpkg-sig
Download and import the package signing public key
curl -JLO "https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-4C80FB51394521E9.pub.gpg" gpg --import runner-gitlab-runner-4C80FB51394521E9.pub.gpg
Verify downloaded package with
dpkg-sig --verify gitlab-runner_amd64.deb Processing gitlab-runner_amd64.deb... GOODSIG _gpgbuilder 09E57083F34CCA94D541BC58A674BF8135DFA027 1623755049
Verification of package with invalid signature or signed with an invalid key (for example a revoked one) will generate an output similar to:
dpkg-sig --verify gitlab-runner_amd64.deb Processing gitlab-runner_amd64.deb... BADSIG _gpgbuilder
If the key is not present in the user’s keyring, the output will be similar to:
dpkg-sig --verify gitlab-runner_amd64.v13.1.0.deb Processing gitlab-runner_amd64.v13.1.0.deb... UNKNOWNSIG _gpgbuilder 880721D4
The current public GPG key used for packages signing can be downloaded from https://packages.gitlab.com/runner/gitlab-runner/gpgkey/runner-gitlab-runner-4C80FB51394521E9.pub.gpg.
release.sha256files for the S3 releases available in the https://gitlab-runner-downloads.s3.amazonaws.com/ bucket.
Keys used in the past can be found in the table below.
For keys that were revoked it’s highly recommended to remove them from package signing verification configuration.
Signatures made by these keys should not be trusted anymore.
|Sl. No.||Key Fingerprint||Status||Expiry Date||Download (revoked keys only)|
You can manually download and install the packages if necessary.
In GitLab Runner 12.10 we’ve added support for a special
GITLAB_RUNNER_DISABLE_SKEL - that when set to
true is preventing usage of
when creating the
$HOME directory of the newly created user.
Starting with GitLab Runner 14.0
GITLAB_RUNNER_DISABLE_SKEL is being set to
true by default.
If for any reason it’s needed that
skel directory will be used to populate the newly
$HOME directory, the
GITLAB_RUNNER_DISABLE_SKEL variable should be set explicitly
false before package installation. For example:
# For Debian/Ubuntu/Mint export GITLAB_RUNNER_DISABLE_SKEL=false; sudo -E apt-get install gitlab-runner # For RHEL/CentOS/Fedora export GITLAB_RUNNER_DISABLE_SKEL=false; sudo -E yum install gitlab-runner
Please note, that shell configuration added to the
$HOME directory with the usage of
interfere with the job execution and introduce unexpected problems like the ones mentioned above.
To upgrade GitLab Runner from a version prior to 10.0:
Remove the old repository:
# For Debian/Ubuntu/Mint sudo rm /etc/apt/sources.list.d/runner_gitlab-ci-multi-runner.list # For RHEL/CentOS/Fedora sudo rm /etc/yum.repos.d/runner_gitlab-ci-multi-runner.repo
Follow the same steps when installing GitLab Runner, without registering it and using the new repository.
For RHEL/CentOS/Fedora, run:
sudo /usr/share/gitlab-runner/post-installIf you don’t run the above command, you will be left with no service file. Follow issue #2786 for more information.