The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Verify |
| Maturity | Lovable |
| Content Last Reviewed | 2025-12-05 |
Thanks for visiting this direction page on the Runner Core category at GitLab. This page belongs to the Runner Group within the Verify Stage and is maintained by Gabriel Engel.
GitLab Runner - the near-ubiquitous build agent that executes CI jobs on a target compute platform is a critical foundational pillar of GitLab's one DevSecOps platform vision. The fundamental problems customers must solve in this product category include installing, configuring, and scaling CI/CD build agents (runners) on public or private cloud infrastructure and securely executing CI/CD jobs on heterogeneous computing architectures, x86-64, ARM, and s390x.
For customers that run millions of CI/CD jobs monthly, the primary GitLab Runner autoscaling options for CI/CD builds in ephemeral, isolated environments are Kubernetes and public cloud or on-premise virtual machine environments. Therefore, critical needs for this customer segment include consistently fast start times for builds, fast build times as measured by total wall clock time, low CI build failure rates due to runner or runner host infrastructure issues, and minimal operational overhead. Other customers require seamless support for multi-platform and architecture builds, while others need the flexibility to install a build agent according to their organization's security and compliance policies
Our major investment themes for GitLab Fiscal Year 2026 are as follows:
In the next three months we plan to deliver these features or capabilities:
group::runnerWe are working on the fault tolerance feature for the Runner Kubernetes executor.
We are not actively working on the following features:
BIC (Best In Class) is an indicator of forecasted near-term market performance based on a combination of factors, including analyst views, market news, and feedback from the sales and product teams. It is critical that we understand where GitLab appears in the BIC landscape.
When you run a continuous integration pipeline job or workflow, the code in that pipeline must execute on some computing platform to complete your software's building, testing, and deployment. Terms used to describe the software that handles the pipeline code execution include worker, agent, or runner.
So while the basic functionality of pipeline code execution is table stakes in the industry, the ability to efficiently build software on multiple compute platforms with low operational maintenance overhead are critical features for a best-in-class solution.
.gitlab-ci.yml file provides a declarative syntax for defining jobs, stages, and dependencies, making it easy for developers to set up and manage their pipelines.| Solution | CI/CD Agent naming convention/brand | Self-Managed Option Availablity | Notes |
|---|---|---|---|
| GitHub Actions | Runners | Available | At its core, GitHub Action Runners are similar to GitLab Runners in that they communicate to a central server via a REST API, execute jobs, and send the logs and artifacts back to the server when finished. However, multi-platform support, native autoscaling on cloud instances, support for Kubernetes as a build environment, concurrency, and parallel CI/CD job execution are more mature in GitLab Runner. As expected, GitHub has continued to invest in features and capabilities to improve the maturity of GitHub Action Runners. For instance, the recently released Actions Runner Controller (ARC) enables GitHub Actions Runners to autoscale on Kubernetes clusters. However, as noted by others, there is operational overhead involved in the setup and configuration of ARC. On the GitHub public roadmap, we also notice similar investment themes regarding multi-platform support as GitHub continues to target market segments requiring a self-managed platform. |
| Harness.io | Harness Delegate | Available | Harness currently provides the following types of Delegate: Kubernetes, Shell Script, AWS ECS, Helm, Docker. Though the Delegates perform a similar essential function as GitLab Runner, i.e., executes tasks provided by the Harness Manager, the Delegates' primary purpose is to deploy software to the target platform. In this regard, the value proposition of the GitLab Agent for Kubernetes is a critical consideration when evaluating capabilities in GitLab for developer frictionless cloud-native deployment. |
| Nx Cloud | Nx Agents | Available | Nx Cloud a build system for optimizing CI performance and scaling for monorepos,includes Nx agents which dynamically distributes the CI/CD jobs across multiple buiild machines. |
| Jenkins | Agents | Available | In Jenkins, an agent is a software executable that runs a task under the direction of the Jenkins controller. Like GitLab Runner, a Jenkins agent can run on different computing environments (bare metal, virtual machines, containers, Kubernetes clusters). Java must be supported and installed on the host OS to run a Jenkins agent. |