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 and narrower than it first appeared: support for Redis 6 ends, and Valkey becomes a fully supported option for teams that want it, per the 19.0 release notes.

Correction, 23 August 2026: this article originally reported that Valkey became GitLab 19.0’s default in-memory data store and that bundled Redis was removed from the Linux package. Neither is correct. GitLab’s 19.0 release notes state that the bundled Redis has used Redis 7 since GitLab 16.2 and is not affected, and GitLab’s own tracking issue for the work records that Redis 7.2 remains the default bundled key-value store, with Valkey available as a fully supported opt-in. The breaking change in 19.0 is the removal of support for Redis 6, which the article reported correctly. The headline, standfirst and the two affected passages have been rewritten; the sections below were added at the same time.

The Valkey switch

Valkey is the community fork of Redis that emerged after Redis changed its licence. GitLab making it a first-class option 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 now cover Terraform modules, which matters to teams treating their infrastructure code as a governed artefact.

What it means for an upgrade

A major-version bump carries more than a version string. 19.0 carries breaking changes, the Redis 6 cut-off chief among them, and Valkey is now a supported choice worth understanding even though the old config keeps working. Check your Redis version before anything else. Then read GitLab's breaking-changes guide and stage the upgrade somewhere that is not production. 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.

What Valkey support in 19.0 amounts to

Valkey is the BSD-licensed community fork that appeared after Redis changed its licence at version 7.4 to terms GitLab's open-source distribution requirements cannot accommodate. In 19.0 it became a fully supported choice, selected with a single configuration line: redis['backend'] = 'valkey'.

Redis 7.2 remains the default bundled key-value store. Redis Inc. has extended support for 7.2 through December 2029, which is why GitLab could take the licensing problem seriously without forcing anybody to migrate on its schedule.

GitLab has said it will decide at 20.0, due May 2027, whether to switch the default to Valkey or deprecate Redis 7.2, and that the decision will be based on ecosystem direction and adoption data. Which store GitLab standardises on stays open for another year. Self-managed operators who opt into Valkey now become part of the data that decides it.

The part that lands on your week

The Redis 6 cut-off is the breaking change, and it applies to external deployments rather than bundled ones. The Redis shipped inside the Linux package has been Redis 7 since GitLab 16.2 and is unaffected.

So the check before upgrading is narrower than a store migration. Find out whether you run an external Redis, find out its version, and move anything on 6 to Redis 7.2 or Valkey 7.2 first. A site running the bundled store has nothing to do here at all.

Gitaly on Kubernetes remains the other reason to plan the upgrade rather than take it, because moving Git storage onto Kubernetes is a change to the part of GitLab that holds the repositories.

Why the self-hosting question came up again in August

A major-version upgrade is one of the few moments a platform team revisits whether to run the thing at all, and the case for self-hosting got a data point in August.

GitHub was degraded for about three hours on 17 August, with archive downloads failing at roughly half, and continuous integration broke in organisations that had not registered they depended on GitHub being available. A self-managed GitLab does not remove that class of risk so much as relocate it: the dependency becomes your own infrastructure, your own upgrade timing and your own Redis version.

Neither answer is obviously right, and 19.0 is a reasonable moment to ask. What has changed since May is only that no forced migration of the in-memory store hangs on the decision.