GitLab Server: Self-hosted CI/CD from $15/month

For deploying a self-hosted GitLab with CI/CD and Registry functionality, ensuring efficient work for a team of up to 10-15 developers, a VPS or dedicated server with a minimum of 4 GB RAM, 2-4 vCPU, and an NVMe disk of 80 GB or more is optimal. Such plans for reliable gitlab server hosting start on Valebyte from $15/month.

GitLab is a powerful platform for the full DevOps lifecycle, integrating Git repository management, CI/CD, issue tracking, wikis, and much more. Deploying your own GitLab (self-hosted GitLab) on your own server provides full control over data, security, and configuration, which is critical for many companies. In this article, we will look at how to choose and configure optimal gitlab server hosting, what resources will be required, and how to effectively use Docker for deployment.

Why choose self-hosted GitLab?

The choice in favor of self-hosted GitLab is driven by a number of advantages that are not available in cloud SaaS solutions, especially for projects with increased requirements for security, performance, and customization. When you host your own GitLab on your own server, you get:

• Full data control: All your repositories, CI/CD pipelines, and artifacts are stored on your infrastructure, which complies with strict regulatory and security requirements.
• Configuration flexibility: The ability to fine-tune all GitLab components, integrate with internal authentication systems (LDAP/AD), custom hooks, and extensions.
• Performance optimization: You manage server resources yourself, can scale them as your team and projects grow, ensuring stable and fast CI/CD operation.
• Cost savings for large teams: For a significant number of users, the cost of a gitlab dedicated server can be significantly lower than monthly payments for cloud plans, especially if you already have infrastructure or plan to develop it.
• Independence from external services: No dependence on pricing policies, updates, and potential outages of third-party providers.

What are the minimum server requirements for GitLab?

Defining gitlab server requirements is the first step to successful deployment. Minimum requirements heavily depend on your team size and usage intensity. GitLab is quite resource-intensive, especially if CI/CD, Container Registry, and other components are actively used.

For small teams (up to 10-15 developers) and not very intensive CI/CD usage, the minimum requirements are as follows:

• Processor (CPU): 2 cores with a frequency of 2.5 GHz or higher. GitLab intensively uses CPU for request processing, running CI/CD jobs, and indexing.
• Random Access Memory (RAM): Minimum 4 GB. This is an absolute minimum; 8 GB is recommended for stable operation. GitLab caches a lot of data in memory.
• Disk space: 80 GB NVMe disk. NVMe is critically important for GitLab performance, especially for Git repository operations, CI/CD caches, and the database. HDD or SATA SSD will significantly slow down performance.
• Operating System: Ubuntu Server (recommended), CentOS/RHEL, Debian.

For larger teams or high loads, these requirements increase significantly. Let's consider typical configurations:

Remember that these figures are a starting point. Actual needs may vary depending on the volume of repositories, the number of parallel CI/CD tasks, the services used (Registry, Pages, etc.), and user activity.

VPS or dedicated server for GitLab: what to choose?

The choice between a VPS and a gitlab dedicated server depends on the scale of your project, budget, and performance requirements. Both options offer full control over the environment but have their own characteristics.

VPS (Virtual Private Server)

A VPS is a virtual machine on a physical server, where resources (CPU, RAM, disk) are shared among several users. This is an excellent choice for:

• Small to medium-sized teams (up to 50-70 developers).
• Startups and projects with limited budgets.
• Development and testing, where maximum performance is not required.

Advantages: Flexibility, rapid scaling, low entry cost. On Valebyte, you can easily increase VPS resources as your project grows.

Disadvantages: Performance can be subject to the "noisy neighbor effect," although this is minimized with reliable providers. Resources, though guaranteed, are virtualized.

Dedicated Server

A dedicated server provides you with exclusive access to all physical resources of the machine. This is an ideal option for:

• Large teams (from 50-100+ developers).
• Projects with high CI/CD load, a large number of repositories, and active use of Container Registry.
• Companies with mission-critical applications requiring maximum performance and stability.

Advantages: Maximum performance, stability, full control over hardware, better security isolation. If you use GitLab not only for code but also as a deployment platform, for example, with Docker containers, then a dedicated server for Docker will be the optimal solution.

Disadvantages: Higher cost, requires more administration experience. However, for GitLab, especially with active CI/CD, these are often justified investments.

