GitLab 19 upgrade: Big Bang-specific notes

GitLab 19 and Helm chart 10 remove the bundled PostgreSQL, Redis, and MinIO charts. There is no automatic data migration. Follow GitLab’s authoritative procedures:

• Bundled chart migration
• Helm chart 10.0 upgrade notes
• GitLab 19 upgrade notes
• Deprecations and removals
• Required upgrade paths
• Background migration checks

Who must migrate

Deployments already using compatible external PostgreSQL 17, Redis 7.0 or later (7.2 recommended) or Valkey 7.2 or later, and GitLab-supported external object storage do not need to migrate service data solely because the bundled charts were removed. Verify the connections, Secrets, and buckets, remove any obsolete bundled-chart values that remain, complete the normal pre-upgrade checks, and take a fresh verified backup.

Deployments using any bundled service must migrate it on the latest GitLab 18.11.z and chart 9.11.z patch. Do not upgrade to chart 10 until GitLab 18.11 works with the external services and a fresh backup has been verified.

Big Bang requirements

The Big Bang GitLab package does not deploy PostgreSQL, Redis or Valkey, object storage, or CloudNativePG resources. It also does not migrate data. Provision and operate these services independently.

This package provides no supported consumer replacements for the removed services. For production, follow GitLab’s Cloud Native Hybrid guidance for externally managed stateful services. If you independently choose CloudNativePG, install and manage the Big Bang maintained CloudNativePG operator before creating the PostgreSQL Cluster; the operator and database lifecycle remain outside this GitLab package.

Configure GitLab’s external-service connections through global.psql, global.redis, global.appConfig.object_store, global.appConfig.backups, upstream.registry.storage, and upstream.gitlab.toolbox.backups.objectStorage. The application backup and temporary buckets are separate from the Toolbox credentials used to read and write backup archives. With the Big Bang umbrella, place all package values under addons.gitlab.values.

While following the upstream migration:

1. Inventory every database and object-storage bucket; the default GitLab backup does not cover every optional database or bucket. Include durable databases such as OpenBao and Registry metadata, rebuild Praefect through the repository restore, and recreate or reset Geo tracking when enabled. Verify separately managed GitLab Runners are compatible with GitLab 19. Configure the Toolbox backup object storage, take a GitLab 18 backup, copy it outside the cluster, and verify that Toolbox can list and read the archive before removing a bundled service.
2. Before disabling bundled MinIO, reconcile chart 9 once with its PVC retained:

addons:
  gitlab:
    values:
      upstream:
        minio:
          persistence:
            keep: true

Verify the live PVC has the helm.sh/resource-policy: keep annotation before continuing. Preserve the chart 9 values, manifest, PVC/PV metadata, and an independent backup until the migration is complete. 3. Provision and validate the external services, required buckets, credentials, and GitLab-required PostgreSQL extensions. GitLab documents the extension ownership messages commonly emitted during restore as non-fatal warnings. 4. Follow the upstream migration while still on GitLab 18. For the chart 9 cutover, schedule downtime, quiesce writes, and drain Sidekiq before repointing Redis; expect active sessions to be lost. Disable bundled MinIO with global.minio.enabled: false, PostgreSQL with upstream.postgresql.install: false, and Redis with upstream.redis.install: false. If GitLab must be repointed before the database restore, temporarily set upstream.gitlab.migrations.enabled: false. Chart 9 requires upstream.minio to remain a map; do not set it to null or add the chart-10-removed upstream.minio.enabled key. 5. A Flux suspension prevents reconciliation but does not stop running GitLab clients. Before restoring PostgreSQL, record and pause any autoscalers, scale Webservice, Sidekiq, and other database clients to zero, and verify they are stopped. After restore, remove the temporary migrations override, restore the replicas and autoscalers, then resume and reconcile helmrelease/gitlab in bigbang. 6. Verify GitLab 18 against the external services and create a new backup. Build a clean chart 10 values document; do not use Helm --reuse-values. Remove obsolete global.minio, upstream.minio, upstream.postgresql, and upstream.redis values while retaining every other supported override. In particular, keep the existing Gitaly persistence size because its StatefulSet volume claim template is immutable. Render and diff the chart 10 values and StatefulSets before reconciling. 7. Upgrade GitLab, wait for regular and post-deployment migrations, and verify application data, Git operations, object storage, Registry, and backup/restore before cleanup.

Retain the Rails Secret, old PVCs, old service Secrets, and independent backups until migration and a new GitLab 19 backup are verified. After GitLab 19 database migrations run, do not start GitLab 18 against that database; rollback requires matching GitLab, database, and object-storage recovery points.