Consider upgrade downtime options

{{< details >}}

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

{{< /details >}}

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:

• GitLab 17 upgrade notes
• GitLab 16 upgrade notes
• GitLab 15 upgrade notes

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.

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 perform a zero downtime upgrade, see the documentation for your installation method: Helm charts, GitLab Operator, or multi-node instances.