GitLab shipped version 19.0 on 21 May, its first major release in a year, and platform teams should read the upgrade notes before they click the button. The headline change is under the hood: Valkey becomes the default in-memory data store, and bundled Redis is removed from the Linux package.

The Valkey switch

Valkey is the community fork of Redis that emerged after Redis changed its licence. GitLab moving to it by default is part of a wider industry shift toward the open fork. Existing Redis configuration still works and is honoured for backward compatibility, and teams running external Redis on scaled setups can keep doing so. One sharper edge: support for Redis 6 is gone. If you run an external Redis 6, move to Redis 7.2 or Valkey 7.2 before upgrading, or 19.0 will not be a quiet one.

Gitaly on Kubernetes

Gitaly, the service that handles GitLab's Git storage, can now run on Kubernetes as a fully supported deployment. That matters for anyone standardising their infrastructure on Kubernetes, since it lets them manage GitLab's storage layer with the same orchestration, scaling and high-availability tooling as the rest of the stack. Package protection rules also now cover Terraform modules, a small but useful win for teams treating their infrastructure code as a governed artefact.

What it means for an upgrade

A major-version bump is never just a number. 19.0 carries breaking changes, the Redis 6 cut-off chief among them, and the move to Valkey is a default worth understanding even though the old config keeps working. Read GitLab's breaking-changes guide, stage the upgrade in a non-production environment, and check your Redis version first. The release also leans further into AI-assisted, more orchestrated DevOps workflows, per The Next Web — but the migration work is the part that will land on your week.