GitLab Self-Hosted Runner vs Shared Runner: Which One Should You Use?

GitLab Self-Hosted Runner vs Shared Runner#

Learn the difference between GitLab-hosted/shared runners and self-hosted runners, when to use each option, and how to choose the right runner model for your DevOps team.

Table of contents#

• Quick answer
• What are shared or GitLab-hosted runners?
• What are self-hosted runners?
• Comparison table
• When to choose each
• Common mistakes
• Related guides

Quick answer#

Use shared/hosted runners#

Good for quick start, simple builds, learning, and teams that do not want to manage infrastructure.

Use self-hosted runners#

Good for private networks, special tools, compliance, custom hardware, and production deployment control.

Use both#

Many teams use hosted runners for normal tests and self-hosted runners for secure deployments.

What are shared or GitLab-hosted runners?#

Shared or hosted runners are runner capacity provided by the platform or organization. They are convenient because developers can run jobs without installing runner software on their own servers.

What are self-hosted runners?#

Self-hosted runners are installed and managed by your team on your own server, VM, container platform, or Kubernetes cluster. They provide more control but also require patching, monitoring, and security management.

Runner comparison table#

When should you choose each?#

Choose shared/hosted runners when:#

• You are learning GitLab CI/CD.
• Your builds are simple.
• You do not need private network access.
• You want less infrastructure maintenance.

Choose self-hosted runners when:#

• Your pipeline needs internal servers or private registries.
• You need special build tools or hardware.
• You need stronger control over where code runs.
• You deploy to production from trusted infrastructure.

Common mistakes#

• Using one runner for every workload.
• Running untrusted merge requests on privileged runners.
• Not monitoring runner disk usage.
• Ignoring runner tags.
• Giving production variables to jobs that do not need them.

Best practices#

• Use runner tags clearly.
• Separate build/test runners from deployment runners.
• Keep self-hosted runners updated.
• Monitor CPU, memory, disk, and queue time.
• Use least privilege for deployment credentials.

• GitLab CI/CD Learning Path
• GitLab Runner Setup on Ubuntu
• GitLab CI/CD Best Practices

Official references#

• GitLab Runner documentation
• GitLab CI/CD runners documentation