Self-Hosted GitLab CE on Linux VPS: DevOps CI/CD Architecture and Runner Optimization in Pakistan

Pakistani software engineering agencies, product startups, and enterprise FinTech teams are increasingly moving away from expensive per-seat SaaS platforms like GitHub Enterprise and SaaS GitLab. With cloud billing denominated in appreciating US Dollars and stringent client intellectual property non-disclosure requirements, self-hosting GitLab Community Edition (CE) on private infrastructure delivers substantial financial and security advantages.

However, GitLab CE is a large, multi-component enterprise application. It bundles a Ruby on Rails application server (Puma), a background job processor (Sidekiq), a PostgreSQL database, Redis caches, Gitaly (Git RPC server), and NGINX. If deployed on an unoptimized virtual machine, it will easily consume 8GB+ of RAM at idle, thrashing the swap partition and rendering CI/CD pipelines painfully sluggish.

This technical guide details how to install, tune, and optimize a high-performance self-hosted GitLab CE instance and scale dedicated GitLab Runners on Linux VPS and bare metal in Pakistan.

---

1. System Topology & Architecture

GitLab coordinates multiple internal microservices that must be allocated adequate CPU and memory thresholds to prevent Out-Of-Memory (OOM) killer terminations.

Developer Workstations (Karachi / Lahore / Islamabad)
                           │
                           ▼ (Sub-15ms Domestic Git Push / Pull)
             [NGINX Reverse Proxy (Port 443 / SSH 22)]
                           │
             ┌─────────────┴─────────────┐
             ▼                           ▼
      [Workhorse / Puma]            [Gitaly Daemon]
     (Rails API & Web UI)        (Direct Git RPC Access)
             │                           │
             ├──► [Redis In-Memory Queue & Cache]
             │
             ├──► [Sidekiq Async Job Workers]
             │
             ▼
      [PostgreSQL 14+ Database Engine]

Key Performance Benefits of Local Hosting:

1. Ultra-Fast Git Operations: Large repositories with gigabytes of assets push and clone at line rate across local fiber rings (1Gbps domestic peering vs 20Mbps throttled overseas routes).
2. Deterministic Build Pipeline Latency: Self-hosted GitLab Runners run on dedicated local hardware, eliminating queue wait times found on free shared SaaS tiers.
3. Source Code Sovereignty: Client source code never leaves sovereign Pakistani infrastructure, ensuring compliance with SECP and bank enterprise NDA standards.

For growing engineering departments running heavy build matrices and Docker container builds, hosting on our high-throughput Cloud VPS provides the dedicated CPU threads and pure NVMe throughput needed to keep pipelines fast.

---

2. Installation and Memory-Optimized gitlab.rb Configuration

Deploying GitLab CE on Ubuntu 22.04 or 24.04 LTS requires configuring the official Omnibus repository and tuning /etc/gitlab/gitlab.rb before the initial reconfigure.

Step 1: Install Dependencies & Omnibus Repository

sudo apt-get update
sudo apt-get install -y curl openssh-server ca-certificates tzdata perl

# Add GitLab CE repository
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

# Install GitLab CE without immediate configuration
sudo EXTERNAL_URL="https://git.devcompany.pk" apt-get install gitlab-ce

Step 2: Tune Resource Allocation for 4GB – 8GB VPS Nodes

By default, GitLab configures itself for massive 32GB+ enterprise nodes. To run smoothly on a high-efficiency 8GB or 16GB Linux VPS, edit /etc/gitlab/gitlab.rb:

# Primary External URL
external_url 'https://git.devcompany.pk'

# Puma Web Server Tuning (Eliminates idle Rails memory bloat)
puma['worker_processes'] = 2
puma['min_threads'] = 4
puma['max_threads'] = 8
puma['worker_timeout'] = 60

# Sidekiq Concurrency Tuning (Reduce background worker consumption)
sidekiq['concurrency'] = 10
sidekiq['max_concurrency'] = 15

# PostgreSQL Memory Optimization
postgresql['shared_buffers'] = "512MB"
postgresql['work_mem'] = "16MB"
postgresql['maintenance_work_mem'] = "64MB"
postgresql['max_connections'] = 100

# Gitaly Concurrency Limits
gitaly['ruby_max_rss'] = 200_000_000
gitaly['concurrency'] = [
  {
    'rpc' => "/gitaly.SmartHTTPService/PostReceivePack",
    'max_per_repo' => 3
  }
]

# NGINX Configuration and Let's Encrypt SSL
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['[email protected]']
letsencrypt['auto_renew'] = true

Apply the optimized configuration:

sudo gitlab-ctl reconfigure

This configuration reduces idle RAM consumption from ~7.8GB down to ~3.2GB, leaving ample memory for concurrent developer interactions and Git pushes.

---

3. Dedicated GitLab Runner Deployment & Optimization

Never run CI/CD builds on the primary GitLab server node. Build processes (Docker in Docker, npm builds, test suites) can easily saturate CPU cores and starve Gitaly, causing web UI timeouts.

Deploy the GitLab Runner on a separate worker node:

# On the dedicated CI/CD Worker Node:
curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
chmod +x /usr/local/bin/gitlab-runner
useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bash
gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner
gitlab-runner start

Register the Runner using the token from your GitLab Admin Area:

sudo gitlab-runner register \
  --url "https://git.devcompany.pk" \
  --registration-token "GLRT-YOUR-REGISTRATION-TOKEN" \
  --executor "docker" \
  --docker-image "docker:stable" \
  --description "High-Speed-Docker-Runner-PK" \
  --docker-privileged

Edit /etc/gitlab-runner/config.toml to maximize concurrent build jobs:

concurrent = 4
check_interval = 0

[session_server]
  session_timeout = 1800

[[runners]]
  name = "High-Speed-Docker-Runner-PK"
  url = "https://git.devcompany.pk"
  executor = "docker"
  [runners.docker]
    tls_verify = false
    image = "docker:stable"
    privileged = true
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock"]
    shm_size = 2147483648

---

4. Hosting Architecture Comparison

Metric	SaaS GitHub/GitLab	Unmanaged Shared Cloud	Dedicated Cloud VPS	Bare-Metal Dedicated Server
Pricing Model	$19 – $29/seat/mo USD	Unpredictable usage fees	Fixed Flat PKR Cost	Maximum Cost Efficiency
Data Residency	Hosted in US/EU	Depends on region	100% Domestic (PKIX)	Completely Isolated Bare Metal
CI/CD Concurrency	Capped free minutes	Slow shared VMs	Dedicated Multi-Core CPU	32+ Dedicated Build Cores
Git Clone Throughput	2MB/s – 10MB/s	5MB/s – 15MB/s	50MB/s – 100MB/s Line Rate	1Gbps+ Local Metro Loop
Enterprise Storage	Billable LFS Storage	Metered SSD	Pure NVMe Storage Arrays	Multi-TB NVMe RAID-10

For development agencies operating enterprise CI/CD clusters across Karachi, Lahore, and Islamabad, hosting on Dedicated Servers in Pakistan provides physical hardware root-of-trust, maximum I/O performance, and complete data privacy.

When coordinating remote teams distributed globally across North America, Europe, and Asia, NextGen’s global Dedicated Servers provide redundant international bandwidth pipelines and carrier-neutral Tier-1 peering.

---

Related Engineering & Hosting Guides

Continue expanding your DevOps automation and production hosting architecture knowledge:

• Enterprise Drupal Hosting Architecture and Production Tuning
• MariaDB and MySQL Performance Tuning on Linux VPS
• WAF Firewall Bypass Audit and OWASP Top 10 Hardening