How to Host a Private GitLab Runner on a VPS

Continuous Integration and Continuous Deployment (CI/CD) pipelines are the backbone of modern software delivery. While GitLab offers shared runners in the cloud, relying on them can lead to slower build times, limited concurrency, and lack of control. Hosting your own GitLab Runner on a VPS ensures faster builds, custom environments, and security isolation. This guide explains how to install, configure, and scale private GitLab Runners in 2025 using VPS infrastructure.

🔹 Why Host Your Own Runner?

Performance: Dedicated CPU/RAM ensures builds aren’t throttled by noisy neighbors.
Customization: Install custom dependencies, Docker images, or GPU drivers not available on shared runners.
Security: Sensitive projects remain within your controlled environment.
Scalability: Scale horizontally with multiple VPS runners distributed across regions.
Cost Control: Avoid per-minute pricing by using flat-rate VPS hosting.

🔹 VPS Requirements

The exact VPS specs depend on build workloads.

Light workloads (frontend, small apps): 2 vCPU, 4–8 GB RAM, 50 GB NVMe storage.
Medium workloads (Dockerized apps, CI/CD for APIs): 4 vCPU, 8–16 GB RAM, 100 GB NVMe.
Heavy workloads (ML builds, GPU acceleration): Dedicated servers with 8–16+ vCPU, 32–64 GB RAM, optional GPU (RTX/Quadro/AMD Instinct).

Bandwidth: Minimum 1 TB/month. For container-heavy workflows, 5–10 TB recommended to handle Docker image pulls and artifact uploads.

🔹 Installation

1. Prepare the VPS

apt update && apt upgrade -y
apt install -y curl gnupg apt-transport-https ca-certificates

2. Add GitLab Repository

curl -fsSL https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | bash

3. Install GitLab Runner

apt install gitlab-runner -y

4. Register the Runner

Use the registration token from your GitLab project/group:

gitlab-runner register
# Example prompts:
URL: https://gitlab.com/
Token: <project-or-group-token>
Description: vps-runner-01
Tags: docker,build
Executor: docker

🔹 Executors Explained

GitLab Runner supports multiple execution backends:

Shell: Fastest but less isolated. Use only in trusted environments.
Docker: Most common. Runs builds in containers for isolation and reproducibility.
Docker+Machine: Autoscale runners by provisioning VPS instances dynamically.
Kubernetes: Ideal for enterprise-scale CI/CD, but requires k8s cluster management.
Custom: GPU runners, LXC, or niche environments.

For most VPS deployments, Docker executor is the sweet spot.

🔹 Optimization Tips

Use Docker-in-Docker (DinD): For building/publishing container images.
Cache Dependencies: Configure cache: in .gitlab-ci.yml for NPM, pip, or Maven.
Artifacts: Store only essential build outputs to reduce storage use.
Parallel Jobs: Assign concurrent in config.toml (e.g., concurrent = 4).

🔹 Security Hardening

Run runners under isolated Linux users.
Enable AppArmor or SELinux profiles for Docker containers.
Rotate GitLab runner tokens periodically.
Restrict SSH access with UFW/iptables + fail2ban.
Use rootless Docker where possible.

🔹 Scaling Runners

Vertical Scaling

Upgrade VPS specs (more CPU/RAM). Useful for monolithic CI pipelines.

Horizontal Scaling

Deploy multiple VPS runners with tags. Distribute jobs (e.g., docker-build, unit-tests, gpu).

Autoscaling

Use Docker Machine executor to spin up VPS instances dynamically on demand (DigitalOcean, AWS, or your own cloud API).

🔹 Monitoring & Maintenance

Logs: Check runner logs in /var/log/gitlab-runner/.
Metrics: GitLab Runners expose Prometheus metrics for queue length and build times.
Alerts: Set up Zabbix or Grafana alerts for CPU, RAM, and disk saturation.
Updates: Keep runner version aligned with GitLab version.

🔹 Example Production Setup

3 VPS runners in EU (4 vCPU / 16 GB RAM each, Docker executor).
1 GPU-enabled dedicated runner for ML workloads.
Autoscaling runners on demand in US region via Docker Machine.

This hybrid architecture handles 100+ concurrent CI jobs for a mid-size SaaS platform at predictable costs.

✅ Conclusion

Hosting a private GitLab Runner on a VPS gives teams full control over CI/CD pipelines. With Docker executor, caching, and security hardening, even modest VPS nodes can handle thousands of builds monthly. Scaling horizontally with multiple VPS instances or GPU runners ensures low queue times and developer productivity. In 2025, controlling your own runners isn’t just about performance — it’s about sovereignty over your build infrastructure.

At WeHaveServers.com, our VPS and dedicated servers are optimized for CI/CD workloads, offering NVMe storage, fast networking, and IPv6 — perfect for GitLab Runner deployments.

❓ FAQ

Do I need root access for GitLab Runner?

Yes. VPS or dedicated with root access is required to install and configure runners.

Can I run multiple runners on one VPS?

Yes. Use multiple runner configurations with different tags in config.toml.

Which executor should I use?

Docker is the most flexible. Shell is faster but less secure; Kubernetes is best for large enterprises.

How much does it cost to run a runner?

€20–€80/month on VPS depending on specs. Dedicated servers cost more but handle heavier pipelines.

Can I use a GPU for GitLab Runner?

Yes. Dedicated servers with NVIDIA or AMD GPUs can accelerate ML builds or CUDA workloads.