offline-gitlab-components

Offline GitLab CE + Runner stack for internal CI components

Small, focused, and built for customer environments where installation has to work without Internet access.

_{Made for clean offline delivery, simple operations, and predictable handover.}

---

Overview

This project gives you a small internal GitLab dedicated to shared CI building blocks:

• CI templates
• reusable pipeline components
• internal scripts
• validation pipelines

It is meant for practical delivery work, not for building a full GitLab platform.

Highlights

• fully offline installation flow
• GitLab CE with Docker-based runner support
• packaging workflow for clean customer handover
• simple deployment with Docker Compose or Podman Compose
• basic hardening and resource limits already in place

Typical use case

This stack works well when teams need a dedicated internal catalog of CI components while keeping their main development workflow on other GitLab instances.

What is included

• GitLab CE
• GitLab Runner with Docker executor
• offline image bundle preparation
• Docker Compose and Podman Compose deployment files
• install, packaging, and verification scripts
• documentation for install, operations, security, and acceptance

What is not included

• Docker or Podman installation on the host
• TLS or reverse proxy design
• GitLab Registry or Pages
• high availability
• external database
• advanced monitoring
• Podman runner support

Recommended sizing

A reasonable starting point for about 20 users and roughly 5 active users at the same time:

Component	Sizing
Host	8 vCPU, 16 GB RAM, 200 GB SSD
GitLab	4 vCPU max, 8 GB RAM max
Runner manager	1 vCPU max, 1 GB RAM max
CI jobs	2 concurrent jobs max, 2 vCPU / 3 GB RAM per job

Repository layout

• compose/ - Docker Compose and Podman Compose files
• config/ - GitLab and Runner templates
• scripts/ - install, package, verify, import, helper scripts
• artifacts/ - offline images, manifests, checksums
• docs/ - architecture, security, install, operations, acceptance

Quick start

1. Prepare the offline bundle on a connected machine

cp .env.example .env
$EDITOR .env
./scripts/prepare-bundle.sh
./scripts/package-deliverable.sh

This creates:

• exported images in artifacts/images/
• an image manifest
• checksums
• a clean deliverable under dist/

2. Install on the target host

Docker

cp .env.example .env
$EDITOR .env
./scripts/install.sh docker
./scripts/verify.sh

Podman

cp .env.example .env
$EDITOR .env
./scripts/install.sh podman
./scripts/verify.sh

In Docker mode, the runner is configured automatically during install.

Main variables

Review these values in .env:

• GITLAB_FQDN
• GITLAB_HTTP_PORT
• GITLAB_SSH_PORT
• GITLAB_IMAGE
• RUNNER_IMAGE
• RUNNER_DEFAULT_JOB_IMAGE
• GITLAB_ROOT_PASSWORD

Advanced runner options:

• RUNNER_AUTH_TOKEN
• RUNNER_REGISTRATION_TOKEN

Security notes

• GitLab signup is disabled
• 2FA should be required for admin or maintenance accounts
• the runner is non-privileged
• CPU and RAM limits are set on GitLab, runner, and jobs
• unnecessary embedded services are disabled

Limits

This is a focused V1:

• runner support is Docker-only
• no built-in TLS layer
• no automated upgrade workflow
• offline success depends on correct image bundle preparation

Documentation

• docs/architecture.md
• docs/security.md
• docs/install-offline.md
• docs/operations.md
• docs/acceptance-checklist.md