Updating GitLab Self-Managed

Related to: https://gitlab.com/gitlab-org/gitlab/-/issues/512758

doc/administration/admin_area.md

@@ -10,8 +10,8 @@ DETAILS:
 **Tier:** Free, Premium, Ultimate
 **Offering:** GitLab Self-Managed, GitLab Dedicated
 
-The **Admin** area provides a web UI to manage and configure features of GitLab
-self-managed instances. If you are an administrator, to access the **Admin** area:
+The **Admin** area provides a web UI to manage and configure features of a
+GitLab Self-Managed instance. If you are an administrator, to access the **Admin** area:
 
 - In GitLab 17.3 and later: on the left sidebar, at the bottom, select **Admin**.
 - In GitLab 16.7 and later: on the left sidebar, at the bottom, select **Admin area**.

doc/administration/credentials_inventory.md

@@ -12,7 +12,7 @@ DETAILS:
 
 As a GitLab administrator, you are responsible for the overall security of your instance.
 To assist, GitLab provides an inventory of all the credentials that can be used to access
-your self-managed instance.
+your GitLab Self-Managed instance.
 
 This page describes how to manage the credentials inventory for GitLab Self-Managed. To manage credentials on GitLab.com, see [Credentials inventory for GitLab.com](../user/group/credentials_inventory.md).
 

doc/administration/get_started.md

@@ -18,7 +18,7 @@ and back up GitLab.
 
 Authentication is the first step in making your installation secure.
 
-- [Enforce two-factor authentication (2FA) for all users](../security/two_factor_authentication.md). We highly recommended 2FA for self-managed instances.
+- [Enforce two-factor authentication (2FA) for all users](../security/two_factor_authentication.md). We highly recommended 2FA for GitLab Self-Managed instances.
 - Ensure users do the following:
   - Choose a strong, secure password. If possible, store it in a password management system.
   - If it is not configured for everyone, enable [two-factor authentication (2FA)](../user/profile/account/two_factor_authentication.md) for your account.
@@ -118,7 +118,7 @@ Unlike other monitoring solutions (for example, Zabbix or New Relic), Prometheus
 
 ## Back up your GitLab data
 
-GitLab provides backup methods to keep your data safe and recoverable. Whether you use a self-managed or a GitLab SaaS database, it's crucial to back up your data regularly.
+GitLab provides backup methods to keep your data safe and recoverable. Whether you use a GitLab Self-Managed or a GitLab.com database, it's crucial to back up your data regularly.
 
 - Decide on a backup strategy.
 - Consider writing a cron job to make daily backups.
