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.

We can reasonably forecast that a significant percentage of organizations will use GitLab SaaS and Saas Runners 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 for Runners. 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

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: hosted GitLab Runners available on GitLab SaaS and that support the GitLab Build Cloud for Linux, Windows and macOS.
  3. Runner Enterprise Management: features and capabilities for installing, configuring, managing and monitoring 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

What's Next & Why

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

Runner Core

Refer to this issue list for a more in-depth view of the Runner backlog for runner core. You can also filter by milestone to get a better sense of which issues are candidates for shipping in a release. This view includes additional details such as deprecations, technical debt, and bug fixes, providing a more comprehensive view of the active workstream.

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
  4. Priyanka - Platform Engineer

Maturity Plan

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 Core 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, macOS, 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.

Investment Focus

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.

Revision Date

This direction page was revised on: 2021-08-02

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