Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Runner

GitLab Runner

GitLab Runner is the multi-platform agent that works with GitLab CI to execute the jobs in a pipeline and powers the CI build platform on GitLab.

Our vision for GitLab Runner is to offer DevOps teams a build agent that works seamlessly on today's and tomorrow's market-leading computing platforms and the tools to eliminate CI build fleet operational complexity at enterprise scale.

DevOps teams may be managing hundreds of Runners, which may also mean offering different virtual machine configurations and sizes, which adds operational complexity. At the heart of the Runner vision, is that DevOps teams should not have to spend enormous amounts of time and effort deploying, configuring, and maintaining Runners.

As is the case with the GitLab product strategy, the Runner's strategy must consider and balance the needs of both self-managed and product offerings. Self-managed customers whose security and compliance requirements dictate that the entire DevOps toolchain runs within their private networks can host the runner themselves. In addition to public clouds, self-managed customers can deploy and host the runner on several platforms, including Kubernetes, RedHat OpenShift, and Linux on Z for IBM Z mainframes. Therefore, the product strategy for self-managed assumes a future, much like today, where there will continue to be a wide variety in the type of infrastructure stacks organizations adopt on public clouds or deploy in their data centers.

Organizational Adoption Journey

graph LR classDef blue fill:#3278ca, color:#fff classDef darkblue fill:#225798, color:#fff subgraph "CUSTOMER JOURNEY" A0[User Actions]:::darkblue end subgraph "POC, ONBOARDING, PRODUCTION ENVIRONMENT SETUP" A1[Install GitLab]:::blue --> A2(Install the 1st Runner):::blue end subgraph "SCALE USAGE PHASE: USERS, FEATURES, STAGE ADOPTION, n...n+1 phases" A2 --> A3(Rollout and start managing more than 1 Runner to support the organization):::blue end A0-.-A1;
graph LR classDef red fill:#c92d39, color:#fff classDef darkred fill:#9a0814, color:#fff classDef blue fill:#3278ca, color:#fff classDef darkblue fill:#225798, color:#fff subgraph "CUSTOMER JOURNEY" A0[Runner Pain Points]:::darkred end subgraph "POC, ONBOARDING, PRODUCTION ENVIRONMENT SETUP" A1[Manual steps to install
and configure first Runner]:::red --> A2(Manual steps to configure additional Runners):::red end subgraph "SCALE USAGE PHASE: USERS, FEATURES, STAGE ADOPTION, n...n+1 phases" A2 --> A3[Runner Token registration
process is manual]:::red A3 --> A4[High operational overhead
to maintain a large fleet of Runners]:::red A4 --> A5[No instrumentation that
indicates why a Runner
has not started]:::red end A0-.-A1;

Runner Product Development Categories

The Runner product development strategy comprises three main focus areas to enable the vision.

  1. Runner Core: features and capabilities for the open-source GitLab Runner CI execution agent.
  2. Runner Cloud: the GitLab Runner CI build virtual machines available on GitLab SaaS.
  3. Runner Enterprise Management: features and capabilities for DevOps teams to simplify the management of the GitLab Runner CI/CD build infrastructure.

Top Vision Item(s)

The content in this section outlines some of the initiatives that we are exploring. In some cases, we are in the early phases of exploring the concept, while in others, we have a more concrete solution in mind and have started work on the first iteration of features or capabilities.

For a more in-depth view of the issue backlog for Runner core, refer to the issue list.

Runner Core

Runner Cloud

Runner Enterprise Management

What's Next & Why

In the section below, we highlight a few key features that we are working to deliver in the near term releases.

Runner Core

Runner Cloud

Maturity Plan

This category is already at the "Lovable" maturity level (see our definitions of maturity levels). However, it's important to us that we defend our lovable status and provide the most value to our user community. To that end, we continue to collect and analyze customer and community feedback to understand users' pain points with installing, managing, and using GitLab Runners. If you have any feedback that you would like to share, you can do so in this epic.

Competitive Landscape

When you run a continuous integration pipeline job or workflow, it is powered by some computing platform. This commonly includes a container, a physical desktop computer, a bare-metal server, or a virtual machine environment. Any computing environment can host a continuous integration pipeline job or workflow.

As its typically referred to, the build agent determines if the pipeline job or workflow can run on a target computing platform. The build agent is also responsible for executing the scripts defined in a continuous integration pipeline job or workflow. There is the GitLab Runner, Jenkins agent, Github runner, Azure Pipelines agents, runners, to name a few.

Hosted Build Agents

Users of SaaS hosted CI platforms, such as, CircleCI, and GitHub, Azure DevOps can run their CI pipelines and get to a first green build without being concerned about the agents' setup and maintenance. Like GitLab, these providers are managing the build agents and the infrastructure that those agents run on.

GitLab Runner is an open-source, lightweight, high performant build agent that executes CI jobs in the cloud very efficiently. The performance of CI jobs, measured in job duration minutes, on hosted runners relative to the market is very comparable. The one variable is the computing resources allocated to the virtual machines hosting the build agents.

Today competitors such as GitHub, CircleCI, and Azure DevOps offer multiple virtual machine types for build agents hosted on Linux or Windows virtual machines. GitLab offers one machine type for both Linux and Windows virtual machines. However, users on can install their own GitLab runners on a supported computing platform and use those runners to execute the CI jobs in their hosted project repository.

Self-Managed Build Agents

For users who need to host and manage their own build agents and the underlying infrastructure, GitLab runner offers a wide array of solutions positioned very well in the market place from a competitive standpoint. First, GitLab Runner binaries are available on x86, AMD64, ARM64, ARM, s390x (IBM-Z mainframes). Linux, Windows, and macOS operating systems are fully supported.

A significant competitive differentiator is the availability of the GitLab Runner custom executor. This open-source solution enables the community to add an executor to the GitLab Runner to execute CI jobs on a computing platform or infrastructure that's not currently supported. With this very powerful yet simple to implement driver, users can configure the GitLab Runner to use an executable to provision, run and clean up a build environment.

GitLab Runner is also available as a container image on DockerHub. Judging by the hundreds of thousands of daily downloads, this is a top-rated solution for users.

Customers hosting build agents on public cloud virtual machines can quickly deploy and use the GitLab Runner autoscaling feature. This autoscaling solution enables the automated provisioning and decommissioning of build agents based on CI job load.

GitLab Runner's support for Kubernetes and the recent addition of autoscaling capability for AWS ECS and Fargate makes the GitLab Runner a compelling option for enterprises considering which value stream delivery platform to deploy to support their digital transformation strategic goals.

Top Customer Success/Sales Issue(s)

For the CS team, the issue gitlab-runner#3121 where orphaned processes can cause issues with the runner in certain cases has been highlighted as generating support issues.

Top Customer Issue(s)

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license