11  GitLab

Note

Self-hosted GitLab at forge.dunn.dev — OIDC authentication, CI runners, container registry.

11.1 Why self-host GitLab

  • GitLab is where the homelab’s own infrastructure lives: instance repos, image builds, CI pipelines
  • Self-hosting means CI runners have direct access to the host (useful for image builds and deploys)
  • The container registry stores all custom images (bootc base images, caddy-cloudflare, etc.)
  • GitLab.com free tier works for public projects; self-hosted handles private repos and runner capacity

11.2 OIDC integration with Authentik

  • GitLab configured as an OIDC relying party against Authentik
  • Users log in via Authentik; GitLab creates/maps accounts automatically
  • Group membership in Authentik can map to GitLab groups/permissions

11.3 Quadlet deployment

  • Pod: gitlab-server + Caddy sidecar
  • ZFS dataset: /zfs/safe/forge (NVMe for database and repository storage)
  • Pod publishes 127.0.0.1:8447->443; Envoy routes forge.dunn.dev via SNI
  • GitLab is resource-heavy; this is the largest single service in the stack

11.4 CI runners

  • GitLab Runner deployed as a separate pod
  • Runners use the Podman executor for container-based CI jobs
  • Runner registration token managed as a podman secret

11.5 Container registry

  • GitLab’s built-in registry serves all custom container images
  • Used by: immutable-base CI (pushes base images), instance CI (pushes instance images), service-specific image builds (caddy-cloudflare)
  • Images signed with cosign keyless via GitLab OIDC

11.6 Backup

  • GitLab backup via gitlab-backup command, triggered by a systemd timer (gitlab-backup.timer)
  • Backup artifacts written to ZFS dataset, included in snapshot and offsite replication strategy