Overall, to get started with gitlab server hosting, a VPS on Valebyte with 4-8 GB RAM and an NVMe disk will be an excellent start. As your project grows and the load increases, you can always upgrade to a more powerful VPS or a dedicated server if the cloud does not meet your requirements.

Deploying GitLab on Docker: a step-by-step guide

Using Docker for deploying self-hosted GitLab significantly simplifies the installation, update, and management process. The GitLab Docker image contains all necessary components and dependencies, minimizing conflicts and ensuring portability.

1. Install Docker and Docker Compose

First, you need to install Docker and Docker Compose on your server. For Ubuntu:

sudo apt update
sudo apt install apt-transport-https ca-certificates curl software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install docker-ce docker-ce-cli containerd.io
sudo systemctl enable docker --now
sudo usermod -aG docker $USER # Add the current user to the docker group
# Restart your session or run newgrp docker

# Install Docker Compose
sudo curl -L "https://github.com/docker/compose/releases/latest/download/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

2. Create docker-compose.yml file

Create a directory for GitLab and the docker-compose.yml file:

mkdir -p ~/gitlab_data/config ~/gitlab_data/logs ~/gitlab_data/data
cd ~/gitlab_data

In the docker-compose.yml file, specify the following configuration:

version: '3.6'
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    container_name: gitlab
    hostname: 'your.gitlab.domain.com' # Replace with your domain
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://your.gitlab.domain.com' # Replace with your domain
        nginx['listen_port'] = 80
        nginx['listen_https'] = false
        nginx['proxy_set_headers'] = {
          "X-Forwarded-Proto" => "https",
          "X-Forwarded-Ssl" => "on"
        }
        # If you are using HTTPS via an external proxy/load balancer (e.g., Nginx on the host)
        # If GitLab should generate certificates itself, remove proxy_set_headers and enable
        # letsencrypt['enable'] = true
        # letsencrypt['contact_emails'] = ['[email protected]']
        # letsencrypt['auto_renew_hour'] = "12"
        # letsencrypt['auto_renew_minute'] = "30"
        # letsencrypt['auto_renew_day_of_month'] = "*/7"
    ports:
      - '80:80'
      - '443:443' # If GitLab handles HTTPS itself
      - '22:22'   # SSH for Git
    volumes:
      - './config:/etc/gitlab'
      - './logs:/var/log/gitlab'
      - './data:/var/opt/gitlab'
    shm_size: '256m' # Recommended for GitLab
    restart: always
    mem_limit: 4g # Memory limit, can be increased if needed

Important: Replace your.gitlab.domain.com with your actual domain. If you plan to use an external Nginx or another proxy for HTTPS, configure nginx['listen_https'] = false and X-Forwarded-Proto as shown. If GitLab should obtain Let's Encrypt certificates itself, uncomment the corresponding lines.

3. Start GitLab

Start the container:

sudo docker-compose up -d

The first launch will take some time as GitLab will initialize the database and perform initial setup. You can monitor the logs:

sudo docker-compose logs -f gitlab

After a successful launch, you will be able to access GitLab at https://your.gitlab.domain.com. Upon first login, you will be prompted to set a password for the root account.

Configuring CI/CD, Registry, and Runners for your GitLab

After deploying self-hosted GitLab, the next step is to configure its key features: CI/CD (Continuous Integration/Continuous Deployment), Container Registry, and GitLab Runners. These components transform GitLab into a full-fledged DevOps platform.

GitLab CI/CD

GitLab CI/CD is built directly into the platform and is activated by a .gitlab-ci.yml file in the root of your repository. It allows you to automate the build, test, and deployment of your code.

Example of a simple .gitlab-ci.yml:

stages:
  - build
  - test
  - deploy

build_job:
  stage: build
  script:
    - echo "Building the application..."
    - mkdir build
    - echo "Hello from build" > build/artifact.txt
  artifacts:
    paths:
      - build/

test_job:
  stage: test
  script:
    - echo "Running tests..."
    - cat build/artifact.txt
    - echo "Tests passed!"

deploy_job:
  stage: deploy
  script:
    - echo "Deploying the application..."
    - echo "Deployment complete!"

GitLab Container Registry

The built-in Container Registry allows you to store Docker images used in your projects. This is especially convenient as it is integrated with GitLab CI/CD and uses the same authentication system.

To use the Registry, you need to ensure it is enabled in your GitLab configuration (it is enabled by default). Then you can log in and push images:

