Consider upgrade downtime options

  • Tier: Free, Premium, Ultimate
  • Offering: GitLab Self-Managed

Downtime options during an upgrade depend on your instance type:

  • Single-node instance: You must upgrade with downtime. Users see a Deploy in progress message or a 502 error.
  • Multi-node instance: Choose between upgrading with or without downtime.

To upgrade across multiple minor releases (for example, 14.6 to 14.9), you must take your GitLab instance offline and upgrade with downtime.

Upgrades with downtime

Before starting, review the version-specific upgrade notes for your upgrade path:

For single-node instances, see upgrade Linux package instances. For multi-node instances, see upgrade a multi-node instance with downtime.

Zero-downtime upgrades

Zero-downtime upgrades let you upgrade a live GitLab environment without taking it offline.

You cannot upgrade a Helm chart instance with zero downtime. Support is available with the GitLab Operator but there are known limitations.

For zero downtime, upgrade GitLab nodes in a specific order. Use load balancing, HA systems, and graceful reloads to minimize disruption.

The documentation covers only core GitLab components. For upgrades or management of third-party services such as AWS RDS, see their documentation.

To upgrade a multi-node instance without downtime, see zero-downtime upgrades.