Skip to main content
Building on pipeline definitions and execution concepts, GitLab CI/CD consists of three core components:
  1. GitLab Server
  2. Runner
  3. Executor
In this guide, we’ll dive into Runners—the agents that pick up and execute your CI/CD jobs. You can choose between Shared Runners hosted by GitLab or Self-Managed Runners on your own infrastructure.

​
Runner Options at a Glance

AspectShared RunnersSelf-Managed Runners
HostingHosted by GitLabOn your own servers or cloud instances
Setup & MaintenanceFully managed by GitLabRequires in-house installation and upkeep
ConfigurationPredefined, limited customizationFully configurable environment
ScalabilityAuto-scaled to meet demandManual scaling and provisioning
Security BoundaryShared across multiple projectsIsolated per project or group
CostIncluded in GitLab subscription tiersInfrastructure, licensing, and maintenance costs
Ideal Use CaseGeneral-purpose workloads, small teamsStrict compliance, custom tooling, high control
The image is a comparison table of GitLab Runners, detailing features of Shared Runners and Self-Managed Runners, including aspects like hosting, setup, maintenance, control, scalability, security, cost, and suitability for different team sizes.
Choosing between Shared and Self-Managed Runners depends on your organization’s size, security requirements, and operational preferences.

​
Shared Runners

Shared Runners are provided as a service by GitLab. They serve jobs from any project in a GitLab SaaS instance on a first-come, first-served basis.

​
Pros

  • Zero setup: Ready to use out of the box.
  • Cost-effective: Included in most GitLab subscription tiers.
  • Auto-scaled: Capacity adjusts automatically to meet job demand.

​
Cons

  • Limited customization: Cannot install additional software or change low-level settings.
  • Resource contention: Performance may vary under heavy load.
  • Shared security boundary: All projects share the same runner environment.
Shared Runners are ideal for small teams or open-source projects where ease of use outweighs the need for deep customization.

​
Self-Managed Runners

Self-Managed Runners run on your own infrastructure—whether on-premises or in the cloud—giving you total control over configuration, security, and performance.

​
Pros

  • Full control: Install custom software, tune performance, and manage updates.
  • Dedicated resources: Reduce job wait times and ensure consistent build performance.
  • Isolated environment: Minimize cross-project interference and meet strict compliance requirements.

​
Cons

  • Operational overhead: Requires expertise to set up, monitor, and maintain.
  • Manual scaling: You must provision or decommission machines as demand fluctuates.
  • Additional costs: Includes hardware, licensing, and ongoing maintenance expenses.
Ensure you implement proper security measures (firewalls, secrets management, network policies) when exposing self-managed runners to public or untrusted networks.

Watch Video