docker login registry.your.gitlab.domain.com
docker build -t registry.your.gitlab.domain.com/your-group/your-project/image-name:tag .
docker push registry.your.gitlab.domain.com/your-group/your-project/image-name:tag

GitLab Runners

GitLab Runners are agents that execute CI/CD jobs. They can be installed on the same server as GitLab or on separate machines to distribute the load. It is recommended to allocate separate resources for Runners, especially if CI/CD pipelines are resource-intensive.

Installing a Runner (e.g., on the same server):

# Add the GitLab Runner repository
curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

# Install GitLab Runner
sudo apt install gitlab-runner

# Register the Runner
sudo gitlab-runner register
# You will need your GitLab URL (e.g., https://your.gitlab.domain.com) and a registration token (Settings -> CI/CD -> Runners -> New project runner)
# Choose an executor, for example, 'docker' or 'shell'

For optimal performance and job isolation, it is best to use the Docker executor and run Runners on separate machines or VPS. This allows CI/CD to scale independently of the main GitLab instance.

How many resources are needed for GitLab per team?

The question of the amount of resources for your own GitLab is key to ensuring stable and fast operation. Needs scale non-linearly with team growth and usage intensity. Here are recommendations for gitlab server requirements depending on team size:

Team of up to 10-15 developers (low CI/CD activity)

• CPU: 2-4 vCPU (2.5 GHz or higher).
• RAM: 8 GB.
• Disk: 100-160 GB NVMe SSD.
• Network: 100 Mbps.
• Example Valebyte VPS: Plans from $15-$30/month.

At this level, GitLab will run fast enough for most operations, but there might be delays during peak CI/CD loads.

Team of 15-50 developers (medium CI/CD activity, Container Registry)

• CPU: 4-8 vCPU (2.5 GHz or higher).
• RAM: 16 GB.
• Disk: 200-320 GB NVMe SSD.
• Network: 200-500 Mbps.
• Example Valebyte VPS: Plans from $30-$70/month.

For such a team, it is recommended to consider allocating separate servers for GitLab and Runners if the budget allows. Or, at a minimum, ensure you have a sufficiently powerful VPS.

Team of 50-100+ developers (high CI/CD activity, Registry, GitLab Pages)

• CPU: 8+ vCPU (3.0 GHz or higher).
• RAM: 32+ GB.
• Disk: 500 GB - 1 TB NVMe SSD (or multiple disks in RAID).
• Network: 1 Gbps.
• Example Valebyte: Dedicated server.

In this case, a gitlab dedicated server becomes almost mandatory. For maximum performance and fault tolerance, a distributed GitLab deployment with separate servers for the database, Gitaly, and Runners can be considered.

General scaling recommendations:

1. Monitoring: Use Prometheus/Grafana (or other tools) to monitor GitLab resources (CPU, RAM, disk I/O). This will help identify bottlenecks. A monitoring server is an important part of any infrastructure.
2. Role separation: For large installations, consider separating GitLab into several components (Gitaly, Postgres, Redis) and hosting them on different servers.
3. Runner scaling: GitLab Runners should scale independently of the main GitLab instance. Use auto-scaling Runners in the cloud or add more machines with Runners.
4. Fast disk: NVMe SSD is not a recommendation, but a requirement for GitLab. Disk I/O speed is critically important.
5. Configuration optimization: Tune PostgreSQL, Redis, and Nginx parameters within GitLab for your specific load.

Optimal Valebyte plans for your GitLab server

Valebyte offers a wide range of VPS and dedicated servers that are ideal for gitlab server hosting, meeting the needs of both small teams and large enterprises. Our plans are designed with performance and flexibility requirements in mind.

Our VPS plans are based on high-performance Intel Xeon E5/E3 processors, NVMe disks, and high-speed network connectivity, providing an excellent foundation for your own GitLab.

When choosing a plan for gitlab server hosting on Valebyte, you get not only powerful hardware but also 24/7 technical support, DDoS protection, and the ability to flexibly scale resources. We understand that every project is unique, so our specialists are ready to help you choose the optimal configuration.

Conclusion

Deploying self-hosted GitLab on your own server is a strategic decision that provides full control, security, and flexibility for your development team. Starting with an optimal VPS from Valebyte costing from $15/month, you get a reliable foundation for CI/CD, Container Registry, and all GitLab features.

As your team grows and the load increases, Valebyte offers easy scaling to more powerful VPS or transitioning to dedicated servers, ensuring that your gitlab server hosting will always meet the highest performance and stability requirements.