Deploy GitLab on TurboStack

Run a self-hosted GitLab on TurboStack - the Kubernetes deployment Hosted Power sets up for you, its configuration keys, and what comes with it.

GitLab is a self-hosted DevOps platform: Git repositories, issues, CI/CD pipelines and a container registry in one application. TurboStack runs it as an application on a Kubernetes cluster (app_type: gitlab), together with the services it depends on.

Important

GitLab is not in the App Type list you can pick from yourself. It needs a Kubernetes cluster and several supporting components, so Hosted Power sets it up for you. Contact Support to have it enabled, and to agree the domain, the edition and the storage size.

What you get

TurboStack deploys GitLab from the official Helm chart and runs everything it needs on the cluster:

GitLab itself - repositories, issues, merge requests and CI/CD.
PostgreSQL and Redis - the database and cache GitLab requires.
MinIO - S3-compatible object storage for artifacts, uploads, backups and the registry.
A container registry - on its own hostname.
cert-manager and an ingress controller - Transport Layer Security (TLS) certificates and routing into the cluster, handled for you.

Each part gets its own hostname under your domain: gitlab, registry, kas, pages, minio and minio-console. So a deployment on example.com publishes GitLab at gitlab.example.com and the registry at registry.example.com.

Configuration

The settings live under a gitlab key on the application. Hosted Power applies them, but these are the values worth deciding before the deployment:

app_type: gitlab
gitlab:
  major_version: 19
  edition: ce                    # Community Edition
  domain: example.com
  persistent_data_size: 60Gi     # repositories, artifacts and registry images
  pages_enabled: false           # GitLab Pages, off by default
  registry_database_enabled: false

Key	What it controls
`major_version`	The GitLab major version to run.
`edition`	`ce` for Community Edition.
`domain`	The domain the component hostnames are built on.
`persistent_data_size`	Disk for the deployment. Repositories, CI artifacts and registry images all grow into it, so size it for the projects you expect.
`pages_enabled`	Publishes GitLab Pages on its own hostname.
`registry_database_enabled`	Gives the container registry its own metadata database. Off by default. Switching it on is a one-way migration, so ask Support before you change it on a running instance.
`version`	Pins an exact GitLab version instead of the newest release of `major_version`. Used to land on an upgrade stop.

Outgoing email is configured for you, and Microsoft Entra ID single sign-on can be enabled if you want your team to log in with their existing accounts. Ask Support for either.

Note

persistent_data_size is the one to get right up front. A container registry fills up faster than people expect, because every pipeline pushes an image.

Upgrades

GitLab requires upgrades to pass through fixed stops: the .2, .5, .8 and .11 release of every major version. A publish that would skip one is refused, and the message names the stop to land on first. Set version to the newest patch of that stop, publish, then raise it again until you reach the release you want. Hosted Power can run the whole chain for you. Ask Support.

After it is running

Open GitLab at your gitlab. hostname and sign in. From there it behaves like any GitLab: create groups and projects, add runners, and push repositories.

For the cluster underneath, see What is Kubernetes?. For backups of the data behind it, see Backups.

Applications overview
What is Kubernetes? - the cluster GitLab runs on
Advanced Database Monitoring - the other platform Hosted Power runs for you
Support