@@ -209,7 +209,7 @@ Learn more about the [data types Geo replicates](../administration/geo/replicati
 
 GitLab provides support for GitLab Self-Managed through different channels.
 
-- Priority support: [Premium and Ultimate](https://about.gitlab.com/pricing/) self-managed customers receive priority support with tiered response times.
+- Priority support: [Premium and Ultimate](https://about.gitlab.com/pricing/) GitLab Self-Managed customers receive priority support with tiered response times.
   Learn more about [upgrading to priority support](https://about.gitlab.com/support/#upgrading-to-priority-support).
 - Live upgrade assistance: Get one-on-one expert guidance during a production upgrade. With your **priority support plan**,
   you're eligible for a live, scheduled screen-sharing session with a member of our support team.

doc/administration/instance_limits.md

@@ -151,7 +151,7 @@ This only applies to project and group webhooks.
 
 Calls over the rate limit are logged into `auth.log`.
 
-To set this limit for a self-managed installation, run the following in the
+To set this limit for a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -272,7 +272,7 @@ Also see [Webhook rate limits](#webhook-rate-limit).
 
 ### Number of webhooks
 
-To set the maximum number of group or project webhooks for a self-managed installation,
+To set the maximum number of group or project webhooks for a GitLab Self-Managed instance,
 run the following in the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -344,7 +344,7 @@ The number of [placeholder users](../user/project/import/index.md#placeholder-us
 
 The default limit for [GitLab Self-Managed](../subscriptions/self_managed/index.md) is `0` (unlimited).
 
-To change this limit for a self-managed installation, run the following in the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
+To change this limit for a GitLab Self-Managed instance, run the following in the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
 # If limits don't exist for the default plan, you can create one with:
@@ -364,7 +364,7 @@ This setting applies in the context of pull refreshes invoked by using the [proj
 or when forcing an update by selecting **Update now** (**{retry}**) in **Settings > Repository > Mirroring repositories**.
 This setting has no effect on the automatic 30 minute interval schedule used by Sidekiq for [pull mirroring](../user/project/repository/mirror/pull.md).
 
-To change this limit for a self-managed installation, run the following in the
+To change this limit for a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -393,7 +393,7 @@ requested offset into the set of results. This limit is only applied to endpoint
 also support keyset-based pagination. More information about pagination options can be
 found in the [API documentation section on pagination](../api/rest/index.md#pagination).
 
-To set this limit for a self-managed installation, run the following in the
+To set this limit for a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -427,7 +427,7 @@ fails with a `job_activity_limit_exceeded` error.
   higher installations, this limit is defined under a `default` plan that affects all
   projects. This limit is disabled (`0`) by default.
 
-To set this limit for a self-managed installation, run the following in the
+To set this limit for a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -460,7 +460,7 @@ too many deployments fail with a `deployments_limit_exceeded` error.
 
 The default limit is 500 for all [GitLab Self-Managed and GitLab.com plans](https://about.gitlab.com/pricing/).
 
-To change the limit for a self-managed installation, change the `default` plan's limit with the following
+To change the limit for a GitLab Self-Managed instance, change the `default` plan's limit with the following
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session) command:
 
 ```ruby
@@ -486,7 +486,7 @@ limit, the subscription is considered invalid.
   this limit is defined under a `default` plan that
   affects all projects. By default, there is a limit of `2` subscriptions.
 
-To set this limit for a self-managed installation, run the following in the
+To set this limit for a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -505,7 +505,7 @@ limit, the trigger is considered invalid.
 
 Set the limit to `0` to disable it. Defaults to `25000` on self-managed instances.
 
-To set this limit to `100` on a self-managed installation, run the following in the
+To set this limit to `100` on a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -528,7 +528,7 @@ On [GitLab Premium](https://about.gitlab.com/pricing/) self-managed or
 higher installations, this limit is defined under a `default` plan that affects all
 projects. By default, there is a limit of `10` pipeline schedules.
 
-To set this limit for a self-managed installation, run the following in the
+To set this limit for a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -550,7 +550,7 @@ limit value. For example, for a maximum frequency of:
 The minimum value is `24`, or one pipeline per 60 minutes.
 There is no maximum value.
 
-To set this limit to `1440` on a self-managed installation, run the following in the
+To set this limit to `1440` on a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -570,7 +570,7 @@ not processed.
 
 By default, self-managed instances do not limit the number of processable schedule rules.
 
-To set this limit for a self-managed installation, run the following in the
+To set this limit for a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -588,7 +588,7 @@ group, and instance settings are all limited for the entire instance. These limi
 each time a new variable is created. If a new variable would cause the total number of variables
 to exceed the respective limit, the new variable is not created.
 
-To update the `default` plan of one of these limits on a self-managed installation, in the
+To update the `default` plan of one of these limits on a GitLab Self-Managed instance, in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session) run the following command:
 
 - [Instance-level CI/CD variable](../ci/variables/index.md#for-an-instance) limit (default: `25`):
@@ -826,7 +826,7 @@ every time a dotenv file is exported as an artifact.
 
 Set the limit to `0` to disable it. Defaults to 5 KB.
 
-To set this limit to 5 KB on a self-managed installation, run the following in the
+To set this limit to 5 KB on a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -857,7 +857,7 @@ You can set a limit on the maximum size of a CI/CD job [annotation](../ci/yaml/a
 
 Set the limit to `0` to disable it. Defaults to 80 KB.
 
-To set this limit to 100 KB on a self-managed installation, run the following in the
+To set this limit to 100 KB on a GitLab Self-Managed instance, run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 
 ```ruby
@@ -979,9 +979,9 @@ indexed, which have a separate limit. For more information, read
 [Maximum file size indexed](#maximum-file-size-indexed).
 
 - On GitLab.com, the field length limit is 20,000 characters.
-- For self-managed installations, the field length is unlimited by default.
+- For GitLab Self-Managed instances, the field length is unlimited by default.
 
-You can configure this limit for self-managed installations when you
+You can configure this limit for GitLab Self-Managed instances when you
 [enable Elasticsearch](../integration/advanced_search/elasticsearch.md#enable-advanced-search).
 Set the limit to `0` to disable it.
 
@@ -1071,7 +1071,7 @@ The default maximum file size for a package that's uploaded to the [GitLab packa
 The [maximum file sizes on GitLab.com](../user/gitlab_com/index.md#package-registry-limits)
 might be different.
 
-To set these limits for a self-managed installation, you can do it [through the **Admin** area](settings/continuous_integration.md#package-file-size-limits)
+To set these limits for a GitLab Self-Managed instance, you can do it [through the **Admin** area](settings/continuous_integration.md#package-file-size-limits)
 or run the following in the
 [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session):
 

doc/administration/whats-new.md

@@ -16,11 +16,11 @@ GitLab versions in the **What's new** feature. It lists new features available i
 
 All users can see the feature list, but the entries might differ depending on the subscription type:
 
-- Features only available on GitLab.com are not shown to self-managed installations.
-- Features only available to self-managed installations are not shown on GitLab.com.
+- Features only available on GitLab.com are not shown on GitLab Self-Managed instances.
+- Features only available to GitLab Self-Managed instances are not shown on GitLab.com.
 
   NOTE:
-  For self-managed installations, the updated **What's new** is included
+  For GitLab Self-Managed, the updated **What's new** is included
   in the first patch release after a new version, such as `13.10.1`.
 
 ## Access What's new

doc/development/avoiding_required_stops.md

@@ -55,7 +55,7 @@ contact the [Distribution team product manager](https://handbook.gitlab.com/hand
 is uncertainty about whether we should declare a required stop, the Distribution product
 manager may escalate to GitLab product leadership (VP or Chief Product Officer) to make
 a final determination. This may happen, for example, if a change might require a stop for
-a small subset of very large self-managed installations and there are well-defined workarounds
+a small subset of very large GitLab Self-Managed instances and there are well-defined workarounds
 if customers run into issues.
 
 ## Causes of required stops

doc/development/database/avoiding_downtime_in_migrations.md

@@ -24,7 +24,7 @@ The reason we spread this out across three releases is that dropping a column is
 a destructive operation that can't be rolled back easily.
 
 Following this procedure helps us to make sure there are no deployments to GitLab.com
-and upgrade processes for self-managed installations that lump together any of these steps.
+and upgrade processes for GitLab Self-Managed instances that lump together any of these steps.
 
 ### Ignoring the column (release M)
 

doc/development/database/partitioning/date_range.md

@@ -164,7 +164,7 @@ This step [queues a batched background migration](../batched_background_migratio
 
 This step must occur at least one release after the release that
 includes step (2). This gives time for the background
-migration to execute properly in self-managed installations. In this step,
+migration to execute properly in GitLab Self-Managed instances. In this step,
 add another post-deployment migration that cleans up after the
 background migration. This includes forcing any remaining jobs to
 execute, and copying data that may have been missed, due to dropped or

doc/development/database/partitioning/int_range.md

@@ -142,7 +142,7 @@ This step [queues a batched background migration](../batched_background_migratio
 
 This step must occur at least one release after the release that
 includes step (2). This gives time for the background
-migration to execute properly in self-managed installations. In this step,
+migration to execute properly in GitLab Self-Managed instances. In this step,
 add another post-deployment migration that cleans up after the
 background migration. This includes forcing any remaining jobs to
 execute, and copying data that may have been missed, due to dropped or

doc/development/organization/index.md

@@ -8,7 +8,7 @@ description: "Development Guidelines: learn about organization when developing G
 # Organization
 
 The [Organization initiative](../../user/organization/index.md) focuses on reaching feature parity between
-SaaS and self-managed installations.
+GitLab.com and GitLab Self-Managed.
 
 ## Consolidate groups and projects
 

doc/user/application_security/offline_deployments/index.md

@@ -16,7 +16,7 @@ To set up an offline environment, you must receive an [opt-out exemption of clou
 It's possible to run most of the GitLab security scanners when not connected to the internet.
 
 This document describes how to operate Secure Categories (that is, scanner types) in an offline
-environment. These instructions also apply to self-managed installations that are secured, have
+environment. These instructions also apply to GitLab Self-Managed instances that are secured, have
 security policies (for example, firewall policies), or are otherwise restricted from accessing the
 full internet. GitLab refers to these environments as _offline environments_. Other common names
 include:

doc/user/duo_amazon_q/index.md

@@ -27,7 +27,7 @@ so they can start to experiment right away.
 
 To access GitLab Duo with Amazon Q, request [access to a lab environment](https://about.gitlab.com/partners/technology-partners/aws/#interest).
 Alternately, if you have GitLab 17.8 or later, you can
-[set it up on your self-managed installation](setup.md).
+[set it up on your GitLab Self-Managed instance](setup.md).
 
 ## Use GitLab Duo with Amazon Q in an issue
 

doc/user/group/access_and_permissions.md

@@ -66,7 +66,7 @@ address. This top-level group setting applies to:
 
 - The GitLab UI, including subgroups, projects, and issues. It does not apply to GitLab Pages.
 - The API.
-- In self-managed installations of GitLab 15.1 and later, you can also configure
+- On GitLab Self-Managed, in 15.1 and later, you can also configure
   [globally-allowed IP address ranges](../../administration/settings/visibility_and_access_controls.md#configure-globally-allowed-ip-address-ranges)
   for the group.
 

doc/user/profile/notifications.md

@@ -339,7 +339,7 @@ If you no longer wish to receive any email notifications:
 1. If you belong to any groups or projects, set their notification setting to **Global** or
    **Disabled**.
 
-On self-managed installations, even after doing this, your instance administrator
+On GitLab Self-Managed instances, even after doing this, your instance administrator
 [can still email you](../../administration/email_from_gitlab.md).
 
 ## Unsubscribe from notification emails

doc/user/project/clusters/add_existing_cluster.md

@@ -28,7 +28,7 @@ See the prerequisites below to add existing clusters to GitLab.
 
 To add any cluster to GitLab, you need:
 
-- Either a GitLab.com account or an account for a self-managed installation
+- An account on a GitLab.com or GitLab Self-Managed instance.
 - The Maintainer role for group-level and project-level clusters.
 - Access to the **Admin** area for instance-level clusters.
 - A Kubernetes cluster.

doc/user/project/code_intelligence.md

@@ -137,7 +137,7 @@ SCIP index and converts it to LSIF for use in GitLab:
 NOTE:
 GitLab limits the artifact produced by the code generation jobs to 200 MB by the
 [(`ci_max_artifact_size_lsif`)](../../administration/instance_limits.md#maximum-file-size-per-type-of-artifact)
-artifact application limit. On self-managed installations, an instance administrator
+artifact application limit. On GitLab Self-Managed instances, an instance administrator
 can change this value.
 
 ## View code intelligence results

doc/user/project/merge_requests/approvals/index.md

@@ -173,6 +173,6 @@ Invalid policy-created rules:
 ## Related topics
 
 - [Merge request approvals API](../../../../api/merge_request_approvals.md)
-- [Instance approval rules](../../../../administration/merge_requests_approvals.md) for self-managed installations
+- [Instance approval rules](../../../../administration/merge_requests_approvals.md) for GitLab Self-Managed instances
 - [Enable approval permissions for users with the Reporter role](rules.md#enable-approval-permissions-for-users-with-the-reporter-role)
 - [Edit or override merge request approval rules](rules.md#edit-or-override-merge-request-approval-rules)

doc/user/project/merge_requests/merge_request_troubleshooting.md

@@ -145,7 +145,7 @@ This error can happen if your merge request:
 - Is many commits behind the target branch.
 - References a Git LFS file that is locked.
 
-Users in self-managed installations can request an administrator review server logs
+Users on GitLab Self-Managed can request an administrator review server logs
 to determine the cause of the error. GitLab SaaS users should
 [contact Support](https://about.gitlab.com/support/#contact-support) for help.
 

doc/user/project/repository/code_suggestions/index.md

@@ -293,7 +293,7 @@ Other supported IDEs offer slower response times and will return the generated c
 By default, code completion requests are sent from the IDE directly to the AI gateway to minimize the latency.
 For this direct connection to work, the IDE must be able to connect to `https://cloud.gitlab.com:443`. If this is not
 possible (for example, because of network restrictions), you can disable direct connections for all users. If you do this,
-code completion requests are sent indirectly through the GitLab self-managed instance, which in turn sends the requests
+code completion requests are sent indirectly through the GitLab Self-Managed instance, which in turn sends the requests
 to the AI gateway. This might result in your requests having higher latency.
 
 #### Configure direct or indirect connections