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

Category Direction - Runner


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

To better understand GitLab Runner's vision, let's discuss how this aligns with the GitLab product vision and strategy and considers the realities of the broader computing and technology landscape. At GitLab, our product vision is to replace DevOps toolchains with a single application that is pre-configured to work by default across the entire DevOps lifecycle. One of the identified strategic challenges along the way to realizing that vision is managing the balance between self-managed and product offerings. So, as is the case with the GitLab product strategy, the Runner three-year strategy must balance the requirements and projected evolution of both the SaaS and Self-Managed solutions.

So - why is that? In ten years (2030), we can reasonably forecast that a significant percentage of organizations will use GitLab SaaS as their value stream delivery platform compared to organizations that choose the self-managed option. However, there will continue to be a subset of organizations that will require a self-managed solution. There will also be a percentage of customers who use a hybrid solution, i.e., GitLab SaaS with self-hosted runners.

Today, GitLab Runner is distributed as a binary or container image. Customers can deploy and host a fleet of runners on public cloud or on-premise infrastructure. Several machine architectures, including Intel (x86-64), ARM (ARM64), IBM z-series, and host operating systems, Linux, Windows Server, macOS, are supported. Industry watchers forecast that based on current trends, containers and microservices will dominate the technology landscape in the 2020s, with Kubernetes the platform of choice for container orchestration. Of course, innovation and technology shifts can happen at any time, so we should anticipate that future technology solutions may change the market dynamics.

We can make at least one fundamental forecast that is likely to be accurate based on the computing industry's historical evolution. In 2030, much like today, there will continue to be several computing platforms and architectures used in the computing industry. And so, to enable the GitLab product vision, GitLab Runner must continue to evolve and seamlessly support the market-leading computing technologies, machine architectures, and container orchestration platforms.

Direction overview

Organizational Adoption Journey

graph LR classDef purple fill:#696dbe, color:#fff subgraph cj1[Customer Journey] style cj1 fill:#121111,stroke:#121111,stroke-width:1px,color:#fff A0[User Actions]:::purple end subgraph ob1["POC, ONBOARDING, PRODUCTION ENVIRONMENT SETUP"] style ob1 fill:#121111,stroke:#121111,stroke-width:1px,color:#fff A1[Install GitLab]:::purple --> A2(Install the 1st Runner):::purple end subgraph sc1["SCALE USAGE PHASE: USERS, FEATURES, STAGE ADOPTION, n...n+1 phases"] style sc1 fill:#121111,stroke:#121111,stroke-width:1px,color:#fff A2 --> A3(Rollout and start managing more than 1 Runner to support the organization):::purple end A0-.-A1;
graph LR classDef orange fill:#f0a543, color:#00000 subgraph cj1[Customer Journey] style cj1 fill:#ededf7,stroke:#ededf7,stroke-width:1px,color:#00000 A0[Runner Pain Points]:::orange end subgraph ob1["POC, ONBOARDING, PRODUCTION ENVIRONMENT SETUP"] style ob1 fill:#ededf7,stroke:#ededf7,stroke-width:1px,color:#00000 A1[Manual steps to install
and configure first Runner]:::orange --> A2(Manual steps to configure additional Runners):::orange end subgraph sc1["SCALE USAGE PHASE: USERS, FEATURES, STAGE ADOPTION, n...n+1 phases"] style sc1 fill:#ededf7,stroke:#ededf7,stroke-width:1px,color:#00000 A2 --> A3[Runner Token registration
process is manual]:::orange A3 --> A4[High operational overhead
to maintain a large fleet of Runners]:::orange A4 --> A5[No instrumentation that
indicates why a Runner
has not started]:::orange 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.

Runner Core

Runner Cloud

Runner Enterprise Management

Refer to this issue list for a more in-depth view of the Runner backlog.

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

Who we are focusing on?

Check out our Ops Section Direction "Who's is it for?" for an in depth look at the our target personas across Ops. For Runner, our "What's Next & Why" are targeting the following personas, as ranked by priority for support:

  1. Devon - DevOps Engineer
  2. Sasha - Software Developer
  3. Delaney - Development Team Lead

Maturity Plan

This category is already at the "Lovable" maturity level (see our definitions of maturity levels). However, we must 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 at scale. Besides working on the long-term vision, we continuously assess and prioritize working on issues opened by the community and customers in each release.

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. A CI/CD agent is the software that is 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, Codefresh Runner, to name a few.

In short, the GitLab Runner takes a job from a GitLab instance, executes that job, and sends the results back to GitLab, all over HTTPS.

So, given the seemingly simple CI job execution task, should we even consider the runner from a competitive analysis standpoint? The answer is yes, for as you can see from the few examples below, the industry recognizes that the CI engine's capabilities are critical to a value stream delivery platform's long-term success in the market.

In GitHub's 2021 Roadmap, we are seeing several runner related features including:

  1. Multiple Hosted Runner Sizes
  2. Enterprise Server can use Actions hosted runners
  3. Customization and security for hosted runners

Our perspective is that GitLab Runner is well-positioned to enable GitLab's strategic vision. Why?

  1. GitLab Runner is open-source. Our community members and customers have full access to the GitLab Runner source code and can contribute features, bug fixes directly to the code base.
  2. GitLab Runner supports multiple executors. One of the most useful executor types is the Docker executor, which enables users to execute CI jobs inside a container, resulting in less maintenance for the CI/CD build environment.
  3. GitLab Runner includes autoscaling out of the box. Autoscaling is available for public cloud virtual machines or Kubernetes stacks by using the Kubernetes executor. For a some a look at the competitive landscape of Autoscaling see gitlab&2502.
  4. GitLab Runner supports several computing architectures. Customers who need to self-host runners on platforms such as IBM Z mainframes to take advantage of GitLab and modern Value Stream Delivery Platforms can. We aim to meet and support customers on the platforms that they use in their environment.

SaaS 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 a 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)

The list below represents issues that have a high number of upvotes from the community. To understand if an issue is targeted for delivery, review the target milestone and issue state labels. Refer to the interpreting issue states section of the handbook for additional guidance.

Give Feedback

The near term features and capabilities highlighted here represent just a subset of the features and capabilities that have been requested by the community and customers. If you have questions about a specific runner feature request or have a requirement that's not yet in our backlog, you can provide feedback or open an issue in the GitLab Runner repository.

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