Upgrade paths
Upgrading across multiple GitLab versions in one go is only possible by accepting downtime. If you don’t want any downtime, read how to upgrade with zero downtime.
For a dynamic view of examples of supported upgrade paths, try the Upgrade Path tool maintained by the GitLab Support team. To share feedback and help improve the tool, create an issue or MR in the upgrade-path project.
When upgrading:
-
Find where your version sits in the upgrade path:
- GitLab 14:
14.0.12>14.3.6>14.9.5>14.10.5. - GitLab 15:
15.0.5>15.1.6(for GitLab instances with multiple web nodes) >15.4.6>15.11.13. - GitLab 16:
16.0.x(only instances with lots of users or large pipeline variables history) >16.1(instances with NPM packages in their Package Registry) >16.2.x(only instances with large pipeline variables history) >16.3> latest16.Y.Z.
- GitLab 14:
- Check for required upgrade stops.
- Consult the version-specific upgrade instructions.
- Upgrade GitLab accordingly.
When not explicitly specified, upgrade GitLab to the latest available patch release of the
major.minor release rather than the first patch release, for example 13.8.8 instead of 13.8.0. This includes major.minor versions you must stop at on the upgrade path as there may be fixes for issues relating to the upgrade process. Specifically around a major version, crucial database schema and migration patches may be included in the latest patch releases.