<SS/> Sashree Seepersad

Article · By Sashree Seepersad · 20 October 2026

Self-hosted GitLab CE: what, why, where, and how

The forge for this practice is GitLab Community Edition on a machine I operate. It is not GitLab.com, and it is not this website. This page is the public note. The repositories stay on the mesh.

What

GitLab CE is the Community Edition, the omnibus distribution: one install that runs Git, merge requests, CI, and a container registry together. The process list on the box is the omnibus set. Gitaly stores the repositories. Workhorse and Puma serve the application. Sidekiq runs the background jobs. Postgres and Redis stay inside the same install. A GitLab Runner on that same machine runs the pipelines, so a job does not leave for a shared runner fleet.

The names are git.neplusultra.eu for the application and registry.neplusultra.eu for the images. Both are names on the estate, not accounts on someone else’s forge.

What runs inside GitLab CE GitLab CE omnibus in rootless Podman. Workhorse and Puma serve the application. Gitaly, Postgres, and Redis hold the data. Sidekiq, the Runner, and the registry sit beside them on the same host. Rootless Podman · GitLab CE omnibus Workhorse · Puma The application Gitaly Repositories Postgres Application data Redis Queues and cache Sidekiq Background jobs Runner Pipelines, same host Registry Container images
What. One omnibus install. The runner stays on the same machine as the repositories.

Why

A hosted Git service holds the history, the CI credentials, and the images. That is another operator. The same test I use for a cloud exit applies here: if the baseline can only be read by asking the vendor, the estate has not left. Source is part of that baseline.

Self-hosting CE keeps three things in one place I can inspect. The repositories. The pipelines that build them. The registry that stores the result. When an engagement ends, the forge does not end with a SaaS subscription.

Where

The install sits on an OVH VPS, the second node of the WireGuard mesh. This website, sashreeseepersad.com, is a static site on the hub. GitLab is not published here. A browser on the public internet that asks for git.neplusultra.eu receives a mesh-required refusal from the hub. Operators reach the forge over WireGuard.

TLS on that name is a Let’s Encrypt certificate. The key agreement negotiated from the hub is the hybrid group X25519MLKEM768, so the session key is not only elliptic curve. The certificate signature itself is still classical. No public CA is issuing post-quantum certificates yet.

Where GitLab CE sits A public browser reaches Caddy on the hub. The personal site is served. Git and the registry are refused unless the client is on the WireGuard mesh, which is the path to GitLab CE on the OVH VPS. Public browser HTTPS Hub · Caddy sashreeseepersad.com This website Served git.neplusultra.eu registry.neplusultra.eu Mesh required WireGuard OVH VPS GitLab CE Omnibus · registry · runner
Where. The website and the forge share a front door. Only the website is public.

How

  1. 1Ubuntu on the OVH node
  2. 2Omnibus in rootless Podman
  3. 3Runner on the same host
  4. 4Hub Caddy, mesh only

The forge is part of the estate. The website can describe it. The website does not host it.

GitLab CESelf-hostedWireGuardPodmanContainer registryX25519MLKEM768