Add latest changes from gitlab-org/gitlab@master

105 files changed, 2792 insertions, 2269 deletions

diff --git a/app/assets/javascripts/pipeline_editor/components/code_snippet_alert/constants.js b/app/assets/javascripts/pipeline_editor/components/code_snippet_alert/constants.js
index 582fdfea6c9..e4fd423249b 100644
--- a/app/assets/javascripts/pipeline_editor/components/code_snippet_alert/constants.js
+++ b/app/assets/javascripts/pipeline_editor/components/code_snippet_alert/constants.js
@@ -2,10 +2,16 @@ import { helpPagePath } from '~/helpers/help_page_helper';
 
 export const CODE_SNIPPET_SOURCE_URL_PARAM = 'code_snippet_copied_from';
 export const CODE_SNIPPET_SOURCE_API_FUZZING = 'api_fuzzing';
-export const CODE_SNIPPET_SOURCES = [CODE_SNIPPET_SOURCE_API_FUZZING];
+export const CODE_SNIPPET_SOURCE_DAST = 'dast';
+
+export const CODE_SNIPPET_SOURCES = [CODE_SNIPPET_SOURCE_API_FUZZING, CODE_SNIPPET_SOURCE_DAST];
 export const CODE_SNIPPET_SOURCE_SETTINGS = {
   [CODE_SNIPPET_SOURCE_API_FUZZING]: {
     datasetKey: 'apiFuzzingConfigurationPath',
     docsPath: helpPagePath('user/application_security/api_fuzzing/index'),
   },
+  [CODE_SNIPPET_SOURCE_DAST]: {
+    datasetKey: 'dastConfigurationPath',
+    docsPath: helpPagePath('user/application_security/dast/index'),
+  },
 };
diff --git a/app/assets/javascripts/releases/components/app_index_apollo_client.vue b/app/assets/javascripts/releases/components/app_index_apollo_client.vue
index df2a3c76efc..29525ce1abc 100644
--- a/app/assets/javascripts/releases/components/app_index_apollo_client.vue
+++ b/app/assets/javascripts/releases/components/app_index_apollo_client.vue
@@ -1,10 +1,11 @@
 <script>
 import { GlButton } from '@gitlab/ui';
 import createFlash from '~/flash';
-import { getParameterByName } from '~/lib/utils/common_utils';
+import { historyPushState, getParameterByName } from '~/lib/utils/common_utils';
 import { scrollUp } from '~/lib/utils/scroll_utils';
+import { setUrlParams } from '~/lib/utils/url_utility';
 import { __ } from '~/locale';
-import { PAGE_SIZE, RELEASED_AT_DESC } from '~/releases/constants';
+import { PAGE_SIZE, DEFAULT_SORT } from '~/releases/constants';
 import allReleasesQuery from '~/releases/graphql/queries/all_releases.query.graphql';
 import { convertAllReleasesGraphQLResponse } from '~/releases/util';
 import ReleaseBlock from './release_block.vue';
@@ -58,7 +59,7 @@ export default {
         before: getParameterByName('before'),
         after: getParameterByName('after'),
       },
-      sort: RELEASED_AT_DESC,
+      sort: DEFAULT_SORT,
     };
   },
   computed: {
@@ -145,6 +146,29 @@ export default {
       // scroll to the top of the page every time a pagination button is pressed.
       scrollUp();
     },
+    onSortChanged(newSort) {
+      if (this.sort === newSort) {
+        return;
+      }
+
+      // Remove the "before" and "after" query parameters from the URL,
+      // effectively placing the user back on page 1 of the results.
+      // This prevents the frontend from requesting the results sorted
+      // by one field (e.g. `released_at`) while using a pagination cursor
+      // intended for a different field (e.g.) `created_at`).
+      // For more details, see the MR that introduced this change:
+      // https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63434
+      historyPushState(
+        setUrlParams({
+          before: null,
+          after: null,
+        }),
+      );
+
+      this.updateQueryParamsFromUrl();
+
+      this.sort = newSort;
+    },
   },
   i18n: {
     newRelease: __('New release'),
@@ -155,7 +179,7 @@ export default {
 <template>
   <div class="flex flex-column mt-2">
     <div class="gl-align-self-end gl-mb-3">
-      <releases-sort-apollo-client v-model="sort" class="gl-mr-2" />
+      <releases-sort-apollo-client :value="sort" class="gl-mr-2" @input="onSortChanged" />
 
       <gl-button
         v-if="newReleasePath"
diff --git a/app/assets/javascripts/releases/constants.js b/app/assets/javascripts/releases/constants.js
index ac31b2a3384..4f862741e11 100644
--- a/app/assets/javascripts/releases/constants.js
+++ b/app/assets/javascripts/releases/constants.js
@@ -47,3 +47,5 @@ export const SORT_MAP = {
     [DESCENDING_ORDER]: CREATED_DESC,
   },
 };
+
+export const DEFAULT_SORT = RELEASED_AT_DESC;
diff --git a/app/assets/javascripts/search/topbar/components/searchable_dropdown.vue b/app/assets/javascripts/search/topbar/components/searchable_dropdown.vue
index dfeea7e74e2..2e2aa052dd8 100644
--- a/app/assets/javascripts/search/topbar/components/searchable_dropdown.vue
+++ b/app/assets/javascripts/search/topbar/components/searchable_dropdown.vue
@@ -8,12 +8,10 @@ import {
   GlButton,
   GlSkeletonLoader,
   GlTooltipDirective,
-  GlAvatar,
 } from '@gitlab/ui';
-import highlight from '~/lib/utils/highlight';
-import { truncateNamespace } from '~/lib/utils/text_utility';
 import { __ } from '~/locale';
 import { ANY_OPTION } from '../constants';
+import SearchableDropdownItem from './searchable_dropdown_item.vue';
 
 export default {
   i18n: {
@@ -28,7 +26,7 @@ export default {
     GlIcon,
     GlButton,
     GlSkeletonLoader,
-    GlAvatar,
+    SearchableDropdownItem,
   },
   directives: {
     GlTooltip: GlTooltipDirective,
@@ -79,11 +77,8 @@ export default {
     resetDropdown() {
       this.$emit('change', ANY_OPTION);
     },
-    truncateNamespace(namespace) {
-      return truncateNamespace(namespace);
-    },
-    highlightedItemName(name) {
-      return highlight(name, this.searchText);
+    updateDropdown(item) {
+      this.$emit('change', item);
     },
   },
   ANY_OPTION,
@@ -97,7 +92,7 @@ export default {
     toggle-class="gl-text-truncate"
     :header-text="headerText"
     :right="true"
-    @show="$emit('search', searchText)"
+    @show="openDropdown"
     @shown="$refs.searchBox.focusInput()"
   >
     <template #button-content>
@@ -126,46 +121,29 @@ export default {
         v-model="searchText"
         class="gl-m-3"
         :debounce="500"
-        @input="$emit('search', searchText)"
+        @input="openDropdown"
       />
       <gl-dropdown-item
         class="gl-border-b-solid gl-border-b-gray-100 gl-border-b-1 gl-pb-2! gl-mb-2"
         :is-check-item="true"
         :is-checked="isSelected($options.ANY_OPTION)"
         :is-check-centered="true"
-        @click="resetDropdown"
+        @click="updateDropdown($options.ANY_OPTION)"
       >
         <span data-testid="item-title">{{ $options.ANY_OPTION.name }}</span>
       </gl-dropdown-item>
     </div>
     <div v-if="!loading">
-      <gl-dropdown-item
+      <searchable-dropdown-item
         v-for="item in items"
         :key="item.id"
-        :is-check-item="true"
-        :is-checked="isSelected(item)"
-        :is-check-centered="true"
-        @click="$emit('change', item)"
-      >
-        <div class="gl-display-flex gl-align-items-center">
-          <gl-avatar
-            :src="item.avatar_url"
-            :entity-id="item.id"
-            :entity-name="item[name]"
-            shape="rect"
-            :size="32"
-          />
-          <div class="gl-display-flex gl-flex-direction-column">
-            <!-- eslint-disable-next-line vue/no-v-html -->
-            <span data-testid="item-title" v-html="highlightedItemName(item[name])">{{
-              item[name]
-            }}</span>
-            <span class="gl-font-sm gl-text-gray-700" data-testid="item-namespace">{{
-              truncateNamespace(item[fullName])
-            }}</span>
-          </div>
-        </div>
-      </gl-dropdown-item>
+        :item="item"
+        :selected-item="selectedItem"
+        :search-text="searchText"
+        :name="name"
+        :full-name="fullName"
+        @change="updateDropdown"
+      />
     </div>
     <div v-if="loading" class="gl-mx-4 gl-mt-3">
       <gl-skeleton-loader :height="100">
diff --git a/app/assets/javascripts/search/topbar/components/searchable_dropdown_item.vue b/app/assets/javascripts/search/topbar/components/searchable_dropdown_item.vue
new file mode 100644
index 00000000000..498d4af59b4
--- /dev/null
+++ b/app/assets/javascripts/search/topbar/components/searchable_dropdown_item.vue
@@ -0,0 +1,73 @@
+<script>
+import { GlDropdownItem, GlAvatar } from '@gitlab/ui';
+import highlight from '~/lib/utils/highlight';
+import { truncateNamespace } from '~/lib/utils/text_utility';
+
+export default {
+  name: 'SearchableDropdownItem',
+  components: {
+    GlDropdownItem,
+    GlAvatar,
+  },
+  props: {
+    item: {
+      type: Object,
+      required: true,
+    },
+    selectedItem: {
+      type: Object,
+      required: true,
+    },
+    searchText: {
+      type: String,
+      required: false,
+      default: '',
+    },
+    name: {
+      type: String,
+      required: true,
+    },
+    fullName: {
+      type: String,
+      required: true,
+    },
+  },
+  computed: {
+    isSelected() {
+      return this.item.id === this.selectedItem.id;
+    },
+    truncatedNamespace() {
+      return truncateNamespace(this.item[this.fullName]);
+    },
+    highlightedItemName() {
+      return highlight(this.item[this.name], this.searchText);
+    },
+  },
+};
+</script>
+
+<template>
+  <gl-dropdown-item
+    :is-check-item="true"
+    :is-checked="isSelected"
+    :is-check-centered="true"
+    @click="$emit('change', item)"
+  >
+    <div class="gl-display-flex gl-align-items-center">
+      <gl-avatar
+        :src="item.avatar_url"
+        :entity-id="item.id"
+        :entity-name="item[name]"
+        shape="rect"
+        :size="32"
+      />
+      <div class="gl-display-flex gl-flex-direction-column">
+        <!-- eslint-disable-next-line vue/no-v-html -->
+        <span data-testid="item-title" v-html="highlightedItemName">{{ item[name] }}</span>
+        <span class="gl-font-sm gl-text-gray-700" data-testid="item-namespace">{{
+          truncatedNamespace
+        }}</span>
+      </div>
+    </div>
+  </gl-dropdown-item>
+</template>
diff --git a/app/graphql/mutations/todos/mark_all_done.rb b/app/graphql/mutations/todos/mark_all_done.rb
index 22a5893d4ec..7dd06cc8293 100644
--- a/app/graphql/mutations/todos/mark_all_done.rb
+++ b/app/graphql/mutations/todos/mark_all_done.rb
@@ -7,12 +7,6 @@ module Mutations
 
       authorize :update_user
 
-      field :updated_ids,
-            [::Types::GlobalIDType[::Todo]],
-            null: false,
-            deprecated: { reason: 'Use to-do items', milestone: '13.2' },
-            description: 'IDs of the updated to-do items.'
-
       field :todos, [::Types::TodoType],
             null: false,
             description: 'Updated to-do items.'
@@ -23,7 +17,6 @@ module Mutations
         updated_ids = mark_all_todos_done
 
         {
-          updated_ids: updated_ids,
           todos: Todo.id_in(updated_ids),
           errors: []
         }
diff --git a/app/graphql/mutations/todos/restore_many.rb b/app/graphql/mutations/todos/restore_many.rb
index 41ccbd77aa6..b09c59a3435 100644
--- a/app/graphql/mutations/todos/restore_many.rb
+++ b/app/graphql/mutations/todos/restore_many.rb
@@ -12,11 +12,6 @@ module Mutations
                required: true,
                description: 'The global IDs of the to-do items to restore (a maximum of 50 is supported at once).'
 
-      field :updated_ids, [::Types::GlobalIDType[Todo]],
-            null: false,
-            description: 'The IDs of the updated to-do items.',
-            deprecated: { reason: 'Use to-do items', milestone: '13.2' }
-
       field :todos, [::Types::TodoType],
             null: false,
             description: 'Updated to-do items.'
diff --git a/app/graphql/types/deprecated_mutations.rb b/app/graphql/types/deprecated_mutations.rb
index a4336fa3ef3..49bad56b6f9 100644
--- a/app/graphql/types/deprecated_mutations.rb
+++ b/app/graphql/types/deprecated_mutations.rb
@@ -5,15 +5,7 @@ module Types
     extend ActiveSupport::Concern
 
     prepended do
-      mount_aliased_mutation 'AddAwardEmoji',
-                             Mutations::AwardEmojis::Add,
-                             deprecated: { reason: 'Use awardEmojiAdd', milestone: '13.2' }
-      mount_aliased_mutation 'RemoveAwardEmoji',
-                             Mutations::AwardEmojis::Remove,
-                             deprecated: { reason: 'Use awardEmojiRemove', milestone: '13.2' }
-      mount_aliased_mutation 'ToggleAwardEmoji',
-                             Mutations::AwardEmojis::Toggle,
-                             deprecated: { reason: 'Use awardEmojiToggle', milestone: '13.2' }
+      # placeholder for any FOSS mutations to be deprecated
     end
   end
 end
diff --git a/app/graphql/types/packages/package_group_sort_enum.rb b/app/graphql/types/packages/package_group_sort_enum.rb
index 70fb27ec0db..28a1bf85911 100644
--- a/app/graphql/types/packages/package_group_sort_enum.rb
+++ b/app/graphql/types/packages/package_group_sort_enum.rb
@@ -6,10 +6,8 @@ module Types
       graphql_name 'PackageGroupSort'
       description 'Values for sorting group packages'
 
-      # The following enums are not available till we enable the new Arel node:
-      # See https://gitlab.com/gitlab-org/gitlab/-/merge_requests/58657#note_552632305
-      # value 'PROJECT_PATH_DESC', 'Project by descending order.', value: :project_path_desc
-      # value 'PROJECT_PATH_ASC', 'Project by ascending order.', value: :project_path_asc
+      value 'PROJECT_PATH_DESC', 'Ordered by project path in descending order.', value: :project_path_desc
+      value 'PROJECT_PATH_ASC', 'Ordered by project path in ascending order.', value: :project_path_asc
     end
   end
 end
diff --git a/app/graphql/types/snippet_type.rb b/app/graphql/types/snippet_type.rb
index 2f79ec48c04..34357ead048 100644
--- a/app/graphql/types/snippet_type.rb
+++ b/app/graphql/types/snippet_type.rb
@@ -61,12 +61,6 @@ module Types
           description: 'Raw URL of the snippet.',
           null: false
 
-    field :blob, type: Types::Snippets::BlobType,
-          description: 'Snippet blob.',
-          calls_gitaly: true,
-          null: false,
-          deprecated: { reason: 'Use `blobs`', milestone: '13.3' }
-
     field :blobs, type: Types::Snippets::BlobType.connection_type,
           description: 'Snippet blobs.',
           calls_gitaly: true,
diff --git a/app/models/concerns/has_user_type.rb b/app/models/concerns/has_user_type.rb
index 468387115e5..4b4f9c0df84 100644
--- a/app/models/concerns/has_user_type.rb
+++ b/app/models/concerns/has_user_type.rb
@@ -12,10 +12,11 @@ module HasUserType
     ghost: 5,
     project_bot: 6,
     migration_bot: 7,
-    security_bot: 8
+    security_bot: 8,
+    automation_bot: 9
   }.with_indifferent_access.freeze
 
-  BOT_USER_TYPES = %w[alert_bot project_bot support_bot visual_review_bot migration_bot security_bot].freeze
+  BOT_USER_TYPES = %w[alert_bot project_bot support_bot visual_review_bot migration_bot security_bot automation_bot].freeze
   NON_INTERNAL_USER_TYPES = %w[human project_bot service_user].freeze
   INTERNAL_USER_TYPES = (USER_TYPES.keys - NON_INTERNAL_USER_TYPES).freeze
 
diff --git a/app/models/concerns/timebox.rb b/app/models/concerns/timebox.rb
index fb9a8cd312d..8dc58f8dca1 100644
--- a/app/models/concerns/timebox.rb
+++ b/app/models/concerns/timebox.rb
@@ -44,7 +44,6 @@ module Timebox
     validates :project, presence: true, unless: :group
     validates :title, presence: true
 
-    validate :uniqueness_of_title, if: :title_changed?
     validate :timebox_type_check
     validate :start_date_should_be_less_than_due_date, if: proc { |m| m.start_date.present? && m.due_date.present? }
     validate :dates_within_4_digits
@@ -243,18 +242,6 @@ module Timebox
     end
   end
 
-  # Timebox titles must be unique across project and group timeboxes
-  def uniqueness_of_title
-    if project
-      relation = self.class.for_projects_and_groups([project_id], [project.group&.id])
-    elsif group
-      relation = self.class.for_projects_and_groups(group.projects.select(:id), [group.id])
-    end
-
-    title_exists = relation.find_by_title(title)
-    errors.add(:title, _("already being used for another group or project %{timebox_name}.") % { timebox_name: timebox_name }) if title_exists
-  end
-
   # Timebox should be either a project timebox or a group timebox
   def timebox_type_check
     if group_id && project_id
diff --git a/app/models/concerns/token_authenticatable_strategies/encryption_helper.rb b/app/models/concerns/token_authenticatable_strategies/encryption_helper.rb
index 25c050820d6..3be82ed72d3 100644
--- a/app/models/concerns/token_authenticatable_strategies/encryption_helper.rb
+++ b/app/models/concerns/token_authenticatable_strategies/encryption_helper.rb
@@ -5,10 +5,6 @@ module TokenAuthenticatableStrategies
     DYNAMIC_NONCE_IDENTIFIER = "|"
     NONCE_SIZE = 12
 
-    def self.encrypt_token(plaintext_token)
-      Gitlab::CryptoHelper.aes256_gcm_encrypt(plaintext_token)
-    end
-
     def self.decrypt_token(token)
       return unless token
 
@@ -22,5 +18,13 @@ module TokenAuthenticatableStrategies
         Gitlab::CryptoHelper.aes256_gcm_decrypt(token)
       end
     end
+
+    def self.encrypt_token(plaintext_token)
+      return Gitlab::CryptoHelper.aes256_gcm_encrypt(plaintext_token) unless Feature.enabled?(:dynamic_nonce, type: :ops)
+
+      iv = ::Digest::SHA256.hexdigest(plaintext_token).bytes.take(NONCE_SIZE).pack('c*')
+      token = Gitlab::CryptoHelper.aes256_gcm_encrypt(plaintext_token, nonce: iv)
+      "#{DYNAMIC_NONCE_IDENTIFIER}#{token}#{iv}"
+    end
   end
 end
diff --git a/app/models/milestone.rb b/app/models/milestone.rb
index 16090f0ebfa..9ed6c106e45 100644
--- a/app/models/milestone.rb
+++ b/app/models/milestone.rb
@@ -36,6 +36,7 @@ class Milestone < ApplicationRecord
   scope :order_by_dates_and_title, -> { order(due_date: :asc, start_date: :asc, title: :asc) }
 
   validates_associated :milestone_releases, message: -> (_, obj) { obj[:value].map(&:errors).map(&:full_messages).join(",") }
+  validate :uniqueness_of_title, if: :title_changed?
 
   state_machine :state, initial: :active do
     event :close do
@@ -172,4 +173,16 @@ class Milestone < ApplicationRecord
   def issues_finder_params
     { project_id: project_id, group_id: group_id, include_subgroups: group_id.present? }.compact
   end
+
+  # milestone titles must be unique across project and group milestones
+  def uniqueness_of_title
+    if project
+      relation = self.class.for_projects_and_groups([project_id], [project.group&.id])
+    elsif group
+      relation = self.class.for_projects_and_groups(group.projects.select(:id), [group.id])
+    end
+
+    title_exists = relation.find_by_title(title)
+    errors.add(:title, _("already being used for another group or project %{timebox_name}.") % { timebox_name: timebox_name }) if title_exists
+  end
 end
diff --git a/app/models/user.rb b/app/models/user.rb
index 5737629e629..7a6bc50639c 100644
--- a/app/models/user.rb
+++ b/app/models/user.rb
@@ -782,6 +782,16 @@ class User < ApplicationRecord
       end
     end
 
+    def automation_bot
+      email_pattern = "automation%s@#{Settings.gitlab.host}"
+
+      unique_internal(where(user_type: :automation_bot), 'automation-bot', email_pattern) do |u|
+        u.bio = 'The GitLab automation bot used for automated workflows and tasks'
+        u.name = 'GitLab Automation Bot'
+        u.avatar = bot_avatar(image: 'support-bot.png') # todo: add an avatar for automation-bot
+      end
+    end
+
     # Return true if there is only single non-internal user in the deployment,
     # ghost user is ignored.
     def single_user?
diff --git a/app/views/shared/runners/_runner_type_alert.html.haml b/app/views/shared/runners/_runner_type_alert.html.haml
index b83def8b802..e0cc1e924d8 100644
--- a/app/views/shared/runners/_runner_type_alert.html.haml
+++ b/app/views/shared/runners/_runner_type_alert.html.haml
@@ -5,16 +5,16 @@
       = s_('Runners|This runner is available to all groups and projects in your GitLab instance.')
     .gl-alert-body
       = s_('Runners|Shared runners are available to every project in a GitLab instance. If you want a runner to build only specific projects, restrict the project in the table below. After you restrict a runner to a project, you cannot change it back to a shared runner.')
-      = link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'shared-runners'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'shared-runners'), target: '_blank', rel: 'noopener noreferrer'
   - elsif runner.group_type?
     %h4.gl-alert-title
       = s_('Runners|This runner is available to all projects and subgroups in a group.')
     .gl-alert-body
       = s_('Runners|Use Group runners when you want all projects in a group to have access to a set of runners.')
-      = link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'group-runners'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'group-runners'), target: '_blank', rel: 'noopener noreferrer'
   - else
     %h4.gl-alert-title
       = s_('Runners|This runner is associated with specific projects.')
     .gl-alert-body
       = s_('Runners|You can set up a specific runner to be used by multiple projects but you cannot make this a shared runner.')
-      = link_to _('Learn more.'), help_page_path('ci/runners/README', anchor: 'specific-runners'), target: '_blank', rel: 'noopener noreferrer'
+      = link_to _('Learn more.'), help_page_path('ci/runners/runners_scope', anchor: 'specific-runners'), target: '_blank', rel: 'noopener noreferrer'
diff --git a/config/feature_flags/ops/dynamic_nonce.yml b/config/feature_flags/ops/dynamic_nonce.yml
new file mode 100644
index 00000000000..6a63eda8862
--- /dev/null
+++ b/config/feature_flags/ops/dynamic_nonce.yml
@@ -0,0 +1,8 @@
+---
+name: dynamic_nonce
+introduced_by_url:
+rollout_issue_url:
+milestone: '14.0'
+type: ops
+group: group::access
+default_enabled: false
diff --git a/config/initializers/1_settings.rb b/config/initializers/1_settings.rb
index 12461791b38..d589bc6069a 100644
--- a/config/initializers/1_settings.rb
+++ b/config/initializers/1_settings.rb
@@ -687,6 +687,9 @@ Gitlab.ee do
   Settings.cron_jobs['iterations_update_status_worker'] ||= Settingslogic.new({})
   Settings.cron_jobs['iterations_update_status_worker']['cron'] ||= '5 0 * * *'
   Settings.cron_jobs['iterations_update_status_worker']['job_class'] = 'IterationsUpdateStatusWorker'
+  Settings.cron_jobs['iterations_generator_worker'] ||= Settingslogic.new({})
+  Settings.cron_jobs['iterations_generator_worker']['cron'] ||= '5 0 * * *'
+  Settings.cron_jobs['iterations_generator_worker']['job_class'] = 'Iterations::Cadences::ScheduleCreateIterationsWorker'
   Settings.cron_jobs['vulnerability_statistics_schedule_worker'] ||= Settingslogic.new({})
   Settings.cron_jobs['vulnerability_statistics_schedule_worker']['cron'] ||= '15 1 * * *'
   Settings.cron_jobs['vulnerability_statistics_schedule_worker']['job_class'] = 'Vulnerabilities::Statistics::ScheduleWorker'
diff --git a/db/migrate/20210527065005_add_index_for_cadence_iterations_automation.rb b/db/migrate/20210527065005_add_index_for_cadence_iterations_automation.rb
new file mode 100644
index 00000000000..99178bc5b04
--- /dev/null
+++ b/db/migrate/20210527065005_add_index_for_cadence_iterations_automation.rb
@@ -0,0 +1,25 @@
+# frozen_string_literal: true
+
+class AddIndexForCadenceIterationsAutomation < ActiveRecord::Migration[6.0]
+  include Gitlab::Database::MigrationHelpers
+
+  INDEX_NAME = 'cadence_create_iterations_automation'
+
+  disable_ddl_transaction!
+
+  def up
+    return if index_exists_by_name?(:iterations_cadences, INDEX_NAME)
+
+    execute(
+      <<-SQL
+        CREATE INDEX CONCURRENTLY #{INDEX_NAME} ON iterations_cadences
+        USING BTREE(automatic, duration_in_weeks, (DATE ((COALESCE("iterations_cadences"."last_run_date", DATE('01-01-1970')) + "iterations_cadences"."duration_in_weeks" * INTERVAL '1 week')))) 
+        WHERE duration_in_weeks IS NOT NULL
+      SQL
+    )
+  end
+
+  def down
+    remove_concurrent_index_by_name :iterations_cadences, INDEX_NAME
+  end
+end
diff --git a/db/migrate/20210529164247_change_iterations_title_uniqueness_index.rb b/db/migrate/20210529164247_change_iterations_title_uniqueness_index.rb
new file mode 100644
index 00000000000..47e7e2c757d
--- /dev/null
+++ b/db/migrate/20210529164247_change_iterations_title_uniqueness_index.rb
@@ -0,0 +1,20 @@
+# frozen_string_literal: true
+
+class ChangeIterationsTitleUniquenessIndex < ActiveRecord::Migration[6.0]
+  include Gitlab::Database::MigrationHelpers
+
+  INDEX_NAME = 'index_sprints_on_iterations_cadence_id_and_title'
+  OLD_INDEX_NAME = 'index_sprints_on_group_id_and_title'
+
+  disable_ddl_transaction!
+
+  def up
+    add_concurrent_index :sprints, [:iterations_cadence_id, :title], name: INDEX_NAME, unique: true
+    remove_concurrent_index_by_name :sprints, OLD_INDEX_NAME
+  end
+
+  def down
+    # noop
+    # rollback would not work as we can have duplicate records once the unique `index_sprints_on_group_id_and_title` index is removed
+  end
+end
diff --git a/db/migrate/20210609013512_add_unique_index_for_batched_background_migrations.rb b/db/migrate/20210609013512_add_unique_index_for_batched_background_migrations.rb
new file mode 100644
index 00000000000..28214aedce6
--- /dev/null
+++ b/db/migrate/20210609013512_add_unique_index_for_batched_background_migrations.rb
@@ -0,0 +1,28 @@
+# frozen_string_literal: true
+
+class AddUniqueIndexForBatchedBackgroundMigrations < ActiveRecord::Migration[6.1]
+  include Gitlab::Database::MigrationHelpers
+
+  disable_ddl_transaction!
+
+  TABLE_NAME = :batched_background_migrations
+  INDEX_NAME = 'index_batched_background_migrations_on_unique_configuration'
+  REDUNDANT_INDEX_NAME = 'index_batched_migrations_on_job_table_and_column_name'
+
+  def up
+    add_concurrent_index TABLE_NAME,
+      %i[job_class_name table_name column_name job_arguments],
+      unique: true,
+      name: INDEX_NAME
+
+    remove_concurrent_index_by_name TABLE_NAME, REDUNDANT_INDEX_NAME
+  end
+
+  def down
+    add_concurrent_index TABLE_NAME,
+      %i[job_class_name table_name column_name],
+      name: REDUNDANT_INDEX_NAME
+
+    remove_concurrent_index_by_name TABLE_NAME, INDEX_NAME
+  end
+end
diff --git a/db/post_migrate/20210604070207_retry_backfill_traversal_ids.rb b/db/post_migrate/20210604070207_retry_backfill_traversal_ids.rb
new file mode 100644
index 00000000000..5e540c7f359
--- /dev/null
+++ b/db/post_migrate/20210604070207_retry_backfill_traversal_ids.rb
@@ -0,0 +1,21 @@
+# frozen_string_literal: true
+
+class RetryBackfillTraversalIds < ActiveRecord::Migration[6.1]
+  include Gitlab::Database::MigrationHelpers
+
+  ROOTS_MIGRATION = 'BackfillNamespaceTraversalIdsRoots'
+  CHILDREN_MIGRATION = 'BackfillNamespaceTraversalIdsChildren'
+  DOWNTIME = false
+  DELAY_INTERVAL = 2.minutes
+
+  disable_ddl_transaction!
+
+  def up
+    duration = requeue_background_migration_jobs_by_range_at_intervals(ROOTS_MIGRATION, DELAY_INTERVAL)
+    requeue_background_migration_jobs_by_range_at_intervals(CHILDREN_MIGRATION, DELAY_INTERVAL, initial_delay: duration)
+  end
+
+  def down
+    # no-op
+  end
+end
diff --git a/db/schema_migrations/20210527065005 b/db/schema_migrations/20210527065005
new file mode 100644
index 00000000000..23df046f302
--- /dev/null
+++ b/db/schema_migrations/20210527065005
@@ -0,0 +1 @@
+983b736defaa128f7466a784d2a06de293fa6b1cee76121e533e7966d19aad73
\ No newline at end of file
diff --git a/db/schema_migrations/20210529164247 b/db/schema_migrations/20210529164247
new file mode 100644
index 00000000000..76637590be7
--- /dev/null
+++ b/db/schema_migrations/20210529164247
@@ -0,0 +1 @@
+8aa9e00be5f2bc6076f4a42a479aff4318b9e4d3da48798117fec67df7158db4
\ No newline at end of file
diff --git a/db/schema_migrations/20210604070207 b/db/schema_migrations/20210604070207
new file mode 100644
index 00000000000..3531c9775bd
--- /dev/null
+++ b/db/schema_migrations/20210604070207
@@ -0,0 +1 @@
+ec44b7f134de2ea6537c6fe3109fa9d7e32785233f3d1b8e9ea118474d21526a
\ No newline at end of file
diff --git a/db/schema_migrations/20210609013512 b/db/schema_migrations/20210609013512
new file mode 100644
index 00000000000..52541965dde
--- /dev/null
+++ b/db/schema_migrations/20210609013512
@@ -0,0 +1 @@
+ddd40d4fb063b3a728f4b9a214d6033f70ee3719ac769957f5295a0c5f62a5c0
\ No newline at end of file
diff --git a/db/structure.sql b/db/structure.sql
index 8a3da9ceed9..93b8c8029a8 100644
--- a/db/structure.sql
+++ b/db/structure.sql
@@ -22305,6 +22305,8 @@ CREATE INDEX approval_mr_rule_index_merge_request_id ON approval_merge_request_r
 
 CREATE UNIQUE INDEX bulk_import_trackers_uniq_relation_by_entity ON bulk_import_trackers USING btree (bulk_import_entity_id, relation);
 
+CREATE INDEX cadence_create_iterations_automation ON iterations_cadences USING btree (automatic, duration_in_weeks, date((COALESCE(last_run_date, '1970-01-01'::date) + ((duration_in_weeks)::double precision * '7 days'::interval)))) WHERE (duration_in_weeks IS NOT NULL);
+
 CREATE INDEX ci_builds_gitlab_monitor_metrics ON ci_builds USING btree (status, created_at, project_id) WHERE ((type)::text = 'Ci::Build'::text);
 
 CREATE INDEX code_owner_approval_required ON protected_branches USING btree (project_id, code_owner_approval_required) WHERE (code_owner_approval_required = true);
@@ -22611,12 +22613,12 @@ CREATE INDEX index_badges_on_group_id ON badges USING btree (group_id);
 
 CREATE INDEX index_badges_on_project_id ON badges USING btree (project_id);
 
+CREATE UNIQUE INDEX index_batched_background_migrations_on_unique_configuration ON batched_background_migrations USING btree (job_class_name, table_name, column_name, job_arguments);
+
 CREATE INDEX index_batched_jobs_by_batched_migration_id_and_id ON batched_background_migration_jobs USING btree (batched_background_migration_id, id);
 
 CREATE INDEX index_batched_jobs_on_batched_migration_id_and_status ON batched_background_migration_jobs USING btree (batched_background_migration_id, status);
 
-CREATE INDEX index_batched_migrations_on_job_table_and_column_name ON batched_background_migrations USING btree (job_class_name, table_name, column_name);
-
 CREATE INDEX index_board_assignees_on_assignee_id ON board_assignees USING btree (assignee_id);
 
 CREATE UNIQUE INDEX index_board_assignees_on_board_id_and_assignee_id ON board_assignees USING btree (board_id, assignee_id);
@@ -24647,7 +24649,7 @@ CREATE INDEX index_sprints_on_due_date ON sprints USING btree (due_date);
 
 CREATE INDEX index_sprints_on_group_id ON sprints USING btree (group_id);
 
-CREATE UNIQUE INDEX index_sprints_on_group_id_and_title ON sprints USING btree (group_id, title) WHERE (group_id IS NOT NULL);
+CREATE UNIQUE INDEX index_sprints_on_iterations_cadence_id_and_title ON sprints USING btree (iterations_cadence_id, title);
 
 CREATE UNIQUE INDEX index_sprints_on_project_id_and_iid ON sprints USING btree (project_id, iid);
 
diff --git a/doc/administration/database_load_balancing.md b/doc/administration/database_load_balancing.md
index 8b79efd917c..9c1ed9b3477 100644
--- a/doc/administration/database_load_balancing.md
+++ b/doc/administration/database_load_balancing.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # Database Load Balancing **(FREE SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/1283) in [GitLab Premium](https://about.gitlab.com/pricing/) 9.0.
-> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60894) from GitLab Premium to GitLab Free in 14.0. See the [instructions below](#load-balancing-in-gitlab).
+> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/60894) from GitLab Premium to GitLab Free in 14.0.
 
 Distribute read-only queries among multiple database servers.
 
@@ -104,17 +104,6 @@ the following. This will balance the load between `host1.example.com` and
 
 1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
 
-### Load balancing in GitLab Free
-
-Database load balancing was moved from GitLab Premium to GitLab Free in
-14.0 with some [known limitations](https://gitlab.com/gitlab-org/gitlab/-/issues/327902).
-For example, requesting new jobs for runners may fail. Hence, this feature is **not ready for production use** in GitLab Free.
-
-To use database load balancing in GitLab Free, set the `ENABLE_LOAD_BALANCING_FOR_FOSS`
-[environment
-variable](https://docs.gitlab.com/omnibus/settings/environment-variables.html)
-to `true`.
-
 ### Enable the load balancer for Sidekiq
 
 Sidekiq mostly writes to the database, which means that most of its traffic hits the
diff --git a/doc/administration/index.md b/doc/administration/index.md
index 557d4b73f20..b02c5c173ba 100644
--- a/doc/administration/index.md
+++ b/doc/administration/index.md
@@ -172,7 +172,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
 - [External Pipeline Validation](external_pipeline_validation.md): Enable, disable, and configure external pipeline validation.
 - [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully).
 - [Job logs](job_logs.md): Information about the job logs.
-- [Register runners](../ci/runners/README.md#types-of-runners): Learn how to register and configure runners.
+- [Register runners](../ci/runners/runners_scope.md): Learn how to register and configure runners.
 - [Shared runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for shared runners.
 - [Enable/disable Auto DevOps](../topics/autodevops/index.md#enable-or-disable-auto-devops): Enable or disable Auto DevOps for your instance.
 
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index c5df10a89b6..454d9d33253 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -411,11 +411,6 @@ The following IPs will be used as an example:
 - `10.6.0.12`: Consul 2
 - `10.6.0.13`: Consul 3
 
-NOTE:
-The configuration processes for the other servers in your reference architecture will
-use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
-with the other servers.
-
 To configure Consul:
 
 1. SSH in to the server that will host Consul.
@@ -446,7 +441,11 @@ To configure Consul:
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Consul nodes, and
    make sure you set up the correct IPs.
 
@@ -603,9 +602,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
 Like most failover handling methods, this has a small chance of leading to data loss.
 Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -705,9 +703,8 @@ The following IPs will be used as an example:
    node_exporter['listen_address'] = '0.0.0.0:9100'
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -866,9 +863,8 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -933,9 +929,8 @@ You can specify multiple roles, like sentinel and Redis, as:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
@@ -1065,9 +1060,8 @@ To configure the Sentinel Cache server:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
@@ -1131,9 +1125,8 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -1192,9 +1185,8 @@ You can specify multiple roles, like sentinel and Redis, as:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
@@ -1324,17 +1316,8 @@ To configure the Sentinel Queues server:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. To prevent database migrations from running on upgrade, run:
-
-   ```shell
-   sudo touch /etc/gitlab/skip-auto-reconfigure
-   ```
-
-   Only the primary GitLab application server should handle migrations.
-
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other Sentinel nodes, and
@@ -1435,7 +1418,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # END user configuration
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
 <div align="right">
@@ -1533,18 +1520,18 @@ To configure the Praefect nodes, on each one:
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
 
    ```ruby
-   # Avoid running unnecessary services on the Gitaly server
+   # Avoid running unnecessary services on the Praefect server
+   gitaly['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Praefect Configuration
    praefect['enable'] = true
@@ -1612,11 +1599,25 @@ To configure the Praefect nodes, on each one:
    # END user configuration
    ```
 
-   1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-      then replace the file of the same name on this server. If that file isn't on
-      this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. Praefect requires to run some database migrations, much like the main GitLab application. For this
+   you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
+   must be configured first before the others as follows:
+   
+   1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
+
+   1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+   
+   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+      to run the Praefect database migrations.
 
-   1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1660,20 +1661,17 @@ On each node:
    storage paths, enable the network listener, and to configure the token:
 
    ```ruby
-   # /etc/gitlab/gitlab.rb
-
    # Avoid running unnecessary services on the Gitaly server
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1681,9 +1679,11 @@ On each node:
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your 'front door' GitLab URL or an internal load
    # balancer.
-   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
+   # Gitaly 
+   gitaly['enable'] = true
+
    # Make Gitaly accept connections on all network interfaces. You must use
    # firewalls to restrict access to this address/port.
    # Comment out following line if you only want to support TLS connections
@@ -1725,9 +1725,8 @@ On each node:
      })
      ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-   then replace the file of the same name on this server. If that file isn't on
-   this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
@@ -1834,28 +1833,19 @@ To configure the Sidekiq nodes, on each one:
 1. Open `/etc/gitlab/gitlab.rb` with your editor:
 
    ```ruby
-   ########################################
-   #####        Services Disabled       ###
-   ########################################
-
-   nginx['enable'] = false
-   grafana['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Sidekiq server
    gitaly['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
+   puma['enable'] = false
+   gitlab_workhorse['enable'] = false
+   prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
    gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
-   ########################################
-   ####              Redis              ###
-   ########################################
-
+   # Redis
    ## Redis connection details
    ## First cluster that will host the cache
    gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
@@ -1887,13 +1877,10 @@ To configure the Sidekiq nodes, on each one:
      {host: '10.6.0.83', port: 26379},
    ]
 
-   #######################################
-   ###              Gitaly             ###
-   #######################################
-
-   # git_data_dirs get configured for the Praefect virtual storage
-   # Address is Internal Load Balancer for Praefect
-   # Token is praefect_external_token
+   # Gitaly Cluster
+   ## git_data_dirs get configured for the Praefect virtual storage
+   ## Address is Internal Load Balancer for Praefect
+   ## Token is praefect_external_token
    git_data_dirs({
      "default" => {
        "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@@ -1901,20 +1888,17 @@ To configure the Sidekiq nodes, on each one:
      }
    })
 
-   #######################################
-   ###            Postgres             ###
-   #######################################
+   # PostgreSQL
    gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
    gitlab_rails['db_adapter'] = 'postgresql'
    gitlab_rails['db_encoding'] = 'unicode'
-   # Prevent database migrations from running on upgrade automatically
+   ## Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
-   #######################################
-   ###      Sidekiq configuration      ###
-   #######################################
+   # Sidekiq
+   sidekiqp['enable'] = true
    sidekiq['listen_address'] = "0.0.0.0"
 
    # Set number of Sidekiq queue processes to the same number as available CPUs
@@ -1923,9 +1907,7 @@ To configure the Sidekiq nodes, on each one:
    # Set number of Sidekiq threads per queue process to the recommend number of 10
    sidekiq['max_concurrency'] = 10
 
-   #######################################
-   ###     Monitoring configuration    ###
-   #######################################
+   # Monitoring
    consul['enable'] = true
    consul['monitoring_service_discovery'] =  true
 
@@ -1933,18 +1915,15 @@ To configure the Sidekiq nodes, on each one:
       retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
    }
 
-   # Set the network addresses that the exporters will listen on
+   ## Set the network addresses that the exporters will listen on
    node_exporter['listen_address'] = '0.0.0.0:9100'
 
-   # Rails Status for prometheus
+   ## Add the monitoring node's IP address to the monitoring whitelist
    gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
 
-   #############################
-   ###     Object storage    ###
-   #############################
-
-   # This is an example for configuring Object Storage on GCP
-   # Replace this config with your chosen Object Storage provider as desired
+   # Object Storage
+   ## This is an example for configuring Object Storage on GCP
+   ## Replace this config with your chosen Object Storage provider as desired
    gitlab_rails['object_store']['connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
@@ -1957,11 +1936,26 @@ To configure the Sidekiq nodes, on each one:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -1992,9 +1986,6 @@ On each node perform the following:
 1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
 
 1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration.
    To maintain uniformity of links across nodes, the `external_url`
@@ -2089,9 +2080,15 @@ On each node perform the following:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
    `git_data_dirs` entry is configured with `tls` instead of `tcp`:
 
@@ -2110,6 +2107,20 @@ On each node perform the following:
       sudo cp cert.pem /etc/gitlab/trusted-certs/
       ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. If you're [using NFS](#configure-nfs-optional):
    1. If necessary, install the NFS client utility packages using the following
       commands:
@@ -2149,7 +2160,8 @@ On each node perform the following:
       registry['gid'] = 9002
       ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+
 1. Confirm the node can connect to Gitaly:
 
    ```shell
@@ -2213,28 +2225,20 @@ To configure the Monitoring node:
 1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
    ```ruby
    external_url 'http://gitlab.example.com'
 
-   # Disable all other services
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Prometheus server
    gitaly['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = true
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
-   sidekiq['enable'] = false
    puma['enable'] = false
-   node_exporter['enable'] = false
+   sidekiq['enable'] = false
+   gitlab_workhorse['enable'] = false
+   alertmanager['enable'] = false
    gitlab_exporter['enable'] = false
 
    # Enable Prometheus
@@ -2260,7 +2264,8 @@ To configure the Monitoring node:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. In the GitLab UI, set `admin/application_settings/metrics_and_profiling` > Metrics - Grafana to `/-/grafana` to
 `http[s]://<MONITOR NODE>/-/grafana`
 
@@ -2395,7 +2400,7 @@ future with further specific cloud provider details.
 
 | Service                                               | Nodes | Configuration           | GCP              | Allocatable CPUs and Memory |
 |-------------------------------------------------------|-------|-------------------------|------------------|-----------------------------|
-| Webservice                                            | 4     | 32 vCPU, 28.8 GB memory | `n1-standard-32` | 127.5 vCPU, 118 GB memory   |
+| Webservice                                            | 4     | 32 vCPU, 28.8 GB memory | `n1-highcpu-32` | 127.5 vCPU, 118 GB memory   |
 | Sidekiq                                               | 4     | 4 vCPU, 15 GB memory    | `n1-standard-4`  | 15.5 vCPU, 50 GB memory     |
 | Supporting services such as NGINX, Prometheus, etc... | 2     | 4 vCPU, 15 GB memory    | `n1-standard-4`  | 7.75 vCPU, 25 GB memory     |
 
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 9f2e002c428..3826b06a350 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -413,11 +413,6 @@ The following IPs will be used as an example:
 - `10.6.0.12`: Consul 2
 - `10.6.0.13`: Consul 3
 
-NOTE:
-The configuration processes for the other servers in your reference architecture will
-use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
-with the other servers.
-
 To configure Consul:
 
 1. SSH in to the server that will host Consul.
@@ -448,7 +443,11 @@ To configure Consul:
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Consul nodes, and
    make sure you set up the correct IPs.
 
@@ -605,9 +604,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
 Like most failover handling methods, this has a small chance of leading to data loss.
 Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -707,9 +705,8 @@ The following IPs will be used as an example:
    node_exporter['listen_address'] = '0.0.0.0:9100'
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -868,9 +865,8 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -935,11 +931,11 @@ You can specify multiple roles, like sentinel and Redis, as:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -1067,11 +1063,11 @@ To configure the Sentinel Cache server:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
    make sure you set up the correct IPs.
 
@@ -1133,9 +1129,8 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -1194,11 +1189,11 @@ You can specify multiple roles, like sentinel and Redis, as:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -1326,7 +1321,10 @@ To configure the Sentinel Queues server:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. To prevent database migrations from running on upgrade, run:
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
 
    ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
@@ -1334,11 +1332,8 @@ To configure the Sentinel Queues server:
 
    Only the primary GitLab application server should handle migrations.
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
-
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Sentinel nodes, and
    make sure you set up the correct IPs.
 
@@ -1437,7 +1432,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # END user configuration
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
 <div align="right">
@@ -1535,18 +1534,18 @@ To configure the Praefect nodes, on each one:
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
 
    ```ruby
-   # Avoid running unnecessary services on the Gitaly server
+   # Avoid running unnecessary services on the Praefect server
+   gitaly['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Praefect Configuration
    praefect['enable'] = true
@@ -1614,11 +1613,25 @@ To configure the Praefect nodes, on each one:
    # END user configuration
    ```
 
-   1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-      then replace the file of the same name on this server. If that file isn't on
-      this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
-   1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Praefect requires to run some database migrations, much like the main GitLab application. For this
+   you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
+   must be configured first before the others as follows:
+   
+   1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
+
+   1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+   
+   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+      to run the Praefect database migrations.
+
+1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1662,20 +1675,17 @@ On each node:
    storage paths, enable the network listener, and to configure the token:
 
    ```ruby
-   # /etc/gitlab/gitlab.rb
-
    # Avoid running unnecessary services on the Gitaly server
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1683,9 +1693,11 @@ On each node:
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your 'front door' GitLab URL or an internal load
    # balancer.
-   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
+   # Gitaly 
+   gitaly['enable'] = true
+
    # Make Gitaly accept connections on all network interfaces. You must use
    # firewalls to restrict access to this address/port.
    # Comment out following line if you only want to support TLS connections
@@ -1727,9 +1739,8 @@ On each node:
      })
      ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-   then replace the file of the same name on this server. If that file isn't on
-   this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
@@ -1836,28 +1847,19 @@ To configure the Sidekiq nodes, on each one:
 1. Open `/etc/gitlab/gitlab.rb` with your editor:
 
    ```ruby
-   ########################################
-   #####        Services Disabled       ###
-   ########################################
-
-   nginx['enable'] = false
-   grafana['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Sidekiq server
    gitaly['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
+   puma['enable'] = false
+   gitlab_workhorse['enable'] = false
+   prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
    gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
-   ########################################
-   ####              Redis              ###
-   ########################################
-
+   # Redis
    ## Redis connection details
    ## First cluster that will host the cache
    gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
@@ -1889,13 +1891,10 @@ To configure the Sidekiq nodes, on each one:
      {host: '10.6.0.83', port: 26379},
    ]
 
-   #######################################
-   ###              Gitaly             ###
-   #######################################
-
-   # git_data_dirs get configured for the Praefect virtual storage
-   # Address is Internal Load Balancer for Praefect
-   # Token is praefect_external_token
+   # Gitaly Cluster
+   ## git_data_dirs get configured for the Praefect virtual storage
+   ## Address is Internal Load Balancer for Praefect
+   ## Token is praefect_external_token
    git_data_dirs({
      "default" => {
        "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@@ -1903,20 +1902,17 @@ To configure the Sidekiq nodes, on each one:
      }
    })
 
-   #######################################
-   ###            Postgres             ###
-   #######################################
+   # PostgreSQL
    gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
    gitlab_rails['db_adapter'] = 'postgresql'
    gitlab_rails['db_encoding'] = 'unicode'
-   # Prevent database migrations from running on upgrade automatically
+   ## Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
-   #######################################
-   ###      Sidekiq configuration      ###
-   #######################################
+   # Sidekiq
+   sidekiq['enable'] = true
    sidekiq['listen_address'] = "0.0.0.0"
 
    # Set number of Sidekiq queue processes to the same number as available CPUs
@@ -1925,9 +1921,7 @@ To configure the Sidekiq nodes, on each one:
    # Set number of Sidekiq threads per queue process to the recommend number of 10
    sidekiq['max_concurrency'] = 10
 
-   #######################################
-   ###     Monitoring configuration    ###
-   #######################################
+   # Monitoring
    consul['enable'] = true
    consul['monitoring_service_discovery'] =  true
 
@@ -1935,16 +1929,13 @@ To configure the Sidekiq nodes, on each one:
       retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
    }
 
-   # Set the network addresses that the exporters will listen on
+   ## Set the network addresses that the exporters will listen on
    node_exporter['listen_address'] = '0.0.0.0:9100'
 
-   # Rails Status for prometheus
+   ## Add the monitoring node's IP address to the monitoring whitelist
    gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
 
-   #############################
-   ###     Object storage    ###
-   #############################
-
+   # Object Storage
    # This is an example for configuring Object Storage on GCP
    # Replace this config with your chosen Object Storage provider as desired
    gitlab_rails['object_store']['connection'] = {
@@ -1959,11 +1950,26 @@ To configure the Sidekiq nodes, on each one:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
+   ```
+
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -1996,9 +2002,6 @@ On each node perform the following:
 1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
 
 1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration.
    To maintain uniformity of links across nodes, the `external_url`
@@ -2093,9 +2096,15 @@ On each node perform the following:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
    `git_data_dirs` entry is configured with `tls` instead of `tcp`:
 
@@ -2114,6 +2123,20 @@ On each node perform the following:
       sudo cp cert.pem /etc/gitlab/trusted-certs/
       ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. If you're [using NFS](#configure-nfs-optional):
    1. If necessary, install the NFS client utility packages using the following
       commands:
@@ -2153,7 +2176,7 @@ On each node perform the following:
       registry['gid'] = 9002
       ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. Confirm the node can connect to Gitaly:
 
    ```shell
@@ -2217,28 +2240,20 @@ To configure the Monitoring node:
 1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
    ```ruby
    external_url 'http://gitlab.example.com'
 
-   # Disable all other services
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Prometheus server
    gitaly['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = true
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
-   sidekiq['enable'] = false
    puma['enable'] = false
-   node_exporter['enable'] = false
+   sidekiq['enable'] = false
+   gitlab_workhorse['enable'] = false
+   alertmanager['enable'] = false
    gitlab_exporter['enable'] = false
 
    # Enable Prometheus
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index 0ff0c6bb550..1cd252cccd4 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -295,6 +295,9 @@ further configuration steps.
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Note the PostgreSQL node's IP address or hostname, port, and
    plain text password. These will be necessary when configuring the [GitLab
@@ -347,18 +350,17 @@ Omnibus:
    ## Enable Redis
    redis['enable'] = true
 
-   ## Disable all other services
+   # Avoid running unnecessary services on the Redis server
+   gitaly['enable'] = false
+   postgresql['enable'] = false
+   puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   puma['enable'] = false
-   postgresql['enable'] = false
-   nginx['enable'] = false
    prometheus['enable'] = false
    alertmanager['enable'] = false
-   pgbouncer_exporter['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitaly['enable'] = false
    grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    redis['bind'] = '0.0.0.0'
    redis['port'] = 6379
@@ -375,7 +377,11 @@ Omnibus:
    }
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Note the Redis node's IP address or hostname, port, and
    Redis password. These will be necessary when [configuring the GitLab
    application servers](#configure-gitlab-rails) later.
@@ -454,15 +460,14 @@ To configure the Gitaly server, on the server node you want to use for Gitaly:
    # Avoid running unnecessary services on the Gitaly server
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -470,9 +475,11 @@ To configure the Gitaly server, on the server node you want to use for Gitaly:
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your 'front door' GitLab URL or an internal load
    # balancer.
-   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
+   # Gitaly
+   gitaly['enable'] = true
+
    # Make Gitaly accept connections on all network interfaces. You must use
    # firewalls to restrict access to this address/port.
    # Comment out following line if you only want to support TLS connections
@@ -492,7 +499,11 @@ To configure the Gitaly server, on the server node you want to use for Gitaly:
    })
    ```
 
-1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Confirm that Gitaly can perform callbacks to the internal API:
 
    ```shell
@@ -656,10 +667,7 @@ On each node perform the following:
    gitlab_rails['monitoring_whitelist'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
    nginx['status']['options']['allow'] = ['<MONITOR NODE IP>/32', '127.0.0.0/8']
 
-   #############################
-   ###     Object storage    ###
-   #############################
-
+   # Object Storage
    # This is an example for configuring Object Storage on GCP
    # Replace this config with your chosen Object Storage provider as desired
    gitlab_rails['object_store']['connection'] = {
@@ -675,6 +683,13 @@ On each node perform the following:
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
 
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
+
    ## Uncomment and edit the following options if you have set up NFS
    ##
    ## Prevent GitLab from starting if NFS data mounts are not available
@@ -708,7 +723,20 @@ On each node perform the following:
       sudo cp cert.pem /etc/gitlab/trusted-certs/
       ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
 1. Tail the logs to see the requests:
 
@@ -716,11 +744,6 @@ On each node perform the following:
    sudo gitlab-ctl tail gitaly
    ```
 
-1. Save the `/etc/gitlab/gitlab-secrets.json` file from one of the two
-   application nodes and install it on the other application node and the
-   [Gitaly node](#configure-gitaly) and
-   [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-
 When you specify `https` in the `external_url`, as in the previous example,
 GitLab expects that the SSL certificates are in `/etc/gitlab/ssl/`. If the
 certificates aren't present, NGINX will fail to start. For more information, see
@@ -777,19 +800,14 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    grafana['enable'] = true
    grafana['admin_password'] = 'toomanysecrets'
 
-   # Disable all other services
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Prometheus server
    gitaly['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = true
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
-   sidekiq['enable'] = false
    puma['enable'] = false
-   node_exporter['enable'] = false
+   sidekiq['enable'] = false
+   gitlab_workhorse['enable'] = false
+   alertmanager['enable'] = false
    gitlab_exporter['enable'] = false
 
    # Prevent database migrations from running on upgrade automatically
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index 4553504a754..a89e50396a7 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -508,6 +508,9 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 You can specify multiple roles, like sentinel and Redis, as:
@@ -591,6 +594,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
@@ -720,7 +726,11 @@ To configure the Sentinel:
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
    make sure you set up the correct IPs.
 
@@ -878,9 +888,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
 Like most failover handling methods, this has a small chance of leading to data loss.
 Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -982,6 +991,9 @@ The following IPs will be used as an example:
    pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 1. Create a `.pgpass` file so Consul is able to
@@ -1135,6 +1147,9 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # END user configuration
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
@@ -1233,18 +1248,18 @@ To configure the Praefect nodes, on each one:
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
 
    ```ruby
-   # Avoid running unnecessary services on the Gitaly server
+   # Avoid running unnecessary services on the Praefect server
+   gitaly['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Praefect Configuration
    praefect['enable'] = true
@@ -1312,11 +1327,25 @@ To configure the Praefect nodes, on each one:
    # END user configuration
    ```
 
-   1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-      then replace the file of the same name on this server. If that file isn't on
-      this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. Praefect requires to run some database migrations, much like the main GitLab application. For this
+   you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
+   must be configured first before the others as follows:
+   
+   1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
-   1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+   
+   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+      to run the Praefect database migrations.
+
+1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1360,28 +1389,27 @@ On each node:
    storage paths, enable the network listener, and to configure the token:
 
    ```ruby
-   # /etc/gitlab/gitlab.rb
-
    # Avoid running unnecessary services on the Gitaly server
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
+   # Gitaly
+   gitaly['enable'] = true
+
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your 'front door' GitLab URL or an internal load
    # balancer.
-   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
    # Make Gitaly accept connections on all network interfaces. You must use
@@ -1425,9 +1453,8 @@ On each node:
      })
      ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-   then replace the file of the same name on this server. If that file isn't on
-   this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
@@ -1536,29 +1563,19 @@ To configure the Sidekiq nodes, one each one:
 1. Open `/etc/gitlab/gitlab.rb` with your editor:
 
    ```ruby
-   ########################################
-   #####        Services Disabled       ###
-   ########################################
-
-   nginx['enable'] = false
-   grafana['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Sidekiq server
    gitaly['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
+   puma['enable'] = false
+   gitlab_workhorse['enable'] = false
+   prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
    gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
-   ########################################
-   ####              Redis              ###
-   ########################################
-
-   ## Must be the same in every sentinel node
+   # Redis
    redis['master_name'] = 'gitlab-redis'
 
    ## The same password for Redis authentication you set up for the master node.
@@ -1571,13 +1588,10 @@ To configure the Sidekiq nodes, one each one:
       {'host' => '10.6.0.13', 'port' => 26379},
    ]
 
-   #######################################
-   ###              Gitaly             ###
-   #######################################
-
-   # git_data_dirs get configured for the Praefect virtual storage
-   # Address is Internal Load Balancer for Praefect
-   # Token is praefect_external_token
+   # Gitaly Cluster
+   ## git_data_dirs get configured for the Praefect virtual storage
+   ## Address is Internal Load Balancer for Praefect
+   ## Token is praefect_external_token
    git_data_dirs({
      "default" => {
        "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@@ -1585,31 +1599,26 @@ To configure the Sidekiq nodes, one each one:
      }
    })
 
-   #######################################
-   ###            Postgres             ###
-   #######################################
+   # PostgreSQL
    gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
    gitlab_rails['db_adapter'] = 'postgresql'
    gitlab_rails['db_encoding'] = 'unicode'
-   # Prevent database migrations from running on upgrade automatically
+   ## Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
-   #######################################
-   ###      Sidekiq configuration      ###
-   #######################################
+   # Sidekiq
+   sidekiq['enable'] = true
    sidekiq['listen_address'] = "0.0.0.0"
 
-   # Set number of Sidekiq queue processes to the same number as available CPUs
+   ## Set number of Sidekiq queue processes to the same number as available CPUs
    sidekiq['queue_groups'] = ['*'] * 2
 
-   # Set number of Sidekiq threads per queue process to the recommend number of 10
+   ## Set number of Sidekiq threads per queue process to the recommend number of 10
    sidekiq['max_concurrency'] = 10
 
-   #######################################
-   ###     Monitoring configuration    ###
-   #######################################
+   # Monitoring
    consul['enable'] = true
    consul['monitoring_service_discovery'] =  true
 
@@ -1617,19 +1626,16 @@ To configure the Sidekiq nodes, one each one:
       retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
    }
 
-   # Set the network addresses that the exporters will listen on
+   ## Set the network addresses that the exporters will listen on
    node_exporter['listen_address'] = '0.0.0.0:9100'
 
-   # Rails Status for prometheus
+   ## Add the monitoring node's IP address to the monitoring whitelist
    gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
    gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
 
-   #############################
-   ###     Object storage    ###
-   #############################
-
-   # This is an example for configuring Object Storage on GCP
-   # Replace this config with your chosen Object Storage provider as desired
+   # Object Storage
+   ## This is an example for configuring Object Storage on GCP
+   ## Replace this config with your chosen Object Storage provider as desired
    gitlab_rails['object_store']['connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
@@ -1643,9 +1649,28 @@ To configure the Sidekiq nodes, one each one:
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
 
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+
 1. Verify the GitLab services are running:
 
    ```shell
@@ -1792,10 +1817,7 @@ On each node perform the following:
    #registry['uid'] = 9002
    #registry['gid'] = 9002
 
-   #############################
-   ###     Object storage    ###
-   #############################
-
+   # Object storage
    # This is an example for configuring Object Storage on GCP
    # Replace this config with your chosen Object Storage provider as desired
    gitlab_rails['object_store']['connection'] = {
@@ -1810,6 +1832,13 @@ On each node perform the following:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
    ```
 
 1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
@@ -1830,7 +1859,20 @@ On each node perform the following:
       sudo cp cert.pem /etc/gitlab/trusted-certs/
       ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
 1. Tail the logs to see the requests:
 
@@ -1838,11 +1880,6 @@ On each node perform the following:
    sudo gitlab-ctl tail gitaly
    ```
 
-1. Save the `/etc/gitlab/gitlab-secrets.json` file from one of the two
-   application nodes and install it on the other application node, the
-   [Gitaly node](#configure-gitaly) and the [Sidekiq node](#configure-sidekiq) and
-   [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-
 1. Verify the GitLab services are running:
 
    ```shell
@@ -1903,19 +1940,14 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    ```ruby
    external_url 'http://gitlab.example.com'
 
-   # Disable all other services
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Prometheus server
    gitaly['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = true
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
-   sidekiq['enable'] = false
    puma['enable'] = false
-   node_exporter['enable'] = false
+   sidekiq['enable'] = false
+   gitlab_workhorse['enable'] = false
+   alertmanager['enable'] = false
    gitlab_exporter['enable'] = false
 
    # Enable Prometheus
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 4eef37c208f..272f6d4cadc 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -420,11 +420,6 @@ The following IPs will be used as an example:
 - `10.6.0.12`: Consul 2
 - `10.6.0.13`: Consul 3
 
-NOTE:
-The configuration processes for the other servers in your reference architecture will
-use the `/etc/gitlab/gitlab-secrets.json` file from your Consul server to connect
-with the other servers.
-
 To configure Consul:
 
 1. SSH in to the server that will host Consul.
@@ -455,7 +450,11 @@ To configure Consul:
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Consul nodes, and
    make sure you set up the correct IPs.
 
@@ -612,9 +611,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
 Like most failover handling methods, this has a small chance of leading to data loss.
 Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -714,9 +712,8 @@ The following IPs will be used as an example:
    node_exporter['listen_address'] = '0.0.0.0:9100'
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -875,9 +872,8 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -942,11 +938,11 @@ You can specify multiple roles, like sentinel and Redis, as:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -1074,11 +1070,11 @@ To configure the Sentinel Cache server:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
    make sure you set up the correct IPs.
 
@@ -1140,9 +1136,8 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -1201,11 +1196,11 @@ You can specify multiple roles, like sentinel and Redis, as:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
 
@@ -1333,7 +1328,7 @@ To configure the Sentinel Queues server:
    gitlab_rails['auto_migrate'] = false
    ```
 
-1. To prevent database migrations from running on upgrade, run:
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
 
    ```shell
    sudo touch /etc/gitlab/skip-auto-reconfigure
@@ -1341,11 +1336,11 @@ To configure the Sentinel Queues server:
 
    Only the primary GitLab application server should handle migrations.
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Go through the steps again for all the other Sentinel nodes, and
    make sure you set up the correct IPs.
 
@@ -1444,7 +1439,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # END user configuration
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
 <div align="right">
@@ -1542,18 +1541,18 @@ To configure the Praefect nodes, on each one:
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
 
    ```ruby
-   # Avoid running unnecessary services on the Gitaly server
+   # Avoid running unnecessary services on the Praefect server
+   gitaly['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Praefect Configuration
    praefect['enable'] = true
@@ -1621,11 +1620,25 @@ To configure the Praefect nodes, on each one:
    # END user configuration
    ```
 
-   1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-      then replace the file of the same name on this server. If that file isn't on
-      this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. Praefect requires to run some database migrations, much like the main GitLab application. For this
+   you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
+   must be configured first before the others as follows:
+   
+   1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
-   1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+   
+   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+      to run the Praefect database migrations.
+
+1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1669,20 +1682,17 @@ On each node:
    storage paths, enable the network listener, and to configure the token:
 
    ```ruby
-   # /etc/gitlab/gitlab.rb
-
    # Avoid running unnecessary services on the Gitaly server
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1690,9 +1700,11 @@ On each node:
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your 'front door' GitLab URL or an internal load
    # balancer.
-   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
+   # Gitaly 
+   gitaly['enable'] = true
+
    # Make Gitaly accept connections on all network interfaces. You must use
    # firewalls to restrict access to this address/port.
    # Comment out following line if you only want to support TLS connections
@@ -1734,9 +1746,8 @@ On each node:
      })
      ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-   then replace the file of the same name on this server. If that file isn't on
-   this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
@@ -1843,28 +1854,19 @@ To configure the Sidekiq nodes, on each one:
 1. Open `/etc/gitlab/gitlab.rb` with your editor:
 
    ```ruby
-   ########################################
-   #####        Services Disabled       ###
-   ########################################
-
-   nginx['enable'] = false
-   grafana['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Sidekiq server
    gitaly['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
+   puma['enable'] = false
+   gitlab_workhorse['enable'] = false
+   prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
    gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
-   ########################################
-   ####              Redis              ###
-   ########################################
-
+   # Redis
    ## Redis connection details
    ## First cluster that will host the cache
    gitlab_rails['redis_cache_instance'] = 'redis://:<REDIS_PRIMARY_PASSWORD_OF_FIRST_CLUSTER>@gitlab-redis-cache'
@@ -1896,10 +1898,7 @@ To configure the Sidekiq nodes, on each one:
      {host: '10.6.0.83', port: 26379},
    ]
 
-   #######################################
-   ###              Gitaly             ###
-   #######################################
-
+   # Gitaly
    # git_data_dirs get configured for the Praefect virtual storage
    # Address is Internal Load Balancer for Praefect
    # Token is praefect_external_token
@@ -1910,31 +1909,26 @@ To configure the Sidekiq nodes, on each one:
      }
    })
 
-   #######################################
-   ###            Postgres             ###
-   #######################################
+   # PostgreSQL
    gitlab_rails['db_host'] = '10.6.0.20' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
    gitlab_rails['db_adapter'] = 'postgresql'
    gitlab_rails['db_encoding'] = 'unicode'
-   # Prevent database migrations from running on upgrade automatically
+   ## Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
-   #######################################
-   ###      Sidekiq configuration      ###
-   #######################################
+   # Sidekiq
+   sidekiq['enable'] = true
    sidekiq['listen_address'] = "0.0.0.0"
 
-   # Set number of Sidekiq queue processes to the same number as available CPUs
+   ## Set number of Sidekiq queue processes to the same number as available CPUs
    sidekiq['queue_groups'] = ['*'] * 4
 
-   # Set number of Sidekiq threads per queue process to the recommend number of 10
+   ## Set number of Sidekiq threads per queue process to the recommend number of 10
    sidekiq['max_concurrency'] = 10
 
-   #######################################
-   ###     Monitoring configuration    ###
-   #######################################
+   # Monitoring 
    consul['enable'] = true
    consul['monitoring_service_discovery'] =  true
 
@@ -1945,15 +1939,12 @@ To configure the Sidekiq nodes, on each one:
    # Set the network addresses that the exporters will listen on
    node_exporter['listen_address'] = '0.0.0.0:9100'
 
-   # Rails Status for prometheus
+   ## Add the monitoring node's IP address to the monitoring whitelist
    gitlab_rails['monitoring_whitelist'] = ['10.6.0.151/32', '127.0.0.0/8']
 
-   #############################
-   ###     Object storage    ###
-   #############################
-
-   # This is an example for configuring Object Storage on GCP
-   # Replace this config with your chosen Object Storage provider as desired
+   # Object storage
+   ## This is an example for configuring Object Storage on GCP
+   ## Replace this config with your chosen Object Storage provider as desired
    gitlab_rails['object_store']['connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
@@ -1966,11 +1957,26 @@ To configure the Sidekiq nodes, on each one:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
+   ```
+
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
    ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -2010,9 +2016,6 @@ On each node perform the following:
 1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
 
 1. Edit `/etc/gitlab/gitlab.rb` and use the following configuration.
    To maintain uniformity of links across nodes, the `external_url`
@@ -2107,9 +2110,15 @@ On each node perform the following:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. If you're using [Gitaly with TLS support](#gitaly-cluster-tls-support), make sure the
    `git_data_dirs` entry is configured with `tls` instead of `tcp`:
 
@@ -2128,6 +2137,20 @@ On each node perform the following:
       sudo cp cert.pem /etc/gitlab/trusted-certs/
       ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. If you're [using NFS](#configure-nfs-optional):
    1. If necessary, install the NFS client utility packages using the following
       commands:
@@ -2167,7 +2190,7 @@ On each node perform the following:
       registry['gid'] = 9002
       ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 1. Confirm the node can connect to Gitaly:
 
    ```shell
@@ -2231,28 +2254,20 @@ To configure the Monitoring node:
 1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
    ```ruby
    external_url 'http://gitlab.example.com'
 
-   # Disable all other services
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Prometheus server
    gitaly['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = true
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
-   sidekiq['enable'] = false
    puma['enable'] = false
-   node_exporter['enable'] = false
+   sidekiq['enable'] = false
+   gitlab_workhorse['enable'] = false
+   alertmanager['enable'] = false
    gitlab_exporter['enable'] = false
 
    # Enable Prometheus
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 5aef6b479d1..7ff28fbf477 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -500,6 +500,9 @@ a node and change its status from primary to replica (and vice versa).
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 You can specify multiple roles, like sentinel and Redis, as:
@@ -583,6 +586,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
    make sure to set up the IPs correctly.
@@ -712,6 +718,9 @@ To configure the Sentinel:
    gitlab_rails['auto_migrate'] = false
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
    make sure you set up the correct IPs.
@@ -870,9 +879,8 @@ PostgreSQL, with Patroni managing its failover, will default to use `pg_rewind`
 Like most failover handling methods, this has a small chance of leading to data loss.
 Learn more about the various [Patroni replication methods](../postgresql/replication_and_failover.md#selecting-the-appropriate-patroni-replication-method).
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and replace
-   the file of the same name on this server. If that file is not on this server,
-   add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
@@ -973,6 +981,9 @@ The following IPs will be used as an example:
    pgbouncer_exporter['listen_address'] = '0.0.0.0:9188'
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure Omnibus GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 1. Create a `.pgpass` file so Consul is able to
@@ -1126,7 +1137,11 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # END user configuration
    ```
 
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
 1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
 
 <div align="right">
@@ -1224,18 +1239,18 @@ To configure the Praefect nodes, on each one:
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
 
    ```ruby
-   # Avoid running unnecessary services on the Gitaly server
+   # Avoid running unnecessary services on the Praefect server
+   gitaly['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Praefect Configuration
    praefect['enable'] = true
@@ -1303,11 +1318,25 @@ To configure the Praefect nodes, on each one:
    # END user configuration
    ```
 
-   1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-      then replace the file of the same name on this server. If that file isn't on
-      this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. Praefect requires to run some database migrations, much like the main GitLab application. For this
+   you should select **one Praefect node only to run the migrations**, AKA the _Deploy Node_. This node
+   must be configured first before the others as follows:
+   
+   1. In the `/etc/gitlab/gitlab.rb` file, change the `praefect['auto_migrate']` setting value from `false` to `true`
 
-   1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+   1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+   
+   1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect and
+      to run the Praefect database migrations.
+
+1. On all other Praefect nodes, [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
 
 ### Configure Gitaly
 
@@ -1351,20 +1380,17 @@ On each node:
    storage paths, enable the network listener, and to configure the token:
 
    ```ruby
-   # /etc/gitlab/gitlab.rb
-
    # Avoid running unnecessary services on the Gitaly server
    postgresql['enable'] = false
    redis['enable'] = false
-   nginx['enable'] = false
    puma['enable'] = false
    sidekiq['enable'] = false
    gitlab_workhorse['enable'] = false
-   grafana['enable'] = false
-
-   # If you run a separate monitoring node you can disable these services
-   alertmanager['enable'] = false
    prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
+   gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1372,9 +1398,11 @@ On each node:
    # Configure the gitlab-shell API callback URL. Without this, `git push` will
    # fail. This can be your 'front door' GitLab URL or an internal load
    # balancer.
-   # Don't forget to copy `/etc/gitlab/gitlab-secrets.json` from web server to Gitaly server.
    gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
 
+   # Gitaly
+   gitaly['enable'] = true
+
    # Make Gitaly accept connections on all network interfaces. You must use
    # firewalls to restrict access to this address/port.
    # Comment out following line if you only want to support TLS connections
@@ -1416,9 +1444,8 @@ On each node:
      })
      ```
 
-1. Copy the `/etc/gitlab/gitlab-secrets.json` file from your Consul server, and
-   then replace the file of the same name on this server. If that file isn't on
-   this server, add the file from your Consul server to this server.
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
@@ -1525,28 +1552,19 @@ To configure the Sidekiq nodes, one each one:
 1. Open `/etc/gitlab/gitlab.rb` with your editor:
 
    ```ruby
-   ########################################
-   #####        Services Disabled       ###
-   ########################################
-
-   nginx['enable'] = false
-   grafana['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
+   # Avoid running unnecessary services on the Sidekiq server
    gitaly['enable'] = false
-   gitlab_workhorse['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   postgres_exporter['enable'] = false
    postgresql['enable'] = false
    redis['enable'] = false
-   redis_exporter['enable'] = false
+   puma['enable'] = false
+   gitlab_workhorse['enable'] = false
+   prometheus['enable'] = false
+   alertmanager['enable'] = false
+   grafana['enable'] = false
    gitlab_exporter['enable'] = false
+   nginx['enable'] = false
 
-   ########################################
-   ####              Redis              ###
-   ########################################
-
+   # Redis
    ## Must be the same in every sentinel node
    redis['master_name'] = 'gitlab-redis'
 
@@ -1560,13 +1578,10 @@ To configure the Sidekiq nodes, one each one:
       {'host' => '10.6.0.13', 'port' => 26379},
    ]
 
-   #######################################
-   ###              Gitaly             ###
-   #######################################
-
-   # git_data_dirs get configured for the Praefect virtual storage
-   # Address is Internal Load Balancer for Praefect
-   # Token is praefect_external_token
+   # Gitaly Cluster
+   ## git_data_dirs get configured for the Praefect virtual storage
+   ## Address is Internal Load Balancer for Praefect
+   ## Token is praefect_external_token
    git_data_dirs({
      "default" => {
        "gitaly_address" => "tcp://10.6.0.40:2305", # internal load balancer IP
@@ -1574,31 +1589,26 @@ To configure the Sidekiq nodes, one each one:
      }
    })
 
-   #######################################
-   ###            Postgres             ###
-   #######################################
+   # PostgreSQL
    gitlab_rails['db_host'] = '10.6.0.40' # internal load balancer IP
    gitlab_rails['db_port'] = 6432
    gitlab_rails['db_password'] = '<postgresql_user_password>'
    gitlab_rails['db_adapter'] = 'postgresql'
    gitlab_rails['db_encoding'] = 'unicode'
-   # Prevent database migrations from running on upgrade automatically
+   ## Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
-   #######################################
-   ###      Sidekiq configuration      ###
-   #######################################
+   # Sidekiq
+   sidekiq['enable'] = true
    sidekiq['listen_address'] = "0.0.0.0"
 
-   # Set number of Sidekiq queue processes to the same number as available CPUs
+   ## Set number of Sidekiq queue processes to the same number as available CPUs
    sidekiq['queue_groups'] = ['*'] * 4
 
-   # Set number of Sidekiq threads per queue process to the recommend number of 10
+   ## Set number of Sidekiq threads per queue process to the recommend number of 10
    sidekiq['max_concurrency'] = 10
 
-   #######################################
-   ###     Monitoring configuration    ###
-   #######################################
+   # Monitoring
    consul['enable'] = true
    consul['monitoring_service_discovery'] =  true
 
@@ -1606,19 +1616,16 @@ To configure the Sidekiq nodes, one each one:
       retry_join: %w(10.6.0.11 10.6.0.12 10.6.0.13)
    }
 
-   # Set the network addresses that the exporters will listen on
+   ## Set the network addresses that the exporters will listen on
    node_exporter['listen_address'] = '0.0.0.0:9100'
 
-   # Rails Status for prometheus
+   ## Add the monitoring node's IP address to the monitoring whitelist
    gitlab_rails['monitoring_whitelist'] = ['10.6.0.81/32', '127.0.0.0/8']
    gitlab_rails['prometheus_address'] = '10.6.0.81:9090'
 
-   #############################
-   ###     Object storage    ###
-   #############################
-
-   # This is an example for configuring Object Storage on GCP
-   # Replace this config with your chosen Object Storage provider as desired
+   # Object Storage
+   ## This is an example for configuring Object Storage on GCP
+   ## Replace this config with your chosen Object Storage provider as desired
    gitlab_rails['object_store']['connection'] = {
      'provider' => 'Google',
      'google_project' => '<gcp-project-name>',
@@ -1631,9 +1638,29 @@ To configure the Sidekiq nodes, one each one:
    gitlab_rails['object_store']['objects']['packages']['bucket'] = "<gcp-packages-bucket-name>"
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
+
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Verify the GitLab services are running:
 
    ```shell
@@ -1784,6 +1811,13 @@ On each node perform the following:
    gitlab_rails['object_store']['objects']['dependency_proxy']['bucket'] = "<gcp-dependency-proxy-bucket-name>"
    gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = "<gcp-terraform-state-bucket-name>"
 
+   gitlab_rails['backup_upload_connection'] = {
+     'provider' => 'Google',
+     'google_project' => '<gcp-project-name>',
+     'google_json_key_location' => '<path-to-gcp-service-account-key>'
+   }
+   gitlab_rails['backup_upload_remote_directory'] = "<gcp-backups-state-bucket-name>"
+
    ## Uncomment and edit the following options if you have set up NFS
    ##
    ## Prevent GitLab from starting if NFS data mounts are not available
@@ -1818,7 +1852,20 @@ On each node perform the following:
       sudo cp cert.pem /etc/gitlab/trusted-certs/
       ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Omnibus node you configured and add or replace
+   the file of the same name on this server. If this is the first Omnibus node you are configuring then you can skip this step.
+
+1. To ensure database migrations are only run during reconfigure and not automatically on upgrade, run:
+
+   ```shell
+   sudo touch /etc/gitlab/skip-auto-reconfigure
+   ```
+
+   Only a single designated node should handle migrations as detailed in the
+   [GitLab Rails post-configuration](#gitlab-rails-post-configuration) section.
+
+1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
+
 1. Run `sudo gitlab-rake gitlab:gitaly:check` to confirm the node can connect to Gitaly.
 1. Tail the logs to see the requests:
 
@@ -1826,11 +1873,6 @@ On each node perform the following:
    sudo gitlab-ctl tail gitaly
    ```
 
-1. Save the `/etc/gitlab/gitlab-secrets.json` file from one of the two
-   application nodes and install it on the other application node, the
-   [Gitaly node](#configure-gitaly) and the [Sidekiq node](#configure-sidekiq) and
-   [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
-
 1. Verify the GitLab services are running:
 
    ```shell
@@ -1891,7 +1933,7 @@ running [Prometheus](../monitoring/prometheus/index.md) and
    ```ruby
    external_url 'http://gitlab.example.com'
 
-   # Disable all other services
+   # Avoid running unnecessary services on the Prometheus server
    alertmanager['enable'] = false
    gitaly['enable'] = false
    gitlab_exporter['enable'] = false
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 0822e94e58f..ec5976c667c 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -87,7 +87,7 @@ Returns [`DesignManagement!`](#designmanagement).
 
 Get configured DevOps adoption namespaces. **BETA** This endpoint is subject to change without notice.
 
-Returns [`DevopsAdoptionSegmentConnection`](#devopsadoptionsegmentconnection).
+Returns [`DevopsAdoptionEnabledNamespaceConnection`](#devopsadoptionenablednamespaceconnection).
 
 This field returns a [connection](#connections). It accepts the
 four standard [pagination arguments](#connection-pagination-arguments):
@@ -455,30 +455,6 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="queryvulnerabilitiescountbydayenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
 | <a id="queryvulnerabilitiescountbydaystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
 
-### `Query.vulnerabilitiesCountByDayAndSeverity`
-
-Number of vulnerabilities per severity level, per day, for the projects on the
-current user's instance security dashboard.
-.
-
-WARNING:
-**Deprecated** in 13.3.
-Use of this is not recommended.
-Use: [`Query.vulnerabilitiesCountByDay`](#queryvulnerabilitiescountbyday).
-
-Returns [`VulnerabilitiesCountByDayAndSeverityConnection`](#vulnerabilitiescountbydayandseverityconnection).
-
-This field returns a [connection](#connections). It accepts the
-four standard [pagination arguments](#connection-pagination-arguments):
-`before: String`, `after: String`, `first: Int`, `last: Int`.
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="queryvulnerabilitiescountbydayandseverityenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
-| <a id="queryvulnerabilitiescountbydayandseveritystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
-
 ### `Query.vulnerability`
 
 Find a vulnerability.
@@ -510,30 +486,6 @@ mutation($id: NoteableID!, $body: String!) {
 }
 ```
 
-### `Mutation.addAwardEmoji`
-
-WARNING:
-**Deprecated** in 13.2.
-Use awardEmojiAdd.
-
-Input type: `AddAwardEmojiInput`
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationaddawardemojiawardableid"></a>`awardableId` | [`AwardableID!`](#awardableid) | The global ID of the awardable resource. |
-| <a id="mutationaddawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationaddawardemojiname"></a>`name` | [`String!`](#string) | The emoji name. |
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationaddawardemojiawardemoji"></a>`awardEmoji` | [`AwardEmoji`](#awardemoji) | The award emoji after mutation. |
-| <a id="mutationaddawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationaddawardemojierrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-
 ### `Mutation.addProjectToSecurityDashboard`
 
 Input type: `AddProjectToSecurityDashboardInput`
@@ -801,7 +753,7 @@ Input type: `BulkEnableDevopsAdoptionNamespacesInput`
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="mutationbulkenabledevopsadoptionnamespacesclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationbulkenabledevopsadoptionnamespacesenablednamespaces"></a>`enabledNamespaces` | [`[DevopsAdoptionSegment!]`](#devopsadoptionsegment) | Enabled namespaces after mutation. |
+| <a id="mutationbulkenabledevopsadoptionnamespacesenablednamespaces"></a>`enabledNamespaces` | [`[DevopsAdoptionEnabledNamespace!]`](#devopsadoptionenablednamespace) | Enabled namespaces after mutation. |
 | <a id="mutationbulkenabledevopsadoptionnamespaceserrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 
 ### `Mutation.ciCdSettingsUpdate`
@@ -1485,7 +1437,6 @@ Input type: `DastScannerProfileCreateInput`
 | ---- | ---- | ----------- |
 | <a id="mutationdastscannerprofilecreateclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
 | <a id="mutationdastscannerprofilecreateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-| <a id="mutationdastscannerprofilecreateglobalid"></a>`globalId` **{warning-solid}** | [`DastScannerProfileID`](#dastscannerprofileid) | **Deprecated:** Use `id`. Deprecated in 13.6. |
 | <a id="mutationdastscannerprofilecreateid"></a>`id` | [`DastScannerProfileID`](#dastscannerprofileid) | ID of the scanner profile. |
 
 ### `Mutation.dastScannerProfileDelete`
@@ -1943,31 +1894,6 @@ Input type: `DiscussionToggleResolveInput`
 | <a id="mutationdiscussiontoggleresolvediscussion"></a>`discussion` | [`Discussion`](#discussion) | The discussion after mutation. |
 | <a id="mutationdiscussiontoggleresolveerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 
-### `Mutation.dismissVulnerability`
-
-WARNING:
-**Deprecated** in 13.5.
-Use vulnerabilityDismiss.
-
-Input type: `DismissVulnerabilityInput`
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationdismissvulnerabilityclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationdismissvulnerabilitycomment"></a>`comment` | [`String`](#string) | Comment why vulnerability should be dismissed. |
-| <a id="mutationdismissvulnerabilitydismissalreason"></a>`dismissalReason` | [`VulnerabilityDismissalReason`](#vulnerabilitydismissalreason) | Reason why vulnerability should be dismissed. |
-| <a id="mutationdismissvulnerabilityid"></a>`id` | [`VulnerabilityID!`](#vulnerabilityid) | ID of the vulnerability to be dismissed. |
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationdismissvulnerabilityclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationdismissvulnerabilityerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-| <a id="mutationdismissvulnerabilityvulnerability"></a>`vulnerability` | [`Vulnerability`](#vulnerability) | The vulnerability after dismissal. |
-
 ### `Mutation.enableDevopsAdoptionNamespace`
 
 **BETA** This endpoint is subject to change without notice.
@@ -1987,7 +1913,7 @@ Input type: `EnableDevopsAdoptionNamespaceInput`
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="mutationenabledevopsadoptionnamespaceclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationenabledevopsadoptionnamespaceenablednamespace"></a>`enabledNamespace` | [`DevopsAdoptionSegment`](#devopsadoptionsegment) | Enabled namespace after mutation. |
+| <a id="mutationenabledevopsadoptionnamespaceenablednamespace"></a>`enabledNamespace` | [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace) | Enabled namespace after mutation. |
 | <a id="mutationenabledevopsadoptionnamespaceerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 
 ### `Mutation.environmentsCanaryIngressUpdate`
@@ -3513,30 +3439,6 @@ Input type: `ReleaseUpdateInput`
 | <a id="mutationreleaseupdateerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationreleaseupdaterelease"></a>`release` | [`Release`](#release) | The release after mutation. |
 
-### `Mutation.removeAwardEmoji`
-
-WARNING:
-**Deprecated** in 13.2.
-Use awardEmojiRemove.
-
-Input type: `RemoveAwardEmojiInput`
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationremoveawardemojiawardableid"></a>`awardableId` | [`AwardableID!`](#awardableid) | The global ID of the awardable resource. |
-| <a id="mutationremoveawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationremoveawardemojiname"></a>`name` | [`String!`](#string) | The emoji name. |
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationremoveawardemojiawardemoji"></a>`awardEmoji` | [`AwardEmoji`](#awardemoji) | The award emoji after mutation. |
-| <a id="mutationremoveawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationremoveawardemojierrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-
 ### `Mutation.removeProjectFromSecurityDashboard`
 
 Input type: `RemoveProjectFromSecurityDashboardInput`
@@ -3577,55 +3479,6 @@ Input type: `RepositionImageDiffNoteInput`
 | <a id="mutationrepositionimagediffnoteerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationrepositionimagediffnotenote"></a>`note` | [`Note`](#note) | The note after mutation. |
 
-### `Mutation.revertVulnerabilityToDetected`
-
-WARNING:
-**Deprecated** in 13.5.
-Use vulnerabilityRevertToDetected.
-
-Input type: `RevertVulnerabilityToDetectedInput`
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationrevertvulnerabilitytodetectedclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationrevertvulnerabilitytodetectedid"></a>`id` | [`VulnerabilityID!`](#vulnerabilityid) | ID of the vulnerability to be reverted. |
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationrevertvulnerabilitytodetectedclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationrevertvulnerabilitytodetectederrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-| <a id="mutationrevertvulnerabilitytodetectedvulnerability"></a>`vulnerability` | [`Vulnerability`](#vulnerability) | The vulnerability after revert. |
-
-### `Mutation.runDastScan`
-
-WARNING:
-**Deprecated** in 13.4.
-Use DastOnDemandScanCreate.
-
-Input type: `RunDASTScanInput`
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationrundastscanbranch"></a>`branch` | [`String!`](#string) | The branch to be associated with the scan. |
-| <a id="mutationrundastscanclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationrundastscanprojectpath"></a>`projectPath` | [`ID!`](#id) | The project the DAST scan belongs to. |
-| <a id="mutationrundastscanscantype"></a>`scanType` | [`DastScanTypeEnum!`](#dastscantypeenum) | The type of scan to be run. |
-| <a id="mutationrundastscantargeturl"></a>`targetUrl` | [`String!`](#string) | The URL of the target to be scanned. |
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationrundastscanclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationrundastscanerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-| <a id="mutationrundastscanpipelineurl"></a>`pipelineUrl` | [`String`](#string) | URL of the pipeline that was created. |
-
 ### `Mutation.runnerDelete`
 
 Available only when feature flag `runner_graphql_query` is enabled.
@@ -3803,7 +3656,6 @@ Input type: `TodoRestoreManyInput`
 | <a id="mutationtodorestoremanyclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
 | <a id="mutationtodorestoremanyerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationtodorestoremanytodos"></a>`todos` | [`[Todo!]!`](#todo) | Updated to-do items. |
-| <a id="mutationtodorestoremanyupdatedids"></a>`updatedIds` **{warning-solid}** | [`[TodoID!]!`](#todoid) | **Deprecated:** Use to-do items. Deprecated in 13.2. |
 
 ### `Mutation.todosMarkAllDone`
 
@@ -3822,32 +3674,6 @@ Input type: `TodosMarkAllDoneInput`
 | <a id="mutationtodosmarkalldoneclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
 | <a id="mutationtodosmarkalldoneerrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
 | <a id="mutationtodosmarkalldonetodos"></a>`todos` | [`[Todo!]!`](#todo) | Updated to-do items. |
-| <a id="mutationtodosmarkalldoneupdatedids"></a>`updatedIds` **{warning-solid}** | [`[TodoID!]!`](#todoid) | **Deprecated:** Use to-do items. Deprecated in 13.2. |
-
-### `Mutation.toggleAwardEmoji`
-
-WARNING:
-**Deprecated** in 13.2.
-Use awardEmojiToggle.
-
-Input type: `ToggleAwardEmojiInput`
-
-#### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationtoggleawardemojiawardableid"></a>`awardableId` | [`AwardableID!`](#awardableid) | The global ID of the awardable resource. |
-| <a id="mutationtoggleawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationtoggleawardemojiname"></a>`name` | [`String!`](#string) | The emoji name. |
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="mutationtoggleawardemojiawardemoji"></a>`awardEmoji` | [`AwardEmoji`](#awardemoji) | The award emoji after mutation. |
-| <a id="mutationtoggleawardemojiclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="mutationtoggleawardemojierrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-| <a id="mutationtoggleawardemojitoggledon"></a>`toggledOn` | [`Boolean!`](#boolean) | Indicates the status of the emoji. True if the toggle awarded the emoji, and false if the toggle removed the emoji. |
 
 ### `Mutation.updateAlertStatus`
 
@@ -5184,28 +5010,28 @@ The edge type for [`DesignVersion`](#designversion).
 | <a id="designversionedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="designversionedgenode"></a>`node` | [`DesignVersion`](#designversion) | The item at the end of the edge. |
 
-#### `DevopsAdoptionSegmentConnection`
+#### `DevopsAdoptionEnabledNamespaceConnection`
 
-The connection type for [`DevopsAdoptionSegment`](#devopsadoptionsegment).
+The connection type for [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace).
 
 ##### Fields
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="devopsadoptionsegmentconnectionedges"></a>`edges` | [`[DevopsAdoptionSegmentEdge]`](#devopsadoptionsegmentedge) | A list of edges. |
-| <a id="devopsadoptionsegmentconnectionnodes"></a>`nodes` | [`[DevopsAdoptionSegment]`](#devopsadoptionsegment) | A list of nodes. |
-| <a id="devopsadoptionsegmentconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
+| <a id="devopsadoptionenablednamespaceconnectionedges"></a>`edges` | [`[DevopsAdoptionEnabledNamespaceEdge]`](#devopsadoptionenablednamespaceedge) | A list of edges. |
+| <a id="devopsadoptionenablednamespaceconnectionnodes"></a>`nodes` | [`[DevopsAdoptionEnabledNamespace]`](#devopsadoptionenablednamespace) | A list of nodes. |
+| <a id="devopsadoptionenablednamespaceconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
 
-#### `DevopsAdoptionSegmentEdge`
+#### `DevopsAdoptionEnabledNamespaceEdge`
 
-The edge type for [`DevopsAdoptionSegment`](#devopsadoptionsegment).
+The edge type for [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace).
 
 ##### Fields
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="devopsadoptionsegmentedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
-| <a id="devopsadoptionsegmentedgenode"></a>`node` | [`DevopsAdoptionSegment`](#devopsadoptionsegment) | The item at the end of the edge. |
+| <a id="devopsadoptionenablednamespaceedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
+| <a id="devopsadoptionenablednamespaceedgenode"></a>`node` | [`DevopsAdoptionEnabledNamespace`](#devopsadoptionenablednamespace) | The item at the end of the edge. |
 
 #### `DiscussionConnection`
 
@@ -6875,29 +6701,6 @@ The edge type for [`UserCore`](#usercore).
 | <a id="usercoreedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
 | <a id="usercoreedgenode"></a>`node` | [`UserCore`](#usercore) | The item at the end of the edge. |
 
-#### `VulnerabilitiesCountByDayAndSeverityConnection`
-
-The connection type for [`VulnerabilitiesCountByDayAndSeverity`](#vulnerabilitiescountbydayandseverity).
-
-##### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="vulnerabilitiescountbydayandseverityconnectionedges"></a>`edges` | [`[VulnerabilitiesCountByDayAndSeverityEdge]`](#vulnerabilitiescountbydayandseverityedge) | A list of edges. |
-| <a id="vulnerabilitiescountbydayandseverityconnectionnodes"></a>`nodes` | [`[VulnerabilitiesCountByDayAndSeverity]`](#vulnerabilitiescountbydayandseverity) | A list of nodes. |
-| <a id="vulnerabilitiescountbydayandseverityconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
-
-#### `VulnerabilitiesCountByDayAndSeverityEdge`
-
-The edge type for [`VulnerabilitiesCountByDayAndSeverity`](#vulnerabilitiescountbydayandseverity).
-
-##### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="vulnerabilitiescountbydayandseverityedgecursor"></a>`cursor` | [`String!`](#string) | A cursor for use in pagination. |
-| <a id="vulnerabilitiescountbydayandseverityedgenode"></a>`node` | [`VulnerabilitiesCountByDayAndSeverity`](#vulnerabilitiescountbydayandseverity) | The item at the end of the edge. |
-
 #### `VulnerabilitiesCountByDayConnection`
 
 The connection type for [`VulnerabilitiesCountByDay`](#vulnerabilitiescountbyday).
@@ -8043,7 +7846,6 @@ Represents a DAST scanner profile.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="dastscannerprofileeditpath"></a>`editPath` | [`String`](#string) | Relative web path to the edit page of a scanner profile. |
-| <a id="dastscannerprofileglobalid"></a>`globalId` **{warning-solid}** | [`DastScannerProfileID!`](#dastscannerprofileid) | **Deprecated** in 13.6. Use `id`. |
 | <a id="dastscannerprofileid"></a>`id` | [`DastScannerProfileID!`](#dastscannerprofileid) | ID of the DAST scanner profile. |
 | <a id="dastscannerprofileprofilename"></a>`profileName` | [`String`](#string) | Name of the DAST scanner profile. |
 | <a id="dastscannerprofilereferencedinsecuritypolicies"></a>`referencedInSecurityPolicies` | [`[String!]`](#string) | List of security policy names that are referencing given project. |
@@ -8378,7 +8180,7 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="detailedstatustext"></a>`text` | [`String`](#string) | Text of the status. |
 | <a id="detailedstatustooltip"></a>`tooltip` | [`String`](#string) | Tooltip associated with the status. |
 
-### `DevopsAdoptionSegment`
+### `DevopsAdoptionEnabledNamespace`
 
 Enabled namespace for DevopsAdoption.
 
@@ -8386,10 +8188,10 @@ Enabled namespace for DevopsAdoption.
 
 | Name | Type | Description |
 | ---- | ---- | ----------- |
-| <a id="devopsadoptionsegmentdisplaynamespace"></a>`displayNamespace` | [`Namespace`](#namespace) | Namespace where data should be displayed. |
-| <a id="devopsadoptionsegmentid"></a>`id` | [`ID!`](#id) | ID of the enabled namespace. |
-| <a id="devopsadoptionsegmentlatestsnapshot"></a>`latestSnapshot` | [`DevopsAdoptionSnapshot`](#devopsadoptionsnapshot) | The latest adoption metrics for the enabled namespace. |
-| <a id="devopsadoptionsegmentnamespace"></a>`namespace` | [`Namespace`](#namespace) | Namespace which should be calculated. |
+| <a id="devopsadoptionenablednamespacedisplaynamespace"></a>`displayNamespace` | [`Namespace`](#namespace) | Namespace where data should be displayed. |
+| <a id="devopsadoptionenablednamespaceid"></a>`id` | [`ID!`](#id) | ID of the enabled namespace. |
+| <a id="devopsadoptionenablednamespacelatestsnapshot"></a>`latestSnapshot` | [`DevopsAdoptionSnapshot`](#devopsadoptionsnapshot) | The latest adoption metrics for the enabled namespace. |
+| <a id="devopsadoptionenablednamespacenamespace"></a>`namespace` | [`Namespace`](#namespace) | Namespace which should be calculated. |
 
 ### `DevopsAdoptionSnapshot`
 
@@ -9558,27 +9360,6 @@ four standard [pagination arguments](#connection-pagination-arguments):
 | <a id="groupvulnerabilitiescountbydayenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
 | <a id="groupvulnerabilitiescountbydaystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
 
-##### `Group.vulnerabilitiesCountByDayAndSeverity`
-
-Number of vulnerabilities per severity level, per day, for the projects in the group and its subgroups.
-
-WARNING:
-**Deprecated** in 13.3.
-Use `vulnerabilitiesCountByDay`.
-
-Returns [`VulnerabilitiesCountByDayAndSeverityConnection`](#vulnerabilitiescountbydayandseverityconnection).
-
-This field returns a [connection](#connections). It accepts the
-four standard [pagination arguments](#connection-pagination-arguments):
-`before: String`, `after: String`, `first: Int`, `last: Int`.
-
-###### Arguments
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="groupvulnerabilitiescountbydayandseverityenddate"></a>`endDate` | [`ISO8601Date!`](#iso8601date) | Last day for which to fetch vulnerability history. |
-| <a id="groupvulnerabilitiescountbydayandseveritystartdate"></a>`startDate` | [`ISO8601Date!`](#iso8601date) | First day for which to fetch vulnerability history. |
-
 ##### `Group.vulnerabilityGrades`
 
 Represents vulnerable project counts for each grade.
@@ -12417,18 +12198,6 @@ Counts of requirements by their state.
 | <a id="rootstoragestatisticsuploadssize"></a>`uploadsSize` | [`Float!`](#float) | The uploads size in bytes. |
 | <a id="rootstoragestatisticswikisize"></a>`wikiSize` | [`Float!`](#float) | The wiki size in bytes. |
 
-### `RunDASTScanPayload`
-
-Autogenerated return type of RunDASTScan.
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="rundastscanpayloadclientmutationid"></a>`clientMutationId` | [`String`](#string) | A unique identifier for the client performing the mutation. |
-| <a id="rundastscanpayloaderrors"></a>`errors` | [`[String!]!`](#string) | Errors encountered during execution of the mutation. |
-| <a id="rundastscanpayloadpipelineurl"></a>`pipelineUrl` | [`String`](#string) | URL of the pipeline that was created. |
-
 ### `RunnerArchitecture`
 
 #### Fields
@@ -12771,7 +12540,6 @@ Represents a snippet entry.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="snippetauthor"></a>`author` | [`UserCore`](#usercore) | The owner of the snippet. |
-| <a id="snippetblob"></a>`blob` **{warning-solid}** | [`SnippetBlob!`](#snippetblob) | **Deprecated** in 13.3. Use `blobs`. |
 | <a id="snippetcreatedat"></a>`createdAt` | [`Time!`](#time) | Timestamp this snippet was created. |
 | <a id="snippetdescription"></a>`description` | [`String`](#string) | Description of the snippet. |
 | <a id="snippetdescriptionhtml"></a>`descriptionHtml` | [`String`](#string) | The GitLab Flavored Markdown rendering of `description`. |
@@ -13389,18 +13157,6 @@ Represents the count of vulnerabilities by severity on a particular day. This da
 | <a id="vulnerabilitiescountbydaytotal"></a>`total` | [`Int!`](#int) | Total number of vulnerabilities on a particular day. |
 | <a id="vulnerabilitiescountbydayunknown"></a>`unknown` | [`Int!`](#int) | Total number of vulnerabilities on a particular day with unknown severity. |
 
-### `VulnerabilitiesCountByDayAndSeverity`
-
-Represents the number of vulnerabilities for a particular severity on a particular day. This data is retained for 365 days.
-
-#### Fields
-
-| Name | Type | Description |
-| ---- | ---- | ----------- |
-| <a id="vulnerabilitiescountbydayandseveritycount"></a>`count` | [`Int`](#int) | Number of vulnerabilities. |
-| <a id="vulnerabilitiescountbydayandseverityday"></a>`day` | [`ISO8601Date`](#iso8601date) | Date for the count. |
-| <a id="vulnerabilitiescountbydayandseverityseverity"></a>`severity` | [`VulnerabilitySeverity`](#vulnerabilityseverity) | Severity of the counted vulnerabilities. |
-
 ### `Vulnerability`
 
 Represents a vulnerability.
@@ -14662,6 +14418,8 @@ Values for sorting group packages.
 | <a id="packagegroupsortcreated_desc"></a>`CREATED_DESC` | Ordered by created_at in descending order. |
 | <a id="packagegroupsortname_asc"></a>`NAME_ASC` | Ordered by name in ascending order. |
 | <a id="packagegroupsortname_desc"></a>`NAME_DESC` | Ordered by name in descending order. |
+| <a id="packagegroupsortproject_path_asc"></a>`PROJECT_PATH_ASC` | Ordered by project path in ascending order. |
+| <a id="packagegroupsortproject_path_desc"></a>`PROJECT_PATH_DESC` | Ordered by project path in descending order. |
 | <a id="packagegroupsorttype_asc"></a>`TYPE_ASC` | Ordered by type in ascending order. |
 | <a id="packagegroupsorttype_desc"></a>`TYPE_DESC` | Ordered by type in descending order. |
 | <a id="packagegroupsortversion_asc"></a>`VERSION_ASC` | Ordered by version in ascending order. |
diff --git a/doc/api/graphql/removed_items.md b/doc/api/graphql/removed_items.md
index a76f1fb7418..d8fc6cb35f8 100644
--- a/doc/api/graphql/removed_items.md
+++ b/doc/api/graphql/removed_items.md
@@ -10,6 +10,32 @@ GraphQL is a versionless API, unlike the REST API.
 Occasionally, items have to be updated or removed from the GraphQL API.
 According to our [process for removing items](index.md#deprecation-and-removal-process), here are the items that have been removed.
 
+## GitLab 14.0
+
+Fields removed in [GitLab 14.0](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63293):
+
+### GraphQL Mutations
+
+| Argument name        | Mutation                 | Deprecated in | Use instead                |
+| -------------------- | --------------------     | ------------- | -------------------------- |
+| `updated_ids`        | `todosMarkAllDone`       | 13.2          | `todos`                    |
+| `updated_ids`        | `todoRestoreMany`        | 13.2          | `todos`                    |
+| `global_id`          | `dastScannerProfileCreate`| 13.6          | `todos`                    |
+| -                    | `addAwardEmoji`          | 13.2          | `awardEmojiAdd`            |
+| -                    | `removeAwardEmoji`       | 13.2          | `awardEmojiRemove`         |
+| -                    | `toggleAwardEmoji`       | 13.2          | `ToggleAwardEmoji`         |
+| -                    | `runDastScan`            | 13.5          | `dastOnDemandScanCreate`   |
+| -                    | `dismissVulnerability`   | 13.5          | `vulnerabilityDismiss`     |
+| -                    | `revertVulnerabilityToDetected`   | 13.5          | `vulnerabilityRevertToDetected`     |
+
+### GraphQL Types
+
+| Field name           | GraphQL type             | Deprecated in | Use instead                |
+| -------------------- | --------------------     | ------------- | -------------------------- |
+| `blob`               | `SnippetType`            | 13.3          | `blobs`                    |
+| `global_id`          | `DastScannerProfileType` | 13.6          | `blobs`                    |
+| `vulnerabilities_count_by_day_and_severity` | `GroupType`, `QueryType` | 13.3          | None. Plaintext tokens no longer supported for security reasons. |
+
 ## GitLab 13.6
 
 Fields removed in [GitLab 13.6](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/44866):
diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md
index 8da512a1270..0778d598d32 100644
--- a/doc/ci/caching/index.md
+++ b/doc/ci/caching/index.md
@@ -43,9 +43,9 @@ can't link to files outside it.
 To ensure maximum availability of the cache, when you declare `cache` in your jobs,
 use one or more of the following:
 
-- [Tag your runners](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
+- [Tag your runners](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) and use the tag on jobs
   that share their cache.
-- [Use runners that are only available to a particular project](../runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
+- [Use runners that are only available to a particular project](../runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects).
 - [Use a `key`](../yaml/README.md#cachekey) that fits your workflow (for example,
   different caches on each branch). For that, you can take advantage of the
   [predefined CI/CD variables](../variables/README.md#predefined-cicd-variables).
diff --git a/doc/ci/docker/using_docker_build.md b/doc/ci/docker/using_docker_build.md
index 54aa3e50a1b..9dac08324c8 100644
--- a/doc/ci/docker/using_docker_build.md
+++ b/doc/ci/docker/using_docker_build.md
@@ -25,9 +25,8 @@ To enable Docker commands for your CI/CD jobs, you can use:
 If you don't want to execute a runner in privileged mode,
 but want to use `docker build`, you can also [use kaniko](using_kaniko.md).
 
-If you are using shared runners on GitLab.com, see
-[GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners)
-to learn more about how these runners are configured.
+If you are using shared runners on GitLab.com, 
+[learn more about how these runners are configured](../runners/README.md).
 
 ### Use the shell executor
 
@@ -91,7 +90,7 @@ The Docker image has all of the `docker` tools installed and can run
 the job script in context of the image in privileged mode.
 
 We recommend you use [Docker-in-Docker with TLS enabled](#docker-in-docker-with-tls-enabled),
-which is supported by [GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners).
+which is supported by [GitLab.com shared runners](../runners/README.md).
 
 You should always specify a specific version of the image, like `docker:19.03.12`.
 If you use a tag like `docker:stable`, you have no control over which version is used.
diff --git a/doc/ci/docker/using_kaniko.md b/doc/ci/docker/using_kaniko.md
index 31e04472bab..6e169baf68a 100644
--- a/doc/ci/docker/using_kaniko.md
+++ b/doc/ci/docker/using_kaniko.md
@@ -133,7 +133,7 @@ The [Least Privilege Container Builds with Kaniko on GitLab](https://www.youtube
 video is a walkthrough of the [Kaniko Docker Build](https://gitlab.com/guided-explorations/containers/kaniko-docker-build)
 Guided Exploration project pipeline. It was tested on:
 
-- [GitLab.com shared runners](../../user/gitlab_com/index.md#shared-runners)
+- [GitLab.com shared runners](../runners/README.md)
 - [The Kubernetes runner executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
 
 The example can be copied to your own group or instance for testing. More details
diff --git a/doc/ci/environments/deployment_safety.md b/doc/ci/environments/deployment_safety.md
index 6fda6bb0d8b..86e004322bc 100644
--- a/doc/ci/environments/deployment_safety.md
+++ b/doc/ci/environments/deployment_safety.md
@@ -117,7 +117,7 @@ The other pipelines don't get the protected variable. You can also
 [scope variables to specific environments](../variables/where_variables_can_be_used.md#variables-with-an-environment-scope).
 We recommend that you use protected variables on protected environments to make sure that the
 secrets aren't exposed unintentionally. You can also define production secrets on the
-[runner side](../runners/README.md#prevent-runners-from-revealing-sensitive-information).
+[runner side](../runners/configure_runners.md#prevent-runners-from-revealing-sensitive-information).
 This prevents other maintainers from reading the secrets and makes sure that the runner only runs on
 protected branches.
 
diff --git a/doc/ci/environments/index.md b/doc/ci/environments/index.md
index 8ed35bf8bfd..a60c0d03e8f 100644
--- a/doc/ci/environments/index.md
+++ b/doc/ci/environments/index.md
@@ -409,7 +409,7 @@ The job with [`action: stop` might not run](#the-job-with-action-stop-doesnt-run
 if it's in a later stage than the job that started the environment.
 
 If you can't use [pipelines for merge requests](../merge_request_pipelines/index.md),
-set the [`GIT_STRATEGY`](../runners/README.md#git-strategy) to `none` in the
+set the [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy) to `none` in the
 `stop_review` job. Then the [runner](https://docs.gitlab.com/runner/) doesn't
 try to check out the code after the branch is deleted.
 
diff --git a/doc/ci/environments/protected_environments.md b/doc/ci/environments/protected_environments.md
index a6c9e4bd38e..c276059cb9e 100644
--- a/doc/ci/environments/protected_environments.md
+++ b/doc/ci/environments/protected_environments.md
@@ -215,7 +215,7 @@ configured:
   (or above) to the top-level group. They can maintain CI/CD configurations for
   the higher environments (such as production) in the group-level settings page,
   wnich includes group-level protected environments,
-  [group-level runners](../runners/README.md#group-runners),
+  [group-level runners](../runners/runners_scope.md#group-runners),
   [group-level clusters](../../user/group/clusters/index.md), etc. Those
   configurations are inherited to the child projects as read-only entries.
   This ensures that only operators can configure the organization-wide
diff --git a/doc/ci/git_submodules.md b/doc/ci/git_submodules.md
index 2b34beaa03d..f0ea5ed582c 100644
--- a/doc/ci/git_submodules.md
+++ b/doc/ci/git_submodules.md
@@ -53,7 +53,7 @@ To make submodules work correctly in CI/CD jobs:
 1. Make sure you use [relative URLs](#configure-the-gitmodules-file)
    for submodules located in the same GitLab server.
 1. You can set the `GIT_SUBMODULE_STRATEGY` variable to either `normal` or `recursive`
-   to tell the runner to [fetch your submodules before the job](runners/README.md#git-submodule-strategy):
+   to tell the runner to [fetch your submodules before the job](runners/configure_runners.md#git-submodule-strategy):
 
    ```yaml
    variables:
diff --git a/doc/ci/interactive_web_terminal/index.md b/doc/ci/interactive_web_terminal/index.md
index 1aa86e0b322..cbf92438488 100644
--- a/doc/ci/interactive_web_terminal/index.md
+++ b/doc/ci/interactive_web_terminal/index.md
@@ -16,7 +16,7 @@ is deployed, some [security precautions](../../administration/integration/termin
 taken to protect the users.
 
 NOTE:
-[Shared runners on GitLab.com](../runners/README.md#shared-runners) do not
+[Shared runners on GitLab.com](../runners/README.md) do not
 provide an interactive web terminal. Follow [this
 issue](https://gitlab.com/gitlab-org/gitlab/-/issues/24674) for progress on
 adding support. For groups and projects hosted on GitLab.com, interactive web
diff --git a/doc/ci/large_repositories/index.md b/doc/ci/large_repositories/index.md
index aff18b0889f..62e9749d959 100644
--- a/doc/ci/large_repositories/index.md
+++ b/doc/ci/large_repositories/index.md
@@ -56,7 +56,7 @@ test:
 
 > Introduced in GitLab Runner 8.9.
 
-By default, GitLab is configured to use the [`fetch` Git strategy](../runners/README.md#git-strategy),
+By default, GitLab is configured to use the [`fetch` Git strategy](../runners/configure_runners.md#git-strategy),
 which is recommended for large repositories.
 This strategy reduces the amount of data to transfer and
 does not really impact the operations that you might do on a repository from CI.
@@ -65,7 +65,7 @@ does not really impact the operations that you might do on a repository from CI.
 
 > Introduced in GitLab Runner 11.10.
 
-[`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) allows you to
+[`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) allows you to
 control where you clone your sources. This can have implications if you
 heavily use big repositories with fork workflow.
 
@@ -77,7 +77,7 @@ In such cases, ideally you want to make the GitLab Runner executor be used only
 for the given project and not shared across different projects to make this
 process more efficient.
 
-The [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) has to be
+The [`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) has to be
 within the `$CI_BUILDS_DIR`. Currently, it is impossible to pick any path
 from disk.
 
@@ -85,12 +85,12 @@ from disk.
 
 > Introduced in GitLab Runner 11.10.
 
-[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) allows you to control
+[`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags) allows you to control
 whether or not you require the `git clean` command to be executed for each CI
 job. By default, GitLab ensures that you have your worktree on the given SHA,
 and that your repository is clean.
 
-[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags) is disabled when set
+[`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags) is disabled when set
 to `none`. On very big repositories, this might be desired because `git
 clean` is disk I/O intensive. Controlling that with `GIT_CLEAN_FLAGS: -ffdx
 -e .build/` (for example) allows you to control and disable removal of some
@@ -99,7 +99,7 @@ the incremental builds. This has the biggest effect if you re-use existing
 machines and have an existing worktree that you can re-use for builds.
 
 For exact parameters accepted by
-[`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags), see the documentation
+[`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags), see the documentation
 for [`git clean`](https://git-scm.com/docs/git-clean). The available parameters
 are dependent on Git version.
 
@@ -107,7 +107,7 @@ are dependent on Git version.
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
 
-[`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags) allows you
+[`GIT_FETCH_EXTRA_FLAGS`](../runners/configure_runners.md#git-fetch-extra-flags) allows you
 to modify `git fetch` behavior by passing extra flags.
 
 For example, if your project contains a large number of tags that your CI jobs don't rely on,
@@ -119,7 +119,7 @@ tags, `--no-tags` can [make a big difference in some
 cases](https://gitlab.com/gitlab-com/gl-infra/scalability/-/issues/746).
 If your CI builds do not depend on Git tags it is worth trying.
 
-See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/README.md#git-fetch-extra-flags)
+See the [`GIT_FETCH_EXTRA_FLAGS` documentation](../runners/configure_runners.md#git-fetch-extra-flags)
 for more information.
 
 ## Fork-based workflow
diff --git a/doc/ci/migration/jenkins.md b/doc/ci/migration/jenkins.md
index 41dba1a2b77..9d3aab4872a 100644
--- a/doc/ci/migration/jenkins.md
+++ b/doc/ci/migration/jenkins.md
@@ -128,16 +128,16 @@ agents you were using.
 
 There are some important differences in the way runners work in comparison to agents:
 
-- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/README.md#types-of-runners).
+- Runners can be set up as [shared across an instance, be added at the group level, or set up at the project level](../runners/runners_scope.md).
   They self-select jobs from the scopes you've defined automatically.
-- You can also [use tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
+- You can also [use tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) for finer control, and
   associate runners with specific jobs. For example, you can use a tag for jobs that
   require dedicated, more powerful, or specific hardware.
 - GitLab has [autoscaling for runners](https://docs.gitlab.com/runner/configuration/autoscale.html).
   Use autoscaling to provision runners only when needed, and scale down when not needed.
   This is similar to ephemeral agents in Jenkins.
 
-If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../../user/gitlab_com/index.md#shared-runners)
+If you are using `gitlab.com`, you can take advantage of our [shared runner fleet](../runners/README.md)
 to run jobs without provisioning your own runners. We are investigating making them
 [available for self-managed instances](https://gitlab.com/groups/gitlab-org/-/epics/835)
 as well.
@@ -230,7 +230,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab.
 The agent section is used to define how a pipeline executes. For GitLab, we use [runners](../runners/README.md)
 to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage
 of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users).
-We also support using [tags](../runners/README.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
+We also support using [tags](../runners/configure_runners.md#use-tags-to-limit-the-number-of-jobs-using-the-runner) to direct different jobs
 to different runners (execution agents).
 
 The `agent` section also allows you to define which Docker images should be used for execution, for which we use
diff --git a/doc/ci/pipelines/settings.md b/doc/ci/pipelines/settings.md
index 0c7aaee4939..6fefe3e7d39 100644
--- a/doc/ci/pipelines/settings.md
+++ b/doc/ci/pipelines/settings.md
@@ -35,7 +35,7 @@ There are two options. Using:
   back to clone if it doesn't exist).
   This is recommended, especially for [large repositories](../large_repositories/index.md#git-strategy).
 
-The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/README.md#git-strategy)
+The configured Git strategy can be overridden by the [`GIT_STRATEGY` variable](../runners/configure_runners.md#git-strategy)
 in `.gitlab-ci.yml`.
 
 ## Git shallow clone
@@ -66,7 +66,7 @@ if the job surpasses the threshold, it is marked as failed.
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17221) in GitLab 10.7.
 
 Project defined timeout (either specific timeout set by user or the default
-60 minutes timeout) may be [overridden for runners](../runners/README.md#set-maximum-job-timeout-for-a-runner).
+60 minutes timeout) may be [overridden for runners](../runners/configure_runners.md#set-maximum-job-timeout-for-a-runner).
 
 ## Maximum artifacts size **(FREE SELF)**
 
diff --git a/doc/ci/quick_start/index.md b/doc/ci/quick_start/index.md
index 3b243a15b14..cd0be8b0561 100644
--- a/doc/ci/quick_start/index.md
+++ b/doc/ci/quick_start/index.md
@@ -41,7 +41,7 @@ The job results [are displayed in a pipeline](#view-the-status-of-your-pipeline-
 In GitLab, runners are agents that run your CI/CD jobs.
 
 You might already have runners available for your project, including
-[shared runners](../runners/README.md#shared-runners), which are
+[shared runners](../runners/runners_scope.md), which are
 available to all projects in your GitLab instance.
 
 To view available runners:
diff --git a/doc/ci/runners/README.md b/doc/ci/runners/README.md
index edff51abda5..8d21849c4d4 100644
--- a/doc/ci/runners/README.md
+++ b/doc/ci/runners/README.md
@@ -5,847 +5,288 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 type: reference
 ---
 
-# Configuring runners in GitLab
+# Runners
 
 In GitLab CI/CD, runners run the code defined in [`.gitlab-ci.yml`](../yaml/README.md).
 A runner is a lightweight, highly-scalable agent that picks up a CI job through
 the coordinator API of GitLab CI/CD, runs the job, and sends the result back to the GitLab instance.
 
-Runners are created by an administrator and are visible in the GitLab UI.
-Runners can be specific to certain projects or available to all projects.
+If you are using GitLab SaaS (GitLab.com), your CI jobs automatically run on shared runners. No configuration is required.
 
-This documentation is focused on using runners in GitLab.
-If you need to install and configure GitLab Runner, see
-[the GitLab Runner documentation](https://docs.gitlab.com/runner/).
+If you are using self-managed GitLab or you want to use your own runners on GitLab.com, you can
+[install and configure your own runners](https://docs.gitlab.com/runner/install/).
 
-## Types of runners
+## Runners on GitLab.com
 
-In the GitLab UI there are three types of runners, based on who you want to have access:
+On GitLab.com, your jobs can run on [Linux](#linux-shared-runners) or [Windows](#windows-shared-runners-beta).
 
-- [Shared runners](#shared-runners) are available to all groups and projects in a GitLab instance.
-- [Group runners](#group-runners) are available to all projects and subgroups in a group.
-- [Specific runners](#specific-runners) are associated with specific projects.
-  Typically, specific runners are used for one project at a time.
+### Linux shared runners
 
-### Shared runners
+Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
 
-*Shared runners* are available to every project in a GitLab instance.
+Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each project, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
 
-Use shared runners when you have multiple jobs with similar requirements. Rather than
-having multiple runners idling for many projects, you can have a few runners that handle
-multiple projects.
+GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
 
-If you are using a self-managed instance of GitLab:
+All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
+installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
+region of the VMs is US East1.
+Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
 
-- Your administrator can install and register shared runners by
-  going to your project's **Settings > CI/CD**, expanding the **Runners** section,
-  and clicking **Show runner installation instructions**.
-  These instructions are also available [in the documentation](https://docs.gitlab.com/runner/install/index.html).
-- The administrator can also configure a maximum number of shared runner [pipeline minutes for
-  each group](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota).
+The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
 
-If you are using GitLab.com:
+Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
+**time out after 3 hours**, regardless of the timeout configured in a
+project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
 
-- You can select from a list of [shared runners that GitLab maintains](../../user/gitlab_com/index.md#shared-runners).
-- The shared runners consume the [pipelines minutes](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes)
-  included with your account.
+Below are the shared runners settings.
 
-#### How shared runners pick jobs
+| Setting                               | GitLab.com                                        | Default    |
+| -----------                           | -----------------                                 | ---------- |
+| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) | [Runner versions dashboard](https://dashboards.gitlab.com/d/000000159/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light) | - |
+| Executor                              | `docker+machine`                                  | -          |
+| Default Docker image                  | `ruby:2.5`                                        | -          |
+| `privileged` (run [Docker in Docker](https://hub.docker.com/_/docker/)) | `true`          | `false`    |
 
-Shared runners process jobs by using a fair usage queue. This queue prevents
-projects from creating hundreds of jobs and using all available
-shared runner resources.
+#### Pre-clone script
 
-The fair usage queue algorithm assigns jobs based on the projects that have the
-fewest number of jobs already running on shared runners.
+Linux shared runners on GitLab.com provide a way to run commands in a CI
+job before the runner attempts to run `git init` and `git fetch` to
+download a GitLab repository. The
+[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
+can be used for:
 
-**Example 1**
+- Seeding the build directory with repository data
+- Sending a request to a server
+- Downloading assets from a CDN
+- Any other commands that must run before the `git init`
 
-If these jobs are in the queue:
+To use this feature, define a [CI/CD variable](../../ci/variables/README.md#custom-cicd-variables) called
+`CI_PRE_CLONE_SCRIPT` that contains a bash script.
 
-- Job 1 for Project 1
-- Job 2 for Project 1
-- Job 3 for Project 1
-- Job 4 for Project 2
-- Job 5 for Project 2
-- Job 6 for Project 3
+[This example](../../development/pipelines.md#pre-clone-step)
+demonstrates how you might use a pre-clone step to seed the build
+directory.
 
-The fair usage algorithm assigns jobs in this order:
+#### `config.toml`
 
-1. Job 1 is chosen first, because it has the lowest job number from projects with no running jobs (that is, all projects).
-1. Job 4 is next, because 4 is now the lowest job number from projects with no running jobs (Project 1 has a job running).
-1. Job 6 is next, because 6 is now the lowest job number from projects with no running jobs (Projects 1 and 2 have jobs running).
-1. Job 2 is next, because, of projects with the lowest number of jobs running (each has 1), it is the lowest job number.
-1. Job 5 is next, because Project 1 now has 2 jobs running and Job 5 is the lowest remaining job number between Projects 2 and 3.
-1. Finally is Job 3... because it's the only job left.
-
----
-
-**Example 2**
-
-If these jobs are in the queue:
-
-- Job 1 for Project 1
-- Job 2 for Project 1
-- Job 3 for Project 1
-- Job 4 for Project 2
-- Job 5 for Project 2
-- Job 6 for Project 3
-
-The fair usage algorithm assigns jobs in this order:
-
-1. Job 1 is chosen first, because it has the lowest job number from projects with no running jobs (that is, all projects).
-1. We finish Job 1.
-1. Job 2 is next, because, having finished Job 1, all projects have 0 jobs running again, and 2 is the lowest available job number.
-1. Job 4 is next, because with Project 1 running a Job, 4 is the lowest number from projects running no jobs (Projects 2 and 3).
-1. We finish Job 4.
-1. Job 5 is next, because having finished Job 4, Project 2 has no jobs running again.
-1. Job 6 is next, because Project 3 is the only project left with no running jobs.
-1. Lastly we choose Job 3... because, again, it's the only job left.
-
-#### Enable shared runners
-
-On GitLab.com, [shared runners](#shared-runners) are enabled in all projects by
-default.
-
-On self-managed instances of GitLab, an administrator must [install](https://docs.gitlab.com/runner/install/index.html)
-and [register](https://docs.gitlab.com/runner/register/index.html) them.
-
-You can also enable shared runners for individual projects.
-
-To enable shared runners:
-
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. Select **Enable shared runners for this project**.
-
-#### Disable shared runners
-
-You can disable shared runners for individual projects or for groups.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the project
-or group.
-
-To disable shared runners for a project:
-
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. In the **Shared runners** area, select **Enable shared runners for this project** so the toggle is grayed-out.
-
-Shared runners are automatically disabled for a project:
-
-- If the shared runners setting for the parent group is disabled, and
-- If overriding this setting is not permitted at the project level.
-
-To disable shared runners for a group:
-
-1. Go to the group's **Settings > CI/CD** and expand the **Runners** section.
-1. In the **Shared runners** area, turn off the **Enable shared runners for this group** toggle.
-1. Optionally, to allow shared runners to be enabled for individual projects or subgroups,
-   click **Allow projects and subgroups to override the group setting**.
-
-NOTE:
-To re-enable the shared runners for a group, turn on the
-**Enable shared runners for this group** toggle.
-Then, an owner or maintainer must explicitly change this setting
-for each project subgroup or project.
-
-### Group runners
-
-Use *Group runners* when you want all projects in a group
-to have access to a set of runners.
-
-Group runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue.
-
-#### Create a group runner
-
-You can create a group runner for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
-
-To create a group runner:
-
-1. [Install GitLab Runner](https://docs.gitlab.com/runner/install/).
-1. Go to the group you want to make the runner work for.
-1. Go to **Settings > CI/CD** and expand the **Runners** section.
-1. Note the URL and token.
-1. [Register the runner](https://docs.gitlab.com/runner/register/).
-
-#### View and manage group runners
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/37366/) in GitLab 13.2.
-
-You can view and manage all runners for a group, its subgroups, and projects.
-You can do this for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
-
-1. Go to the group where you want to view the runners.
-1. Go to **Settings > CI/CD** and expand the **Runners** section.
-1. The following fields are displayed.
-
-   | Attribute    | Description |
-   | ------------ | ----------- |
-   | Type         | Displays the runner type: `group` or `specific`, together with the optional states `locked` and `paused` |
-   | Runner token | Token used to identify the runner, and that the runner uses to communicate with the GitLab instance |
-   | Description  | Description given to the runner when it was created |
-   | Version      | GitLab Runner version |
-   | IP address   | IP address of the host on which the runner is registered |
-   | Projects     | The count of projects to which the runner is assigned |
-   | Jobs         | Total of jobs run by the runner |
-   | Tags         | Tags associated with the runner |
-   | Last contact | Timestamp indicating when the GitLab instance last contacted the runner |
-
-From this page, you can edit, pause, and remove runners from the group, its subgroups, and projects.
-
-#### Pause or remove a group runner
-
-You can pause or remove a group runner for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
-
-1. Go to the group you want to remove or pause the runner for.
-1. Go to **Settings > CI/CD** and expand the **Runners** section.
-1. Click **Pause** or **Remove runner**.
-   - If you pause a group runner that is used by multiple projects, the runner pauses for all projects.
-   - From the group view, you cannot remove a runner that is assigned to more than one project.
-     You must remove it from each project first.
-1. On the confirmation dialog, click **OK**.
-
-### Specific runners
-
-Use *Specific runners* when you want to use runners for specific projects. For example,
-when you have:
-
-- Jobs with specific requirements, like a deploy job that requires credentials.
-- Projects with a lot of CI activity that can benefit from being separate from other runners.
-
-You can set up a specific runner to be used by multiple projects. Specific runners
-must be enabled for each project explicitly.
-
-Specific runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue.
+The full contents of our `config.toml` are:
 
 NOTE:
-Specific runners do not get shared with forked projects automatically.
-A fork *does* copy the CI/CD settings of the cloned repository.
-
-#### Create a specific runner
-
-You can create a specific runner for your self-managed GitLab instance or for GitLab.com.
-You must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
-
-To create a specific runner:
-
-1. [Install runner](https://docs.gitlab.com/runner/install/).
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. Note the URL and token.
-1. [Register the runner](https://docs.gitlab.com/runner/register/).
-
-#### Enable a specific runner for a specific project
-
-A specific runner is available in the project it was created for. An administrator can
-enable a specific runner to apply to additional projects.
-
-- You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the
-  project.
-- The specific runner must not be [locked](#prevent-a-specific-runner-from-being-enabled-for-other-projects).
-
-To enable or disable a specific runner for a project:
-
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. Click **Enable for this project** or **Disable for this project**.
-
-#### Prevent a specific runner from being enabled for other projects
-
-You can configure a specific runner so it is "locked" and cannot be enabled for other projects.
-This setting can be enabled when you first [register a runner](https://docs.gitlab.com/runner/register/),
-but can also be changed later.
-
-To lock or unlock a runner:
-
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. Find the runner you want to lock or unlock. Make sure it's enabled.
-1. Click the pencil button.
-1. Check the **Lock to current projects** option.
-1. Click **Save changes**.
-
-## Manually clear the runner cache
-
-Read [clearing the cache](../caching/index.md#clearing-the-cache).
-
-## Set maximum job timeout for a runner
-
-For each runner, you can specify a *maximum job timeout*. This timeout,
-if smaller than the [project defined timeout](../pipelines/settings.md#timeout), takes precedence.
-
-This feature can be used to prevent your shared runner from being overwhelmed
-by a project that has jobs with a long timeout (for example, one week).
-
-When not configured, runners do not override the project timeout.
-
-On GitLab.com, you cannot override the job timeout for shared runners and must use the [project defined timeout](../pipelines/settings.md#timeout).
-
-To set the maximum job timeout:
-
-1. In a project, go to **Settings > CI/CD > Runners**.
-1. Select your specific runner to edit the settings.
-1. Enter a value under **Maximum job timeout**.
-1. Select **Save changes**.
-
-How this feature works:
-
-**Example 1 - Runner timeout bigger than project timeout**
-
-1. You set the _maximum job timeout_ for a runner to 24 hours
-1. You set the _CI/CD Timeout_ for a project to **2 hours**
-1. You start a job
-1. The job, if running longer, times out after **2 hours**
-
-**Example 2 - Runner timeout not configured**
-
-1. You remove the _maximum job timeout_ configuration from a runner
-1. You set the _CI/CD Timeout_ for a project to **2 hours**
-1. You start a job
-1. The job, if running longer, times out after **2 hours**
-
-**Example 3 - Runner timeout smaller than project timeout**
-
-1. You set the _maximum job timeout_ for a runner to **30 minutes**
-1. You set the _CI/CD Timeout_ for a project to 2 hours
-1. You start a job
-1. The job, if running longer, times out after **30 minutes**
-
-## Be careful with sensitive information
-
-With some [runner executors](https://docs.gitlab.com/runner/executors/README.html),
-if you can run a job on the runner, you can get full access to the file system,
-and thus any code it runs as well as the token of the runner. With shared runners, this means that anyone
-that runs jobs on the runner, can access anyone else's code that runs on the
-runner.
-
-In addition, because you can get access to the runner token, it is possible
-to create a clone of a runner and submit false jobs, for example.
-
-The above is easily avoided by restricting the usage of shared runners
-on large public GitLab instances, controlling access to your GitLab instance,
-and using more secure [runner executors](https://docs.gitlab.com/runner/executors/README.html).
-
-### Prevent runners from revealing sensitive information
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13194) in GitLab 10.0.
-
-You can protect runners so they don't reveal sensitive information.
-When a runner is protected, the runner picks jobs created on
-[protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md) only,
-and ignores other jobs.
-
-To protect or unprotect a runner:
-
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. Find the runner you want to protect or unprotect. Make sure it's enabled.
-1. Click the pencil button.
-1. Check the **Protected** option.
-1. Click **Save changes**.
-
-![specific runners edit icon](img/protected_runners_check_box.png)
-
-### Forks
-
-Whenever a project is forked, it copies the settings of the jobs that relate
-to it. This means that if you have shared runners set up for a project and
-someone forks that project, the shared runners serve jobs of this project.
-
-### Attack vectors in runners
-
-Mentioned briefly earlier, but the following things of runners can be exploited.
-We're always looking for contributions that can mitigate these
-[Security Considerations](https://docs.gitlab.com/runner/security/).
-
-### Reset the runner registration token for a project
-
-If you think that a registration token for a project was revealed, you should
-reset it. A token can be used to register another runner for the project. That new runner
-may then be used to obtain the values of secret variables or to clone project code.
-
-To reset the token:
-
-1. Go to the project's **Settings > CI/CD**.
-1. Expand the **General pipelines settings** section.
-1. Find the **Runner token** form field and click the **Reveal value** button.
-1. Delete the value and save the form.
-1. After the page is refreshed, expand the **Runners settings** section
-   and check the registration token - it should be changed.
-
-From now on the old token is no longer valid and does not register
-any new runners to the project. If you are using any tools to provision and
-register new runners, the tokens used in those tools should be updated to reflect the
-value of the new token.
-
-## Determine the IP address of a runner
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17286) in GitLab 10.6.
-
-It may be useful to know the IP address of a runner so you can troubleshoot
-issues with that runner. GitLab stores and displays the IP address by viewing
-the source of the HTTP requests it makes to GitLab when polling for jobs. The
-IP address is always kept up to date so if the runner IP changes it
-automatically updates in GitLab.
-
-The IP address for shared runners and specific runners can be found in
-different places.
-
-### Determine the IP address of a shared runner
-
-To view the IP address of a shared runner you must have admin access to
-the GitLab instance. To determine this:
-
-1. Visit **Admin Area > Overview > Runners**.
-1. Look for the runner in the table and you should see a column for **IP Address**.
-
-![shared runner IP address](img/shared_runner_ip_address.png)
-
-### Determine the IP address of a specific runner
-
-To can find the IP address of a runner for a specific project,
-you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the
-project.
-
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. On the details page you should see a row for **IP Address**.
-
-![specific runner IP address](img/specific_runner_ip_address.png)
-
-## Use tags to limit the number of jobs using the runner
-
-You must set up a runner to be able to run all the different types of jobs
-that it may encounter on the projects it's shared over. This would be
-problematic for large amounts of projects, if it weren't for tags.
-
-GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with runners.
-Git tags are associated with commits.
-
-By tagging a runner for the types of jobs it can handle, you can make sure
-shared runners will [only run the jobs they are equipped to run](../yaml/README.md#tags).
-
-For instance, at GitLab we have runners tagged with `rails` if they contain
-the appropriate dependencies to run Rails test suites.
-
-When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
-[tagged jobs](../yaml/README.md#tags).
-To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
-
-To make a runner pick untagged jobs:
-
-1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
-1. Find the runner you want to pick untagged jobs and make sure it's enabled.
-1. Click the pencil button.
-1. Check the **Run untagged jobs** option.
-1. Click the **Save changes** button for the changes to take effect.
-
-NOTE:
-The runner tags list can not be empty when it's not allowed to pick untagged jobs.
-
-Below are some example scenarios of different variations.
-
-### runner runs only tagged jobs
-
-The following examples illustrate the potential impact of the runner being set
-to run only tagged jobs.
-
-Example 1:
-
-1. The runner is configured to run only tagged jobs and has the `docker` tag.
-1. A job that has a `hello` tag is executed and stuck.
-
-Example 2:
-
-1. The runner is configured to run only tagged jobs and has the `docker` tag.
-1. A job that has a `docker` tag is executed and run.
-
-Example 3:
-
-1. The runner is configured to run only tagged jobs and has the `docker` tag.
-1. A job that has no tags defined is executed and stuck.
-
-### runner is allowed to run untagged jobs
-
-The following examples illustrate the potential impact of the runner being set
-to run tagged and untagged jobs.
-
-Example 1:
-
-1. The runner is configured to run untagged jobs and has the `docker` tag.
-1. A job that has no tags defined is executed and run.
-1. A second job that has a `docker` tag defined is executed and run.
-
-Example 2:
-
-1. The runner is configured to run untagged jobs and has no tags defined.
-1. A job that has no tags defined is executed and run.
-1. A second job that has a `docker` tag defined is stuck.
-
-## Configure runner behavior with variables
-
-You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior
-globally or for individual jobs:
-
-- [`GIT_STRATEGY`](#git-strategy)
-- [`GIT_SUBMODULE_STRATEGY`](#git-submodule-strategy)
-- [`GIT_CHECKOUT`](#git-checkout)
-- [`GIT_CLEAN_FLAGS`](#git-clean-flags)
-- [`GIT_FETCH_EXTRA_FLAGS`](#git-fetch-extra-flags)
-- [`GIT_DEPTH`](#shallow-cloning) (shallow cloning)
-- [`GIT_CLONE_PATH`](#custom-build-directories) (custom build directories)
-
-You can also use variables to configure how many times a runner
-[attempts certain stages of job execution](#job-stages-attempts).
-
-### Git strategy
-
-> - Introduced in GitLab 8.9 as an experimental feature.
-> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
-
-You can set the `GIT_STRATEGY` used to fetch the repository content, either
-globally or per-job in the [`variables`](../yaml/README.md#variables) section:
-
-```yaml
-variables:
-  GIT_STRATEGY: clone
-```
-
-There are three possible values: `clone`, `fetch`, and `none`. If left unspecified,
-jobs use the [project's pipeline setting](../pipelines/settings.md#git-strategy).
-
-`clone` is the slowest option. It clones the repository from scratch for every
-job, ensuring that the local working copy is always pristine.
-If an existing worktree is found, it is removed before cloning.
-
-`fetch` is faster as it re-uses the local working copy (falling back to `clone`
-if it does not exist). `git clean` is used to undo any changes made by the last
-job, and `git fetch` is used to retrieve commits made after the last job ran.
-
-However, `fetch` does require access to the previous worktree. This works
-well when using the `shell` or `docker` executor because these
-try to preserve worktrees and try to re-use them by default.
-
-This has limitations when using the [Docker Machine executor](https://docs.gitlab.com/runner/executors/docker_machine.html).
-
-It does not work for [the `kubernetes` executor](https://docs.gitlab.com/runner/executors/kubernetes.html),
-but a [feature proposal](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847) exists.
-The `kubernetes` executor always clones into an temporary directory.
-
-A Git strategy of `none` also re-uses the local working copy, but skips all Git
-operations normally done by GitLab. GitLab Runner pre-clone scripts are also skipped,
-if present. This strategy could mean you need to add `fetch` and `checkout` commands
-to [your `.gitlab-ci.yml` script](../yaml/README.md#script).
-
-It can be used for jobs that operate exclusively on artifacts, like a deployment job.
-Git repository data may be present, but it's likely out of date. You should only
-rely on files brought into the local working copy from cache or artifacts.
-
-### Git submodule strategy
-
-> Requires GitLab Runner v1.10+.
-
-The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git
-submodules are included when fetching the code before a build. You can set them
-globally or per-job in the [`variables`](../yaml/README.md#variables) section.
-
-There are three possible values: `none`, `normal`, and `recursive`:
-
-- `none` means that submodules are not included when fetching the project
-  code. This is the default, which matches the pre-v1.10 behavior.
-
-- `normal` means that only the top-level submodules are included. It's
-  equivalent to:
-
-  ```shell
-  git submodule sync
-  git submodule update --init
-  ```
-
-- `recursive` means that all submodules (including submodules of submodules)
-  are included. This feature needs Git v1.8.1 and later. When using a
-  GitLab Runner with an executor not based on Docker, make sure the Git version
-  meets that requirement. It's equivalent to:
-
-  ```shell
-  git submodule sync --recursive
-  git submodule update --init --recursive
-  ```
-
-For this feature to work correctly, the submodules must be configured
-(in `.gitmodules`) with either:
-
-- the HTTP(S) URL of a publicly-accessible repository, or
-- a relative path to another repository on the same GitLab server. See the
-  [Git submodules](../git_submodules.md) documentation.
-
-### Git checkout
-
-> Introduced in GitLab Runner 9.3.
-
-The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either
-`clone` or `fetch` to specify whether a `git checkout` should be run. If not
-specified, it defaults to true. You can set them globally or per-job in the
-[`variables`](../yaml/README.md#variables) section.
-
-If set to `false`, the runner:
-
-- when doing `fetch` - updates the repository and leaves the working copy on
-  the current revision,
-- when doing `clone` - clones the repository and leaves the working copy on the
-  default branch.
-
-If `GIT_CHECKOUT` is set to `true`, both `clone` and `fetch` work the same way.
-The runner checks out the working copy of a revision related
-to the CI pipeline:
-
-```yaml
-variables:
-  GIT_STRATEGY: clone
-  GIT_CHECKOUT: "false"
-script:
-  - git checkout -B master origin/master
-  - git merge $CI_COMMIT_SHA
+Settings that are not public are shown as `X`.
+
+**Google Cloud Platform**
+
+```toml
+concurrent = X
+check_interval = 1
+metrics_server = "X"
+sentry_dsn = "X"
+
+[[runners]]
+  name = "docker-auto-scale"
+  request_concurrency = X
+  url = "https://gitlab.com/"
+  token = "SHARED_RUNNER_TOKEN"
+  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
+  executor = "docker+machine"
+  environment = [
+    "DOCKER_DRIVER=overlay2",
+    "DOCKER_TLS_CERTDIR="
+  ]
+  limit = X
+  [runners.docker]
+    image = "ruby:2.5"
+    privileged = true
+    volumes = [
+      "/certs/client",
+      "/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
+    ]
+  [runners.machine]
+    IdleCount = 50
+    IdleTime = 3600
+    MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
+    MachineName = "srm-%s"
+    MachineDriver = "google"
+    MachineOptions = [
+      "google-project=PROJECT",
+      "google-disk-size=25",
+      "google-machine-type=n1-standard-1",
+      "google-username=core",
+      "google-tags=gitlab-com,srm",
+      "google-use-internal-ip",
+      "google-zone=us-east1-d",
+      "engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
+      "google-machine-image=PROJECT/global/images/IMAGE",
+      "engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
+      "engine-opt=fixed-cidr-v6=fc00::/7",
+      "google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
+    ]
+    [[runners.machine.autoscaling]]
+      Periods = ["* * * * * sat,sun *"]
+      Timezone = "UTC"
+      IdleCount = 70
+      IdleTime = 3600
+    [[runners.machine.autoscaling]]
+      Periods = ["* 30-59 3 * * * *", "* 0-30 4 * * * *"]
+      Timezone = "UTC"
+      IdleCount = 700
+      IdleTime = 3600
+  [runners.cache]
+    Type = "gcs"
+    Shared = true
+    [runners.cache.gcs]
+      CredentialsFile = "/path/to/file"
+      BucketName = "bucket-name"
 ```
 
-### Git clean flags
+### Windows shared runners (beta)
 
-> Introduced in GitLab Runner 11.10
+The Windows shared runners are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
+and shouldn't be used for production workloads.
 
-The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
-`git clean` after checking out the sources. You can set it globally or per-job in the
-[`variables`](../yaml/README.md#variables) section.
+During this beta period, the [shared runner pipeline quota](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
+applies for groups and projects in the same manner as Linux runners. This may
+change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
 
-`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
-command.
+Windows shared runners on GitLab.com autoscale by launching virtual machines on
+the Google Cloud Platform. This solution uses an
+[autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/tree/master/docs/readme.md)
+developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
+Windows shared runners execute your CI/CD jobs on `n1-standard-2` instances with
+2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
+the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md).
 
-`git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
+We want to keep iterating to get Windows shared runners in a stable state and
+[generally available](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga).
+You can follow our work towards this goal in the
+[related epic](https://gitlab.com/groups/gitlab-org/-/epics/2162).
 
-If `GIT_CLEAN_FLAGS` is:
+#### Configuration
 
-- Not specified, `git clean` flags default to `-ffdx`.
-- Given the value `none`, `git clean` is not executed.
-
-For example:
-
-```yaml
-variables:
-  GIT_CLEAN_FLAGS: -ffdx -e cache/
-script:
-  - ls -al cache/
-```
-
-### Git fetch extra flags
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
-
-The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of
-`git fetch`. You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
-
-`GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified.
-
-The default flags are:
-
-- [GIT_DEPTH](#shallow-cloning).
-- The list of [refspecs](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec).
-- A remote called `origin`.
-
-If `GIT_FETCH_EXTRA_FLAGS` is:
-
-- Not specified, `git fetch` flags default to `--prune --quiet` along with the default flags.
-- Given the value `none`, `git fetch` is executed only with the default flags.
-
-For example, the default flags are `--prune --quiet`, so you can make `git fetch` more verbose by overriding this with just `--prune`:
-
-```yaml
-variables:
-  GIT_FETCH_EXTRA_FLAGS: --prune
-script:
-  - ls -al cache/
-```
-
-The configuration above results in `git fetch` being called this way:
-
-```shell
-git fetch origin $REFSPECS --depth 50  --prune
-```
+The full contents of our `config.toml` are:
 
-Where `$REFSPECS` is a value provided to the runner internally by GitLab.
-
-### Shallow cloning
-
-> Introduced in GitLab 8.9 as an experimental feature.
-
-You can specify the depth of fetching and cloning using `GIT_DEPTH`.
-`GIT_DEPTH` does a shallow clone of the repository and can significantly speed up cloning.
-It can be helpful for repositories with a large number of commits or old, large binaries. The value is
-passed to `git fetch` and `git clone`.
-
-In GitLab 12.0 and later, newly-created projects automatically have a
-[default `git depth` value of `50`](../pipelines/settings.md#git-shallow-clone).
-
-If you use a depth of `1` and have a queue of jobs or retry
-jobs, jobs may fail.
-
-Git fetching and cloning is based on a ref, such as a branch name, so runners
-can't clone a specific commit SHA. If multiple jobs are in the queue, or
-you're retrying an old job, the commit to be tested must be within the
-Git history that is cloned. Setting too small a value for `GIT_DEPTH` can make
-it impossible to run these old commits and `unresolved reference` is displayed in
-job logs. You should then reconsider changing `GIT_DEPTH` to a higher value.
-
-Jobs that rely on `git describe` may not work correctly when `GIT_DEPTH` is
-set since only part of the Git history is present.
-
-To fetch or clone only the last 3 commits:
-
-```yaml
-variables:
-  GIT_DEPTH: "3"
+NOTE:
+Settings that aren't public are shown as `X`.
+
+```toml
+concurrent = X
+check_interval = 3
+
+[[runners]]
+  name = "windows-runner"
+  url = "https://gitlab.com/"
+  token = "TOKEN"
+  executor = "custom"
+  builds_dir = "C:\\GitLab-Runner\\builds"
+  cache_dir = "C:\\GitLab-Runner\\cache"
+  shell  = "powershell"
+  [runners.custom]
+    config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
+    prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
+    run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
+    cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
+    cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]
 ```
 
-You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
-
-### Custom build directories
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2211) in GitLab Runner 11.10.
-
-By default, GitLab Runner clones the repository in a unique subpath of the
-`$CI_BUILDS_DIR` directory. However, your project might require the code in a
-specific directory (Go projects, for example). In that case, you can specify
-the `GIT_CLONE_PATH` variable to tell the runner the directory to clone the
-repository in:
-
-```yaml
-variables:
-  GIT_CLONE_PATH: $CI_BUILDS_DIR/project-name
-
-test:
-  script:
-    - pwd
+The full contents of our `autoscaler/config.toml` are:
+
+```toml
+Provider = "gcp"
+Executor = "winrm"
+OS = "windows"
+LogLevel = "info"
+LogFormat = "text"
+LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
+VMTag = "windows"
+
+[GCP]
+  ServiceAccountFile = "PATH"
+  Project = "some-project-df9323"
+  Zone = "us-east1-c"
+  MachineType = "n1-standard-2"
+  Image = "IMAGE"
+  DiskSize = 50
+  DiskType = "pd-standard"
+  Subnetwork = "default"
+  Network = "default"
+  Tags = ["TAGS"]
+  Username = "gitlab_runner"
+
+[WinRM]
+  MaximumTimeout = 3600
+  ExecutionMaxRetries = 0
+
+[ProviderCache]
+  Enabled = true
+  Directory = "C:\\GitLab-Runner\\autoscaler\\machines"
 ```
 
-The `GIT_CLONE_PATH` has to always be within `$CI_BUILDS_DIR`. The directory set in `$CI_BUILDS_DIR`
-is dependent on executor and configuration of [runners.builds_dir](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
-setting.
-
-This can only be used when `custom_build_dir` is enabled in the
-[runner's configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscustom_build_dir-section).
-This is the default configuration for the `docker` and `kubernetes` executors.
-
-#### Handling concurrency
-
-An executor that uses a concurrency greater than `1` might lead
-to failures. Multiple jobs might be working on the same directory if the `builds_dir`
-is shared between jobs.
-
-The runner does not try to prevent this situation. It's up to the administrator
-and developers to comply with the requirements of runner configuration.
-
-To avoid this scenario, you can use a unique path within `$CI_BUILDS_DIR`, because runner
-exposes two additional variables that provide a unique `ID` of concurrency:
+#### Example
 
-- `$CI_CONCURRENT_ID`: Unique ID for all jobs running within the given executor.
-- `$CI_CONCURRENT_PROJECT_ID`: Unique ID for all jobs running within the given executor and project.
-
-The most stable configuration that should work well in any scenario and on any executor
-is to use `$CI_CONCURRENT_ID` in the `GIT_CLONE_PATH`. For example:
+Below is a simple `.gitlab-ci.yml` file to show how to start using the
+Windows shared runners:
 
 ```yaml
-variables:
-  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-name
-
-test:
+.shared_windows_runners:
+  tags:
+    - shared-windows
+    - windows
+    - windows-1809
+
+stages:
+  - build
+  - test
+
+before_script:
+ - Set-Variable -Name "time" -Value (date -Format "%H:%m")
+ - echo ${time}
+ - echo "started by ${GITLAB_USER_NAME}"
+
+build:
+  extends:
+    - .shared_windows_runners
+  stage: build
   script:
-    - pwd
-```
-
-The `$CI_CONCURRENT_PROJECT_ID` should be used in conjunction with `$CI_PROJECT_PATH`
-as the `$CI_PROJECT_PATH` provides a path of a repository. That is, `group/subgroup/project`. For example:
-
-```yaml
-variables:
-  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATH
+    - echo "running scripts in the build job"
 
 test:
+  extends:
+    - .shared_windows_runners
+  stage: test
   script:
-    - pwd
-```
-
-#### Nested paths
-
-The value of `GIT_CLONE_PATH` is expanded once and nesting variables
-within is not supported.
-
-For example, you define both the variables below in your
-`.gitlab-ci.yml` file:
-
-```yaml
-variables:
-  GOPATH: $CI_BUILDS_DIR/go
-  GIT_CLONE_PATH: $GOPATH/src/namespace/project
-```
-
-The value of `GIT_CLONE_PATH` is expanded once into
-`$CI_BUILDS_DIR/go/src/namespace/project`, and results in failure
-because `$CI_BUILDS_DIR` is not expanded.
-
-### Job stages attempts
-
-> Introduced in GitLab, it requires GitLab Runner v1.9+.
-
-You can set the number of attempts that the running job tries to execute
-the following stages:
-
-| Variable                        | Description                                            |
-|---------------------------------|--------------------------------------------------------|
-| `ARTIFACT_DOWNLOAD_ATTEMPTS`    | Number of attempts to download artifacts running a job |
-| `EXECUTOR_JOB_SECTION_ATTEMPTS` | [In GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) and later, the number of attempts to run a section in a job after a [`No Such Container`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) error ([Docker executor](https://docs.gitlab.com/runner/executors/docker.html) only). |
-| `GET_SOURCES_ATTEMPTS`          | Number of attempts to fetch sources running a job      |
-| `RESTORE_CACHE_ATTEMPTS`        | Number of attempts to restore the cache running a job  |
-
-The default is one single attempt.
-
-Example:
-
-```yaml
-variables:
-  GET_SOURCES_ATTEMPTS: 3
-```
-
-You can set them globally or per-job in the [`variables`](../yaml/README.md#variables) section.
-
-## System calls not available on GitLab.com shared runners
-
-GitLab.com shared runners run on CoreOS. This means that you cannot use some system calls, like `getlogin`, from the C standard library.
-
-## Artifact and cache settings
-
-> Introduced in GitLab Runner 13.9.
-
-Artifact and cache settings control the compression ratio of artifacts and caches.
-Use these settings to specify the size of the archive produced by a job.
-
-- On a slow network, uploads might be faster for smaller archives.
-- On a fast network where bandwidth and storage are not a concern, uploads might be faster using the fastest compression ratio, despite the archive produced being larger.
-
-For [GitLab Pages](../../user/project/pages/index.md) to serve
-[HTTP Range requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests), artifacts
-should use the `ARTIFACT_COMPRESSION_LEVEL: fastest` setting, as only uncompressed zip archives
-support this feature.
-
-A meter can also be enabled to provide the rate of transfer for uploads and downloads.
-
-```yaml
-variables:
-  # output upload and download progress every 2 seconds
-  TRANSFER_METER_FREQUENCY: "2s"
-
-  # Use fast compression for artifacts, resulting in larger archives
-  ARTIFACT_COMPRESSION_LEVEL: "fast"
-
-  # Use no compression for caches
-  CACHE_COMPRESSION_LEVEL: "fastest"
+    - echo "running scripts in the test job"
 ```
 
-| Variable                        | Description                                            |
-|---------------------------------|--------------------------------------------------------|
-| `TRANSFER_METER_FREQUENCY`      | Specify how often to print the meter's transfer rate. It can be set to a duration (for example, `1s` or `1m30s`). A duration of `0` disables the meter (default). When a value is set, the pipeline shows a progress meter for artifact and cache uploads and downloads. |
-| `ARTIFACT_COMPRESSION_LEVEL`    | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
-| `CACHE_COMPRESSION_LEVEL`       | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
+#### Limitations and known issues
+
+- All the limitations mentioned in our [beta
+  definition](https://about.gitlab.com/handbook/product/#beta).
+- The average provisioning time for a new Windows VM is 5 minutes.
+  This means that you may notice slower build start times
+  on the Windows shared runner fleet during the beta. In a future
+  release we intend to update the autoscaler to enable
+  the pre-provisioning of virtual machines. This is intended to significantly reduce
+  the time it takes to provision a VM on the Windows fleet. You can
+  follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
+- The Windows shared runner fleet may be unavailable occasionally
+  for maintenance or updates.
+- The Windows shared runner virtual machine instances do not use the
+  GitLab Docker executor. This means that you can't specify
+  [`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
+  your pipeline configuration.
+- For the beta release, we have included a set of software packages in
+  the base VM image. If your CI job requires additional software that's
+  not included in this list, then you must add installation
+  commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
+  software. Note that each job runs on a new VM instance, so the
+  installation of additional software packages needs to be repeated for
+  each job in your pipeline.
+- The job may stay in a pending state for longer than the
+  Linux shared runners.
+- There is the possibility that we introduce breaking changes which will
+  require updates to pipelines that are using the Windows shared runner
+  fleet.
diff --git a/doc/ci/runners/configure_runners.md b/doc/ci/runners/configure_runners.md
new file mode 100644
index 00000000000..f0fd4aba8b8
--- /dev/null
+++ b/doc/ci/runners/configure_runners.md
@@ -0,0 +1,600 @@
+---
+stage: Verify
+group: Runner
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+type: reference
+---
+
+# Configuring runners
+
+If you have installed your own runners, you can configure and secure them in GitLab.
+
+If you need to configure runners on the machine where you installed GitLab Runner, see
+[the GitLab Runner documentation](https://docs.gitlab.com/runner/configuration).
+
+## Manually clear the runner cache
+
+Read [clearing the cache](../caching/index.md#clearing-the-cache).
+
+## Set maximum job timeout for a runner
+
+For each runner, you can specify a *maximum job timeout*. This timeout,
+if smaller than the [project defined timeout](../pipelines/settings.md#timeout), takes precedence.
+
+This feature can be used to prevent your shared runner from being overwhelmed
+by a project that has jobs with a long timeout (for example, one week).
+
+When not configured, runners do not override the project timeout.
+
+On GitLab.com, you cannot override the job timeout for shared runners and must use the [project defined timeout](../pipelines/settings.md#timeout).
+
+To set the maximum job timeout:
+
+1. In a project, go to **Settings > CI/CD > Runners**.
+1. Select your specific runner to edit the settings.
+1. Enter a value under **Maximum job timeout**.
+1. Select **Save changes**.
+
+How this feature works:
+
+**Example 1 - Runner timeout bigger than project timeout**
+
+1. You set the _maximum job timeout_ for a runner to 24 hours
+1. You set the _CI/CD Timeout_ for a project to **2 hours**
+1. You start a job
+1. The job, if running longer, times out after **2 hours**
+
+**Example 2 - Runner timeout not configured**
+
+1. You remove the _maximum job timeout_ configuration from a runner
+1. You set the _CI/CD Timeout_ for a project to **2 hours**
+1. You start a job
+1. The job, if running longer, times out after **2 hours**
+
+**Example 3 - Runner timeout smaller than project timeout**
+
+1. You set the _maximum job timeout_ for a runner to **30 minutes**
+1. You set the _CI/CD Timeout_ for a project to 2 hours
+1. You start a job
+1. The job, if running longer, times out after **30 minutes**
+
+## Be careful with sensitive information
+
+With some [runner executors](https://docs.gitlab.com/runner/executors/README.html),
+if you can run a job on the runner, you can get full access to the file system,
+and thus any code it runs as well as the token of the runner. With shared runners, this means that anyone
+that runs jobs on the runner, can access anyone else's code that runs on the
+runner.
+
+In addition, because you can get access to the runner token, it is possible
+to create a clone of a runner and submit false jobs, for example.
+
+The above is easily avoided by restricting the usage of shared runners
+on large public GitLab instances, controlling access to your GitLab instance,
+and using more secure [runner executors](https://docs.gitlab.com/runner/executors/README.html).
+
+### Prevent runners from revealing sensitive information
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/13194) in GitLab 10.0.
+
+You can protect runners so they don't reveal sensitive information.
+When a runner is protected, the runner picks jobs created on
+[protected branches](../../user/project/protected_branches.md) or [protected tags](../../user/project/protected_tags.md) only,
+and ignores other jobs.
+
+To protect or unprotect a runner:
+
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. Find the runner you want to protect or unprotect. Make sure it's enabled.
+1. Click the pencil button.
+1. Check the **Protected** option.
+1. Click **Save changes**.
+
+![specific runners edit icon](img/protected_runners_check_box.png)
+
+### Forks
+
+Whenever a project is forked, it copies the settings of the jobs that relate
+to it. This means that if you have shared runners set up for a project and
+someone forks that project, the shared runners serve jobs of this project.
+
+### Attack vectors in runners
+
+Mentioned briefly earlier, but the following things of runners can be exploited.
+We're always looking for contributions that can mitigate these
+[Security Considerations](https://docs.gitlab.com/runner/security/).
+
+### Reset the runner registration token for a project
+
+If you think that a registration token for a project was revealed, you should
+reset it. A token can be used to register another runner for the project. That new runner
+may then be used to obtain the values of secret variables or to clone project code.
+
+To reset the token:
+
+1. Go to the project's **Settings > CI/CD**.
+1. Expand the **General pipelines settings** section.
+1. Find the **Runner token** form field and click the **Reveal value** button.
+1. Delete the value and save the form.
+1. After the page is refreshed, expand the **Runners settings** section
+   and check the registration token - it should be changed.
+
+From now on the old token is no longer valid and does not register
+any new runners to the project. If you are using any tools to provision and
+register new runners, the tokens used in those tools should be updated to reflect the
+value of the new token.
+
+## Determine the IP address of a runner
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/17286) in GitLab 10.6.
+
+It may be useful to know the IP address of a runner so you can troubleshoot
+issues with that runner. GitLab stores and displays the IP address by viewing
+the source of the HTTP requests it makes to GitLab when polling for jobs. The
+IP address is always kept up to date so if the runner IP changes it
+automatically updates in GitLab.
+
+The IP address for shared runners and specific runners can be found in
+different places.
+
+### Determine the IP address of a shared runner
+
+To view the IP address of a shared runner you must have admin access to
+the GitLab instance. To determine this:
+
+1. Visit **Admin Area > Overview > Runners**.
+1. Look for the runner in the table and you should see a column for **IP Address**.
+
+![shared runner IP address](img/shared_runner_ip_address.png)
+
+### Determine the IP address of a specific runner
+
+To can find the IP address of a runner for a specific project,
+you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the
+project.
+
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. On the details page you should see a row for **IP Address**.
+
+![specific runner IP address](img/specific_runner_ip_address.png)
+
+## Use tags to limit the number of jobs using the runner
+
+You must set up a runner to be able to run all the different types of jobs
+that it may encounter on the projects it's shared over. This would be
+problematic for large amounts of projects, if it weren't for tags.
+
+GitLab CI tags are not the same as Git tags. GitLab CI tags are associated with runners.
+Git tags are associated with commits.
+
+By tagging a runner for the types of jobs it can handle, you can make sure
+shared runners will [only run the jobs they are equipped to run](../yaml/README.md#tags).
+
+For instance, at GitLab we have runners tagged with `rails` if they contain
+the appropriate dependencies to run Rails test suites.
+
+When you [register a runner](https://docs.gitlab.com/runner/register/), its default behavior is to **only pick**
+[tagged jobs](../yaml/README.md#tags).
+To change this, you must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
+
+To make a runner pick untagged jobs:
+
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. Find the runner you want to pick untagged jobs and make sure it's enabled.
+1. Click the pencil button.
+1. Check the **Run untagged jobs** option.
+1. Click the **Save changes** button for the changes to take effect.
+
+NOTE:
+The runner tags list can not be empty when it's not allowed to pick untagged jobs.
+
+Below are some example scenarios of different variations.
+
+### runner runs only tagged jobs
+
+The following examples illustrate the potential impact of the runner being set
+to run only tagged jobs.
+
+Example 1:
+
+1. The runner is configured to run only tagged jobs and has the `docker` tag.
+1. A job that has a `hello` tag is executed and stuck.
+
+Example 2:
+
+1. The runner is configured to run only tagged jobs and has the `docker` tag.
+1. A job that has a `docker` tag is executed and run.
+
+Example 3:
+
+1. The runner is configured to run only tagged jobs and has the `docker` tag.
+1. A job that has no tags defined is executed and stuck.
+
+### runner is allowed to run untagged jobs
+
+The following examples illustrate the potential impact of the runner being set
+to run tagged and untagged jobs.
+
+Example 1:
+
+1. The runner is configured to run untagged jobs and has the `docker` tag.
+1. A job that has no tags defined is executed and run.
+1. A second job that has a `docker` tag defined is executed and run.
+
+Example 2:
+
+1. The runner is configured to run untagged jobs and has no tags defined.
+1. A job that has no tags defined is executed and run.
+1. A second job that has a `docker` tag defined is stuck.
+
+## Configure runner behavior with variables
+
+You can use [CI/CD variables](../variables/README.md) to configure runner Git behavior
+globally or for individual jobs:
+
+- [`GIT_STRATEGY`](#git-strategy)
+- [`GIT_SUBMODULE_STRATEGY`](#git-submodule-strategy)
+- [`GIT_CHECKOUT`](#git-checkout)
+- [`GIT_CLEAN_FLAGS`](#git-clean-flags)
+- [`GIT_FETCH_EXTRA_FLAGS`](#git-fetch-extra-flags)
+- [`GIT_DEPTH`](#shallow-cloning) (shallow cloning)
+- [`GIT_CLONE_PATH`](#custom-build-directories) (custom build directories)
+
+You can also use variables to configure how many times a runner
+[attempts certain stages of job execution](#job-stages-attempts).
+
+### Git strategy
+
+> - Introduced in GitLab 8.9 as an experimental feature.
+> - `GIT_STRATEGY=none` requires GitLab Runner v1.7+.
+
+You can set the `GIT_STRATEGY` used to fetch the repository content, either
+globally or per-job in the [`variables`](../yaml/README.md#variables) section:
+
+```yaml
+variables:
+  GIT_STRATEGY: clone
+```
+
+There are three possible values: `clone`, `fetch`, and `none`. If left unspecified,
+jobs use the [project's pipeline setting](../pipelines/settings.md#git-strategy).
+
+`clone` is the slowest option. It clones the repository from scratch for every
+job, ensuring that the local working copy is always pristine.
+If an existing worktree is found, it is removed before cloning.
+
+`fetch` is faster as it re-uses the local working copy (falling back to `clone`
+if it does not exist). `git clean` is used to undo any changes made by the last
+job, and `git fetch` is used to retrieve commits made after the last job ran.
+
+However, `fetch` does require access to the previous worktree. This works
+well when using the `shell` or `docker` executor because these
+try to preserve worktrees and try to re-use them by default.
+
+This has limitations when using the [Docker Machine executor](https://docs.gitlab.com/runner/executors/docker_machine.html).
+
+It does not work for [the `kubernetes` executor](https://docs.gitlab.com/runner/executors/kubernetes.html),
+but a [feature proposal](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3847) exists.
+The `kubernetes` executor always clones into an temporary directory.
+
+A Git strategy of `none` also re-uses the local working copy, but skips all Git
+operations normally done by GitLab. GitLab Runner pre-clone scripts are also skipped,
+if present. This strategy could mean you need to add `fetch` and `checkout` commands
+to [your `.gitlab-ci.yml` script](../yaml/README.md#script).
+
+It can be used for jobs that operate exclusively on artifacts, like a deployment job.
+Git repository data may be present, but it's likely out of date. You should only
+rely on files brought into the local working copy from cache or artifacts.
+
+### Git submodule strategy
+
+> Requires GitLab Runner v1.10+.
+
+The `GIT_SUBMODULE_STRATEGY` variable is used to control if / how Git
+submodules are included when fetching the code before a build. You can set them
+globally or per-job in the [`variables`](../yaml/README.md#variables) section.
+
+There are three possible values: `none`, `normal`, and `recursive`:
+
+- `none` means that submodules are not included when fetching the project
+  code. This is the default, which matches the pre-v1.10 behavior.
+
+- `normal` means that only the top-level submodules are included. It's
+  equivalent to:
+
+  ```shell
+  git submodule sync
+  git submodule update --init
+  ```
+
+- `recursive` means that all submodules (including submodules of submodules)
+  are included. This feature needs Git v1.8.1 and later. When using a
+  GitLab Runner with an executor not based on Docker, make sure the Git version
+  meets that requirement. It's equivalent to:
+
+  ```shell
+  git submodule sync --recursive
+  git submodule update --init --recursive
+  ```
+
+For this feature to work correctly, the submodules must be configured
+(in `.gitmodules`) with either:
+
+- the HTTP(S) URL of a publicly-accessible repository, or
+- a relative path to another repository on the same GitLab server. See the
+  [Git submodules](../git_submodules.md) documentation.
+
+### Git checkout
+
+> Introduced in GitLab Runner 9.3.
+
+The `GIT_CHECKOUT` variable can be used when the `GIT_STRATEGY` is set to either
+`clone` or `fetch` to specify whether a `git checkout` should be run. If not
+specified, it defaults to true. You can set them globally or per-job in the
+[`variables`](../yaml/README.md#variables) section.
+
+If set to `false`, the runner:
+
+- when doing `fetch` - updates the repository and leaves the working copy on
+  the current revision,
+- when doing `clone` - clones the repository and leaves the working copy on the
+  default branch.
+
+If `GIT_CHECKOUT` is set to `true`, both `clone` and `fetch` work the same way.
+The runner checks out the working copy of a revision related
+to the CI pipeline:
+
+```yaml
+variables:
+  GIT_STRATEGY: clone
+  GIT_CHECKOUT: "false"
+script:
+  - git checkout -B master origin/master
+  - git merge $CI_COMMIT_SHA
+```
+
+### Git clean flags
+
+> Introduced in GitLab Runner 11.10
+
+The `GIT_CLEAN_FLAGS` variable is used to control the default behavior of
+`git clean` after checking out the sources. You can set it globally or per-job in the
+[`variables`](../yaml/README.md#variables) section.
+
+`GIT_CLEAN_FLAGS` accepts all possible options of the [`git clean`](https://git-scm.com/docs/git-clean)
+command.
+
+`git clean` is disabled if `GIT_CHECKOUT: "false"` is specified.
+
+If `GIT_CLEAN_FLAGS` is:
+
+- Not specified, `git clean` flags default to `-ffdx`.
+- Given the value `none`, `git clean` is not executed.
+
+For example:
+
+```yaml
+variables:
+  GIT_CLEAN_FLAGS: -ffdx -e cache/
+script:
+  - ls -al cache/
+```
+
+### Git fetch extra flags
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4142) in GitLab Runner 13.1.
+
+The `GIT_FETCH_EXTRA_FLAGS` variable is used to control the behavior of
+`git fetch`. You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
+
+`GIT_FETCH_EXTRA_FLAGS` accepts all options of the [`git fetch`](https://git-scm.com/docs/git-fetch) command. However, `GIT_FETCH_EXTRA_FLAGS` flags are appended after the default flags that can't be modified.
+
+The default flags are:
+
+- [GIT_DEPTH](#shallow-cloning).
+- The list of [refspecs](https://git-scm.com/book/en/v2/Git-Internals-The-Refspec).
+- A remote called `origin`.
+
+If `GIT_FETCH_EXTRA_FLAGS` is:
+
+- Not specified, `git fetch` flags default to `--prune --quiet` along with the default flags.
+- Given the value `none`, `git fetch` is executed only with the default flags.
+
+For example, the default flags are `--prune --quiet`, so you can make `git fetch` more verbose by overriding this with just `--prune`:
+
+```yaml
+variables:
+  GIT_FETCH_EXTRA_FLAGS: --prune
+script:
+  - ls -al cache/
+```
+
+The configuration above results in `git fetch` being called this way:
+
+```shell
+git fetch origin $REFSPECS --depth 50  --prune
+```
+
+Where `$REFSPECS` is a value provided to the runner internally by GitLab.
+
+### Shallow cloning
+
+> Introduced in GitLab 8.9 as an experimental feature.
+
+You can specify the depth of fetching and cloning using `GIT_DEPTH`.
+`GIT_DEPTH` does a shallow clone of the repository and can significantly speed up cloning.
+It can be helpful for repositories with a large number of commits or old, large binaries. The value is
+passed to `git fetch` and `git clone`.
+
+In GitLab 12.0 and later, newly-created projects automatically have a
+[default `git depth` value of `50`](../pipelines/settings.md#git-shallow-clone).
+
+If you use a depth of `1` and have a queue of jobs or retry
+jobs, jobs may fail.
+
+Git fetching and cloning is based on a ref, such as a branch name, so runners
+can't clone a specific commit SHA. If multiple jobs are in the queue, or
+you're retrying an old job, the commit to be tested must be within the
+Git history that is cloned. Setting too small a value for `GIT_DEPTH` can make
+it impossible to run these old commits and `unresolved reference` is displayed in
+job logs. You should then reconsider changing `GIT_DEPTH` to a higher value.
+
+Jobs that rely on `git describe` may not work correctly when `GIT_DEPTH` is
+set since only part of the Git history is present.
+
+To fetch or clone only the last 3 commits:
+
+```yaml
+variables:
+  GIT_DEPTH: "3"
+```
+
+You can set it globally or per-job in the [`variables`](../yaml/README.md#variables) section.
+
+### Custom build directories
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2211) in GitLab Runner 11.10.
+
+By default, GitLab Runner clones the repository in a unique subpath of the
+`$CI_BUILDS_DIR` directory. However, your project might require the code in a
+specific directory (Go projects, for example). In that case, you can specify
+the `GIT_CLONE_PATH` variable to tell the runner the directory to clone the
+repository in:
+
+```yaml
+variables:
+  GIT_CLONE_PATH: $CI_BUILDS_DIR/project-name
+
+test:
+  script:
+    - pwd
+```
+
+The `GIT_CLONE_PATH` has to always be within `$CI_BUILDS_DIR`. The directory set in `$CI_BUILDS_DIR`
+is dependent on executor and configuration of [runners.builds_dir](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
+setting.
+
+This can only be used when `custom_build_dir` is enabled in the
+[runner's configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscustom_build_dir-section).
+This is the default configuration for the `docker` and `kubernetes` executors.
+
+#### Handling concurrency
+
+An executor that uses a concurrency greater than `1` might lead
+to failures. Multiple jobs might be working on the same directory if the `builds_dir`
+is shared between jobs.
+
+The runner does not try to prevent this situation. It's up to the administrator
+and developers to comply with the requirements of runner configuration.
+
+To avoid this scenario, you can use a unique path within `$CI_BUILDS_DIR`, because runner
+exposes two additional variables that provide a unique `ID` of concurrency:
+
+- `$CI_CONCURRENT_ID`: Unique ID for all jobs running within the given executor.
+- `$CI_CONCURRENT_PROJECT_ID`: Unique ID for all jobs running within the given executor and project.
+
+The most stable configuration that should work well in any scenario and on any executor
+is to use `$CI_CONCURRENT_ID` in the `GIT_CLONE_PATH`. For example:
+
+```yaml
+variables:
+  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-name
+
+test:
+  script:
+    - pwd
+```
+
+The `$CI_CONCURRENT_PROJECT_ID` should be used in conjunction with `$CI_PROJECT_PATH`
+as the `$CI_PROJECT_PATH` provides a path of a repository. That is, `group/subgroup/project`. For example:
+
+```yaml
+variables:
+  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATH
+
+test:
+  script:
+    - pwd
+```
+
+#### Nested paths
+
+The value of `GIT_CLONE_PATH` is expanded once and nesting variables
+within is not supported.
+
+For example, you define both the variables below in your
+`.gitlab-ci.yml` file:
+
+```yaml
+variables:
+  GOPATH: $CI_BUILDS_DIR/go
+  GIT_CLONE_PATH: $GOPATH/src/namespace/project
+```
+
+The value of `GIT_CLONE_PATH` is expanded once into
+`$CI_BUILDS_DIR/go/src/namespace/project`, and results in failure
+because `$CI_BUILDS_DIR` is not expanded.
+
+### Job stages attempts
+
+> Introduced in GitLab, it requires GitLab Runner v1.9+.
+
+You can set the number of attempts that the running job tries to execute
+the following stages:
+
+| Variable                        | Description                                            |
+|---------------------------------|--------------------------------------------------------|
+| `ARTIFACT_DOWNLOAD_ATTEMPTS`    | Number of attempts to download artifacts running a job |
+| `EXECUTOR_JOB_SECTION_ATTEMPTS` | [In GitLab 12.10](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) and later, the number of attempts to run a section in a job after a [`No Such Container`](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4450) error ([Docker executor](https://docs.gitlab.com/runner/executors/docker.html) only). |
+| `GET_SOURCES_ATTEMPTS`          | Number of attempts to fetch sources running a job      |
+| `RESTORE_CACHE_ATTEMPTS`        | Number of attempts to restore the cache running a job  |
+
+The default is one single attempt.
+
+Example:
+
+```yaml
+variables:
+  GET_SOURCES_ATTEMPTS: 3
+```
+
+You can set them globally or per-job in the [`variables`](../yaml/README.md#variables) section.
+
+## System calls not available on GitLab.com shared runners
+
+GitLab.com shared runners run on CoreOS. This means that you cannot use some system calls, like `getlogin`, from the C standard library.
+
+## Artifact and cache settings
+
+> Introduced in GitLab Runner 13.9.
+
+Artifact and cache settings control the compression ratio of artifacts and caches.
+Use these settings to specify the size of the archive produced by a job.
+
+- On a slow network, uploads might be faster for smaller archives.
+- On a fast network where bandwidth and storage are not a concern, uploads might be faster using the fastest compression ratio, despite the archive produced being larger.
+
+For [GitLab Pages](../../user/project/pages/index.md) to serve
+[HTTP Range requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Range_requests), artifacts
+should use the `ARTIFACT_COMPRESSION_LEVEL: fastest` setting, as only uncompressed zip archives
+support this feature.
+
+A meter can also be enabled to provide the rate of transfer for uploads and downloads.
+
+```yaml
+variables:
+  # output upload and download progress every 2 seconds
+  TRANSFER_METER_FREQUENCY: "2s"
+
+  # Use fast compression for artifacts, resulting in larger archives
+  ARTIFACT_COMPRESSION_LEVEL: "fast"
+
+  # Use no compression for caches
+  CACHE_COMPRESSION_LEVEL: "fastest"
+```
+
+| Variable                        | Description                                            |
+|---------------------------------|--------------------------------------------------------|
+| `TRANSFER_METER_FREQUENCY`      | Specify how often to print the meter's transfer rate. It can be set to a duration (for example, `1s` or `1m30s`). A duration of `0` disables the meter (default). When a value is set, the pipeline shows a progress meter for artifact and cache uploads and downloads. |
+| `ARTIFACT_COMPRESSION_LEVEL`    | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
+| `CACHE_COMPRESSION_LEVEL`       | To adjust compression ratio, set to `fastest`, `fast`, `default`, `slow`, or `slowest`. This setting works with the Fastzip archiver only, so the GitLab Runner feature flag [`FF_USE_FASTZIP`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) must also be enabled. |
diff --git a/doc/ci/runners/runners_scope.md b/doc/ci/runners/runners_scope.md
new file mode 100644
index 00000000000..fa56be3a151
--- /dev/null
+++ b/doc/ci/runners/runners_scope.md
@@ -0,0 +1,251 @@
+---
+stage: Verify
+group: Runner
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+type: reference
+---
+
+# The scope of runners
+
+Runners are available based on who you want to have access:
+
+- [Shared runners](#shared-runners) are available to all groups and projects in a GitLab instance.
+- [Group runners](#group-runners) are available to all projects and subgroups in a group.
+- [Specific runners](#specific-runners) are associated with specific projects.
+  Typically, specific runners are used for one project at a time.
+
+## Shared runners
+
+*Shared runners* are available to every project in a GitLab instance.
+
+Use shared runners when you have multiple jobs with similar requirements. Rather than
+having multiple runners idling for many projects, you can have a few runners that handle
+multiple projects.
+
+If you are using a self-managed instance of GitLab:
+
+- Your administrator can install and register shared runners by
+  going to your project's **Settings > CI/CD**, expanding the **Runners** section,
+  and clicking **Show runner installation instructions**.
+  These instructions are also available [in the documentation](https://docs.gitlab.com/runner/install/index.html).
+- The administrator can also configure a maximum number of shared runner [pipeline minutes for
+  each group](../../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota).
+
+If you are using GitLab.com:
+
+- You can select from a list of [shared runners that GitLab maintains](../../user/gitlab_com/index.md#shared-runners).
+- The shared runners consume the [pipelines minutes](../../subscriptions/gitlab_com/index.md#ci-pipeline-minutes)
+  included with your account.
+
+### Enable shared runners
+
+On GitLab.com, [shared runners](#shared-runners) are enabled in all projects by
+default.
+
+On self-managed instances of GitLab, an administrator must [install](https://docs.gitlab.com/runner/install/index.html)
+and [register](https://docs.gitlab.com/runner/register/index.html) them.
+
+You can also enable shared runners for individual projects.
+
+To enable shared runners:
+
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. Select **Enable shared runners for this project**.
+
+### Disable shared runners
+
+You can disable shared runners for individual projects or for groups.
+You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the project
+or group.
+
+To disable shared runners for a project:
+
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. In the **Shared runners** area, select **Enable shared runners for this project** so the toggle is grayed-out.
+
+Shared runners are automatically disabled for a project:
+
+- If the shared runners setting for the parent group is disabled, and
+- If overriding this setting is not permitted at the project level.
+
+To disable shared runners for a group:
+
+1. Go to the group's **Settings > CI/CD** and expand the **Runners** section.
+1. In the **Shared runners** area, turn off the **Enable shared runners for this group** toggle.
+1. Optionally, to allow shared runners to be enabled for individual projects or subgroups,
+   click **Allow projects and subgroups to override the group setting**.
+
+NOTE:
+To re-enable the shared runners for a group, turn on the
+**Enable shared runners for this group** toggle.
+Then, an owner or maintainer must explicitly change this setting
+for each project subgroup or project.
+
+### How shared runners pick jobs
+
+Shared runners process jobs by using a fair usage queue. This queue prevents
+projects from creating hundreds of jobs and using all available
+shared runner resources.
+
+The fair usage queue algorithm assigns jobs based on the projects that have the
+fewest number of jobs already running on shared runners.
+
+**Example 1**
+
+If these jobs are in the queue:
+
+- Job 1 for Project 1
+- Job 2 for Project 1
+- Job 3 for Project 1
+- Job 4 for Project 2
+- Job 5 for Project 2
+- Job 6 for Project 3
+
+The fair usage algorithm assigns jobs in this order:
+
+1. Job 1 is first, because it has the lowest job number from projects with no running jobs (that is, all projects).
+1. Job 4 is next, because 4 is now the lowest job number from projects with no running jobs (Project 1 has a job running).
+1. Job 6 is next, because 6 is now the lowest job number from projects with no running jobs (Projects 1 and 2 have jobs running).
+1. Job 2 is next, because, of projects with the lowest number of jobs running (each has 1), it is the lowest job number.
+1. Job 5 is next, because Project 1 now has 2 jobs running and Job 5 is the lowest remaining job number between Projects 2 and 3.
+1. Finally is Job 3... because it's the only job left.
+
+---
+
+**Example 2**
+
+If these jobs are in the queue:
+
+- Job 1 for Project 1
+- Job 2 for Project 1
+- Job 3 for Project 1
+- Job 4 for Project 2
+- Job 5 for Project 2
+- Job 6 for Project 3
+
+The fair usage algorithm assigns jobs in this order:
+
+1. Job 1 is chosen first, because it has the lowest job number from projects with no running jobs (that is, all projects).
+1. We finish Job 1.
+1. Job 2 is next, because, having finished Job 1, all projects have 0 jobs running again, and 2 is the lowest available job number.
+1. Job 4 is next, because with Project 1 running a Job, 4 is the lowest number from projects running no jobs (Projects 2 and 3).
+1. We finish Job 4.
+1. Job 5 is next, because having finished Job 4, Project 2 has no jobs running again.
+1. Job 6 is next, because Project 3 is the only project left with no running jobs.
+1. Lastly we choose Job 3... because, again, it's the only job left.
+
+## Group runners
+
+Use *Group runners* when you want all projects in a group
+to have access to a set of runners.
+
+Group runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue.
+
+### Create a group runner
+
+You can create a group runner for your self-managed GitLab instance or for GitLab.com.
+You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
+
+To create a group runner:
+
+1. [Install GitLab Runner](https://docs.gitlab.com/runner/install/).
+1. Go to the group you want to make the runner work for.
+1. Go to **Settings > CI/CD** and expand the **Runners** section.
+1. Note the URL and token.
+1. [Register the runner](https://docs.gitlab.com/runner/register/).
+
+### View and manage group runners
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/37366/) in GitLab 13.2.
+
+You can view and manage all runners for a group, its subgroups, and projects.
+You can do this for your self-managed GitLab instance or for GitLab.com.
+You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
+
+1. Go to the group where you want to view the runners.
+1. Go to **Settings > CI/CD** and expand the **Runners** section.
+1. The following fields are displayed.
+
+   | Attribute    | Description |
+   | ------------ | ----------- |
+   | Type         | Displays the runner type: `group` or `specific`, together with the optional states `locked` and `paused` |
+   | Runner token | Token used to identify the runner, and that the runner uses to communicate with the GitLab instance |
+   | Description  | Description given to the runner when it was created |
+   | Version      | GitLab Runner version |
+   | IP address   | IP address of the host on which the runner is registered |
+   | Projects     | The count of projects to which the runner is assigned |
+   | Jobs         | Total of jobs run by the runner |
+   | Tags         | Tags associated with the runner |
+   | Last contact | Timestamp indicating when the GitLab instance last contacted the runner |
+
+From this page, you can edit, pause, and remove runners from the group, its subgroups, and projects.
+
+### Pause or remove a group runner
+
+You can pause or remove a group runner for your self-managed GitLab instance or for GitLab.com.
+You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the group.
+
+1. Go to the group you want to remove or pause the runner for.
+1. Go to **Settings > CI/CD** and expand the **Runners** section.
+1. Click **Pause** or **Remove runner**.
+   - If you pause a group runner that is used by multiple projects, the runner pauses for all projects.
+   - From the group view, you cannot remove a runner that is assigned to more than one project.
+     You must remove it from each project first.
+1. On the confirmation dialog, click **OK**.
+
+## Specific runners
+
+Use *Specific runners* when you want to use runners for specific projects. For example,
+when you have:
+
+- Jobs with specific requirements, like a deploy job that requires credentials.
+- Projects with a lot of CI activity that can benefit from being separate from other runners.
+
+You can set up a specific runner to be used by multiple projects. Specific runners
+must be enabled for each project explicitly.
+
+Specific runners process jobs by using a first in, first out ([FIFO](https://en.wikipedia.org/wiki/FIFO_(computing_and_electronics))) queue.
+
+NOTE:
+Specific runners do not get shared with forked projects automatically.
+A fork *does* copy the CI/CD settings of the cloned repository.
+
+### Create a specific runner
+
+You can create a specific runner for your self-managed GitLab instance or for GitLab.com.
+You must have the [Owner role](../../user/permissions.md#project-members-permissions) for the project.
+
+To create a specific runner:
+
+1. [Install runner](https://docs.gitlab.com/runner/install/).
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. Note the URL and token.
+1. [Register the runner](https://docs.gitlab.com/runner/register/).
+
+### Enable a specific runner for a specific project
+
+A specific runner is available in the project it was created for. An administrator can
+enable a specific runner to apply to additional projects.
+
+- You must have the [Owner role](../../user/permissions.md#group-members-permissions) for the
+  project.
+- The specific runner must not be [locked](#prevent-a-specific-runner-from-being-enabled-for-other-projects).
+
+To enable or disable a specific runner for a project:
+
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. Click **Enable for this project** or **Disable for this project**.
+
+### Prevent a specific runner from being enabled for other projects
+
+You can configure a specific runner so it is "locked" and cannot be enabled for other projects.
+This setting can be enabled when you first [register a runner](https://docs.gitlab.com/runner/register/),
+but can also be changed later.
+
+To lock or unlock a runner:
+
+1. Go to the project's **Settings > CI/CD** and expand the **Runners** section.
+1. Find the runner you want to lock or unlock. Make sure it's enabled.
+1. Click the pencil button.
+1. Check the **Lock to current projects** option.
+1. Click **Save changes**.
diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md
index 6c0a63ddc64..f4275914b0b 100644
--- a/doc/ci/yaml/README.md
+++ b/doc/ci/yaml/README.md
@@ -3740,7 +3740,7 @@ Possible values for `when` are:
 - `scheduler_failure`: Retry if the scheduler failed to assign the job to a runner.
 - `data_integrity_failure`: Retry if there is a structural integrity problem detected.
 
-You can specify the number of [retry attempts for certain stages of job execution](../runners/README.md#job-stages-attempts) using variables.
+You can specify the number of [retry attempts for certain stages of job execution](../runners/configure_runners.md#job-stages-attempts) using variables.
 
 ### `timeout`
 
@@ -4801,19 +4801,19 @@ You cannot set job-level variables to be pre-filled when you run a pipeline manu
 
 You can use [CI/CD variables](../variables/README.md) to configure how the runner processes Git requests:
 
-- [`GIT_STRATEGY`](../runners/README.md#git-strategy)
-- [`GIT_SUBMODULE_STRATEGY`](../runners/README.md#git-submodule-strategy)
-- [`GIT_CHECKOUT`](../runners/README.md#git-checkout)
-- [`GIT_CLEAN_FLAGS`](../runners/README.md#git-clean-flags)
-- [`GIT_FETCH_EXTRA_FLAGS`](../runners/README.md#git-fetch-extra-flags)
-- [`GIT_DEPTH`](../runners/README.md#shallow-cloning) (shallow cloning)
-- [`GIT_CLONE_PATH`](../runners/README.md#custom-build-directories) (custom build directories)
-- [`TRANSFER_METER_FREQUENCY`](../runners/README.md#artifact-and-cache-settings) (artifact/cache meter update frequency)
-- [`ARTIFACT_COMPRESSION_LEVEL`](../runners/README.md#artifact-and-cache-settings) (artifact archiver compression level)
-- [`CACHE_COMPRESSION_LEVEL`](../runners/README.md#artifact-and-cache-settings) (cache archiver compression level)
+- [`GIT_STRATEGY`](../runners/configure_runners.md#git-strategy)
+- [`GIT_SUBMODULE_STRATEGY`](../runners/configure_runners.md#git-submodule-strategy)
+- [`GIT_CHECKOUT`](../runners/configure_runners.md#git-checkout)
+- [`GIT_CLEAN_FLAGS`](../runners/configure_runners.md#git-clean-flags)
+- [`GIT_FETCH_EXTRA_FLAGS`](../runners/configure_runners.md#git-fetch-extra-flags)
+- [`GIT_DEPTH`](../runners/configure_runners.md#shallow-cloning) (shallow cloning)
+- [`GIT_CLONE_PATH`](../runners/configure_runners.md#custom-build-directories) (custom build directories)
+- [`TRANSFER_METER_FREQUENCY`](../runners/configure_runners.md#artifact-and-cache-settings) (artifact/cache meter update frequency)
+- [`ARTIFACT_COMPRESSION_LEVEL`](../runners/configure_runners.md#artifact-and-cache-settings) (artifact archiver compression level)
+- [`CACHE_COMPRESSION_LEVEL`](../runners/configure_runners.md#artifact-and-cache-settings) (cache archiver compression level)
 
 You can also use variables to configure how many times a runner
-[attempts certain stages of job execution](../runners/README.md#job-stages-attempts).
+[attempts certain stages of job execution](../runners/configure_runners.md#job-stages-attempts).
 
 ## YAML-specific features
 
diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 3f374a9a223..caad0ee6cfe 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -478,7 +478,7 @@ The following GitLab features are used among others:
 - [Multi project pipelines](../../ci/multi_project_pipelines.md)
 - [Review Apps](../../ci/review_apps/index.md)
 - [Artifacts](../../ci/yaml/README.md#artifacts)
-- [Specific runner](../../ci/runners/README.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
+- [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
 - [Pipelines for merge requests](../../ci/merge_request_pipelines/index.md)
 
 ## Testing
diff --git a/doc/development/pipelines.md b/doc/development/pipelines.md
index cde511228af..a3c9d77f573 100644
--- a/doc/development/pipelines.md
+++ b/doc/development/pipelines.md
@@ -583,7 +583,7 @@ several reasons:
 - It significantly reduces load on the file server, as smaller deltas mean less time spent in `git pack-objects`.
 
 The pre-clone step works by using the `CI_PRE_CLONE_SCRIPT` variable
-[defined by GitLab.com shared runners](../user/gitlab_com/index.md#pre-clone-script).
+[defined by GitLab.com shared runners](../ci/runners/README.md#pre-clone-script).
 
 The `CI_PRE_CLONE_SCRIPT` is currently defined as a project CI/CD variable:
 
diff --git a/doc/topics/autodevops/requirements.md b/doc/topics/autodevops/requirements.md
index edcc662d8fd..f39f33c7730 100644
--- a/doc/topics/autodevops/requirements.md
+++ b/doc/topics/autodevops/requirements.md
@@ -64,8 +64,8 @@ To make full use of Auto DevOps with Kubernetes, you need:
   You can configure Docker-based runners to autoscale as well, using
   [Docker Machine](https://docs.gitlab.com/runner/install/autoscaling.html).
 
-  Runners should be registered as [shared runners](../../ci/runners/README.md#shared-runners)
-  for the entire GitLab instance, or [specific runners](../../ci/runners/README.md#specific-runners)
+  Runners should be registered as [shared runners](../../ci/runners/runners_scope.md#shared-runners)
+  for the entire GitLab instance, or [specific runners](../../ci/runners/runners_scope.md#specific-runners)
   that are assigned to specific projects (the default if you've installed the
   GitLab Runner managed application).
 
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 48d7d68996e..8e83ade5608 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -571,7 +571,7 @@ automatically generates.
 To enable remediation support, the scanning tool _must_ have access to the `Dockerfile` specified by
 the [`DOCKERFILE_PATH`](#available-cicd-variables) CI/CD variable. To ensure that the scanning tool
 has access to this
-file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/README.md#git-strategy) in
+file, it's necessary to set [`GIT_STRATEGY: fetch`](../../../ci/runners/configure_runners.md#git-strategy) in
 your `.gitlab-ci.yml` file by following the instructions described in this document's
 [overriding the container scanning template](#overriding-the-container-scanning-template) section.
 
diff --git a/doc/user/application_security/dast/index.md b/doc/user/application_security/dast/index.md
index 97771d9aec0..fbdef70c7c8 100644
--- a/doc/user/application_security/dast/index.md
+++ b/doc/user/application_security/dast/index.md
@@ -810,7 +810,7 @@ variables:
 ### Cloning the project's repository
 
 The DAST job does not require the project's repository to be present when running, so by default
-[`GIT_STRATEGY`](../../../ci/runners/README.md#git-strategy) is set to `none`.
+[`GIT_STRATEGY`](../../../ci/runners/configure_runners.md#git-strategy) is set to `none`.
 
 ### Debugging DAST jobs
 
diff --git a/doc/user/application_security/secret_detection/index.md b/doc/user/application_security/secret_detection/index.md
index bebb809f4f2..b3adfb3ae3c 100644
--- a/doc/user/application_security/secret_detection/index.md
+++ b/doc/user/application_security/secret_detection/index.md
@@ -177,7 +177,7 @@ is no longer supported. When overriding the template, you must use [`rules`](../
 
 #### GIT_DEPTH
 
-The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning) affects Secret Detection.
+The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning) affects Secret Detection.
 The Secret Detection analyzer relies on generating patches between commits to scan content for
 secrets. If you override the default, ensure the value is greater than 1. If the number of commits
 in an MR is greater than the GIT_DEPTH value, Secret Detection will [fail to detect secrets](#error-couldnt-run-the-gitleaks-command-exit-status-2).
@@ -399,7 +399,7 @@ ERRO[2020-11-18T18:05:52Z] object not found
 [ERRO] [secrets] [2020-11-18T18:05:52Z] ▶ Gitleaks analysis failed: exit status 2
 ```
 
-To resolve the issue, set the [`GIT_DEPTH` CI/CD variable](../../../ci/runners/README.md#shallow-cloning)
+To resolve the issue, set the [`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning)
 to a higher value. To apply this only to the Secret Detection job, the following can be added to
 your `.gitlab-ci.yml` file:
 
diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md
index 3a8335b9f19..b0130795f94 100644
--- a/doc/user/gitlab_com/index.md
+++ b/doc/user/gitlab_com/index.md
@@ -157,285 +157,13 @@ A limit of:
 
 - 100 webhooks applies to projects.
 - 50 webhooks applies to groups. **(BRONZE ONLY)**
-- Payload is limited to 25MB
+- Payload is limited to 25MB.
 
 ## Shared runners
 
-GitLab offers Linux and Windows shared runners hosted on GitLab.com for executing your pipelines.
+GitLab has shared runners on GitLab.com that you can use to run your CI jobs.
 
-NOTE:
-Shared runners provided by GitLab are **not** configurable. Consider [installing your own runner](https://docs.gitlab.com/runner/install/) if you have specific configuration needs.
-
-### Linux shared runners
-
-Linux shared runners on GitLab.com run in autoscale mode and are powered by Google Cloud Platform.
-
-Autoscaling means reduced queue times to spin up CI/CD jobs, and isolated VMs for each project, thus maximizing security. These shared runners are available for users and customers on GitLab.com.
-
-GitLab offers Ultimate tier capabilities and included CI/CD minutes per group per month for our [Open Source](https://about.gitlab.com/solutions/open-source/join/), [Education](https://about.gitlab.com/solutions/education/), and [Startups](https://about.gitlab.com/solutions/startups/) programs. For private projects, GitLab offers various [plans](https://about.gitlab.com/pricing/), starting with a Free tier.
-
-All your CI/CD jobs run on [n1-standard-1 instances](https://cloud.google.com/compute/docs/machine-types) with 3.75GB of RAM, CoreOS and the latest Docker Engine
-installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default
-region of the VMs is US East1.
-Each instance is used only for one job, this ensures any sensitive data left on the system can't be accessed by other people their CI jobs.
-
-The `gitlab-shared-runners-manager-X.gitlab.com` fleet of runners are dedicated for GitLab projects as well as community forks of them. They use a slightly larger machine type (n1-standard-2) and have a bigger SSD disk size. They don't run untagged jobs and unlike the general fleet of shared runners, the instances are re-used up to 40 times.
-
-Jobs handled by the shared runners on GitLab.com (`shared-runners-manager-X.gitlab.com`),
-**time out after 3 hours**, regardless of the timeout configured in a
-project. Check the issues [4010](https://gitlab.com/gitlab-com/infrastructure/-/issues/4010) and [4070](https://gitlab.com/gitlab-com/infrastructure/-/issues/4070) for the reference.
-
-Below are the shared runners settings.
-
-| Setting                               | GitLab.com                                        | Default    |
-| -----------                           | -----------------                                 | ---------- |
-| [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) | [Runner versions dashboard](https://dashboards.gitlab.com/d/000000159/ci?from=now-1h&to=now&refresh=5m&orgId=1&panelId=12&fullscreen&theme=light) | - |
-| Executor                              | `docker+machine`                                  | -          |
-| Default Docker image                  | `ruby:2.5`                                        | -          |
-| `privileged` (run [Docker in Docker](https://hub.docker.com/_/docker/)) | `true`          | `false`    |
-
-#### Pre-clone script
-
-Linux shared runners on GitLab.com provide a way to run commands in a CI
-job before the runner attempts to run `git init` and `git fetch` to
-download a GitLab repository. The
-[`pre_clone_script`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section)
-can be used for:
-
-- Seeding the build directory with repository data
-- Sending a request to a server
-- Downloading assets from a CDN
-- Any other commands that must run before the `git init`
-
-To use this feature, define a [CI/CD variable](../../ci/variables/README.md#custom-cicd-variables) called
-`CI_PRE_CLONE_SCRIPT` that contains a bash script.
-
-[This example](../../development/pipelines.md#pre-clone-step)
-demonstrates how you might use a pre-clone step to seed the build
-directory.
-
-#### `config.toml`
-
-The full contents of our `config.toml` are:
-
-NOTE:
-Settings that are not public are shown as `X`.
-
-**Google Cloud Platform**
-
-```toml
-concurrent = X
-check_interval = 1
-metrics_server = "X"
-sentry_dsn = "X"
-
-[[runners]]
-  name = "docker-auto-scale"
-  request_concurrency = X
-  url = "https://gitlab.com/"
-  token = "SHARED_RUNNER_TOKEN"
-  pre_clone_script = "eval \"$CI_PRE_CLONE_SCRIPT\""
-  executor = "docker+machine"
-  environment = [
-    "DOCKER_DRIVER=overlay2",
-    "DOCKER_TLS_CERTDIR="
-  ]
-  limit = X
-  [runners.docker]
-    image = "ruby:2.5"
-    privileged = true
-    volumes = [
-      "/certs/client",
-      "/dummy-sys-class-dmi-id:/sys/class/dmi/id:ro" # Make kaniko builds work on GCP.
-    ]
-  [runners.machine]
-    IdleCount = 50
-    IdleTime = 3600
-    MaxBuilds = 1 # For security reasons we delete the VM after job has finished so it's not reused.
-    MachineName = "srm-%s"
-    MachineDriver = "google"
-    MachineOptions = [
-      "google-project=PROJECT",
-      "google-disk-size=25",
-      "google-machine-type=n1-standard-1",
-      "google-username=core",
-      "google-tags=gitlab-com,srm",
-      "google-use-internal-ip",
-      "google-zone=us-east1-d",
-      "engine-opt=mtu=1460", # Set MTU for container interface, for more information check https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3214#note_82892928
-      "google-machine-image=PROJECT/global/images/IMAGE",
-      "engine-opt=ipv6", # This will create IPv6 interfaces in the containers.
-      "engine-opt=fixed-cidr-v6=fc00::/7",
-      "google-operation-backoff-initial-interval=2" # Custom flag from forked docker-machine, for more information check https://github.com/docker/machine/pull/4600
-    ]
-    [[runners.machine.autoscaling]]
-      Periods = ["* * * * * sat,sun *"]
-      Timezone = "UTC"
-      IdleCount = 70
-      IdleTime = 3600
-    [[runners.machine.autoscaling]]
-      Periods = ["* 30-59 3 * * * *", "* 0-30 4 * * * *"]
-      Timezone = "UTC"
-      IdleCount = 700
-      IdleTime = 3600
-  [runners.cache]
-    Type = "gcs"
-    Shared = true
-    [runners.cache.gcs]
-      CredentialsFile = "/path/to/file"
-      BucketName = "bucket-name"
-```
-
-### Windows shared runners (beta)
-
-The Windows shared runners are in [beta](https://about.gitlab.com/handbook/product/gitlab-the-product/#beta)
-and shouldn't be used for production workloads.
-
-During this beta period, the [shared runner pipeline quota](../admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota)
-applies for groups and projects in the same manner as Linux runners. This may
-change when the beta period ends, as discussed in this [related issue](https://gitlab.com/gitlab-org/gitlab/-/issues/30834).
-
-Windows shared runners on GitLab.com autoscale by launching virtual machines on
-the Google Cloud Platform. This solution uses an
-[autoscaling driver](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/tree/master/docs/readme.md)
-developed by GitLab for the [custom executor](https://docs.gitlab.com/runner/executors/custom.html).
-Windows shared runners execute your CI/CD jobs on `n1-standard-2` instances with
-2 vCPUs and 7.5 GB RAM. You can find a full list of available Windows packages in
-the [package documentation](https://gitlab.com/gitlab-org/ci-cd/shared-runners/images/gcp/windows-containers/blob/master/cookbooks/preinstalled-software/README.md).
-
-We want to keep iterating to get Windows shared runners in a stable state and
-[generally available](https://about.gitlab.com/handbook/product/gitlab-the-product/#generally-available-ga).
-You can follow our work towards this goal in the
-[related epic](https://gitlab.com/groups/gitlab-org/-/epics/2162).
-
-#### Configuration
-
-The full contents of our `config.toml` are:
-
-NOTE:
-Settings that aren't public are shown as `X`.
-
-```toml
-concurrent = X
-check_interval = 3
-
-[[runners]]
-  name = "windows-runner"
-  url = "https://gitlab.com/"
-  token = "TOKEN"
-  executor = "custom"
-  builds_dir = "C:\\GitLab-Runner\\builds"
-  cache_dir = "C:\\GitLab-Runner\\cache"
-  shell  = "powershell"
-  [runners.custom]
-    config_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    config_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "config"]
-    prepare_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    prepare_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "prepare"]
-    run_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    run_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "run"]
-    cleanup_exec = "C:\\GitLab-Runner\\autoscaler\\autoscaler.exe"
-    cleanup_args = ["--config", "C:\\GitLab-Runner\\autoscaler\\config.toml", "custom", "cleanup"]
-```
-
-The full contents of our `autoscaler/config.toml` are:
-
-```toml
-Provider = "gcp"
-Executor = "winrm"
-OS = "windows"
-LogLevel = "info"
-LogFormat = "text"
-LogFile = "C:\\GitLab-Runner\\autoscaler\\autoscaler.log"
-VMTag = "windows"
-
-[GCP]
-  ServiceAccountFile = "PATH"
-  Project = "some-project-df9323"
-  Zone = "us-east1-c"
-  MachineType = "n1-standard-2"
-  Image = "IMAGE"
-  DiskSize = 50
-  DiskType = "pd-standard"
-  Subnetwork = "default"
-  Network = "default"
-  Tags = ["TAGS"]
-  Username = "gitlab_runner"
-
-[WinRM]
-  MaximumTimeout = 3600
-  ExecutionMaxRetries = 0
-
-[ProviderCache]
-  Enabled = true
-  Directory = "C:\\GitLab-Runner\\autoscaler\\machines"
-```
-
-#### Example
-
-Below is a simple `.gitlab-ci.yml` file to show how to start using the
-Windows shared runners:
-
-```yaml
-.shared_windows_runners:
-  tags:
-    - shared-windows
-    - windows
-    - windows-1809
-
-stages:
-  - build
-  - test
-
-before_script:
- - Set-Variable -Name "time" -Value (date -Format "%H:%m")
- - echo ${time}
- - echo "started by ${GITLAB_USER_NAME}"
-
-build:
-  extends:
-    - .shared_windows_runners
-  stage: build
-  script:
-    - echo "running scripts in the build job"
-
-test:
-  extends:
-    - .shared_windows_runners
-  stage: test
-  script:
-    - echo "running scripts in the test job"
-```
-
-#### Limitations and known issues
-
-- All the limitations mentioned in our [beta
-  definition](https://about.gitlab.com/handbook/product/#beta).
-- The average provisioning time for a new Windows VM is 5 minutes.
-  This means that you may notice slower build start times
-  on the Windows shared runner fleet during the beta. In a future
-  release we intend to update the autoscaler to enable
-  the pre-provisioning of virtual machines. This is intended to significantly reduce
-  the time it takes to provision a VM on the Windows fleet. You can
-  follow along in the [related issue](https://gitlab.com/gitlab-org/ci-cd/custom-executor-drivers/autoscaler/-/issues/32).
-- The Windows shared runner fleet may be unavailable occasionally
-  for maintenance or updates.
-- The Windows shared runner virtual machine instances do not use the
-  GitLab Docker executor. This means that you can't specify
-  [`image`](../../ci/yaml/README.md#image) or [`services`](../../ci/yaml/README.md#services) in
-  your pipeline configuration.
-- For the beta release, we have included a set of software packages in
-  the base VM image. If your CI job requires additional software that's
-  not included in this list, then you must add installation
-  commands to [`before_script`](../../ci/yaml/README.md#before_script) or [`script`](../../ci/yaml/README.md#script) to install the required
-  software. Note that each job runs on a new VM instance, so the
-  installation of additional software packages needs to be repeated for
-  each job in your pipeline.
-- The job may stay in a pending state for longer than the
-  Linux shared runners.
-- There is the possibility that we introduce breaking changes which will
-  require updates to pipelines that are using the Windows shared runner
-  fleet.
+For more information, see [choosing a runner](../../ci/runners/README.md).
 
 ## Sidekiq
 
diff --git a/doc/user/project/merge_requests/load_performance_testing.md b/doc/user/project/merge_requests/load_performance_testing.md
index c97ca64a30a..d1b697add08 100644
--- a/doc/user/project/merge_requests/load_performance_testing.md
+++ b/doc/user/project/merge_requests/load_performance_testing.md
@@ -93,7 +93,7 @@ template that is included with GitLab.
 NOTE:
 For large scale k6 tests you need to ensure the GitLab Runner instance performing the actual
 test is able to handle running the test. Refer to [k6's guidance](https://k6.io/docs/testing-guides/running-large-tests#hardware-considerations)
-for spec details. The [default shared GitLab.com runners](../../gitlab_com/#linux-shared-runners)
+for spec details. The [default shared GitLab.com runners](../../../ci/runners/README.md#linux-shared-runners)
 likely have insufficient specs to handle most large k6 tests.
 
 This template runs the
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
index f02697a3cd5..410fdab15e7 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/dns_concepts.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# DNS records overview
+# DNS records overview **(FREE)**
 
 _Read this document for a brief overview of DNS records in the scope
 of GitLab Pages, for beginners in web development._
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
index 8ed0ef82893..50fd6795efc 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/index.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Custom domains and SSL/TLS Certificates
+# Custom domains and SSL/TLS certificates **(FREE)**
 
 Setting up GitLab Pages with custom domains, and adding SSL/TLS certificates to them, are optional features of GitLab Pages.
 
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
index 5d126ff9653..f0a922ff390 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/lets_encrypt_integration.md
@@ -6,7 +6,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# GitLab Pages integration with Let's Encrypt
+# GitLab Pages integration with Let's Encrypt **(FREE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28996) in GitLab 12.1. For versions earlier than GitLab 12.1, see the [manual Let's Encrypt instructions](../lets_encrypt_for_gitlab_pages.md).
 
diff --git a/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md b/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md
index f79c60a933a..48412f48c12 100644
--- a/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md
+++ b/doc/user/project/pages/custom_domains_ssl_tls_certification/ssl_tls_concepts.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# SSL/TLS Certificates
+# SSL/TLS certificates **(FREE)**
 
 _Read this document for a brief overview of SSL/TLS certificates in
 the scope of GitLab Pages, for beginners in web development._
diff --git a/doc/user/project/pages/getting_started/pages_ci_cd_template.md b/doc/user/project/pages/getting_started/pages_ci_cd_template.md
index 30dd337d9d8..e2280cb0f39 100644
--- a/doc/user/project/pages/getting_started/pages_ci_cd_template.md
+++ b/doc/user/project/pages/getting_started/pages_ci_cd_template.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Create a Pages website by using a CI/CD template
+# Create a Pages website by using a CI/CD template **(FREE)**
 
 GitLab provides `.gitlab-ci.yml` templates for the most popular Static Site Generators (SSGs).
 You can create your own `.gitlab-ci.yml` file from one of these templates, and run
diff --git a/doc/user/project/pages/getting_started/pages_forked_sample_project.md b/doc/user/project/pages/getting_started/pages_forked_sample_project.md
index d9ec2aae2b7..386ed566225 100644
--- a/doc/user/project/pages/getting_started/pages_forked_sample_project.md
+++ b/doc/user/project/pages/getting_started/pages_forked_sample_project.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Create a Pages website from a forked sample
+# Create a Pages website from a forked sample **(FREE)**
 
 GitLab provides [sample projects for the most popular Static Site Generators (SSG)](https://gitlab.com/pages).
 You can fork one of the sample projects and run the CI/CD pipeline to generate a Pages website.
diff --git a/doc/user/project/pages/getting_started/pages_from_scratch.md b/doc/user/project/pages/getting_started/pages_from_scratch.md
index 8368b38bc80..9f80e2e7613 100644
--- a/doc/user/project/pages/getting_started/pages_from_scratch.md
+++ b/doc/user/project/pages/getting_started/pages_from_scratch.md
@@ -4,7 +4,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Create a GitLab Pages website from scratch
+# Create a GitLab Pages website from scratch **(FREE)**
 
 This tutorial shows you how to create a Pages site from scratch. You start with
 a blank project and create your own CI file, which gives instruction to
diff --git a/doc/user/project/pages/getting_started/pages_new_project_template.md b/doc/user/project/pages/getting_started/pages_new_project_template.md
index e07b37a16d0..f52f64626ac 100644
--- a/doc/user/project/pages/getting_started/pages_new_project_template.md
+++ b/doc/user/project/pages/getting_started/pages_new_project_template.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Create a Pages website from a template
+# Create a Pages website from a template **(FREE)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47857) in GitLab 11.8.
 
diff --git a/doc/user/project/pages/getting_started_part_one.md b/doc/user/project/pages/getting_started_part_one.md
index 9eb80e3287c..32826346eab 100644
--- a/doc/user/project/pages/getting_started_part_one.md
+++ b/doc/user/project/pages/getting_started_part_one.md
@@ -4,7 +4,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# GitLab Pages domain names, URLs, and base URLs
+# GitLab Pages domain names, URLs, and base URLs **(FREE)**
 
 On this document, learn how to name your project for GitLab Pages
 according to your intended website's URL.
diff --git a/doc/user/project/pages/index.md b/doc/user/project/pages/index.md
index 2ff91292b1b..1f5e1a6ab45 100644
--- a/doc/user/project/pages/index.md
+++ b/doc/user/project/pages/index.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# GitLab Pages
+# GitLab Pages **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/80) in GitLab Enterprise Edition 8.3.
 > - Custom CNAMEs with TLS support were [introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173) in GitLab Enterprise Edition 8.5.
diff --git a/doc/user/project/pages/introduction.md b/doc/user/project/pages/introduction.md
index 18acb360f5a..4d6a8653657 100644
--- a/doc/user/project/pages/introduction.md
+++ b/doc/user/project/pages/introduction.md
@@ -4,7 +4,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Exploring GitLab Pages
+# Exploring GitLab Pages **(FREE)**
 
 This document is a user guide to explore the options and settings
 GitLab Pages offers.
@@ -324,4 +324,4 @@ pages:
       - public
 ```
 
-The `FF_USE_FASTZIP` variable enables the [feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) which is needed for [`ARTIFACT_COMPRESSION_LEVEL`](../../../ci/runners/README.md#artifact-and-cache-settings).
+The `FF_USE_FASTZIP` variable enables the [feature flag](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) which is needed for [`ARTIFACT_COMPRESSION_LEVEL`](../../../ci/runners/configure_runners.md#artifact-and-cache-settings).
diff --git a/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md b/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md
index b5932fc8766..ce49699785e 100644
--- a/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md
+++ b/doc/user/project/pages/lets_encrypt_for_gitlab_pages.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 description: "How to secure GitLab Pages websites with Let's Encrypt (manual process, deprecated)."
 ---
 
-# Let's Encrypt for GitLab Pages (manual process, deprecated)
+# Let's Encrypt for GitLab Pages (manual process, deprecated) **(FREE)**
 
 WARNING:
 This method is still valid but was **deprecated** in favor of the
diff --git a/doc/user/project/pages/pages_access_control.md b/doc/user/project/pages/pages_access_control.md
index 2e0fc87b3df..532a36b2327 100644
--- a/doc/user/project/pages/pages_access_control.md
+++ b/doc/user/project/pages/pages_access_control.md
@@ -5,7 +5,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# GitLab Pages Access Control
+# GitLab Pages access control **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/33422) in GitLab 11.5.
 > - Available on GitLab.com in GitLab 12.4.
diff --git a/doc/user/project/pages/redirects.md b/doc/user/project/pages/redirects.md
index 8c189614102..8ed6f214605 100644
--- a/doc/user/project/pages/redirects.md
+++ b/doc/user/project/pages/redirects.md
@@ -4,7 +4,7 @@ group: Release
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
-# Create redirects for GitLab Pages
+# Create redirects for GitLab Pages **(FREE)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab-pages/-/issues/24) in GitLab Pages 1.25.0 and GitLab 13.4 behind a feature flag, disabled by default.
 > - [Became enabled by default](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/367) in GitLab 13.5.
diff --git a/lib/gitlab/database/background_migration/batched_migration.rb b/lib/gitlab/database/background_migration/batched_migration.rb
index 53a5089a877..36e89023c86 100644
--- a/lib/gitlab/database/background_migration/batched_migration.rb
+++ b/lib/gitlab/database/background_migration/batched_migration.rb
@@ -14,6 +14,10 @@ module Gitlab
           class_name: 'Gitlab::Database::BackgroundMigration::BatchedJob',
           foreign_key: :batched_background_migration_id
 
+        validates :job_arguments, uniqueness: {
+          scope: [:job_class_name, :table_name, :column_name]
+        }
+
         scope :queue_order, -> { order(id: :asc) }
         scope :queued, -> { where(status: [:active, :paused]) }
         scope :for_configuration, ->(job_class_name, table_name, column_name, job_arguments) do
diff --git a/lib/gitlab/database/load_balancing.rb b/lib/gitlab/database/load_balancing.rb
index ea4628ab757..88743cd2e75 100644
--- a/lib/gitlab/database/load_balancing.rb
+++ b/lib/gitlab/database/load_balancing.rb
@@ -97,16 +97,9 @@ module Gitlab
       # posting the write location of the database if load balancing is
       # configured.
       def self.configured?
-        return false unless feature_available?
-
         hosts.any? || service_discovery_enabled?
       end
 
-      # Temporarily disabled for FOSS until move from EE to FOSS is complete
-      def self.feature_available?
-        Gitlab.ee? || Gitlab::Utils.to_boolean(ENV['ENABLE_LOAD_BALANCING_FOR_FOSS'], default: false)
-      end
-
       def self.start_service_discovery
         return unless service_discovery_enabled?
 
diff --git a/lib/gitlab/database/migrations/background_migration_helpers.rb b/lib/gitlab/database/migrations/background_migration_helpers.rb
index f56d375bb9e..fa30ffb62f5 100644
--- a/lib/gitlab/database/migrations/background_migration_helpers.rb
+++ b/lib/gitlab/database/migrations/background_migration_helpers.rb
@@ -131,6 +131,42 @@ module Gitlab
           final_delay
         end
 
+        # Requeue pending jobs previously queued with #queue_background_migration_jobs_by_range_at_intervals
+        #
+        # This method is useful to schedule jobs that had previously failed.
+        #
+        # job_class_name - The background migration job class as a string
+        # delay_interval - The duration between each job's scheduled time
+        # batch_size - The maximum number of jobs to fetch to memory from the database.
+        def requeue_background_migration_jobs_by_range_at_intervals(job_class_name, delay_interval, batch_size: BATCH_SIZE, initial_delay: 0)
+          # To not overload the worker too much we enforce a minimum interval both
+          # when scheduling and performing jobs.
+          delay_interval = [delay_interval, BackgroundMigrationWorker.minimum_interval].max
+
+          final_delay = 0
+          job_counter = 0
+
+          jobs = Gitlab::Database::BackgroundMigrationJob.pending.where(class_name: job_class_name)
+          jobs.each_batch(of: batch_size) do |job_batch|
+            job_batch.each do |job|
+              final_delay = initial_delay + delay_interval * job_counter
+
+              migrate_in(final_delay, job_class_name, job.arguments)
+
+              job_counter += 1
+            end
+          end
+
+          duration = initial_delay + delay_interval * job_counter
+          say <<~SAY
+            Scheduled #{job_counter} #{job_class_name} jobs with an interval of #{delay_interval} seconds.
+
+            The migration is expected to take at least #{duration} seconds. Expect all jobs to have completed after #{Time.zone.now + duration}."
+          SAY
+
+          duration
+        end
+
         # Creates a batched background migration for the given table. A batched migration runs one job
         # at a time, computing the bounds of the next batch based on the current migration settings and the previous
         # batch bounds. Each job's execution status is tracked in the database as the migration runs. The given job
diff --git a/lib/gitlab/import_export/group/import_export.yml b/lib/gitlab/import_export/group/import_export.yml
index 4ef2158abc7..4786c7a52cc 100644
--- a/lib/gitlab/import_export/group/import_export.yml
+++ b/lib/gitlab/import_export/group/import_export.yml
@@ -77,6 +77,7 @@ ee:
           - :award_emoji
           - events:
             - :push_event_payload
+          - :system_note_metadata
       - boards:
         - :board_assignee
         - :milestone
diff --git a/locale/gitlab.pot b/locale/gitlab.pot
index 853fa1261fc..c09e37b0137 100644
--- a/locale/gitlab.pot
+++ b/locale/gitlab.pot
@@ -5812,6 +5812,9 @@ msgstr ""
 msgid "CVE|Why Request a CVE ID?"
 msgstr ""
 
+msgid "Cadence is not automated"
+msgstr ""
+
 msgid "Callback URL"
 msgstr ""
 
@@ -10042,6 +10045,9 @@ msgstr ""
 msgid "DastConfig|DAST Settings"
 msgstr ""
 
+msgid "DastConfig|Generate code snippet"
+msgstr ""
+
 msgid "DastConfig|Scan Configuration"
 msgstr ""
 
@@ -33123,6 +33129,9 @@ msgstr ""
 msgid "This chart could not be displayed"
 msgstr ""
 
+msgid "This code snippet contains everything reflected in the configuration form. Copy and paste it into %{linkStart}.gitlab-ci.yml%{linkEnd} file and save your changes. Future %{scanType} scans will use these settings."
+msgstr ""
+
 msgid "This comment changed after you started editing it. Review the %{startTag}updated comment%{endTag} to ensure information is not lost."
 msgstr ""
 
@@ -37934,6 +37943,9 @@ msgstr ""
 msgid "already being used for another group or project %{timebox_name}."
 msgstr ""
 
+msgid "already being used for another iteration within this cadence."
+msgstr ""
+
 msgid "already has a \"created\" issue link"
 msgstr ""
 
diff --git a/spec/factories/gitlab/database/background_migration/batched_migrations.rb b/spec/factories/gitlab/database/background_migration/batched_migrations.rb
index c03841d8c02..de57e0c1565 100644
--- a/spec/factories/gitlab/database/background_migration/batched_migrations.rb
+++ b/spec/factories/gitlab/database/background_migration/batched_migrations.rb
@@ -9,6 +9,7 @@ FactoryBot.define do
     job_class_name { 'CopyColumnUsingBackgroundMigrationJob' }
     table_name { :events }
     column_name { :id }
+    sequence(:job_arguments) { |n| [["column_#{n}"], ["column_#{n}_convert_to_bigint"]] }
     total_tuple_count { 10_000 }
     pause_ms { 100 }
   end
diff --git a/spec/fixtures/bulk_imports/epics.ndjson.gz b/spec/fixtures/bulk_imports/epics.ndjson.gz
deleted file mode 100644
index 1f02a027c0c..00000000000
--- a/spec/fixtures/bulk_imports/epics.ndjson.gz
+++ /dev/null
diff --git a/spec/frontend/releases/components/app_index_apollo_client_spec.js b/spec/frontend/releases/components/app_index_apollo_client_spec.js
index 84bcea36406..eae3a5b96a4 100644
--- a/spec/frontend/releases/components/app_index_apollo_client_spec.js
+++ b/spec/frontend/releases/components/app_index_apollo_client_spec.js
@@ -4,13 +4,14 @@ import VueApollo from 'vue-apollo';
 import createMockApollo from 'helpers/mock_apollo_helper';
 import { shallowMountExtended } from 'helpers/vue_test_utils_helper';
 import createFlash from '~/flash';
+import { historyPushState } from '~/lib/utils/common_utils';
 import ReleasesIndexApolloClientApp from '~/releases/components/app_index_apollo_client.vue';
 import ReleaseBlock from '~/releases/components/release_block.vue';
 import ReleaseSkeletonLoader from '~/releases/components/release_skeleton_loader.vue';
 import ReleasesEmptyState from '~/releases/components/releases_empty_state.vue';
 import ReleasesPaginationApolloClient from '~/releases/components/releases_pagination_apollo_client.vue';
 import ReleasesSortApolloClient from '~/releases/components/releases_sort_apollo_client.vue';
-import { PAGE_SIZE, RELEASED_AT_DESC, CREATED_ASC } from '~/releases/constants';
+import { PAGE_SIZE, CREATED_ASC, DEFAULT_SORT } from '~/releases/constants';
 import allReleasesQuery from '~/releases/graphql/queries/all_releases.query.graphql';
 
 Vue.use(VueApollo);
@@ -23,6 +24,7 @@ jest.mock('~/lib/utils/common_utils', () => ({
   getParameterByName: jest
     .fn()
     .mockImplementation((parameterName) => mockQueryParams[parameterName]),
+  historyPushState: jest.fn(),
 }));
 
 describe('app_index_apollo_client.vue', () => {
@@ -225,7 +227,7 @@ describe('app_index_apollo_client.vue', () => {
         expect(allReleasesQueryMock).toHaveBeenCalledWith({
           first: PAGE_SIZE,
           fullPath: projectPath,
-          sort: RELEASED_AT_DESC,
+          sort: DEFAULT_SORT,
         });
       });
     });
@@ -241,7 +243,7 @@ describe('app_index_apollo_client.vue', () => {
           before,
           last: PAGE_SIZE,
           fullPath: projectPath,
-          sort: RELEASED_AT_DESC,
+          sort: DEFAULT_SORT,
         });
       });
     });
@@ -257,7 +259,7 @@ describe('app_index_apollo_client.vue', () => {
           after,
           first: PAGE_SIZE,
           fullPath: projectPath,
-          sort: RELEASED_AT_DESC,
+          sort: DEFAULT_SORT,
         });
       });
     });
@@ -273,7 +275,7 @@ describe('app_index_apollo_client.vue', () => {
           after,
           first: PAGE_SIZE,
           fullPath: projectPath,
-          sort: RELEASED_AT_DESC,
+          sort: DEFAULT_SORT,
         });
       });
     });
@@ -320,21 +322,82 @@ describe('app_index_apollo_client.vue', () => {
       createComponent();
     });
 
-    it(`sorts by ${RELEASED_AT_DESC} by default`, () => {
+    it(`sorts by ${DEFAULT_SORT} by default`, () => {
       expect(allReleasesQueryMock.mock.calls).toEqual([
-        [expect.objectContaining({ sort: RELEASED_AT_DESC })],
+        [expect.objectContaining({ sort: DEFAULT_SORT })],
       ]);
     });
 
-    it('requeries the GraphQL endpoint when the sort is changed', async () => {
+    it('requeries the GraphQL endpoint and updates the URL when the sort is changed', async () => {
       findSort().vm.$emit('input', CREATED_ASC);
 
       await wrapper.vm.$nextTick();
 
       expect(allReleasesQueryMock.mock.calls).toEqual([
-        [expect.objectContaining({ sort: RELEASED_AT_DESC })],
+        [expect.objectContaining({ sort: DEFAULT_SORT })],
         [expect.objectContaining({ sort: CREATED_ASC })],
       ]);
+
+      // URL manipulation is tested in more detail in the `describe` block below
+      expect(historyPushState).toHaveBeenCalled();
+    });
+
+    it('does not requery the GraphQL endpoint or update the URL if the sort is updated to the same value', async () => {
+      findSort().vm.$emit('input', DEFAULT_SORT);
+
+      await wrapper.vm.$nextTick();
+
+      expect(allReleasesQueryMock.mock.calls).toEqual([
+        [expect.objectContaining({ sort: DEFAULT_SORT })],
+      ]);
+
+      expect(historyPushState).not.toHaveBeenCalled();
     });
   });
+
+  describe('sorting + pagination interaction', () => {
+    const nonPaginationQueryParam = 'nonPaginationQueryParam';
+
+    beforeEach(() => {
+      historyPushState.mockImplementation((newUrl) => {
+        mockQueryParams = Object.fromEntries(new URL(newUrl).searchParams);
+      });
+    });
+
+    describe.each`
+      queryParamsBefore                      | paramName   | paramInitialValue
+      ${{ before, nonPaginationQueryParam }} | ${'before'} | ${before}
+      ${{ after, nonPaginationQueryParam }}  | ${'after'}  | ${after}
+    `(
+      'when the URL contains a "$paramName" pagination cursor',
+      ({ queryParamsBefore, paramName, paramInitialValue }) => {
+        beforeEach(async () => {
+          mockQueryParams = queryParamsBefore;
+          createComponent();
+
+          findSort().vm.$emit('input', CREATED_ASC);
+
+          await wrapper.vm.$nextTick();
+        });
+
+        it(`resets the page's "${paramName}" pagination cursor when the sort is changed`, () => {
+          const firstRequestVariables = allReleasesQueryMock.mock.calls[0][0];
+          const secondRequestVariables = allReleasesQueryMock.mock.calls[1][0];
+
+          expect(firstRequestVariables[paramName]).toBe(paramInitialValue);
+          expect(secondRequestVariables[paramName]).toBeUndefined();
+        });
+
+        it(`updates the URL to not include the "${paramName}" URL query parameter`, () => {
+          expect(historyPushState).toHaveBeenCalledTimes(1);
+
+          const updatedUrlQueryParams = Object.fromEntries(
+            new URL(historyPushState.mock.calls[0][0]).searchParams,
+          );
+
+          expect(updatedUrlQueryParams[paramName]).toBeUndefined();
+        });
+      },
+    );
+  });
 });
diff --git a/spec/frontend/search/topbar/components/searchable_dropdown_item_spec.js b/spec/frontend/search/topbar/components/searchable_dropdown_item_spec.js
new file mode 100644
index 00000000000..e51fe9a4cf9
--- /dev/null
+++ b/spec/frontend/search/topbar/components/searchable_dropdown_item_spec.js
@@ -0,0 +1,97 @@
+import { GlDropdownItem, GlAvatar } from '@gitlab/ui';
+import { shallowMountExtended } from 'helpers/vue_test_utils_helper';
+import { MOCK_GROUPS } from 'jest/search/mock_data';
+import { truncateNamespace } from '~/lib/utils/text_utility';
+import SearchableDropdownItem from '~/search/topbar/components/searchable_dropdown_item.vue';
+import { GROUP_DATA } from '~/search/topbar/constants';
+
+describe('Global Search Searchable Dropdown Item', () => {
+  let wrapper;
+
+  const defaultProps = {
+    item: MOCK_GROUPS[0],
+    selectedItem: MOCK_GROUPS[0],
+    name: GROUP_DATA.name,
+    fullName: GROUP_DATA.fullName,
+  };
+
+  const createComponent = (props) => {
+    wrapper = shallowMountExtended(SearchableDropdownItem, {
+      propsData: {
+        ...defaultProps,
+        ...props,
+      },
+    });
+  };
+
+  afterEach(() => {
+    wrapper.destroy();
+  });
+
+  const findGlDropdownItem = () => wrapper.findComponent(GlDropdownItem);
+  const findGlAvatar = () => wrapper.findComponent(GlAvatar);
+  const findDropdownTitle = () => wrapper.findByTestId('item-title');
+  const findDropdownSubtitle = () => wrapper.findByTestId('item-namespace');
+
+  describe('template', () => {
+    describe('always', () => {
+      beforeEach(() => {
+        createComponent();
+      });
+
+      it('renders GlDropdownItem', () => {
+        expect(findGlDropdownItem().exists()).toBe(true);
+      });
+
+      it('renders GlAvatar', () => {
+        expect(findGlAvatar().exists()).toBe(true);
+      });
+
+      it('renders Dropdown Title correctly', () => {
+        const titleEl = findDropdownTitle();
+
+        expect(titleEl.exists()).toBe(true);
+        expect(titleEl.text()).toBe(MOCK_GROUPS[0][GROUP_DATA.name]);
+      });
+
+      it('renders Dropdown Subtitle correctly', () => {
+        const subtitleEl = findDropdownSubtitle();
+
+        expect(subtitleEl.exists()).toBe(true);
+        expect(subtitleEl.text()).toBe(truncateNamespace(MOCK_GROUPS[0][GROUP_DATA.fullName]));
+      });
+    });
+
+    describe('when item === selectedItem', () => {
+      beforeEach(() => {
+        createComponent({ item: MOCK_GROUPS[0], selectedItem: MOCK_GROUPS[0] });
+      });
+
+      it('marks the dropdown as checked', () => {
+        expect(findGlDropdownItem().attributes('ischecked')).toBe('true');
+      });
+    });
+
+    describe('when item !== selectedItem', () => {
+      beforeEach(() => {
+        createComponent({ item: MOCK_GROUPS[0], selectedItem: MOCK_GROUPS[1] });
+      });
+
+      it('marks the dropdown as not checked', () => {
+        expect(findGlDropdownItem().attributes('ischecked')).toBeUndefined();
+      });
+    });
+  });
+
+  describe('actions', () => {
+    beforeEach(() => {
+      createComponent();
+    });
+
+    it('clicking the dropdown item $emits change with the item', () => {
+      findGlDropdownItem().vm.$emit('click');
+
+      expect(wrapper.emitted('change')[0]).toEqual([MOCK_GROUPS[0]]);
+    });
+  });
+});
diff --git a/spec/frontend/search/topbar/components/searchable_dropdown_spec.js b/spec/frontend/search/topbar/components/searchable_dropdown_spec.js
index b5d5c5cf56e..10d779f0f90 100644
--- a/spec/frontend/search/topbar/components/searchable_dropdown_spec.js
+++ b/spec/frontend/search/topbar/components/searchable_dropdown_spec.js
@@ -1,17 +1,10 @@
-import {
-  GlDropdown,
-  GlDropdownItem,
-  GlSearchBoxByType,
-  GlSkeletonLoader,
-  GlAvatar,
-} from '@gitlab/ui';
+import { GlDropdown, GlDropdownItem, GlSearchBoxByType, GlSkeletonLoader } from '@gitlab/ui';
 import { shallowMount, mount } from '@vue/test-utils';
 import Vue from 'vue';
 import Vuex from 'vuex';
-import { extendedWrapper } from 'helpers/vue_test_utils_helper';
 import { MOCK_GROUPS, MOCK_GROUP, MOCK_QUERY } from 'jest/search/mock_data';
-import { truncateNamespace } from '~/lib/utils/text_utility';
 import SearchableDropdown from '~/search/topbar/components/searchable_dropdown.vue';
+import SearchableDropdownItem from '~/search/topbar/components/searchable_dropdown_item.vue';
 import { ANY_OPTION, GROUP_DATA } from '~/search/topbar/constants';
 
 Vue.use(Vuex);
@@ -36,37 +29,27 @@ describe('Global Search Searchable Dropdown', () => {
       },
     });
 
-    wrapper = extendedWrapper(
-      mountFn(SearchableDropdown, {
-        store,
-        propsData: {
-          ...defaultProps,
-          ...props,
-        },
-      }),
-    );
+    wrapper = mountFn(SearchableDropdown, {
+      store,
+      propsData: {
+        ...defaultProps,
+        ...props,
+      },
+    });
   };
 
   afterEach(() => {
     wrapper.destroy();
-    wrapper = null;
   });
 
-  const findGlDropdown = () => wrapper.find(GlDropdown);
-  const findGlDropdownSearch = () => findGlDropdown().find(GlSearchBoxByType);
+  const findGlDropdown = () => wrapper.findComponent(GlDropdown);
+  const findGlDropdownSearch = () => findGlDropdown().findComponent(GlSearchBoxByType);
   const findDropdownText = () => findGlDropdown().find('.dropdown-toggle-text');
-  const findDropdownItems = () => findGlDropdown().findAll(GlDropdownItem);
-  const findDropdownItemTitles = () => wrapper.findAllByTestId('item-title');
-  const findDropdownItemNamespaces = () => wrapper.findAllByTestId('item-namespace');
-  const findDropdownAvatars = () => wrapper.findAllComponents(GlAvatar);
-  const findAnyDropdownItem = () => findDropdownItems().at(0);
-  const findFirstGroupDropdownItem = () => findDropdownItems().at(1);
-  const findLoader = () => wrapper.find(GlSkeletonLoader);
-
-  const findDropdownItemTitlesText = () => findDropdownItemTitles().wrappers.map((w) => w.text());
-  const findDropdownItemNamespacesText = () =>
-    findDropdownItemNamespaces().wrappers.map((w) => w.text());
-  const findDropdownAvatarUrls = () => findDropdownAvatars().wrappers.map((w) => w.props('src'));
+  const findSearchableDropdownItems = () =>
+    findGlDropdown().findAllComponents(SearchableDropdownItem);
+  const findAnyDropdownItem = () => findGlDropdown().findComponent(GlDropdownItem);
+  const findFirstGroupDropdownItem = () => findSearchableDropdownItems().at(0);
+  const findLoader = () => wrapper.findComponent(GlSkeletonLoader);
 
   describe('template', () => {
     beforeEach(() => {
@@ -109,19 +92,12 @@ describe('Global Search Searchable Dropdown', () => {
           expect(findLoader().exists()).toBe(false);
         });
 
-        it('renders titles correctly including Any', () => {
-          const resultsIncludeAny = ['Any'].concat(MOCK_GROUPS.map((n) => n[GROUP_DATA.name]));
-          expect(findDropdownItemTitlesText()).toStrictEqual(resultsIncludeAny);
-        });
-
-        it('renders namespaces truncated correctly', () => {
-          const namespaces = MOCK_GROUPS.map((n) => truncateNamespace(n[GROUP_DATA.fullName]));
-          expect(findDropdownItemNamespacesText()).toStrictEqual(namespaces);
+        it('renders the Any Dropdown', () => {
+          expect(findAnyDropdownItem().exists()).toBe(true);
         });
 
-        it('renders GlAvatar for each item', () => {
-          const avatars = MOCK_GROUPS.map((n) => n.avatar_url);
-          expect(findDropdownAvatarUrls()).toStrictEqual(avatars);
+        it('renders SearchableDropdownItem for each item', () => {
+          expect(findSearchableDropdownItems()).toHaveLength(MOCK_GROUPS.length);
         });
       });
 
@@ -134,18 +110,12 @@ describe('Global Search Searchable Dropdown', () => {
           expect(findLoader().exists()).toBe(true);
         });
 
-        it('renders only Any in dropdown', () => {
-          expect(findDropdownItemTitlesText()).toStrictEqual(['Any']);
-        });
-      });
-
-      describe('when item is selected', () => {
-        beforeEach(() => {
-          createComponent({}, { items: MOCK_GROUPS, selectedItem: MOCK_GROUPS[0] });
+        it('renders the Any Dropdown', () => {
+          expect(findAnyDropdownItem().exists()).toBe(true);
         });
 
-        it('marks the dropdown as checked', () => {
-          expect(findFirstGroupDropdownItem().attributes('ischecked')).toBe('true');
+        it('does not render SearchableDropdownItem', () => {
+          expect(findSearchableDropdownItems()).toHaveLength(0);
         });
       });
     });
@@ -184,8 +154,8 @@ describe('Global Search Searchable Dropdown', () => {
       expect(wrapper.emitted('change')[0]).toEqual([ANY_OPTION]);
     });
 
-    it('clicking result dropdown item $emits @change with result', () => {
-      findFirstGroupDropdownItem().vm.$emit('click');
+    it('on SearchableDropdownItem @change, the wrapper $emits change with the item', () => {
+      findFirstGroupDropdownItem().vm.$emit('change', MOCK_GROUPS[0]);
 
       expect(wrapper.emitted('change')[0]).toEqual([MOCK_GROUPS[0]]);
     });
diff --git a/spec/graphql/mutations/todos/mark_all_done_spec.rb b/spec/graphql/mutations/todos/mark_all_done_spec.rb
index f3b6bf52ef7..1e12d86aa18 100644
--- a/spec/graphql/mutations/todos/mark_all_done_spec.rb
+++ b/spec/graphql/mutations/todos/mark_all_done_spec.rb
@@ -21,26 +21,25 @@ RSpec.describe Mutations::Todos::MarkAllDone do
 
   describe '#resolve' do
     it 'marks all pending todos as done' do
-      updated_todo_ids, todos = mutation_for(current_user).resolve.values_at(:updated_ids, :todos)
+      todos = mutation_for(current_user).resolve[:todos]
 
       expect(todo1.reload.state).to eq('done')
       expect(todo2.reload.state).to eq('done')
       expect(todo3.reload.state).to eq('done')
       expect(other_user_todo.reload.state).to eq('pending')
 
-      expect(updated_todo_ids).to contain_exactly(todo1.id, todo3.id)
       expect(todos).to contain_exactly(todo1, todo3)
     end
 
     it 'behaves as expected if there are no todos for the requesting user' do
-      updated_todo_ids = mutation_for(user3).resolve.dig(:updated_ids)
+      todos = mutation_for(user3).resolve[:todos]
 
       expect(todo1.reload.state).to eq('pending')
       expect(todo2.reload.state).to eq('done')
       expect(todo3.reload.state).to eq('pending')
       expect(other_user_todo.reload.state).to eq('pending')
 
-      expect(updated_todo_ids).to be_empty
+      expect(todos).to be_empty
     end
 
     context 'when user is not logged in' do
diff --git a/spec/graphql/resolvers/group_packages_resolver_spec.rb b/spec/graphql/resolvers/group_packages_resolver_spec.rb
index 48f4c8ec4ca..eba3a5f2de8 100644
--- a/spec/graphql/resolvers/group_packages_resolver_spec.rb
+++ b/spec/graphql/resolvers/group_packages_resolver_spec.rb
@@ -7,7 +7,7 @@ RSpec.describe Resolvers::GroupPackagesResolver do
 
   let_it_be(:user) { create(:user) }
   let_it_be(:group) { create(:group, :public) }
-  let_it_be(:project) { create(:project, :public, group: group) }
+  let_it_be(:project) { create(:project, :public, group: group, path: 'a') }
 
   let(:args) do
     { sort: :created_desc }
@@ -17,5 +17,25 @@ RSpec.describe Resolvers::GroupPackagesResolver do
     subject { resolve(described_class, ctx: { current_user: user }, obj: group, args: args).to_a }
 
     it_behaves_like 'group and projects packages resolver'
+
+    describe 'project_path sorting' do
+      let_it_be(:project2) { create(:project, :public, group: group, path: 'b') }
+      let_it_be(:package) { create(:package, project: project ) }
+      let_it_be(:package2) { create(:package, project: project2 ) }
+      let_it_be(:package3) { create(:package, project: project ) }
+      let_it_be(:package4) { create(:package, project: project2 ) }
+
+      context 'filter by package_name' do
+        let(:args) { { sort: :project_path_desc } }
+
+        it { is_expected.to eq([package4, package2, package3, package]) }
+      end
+
+      context 'filter by package_type' do
+        let(:args) { { sort: :project_path_asc } }
+
+        it { is_expected.to eq([package, package3, package2, package4]) }
+      end
+    end
   end
 end
diff --git a/spec/graphql/types/mutation_type_spec.rb b/spec/graphql/types/mutation_type_spec.rb
index e4144e4fa97..c1a5c93c85b 100644
--- a/spec/graphql/types/mutation_type_spec.rb
+++ b/spec/graphql/types/mutation_type_spec.rb
@@ -15,28 +15,6 @@ RSpec.describe Types::MutationType do
     expect(described_class).to have_graphql_mutation(Mutations::MergeRequests::SetDraft)
   end
 
-  describe 'deprecated and aliased mutations' do
-    using RSpec::Parameterized::TableSyntax
-
-    where(:alias_name, :canonical_name) do
-      'AddAwardEmoji'    | 'AwardEmojiAdd'
-      'RemoveAwardEmoji' | 'AwardEmojiRemove'
-      'ToggleAwardEmoji' | 'AwardEmojiToggle'
-    end
-
-    with_them do
-      let(:alias_field) { get_field(alias_name) }
-      let(:canonical_field) { get_field(canonical_name) }
-
-      it { expect(alias_field).to be_present }
-      it { expect(canonical_field).to be_present }
-      it { expect(alias_field.deprecation_reason).to be_present }
-      it { expect(canonical_field.deprecation_reason).not_to be_present }
-      it { expect(alias_field.resolver.fields).to eq(canonical_field.resolver.fields) }
-      it { expect(alias_field.resolver.arguments).to eq(canonical_field.resolver.arguments) }
-    end
-  end
-
   def get_field(name)
     described_class.fields[GraphqlHelpers.fieldnamerize(name)]
   end
diff --git a/spec/graphql/types/packages/package_group_sort_enum_spec.rb b/spec/graphql/types/packages/package_group_sort_enum_spec.rb
new file mode 100644
index 00000000000..f2ed8f66fb3
--- /dev/null
+++ b/spec/graphql/types/packages/package_group_sort_enum_spec.rb
@@ -0,0 +1,9 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe GitlabSchema.types['PackageGroupSort'] do
+  it 'exposes all package group sort values' do
+    expect(described_class.values.keys).to contain_exactly(*%w[CREATED_DESC CREATED_ASC NAME_DESC NAME_ASC PROJECT_PATH_DESC PROJECT_PATH_ASC VERSION_DESC VERSION_ASC TYPE_DESC TYPE_ASC])
+  end
+end
diff --git a/spec/graphql/types/packages/package_sort_enum_spec.rb b/spec/graphql/types/packages/package_sort_enum_spec.rb
new file mode 100644
index 00000000000..fe9ce120c73
--- /dev/null
+++ b/spec/graphql/types/packages/package_sort_enum_spec.rb
@@ -0,0 +1,9 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+
+RSpec.describe GitlabSchema.types['PackageSort'] do
+  it 'exposes all package sort values' do
+    expect(described_class.values.keys).to contain_exactly(*%w[CREATED_DESC CREATED_ASC NAME_DESC NAME_ASC VERSION_DESC VERSION_ASC TYPE_DESC TYPE_ASC])
+  end
+end
diff --git a/spec/graphql/types/snippet_type_spec.rb b/spec/graphql/types/snippet_type_spec.rb
index b87770ebe8d..f284d88180c 100644
--- a/spec/graphql/types/snippet_type_spec.rb
+++ b/spec/graphql/types/snippet_type_spec.rb
@@ -13,7 +13,7 @@ RSpec.describe GitlabSchema.types['Snippet'] do
                        :visibility_level, :created_at, :updated_at,
                        :web_url, :raw_url, :ssh_url_to_repo, :http_url_to_repo,
                        :notes, :discussions, :user_permissions,
-                       :description_html, :blob, :blobs]
+                       :description_html, :blobs]
 
     expect(described_class).to have_graphql_fields(*expected_fields)
   end
@@ -133,32 +133,6 @@ RSpec.describe GitlabSchema.types['Snippet'] do
     end
   end
 
-  describe '#blob' do
-    let(:query_blob) { subject.dig('data', 'snippets', 'nodes')[0]['blob'] }
-
-    subject { GitlabSchema.execute(snippet_query_for(field: 'blob'), context: { current_user: user }).as_json }
-
-    context 'when snippet has repository' do
-      let!(:snippet) { create(:personal_snippet, :repository, :public, author: user) }
-      let(:blob) { snippet.blobs.first }
-
-      it 'returns the first blob from the repository' do
-        expect(query_blob['name']).to eq blob.name
-        expect(query_blob['path']).to eq blob.path
-      end
-    end
-
-    context 'when snippet does not have a repository' do
-      let!(:snippet) { create(:personal_snippet, :public, author: user) }
-      let(:blob) { snippet.blob }
-
-      it 'returns SnippetBlob type' do
-        expect(query_blob['name']).to eq blob.name
-        expect(query_blob['path']).to eq blob.path
-      end
-    end
-  end
-
   describe '#blobs' do
     let_it_be(:snippet) { create(:personal_snippet, :public, author: user) }
 
diff --git a/spec/graphql/types/snippets/blob_viewer_type_spec.rb b/spec/graphql/types/snippets/blob_viewer_type_spec.rb
index 295df992c67..c3b98236f2b 100644
--- a/spec/graphql/types/snippets/blob_viewer_type_spec.rb
+++ b/spec/graphql/types/snippets/blob_viewer_type_spec.rb
@@ -31,7 +31,7 @@ RSpec.describe GitlabSchema.types['SnippetBlobViewer'] do
     end
 
     it 'returns false' do
-      snippet_blob = subject.dig('data', 'snippets', 'edges')[0].dig('node', 'blob')
+      snippet_blob = subject.dig('data', 'snippets', 'edges').first.dig('node', 'blobs', 'nodes').find { |b| b['path'] == blob.path }
 
       expect(snippet_blob['path']).to eq blob.path
       expect(blob_attribute).to be_nil
@@ -47,10 +47,12 @@ RSpec.describe GitlabSchema.types['SnippetBlobViewer'] do
             snippets(ids: "#{snippet.to_global_id}") {
               edges {
                 node {
-                  blob {
-                    path
-                    simpleViewer {
-                      collapsed
+                  blobs {
+                    nodes {
+                      path
+                      simpleViewer {
+                        collapsed
+                      }
                     }
                   }
                 }
@@ -73,10 +75,12 @@ RSpec.describe GitlabSchema.types['SnippetBlobViewer'] do
             snippets(ids: "#{snippet.to_global_id}") {
               edges {
                 node {
-                  blob {
-                    path
-                    simpleViewer {
-                      tooLarge
+                  blobs {
+                    nodes {
+                      path
+                      simpleViewer {
+                        tooLarge
+                      }
                     }
                   }
                 }
diff --git a/spec/lib/gitlab/database/background_migration/batched_migration_spec.rb b/spec/lib/gitlab/database/background_migration/batched_migration_spec.rb
index 47f9bcc08d2..d881390cd52 100644
--- a/spec/lib/gitlab/database/background_migration/batched_migration_spec.rb
+++ b/spec/lib/gitlab/database/background_migration/batched_migration_spec.rb
@@ -19,6 +19,12 @@ RSpec.describe Gitlab::Database::BackgroundMigration::BatchedMigration, type: :m
     end
   end
 
+  describe 'validations' do
+    subject { build(:batched_background_migration) }
+
+    it { is_expected.to validate_uniqueness_of(:job_arguments).scoped_to(:job_class_name, :table_name, :column_name) }
+  end
+
   describe '.queue_order' do
     let!(:migration1) { create(:batched_background_migration) }
     let!(:migration2) { create(:batched_background_migration) }
diff --git a/spec/lib/gitlab/database/load_balancing_spec.rb b/spec/lib/gitlab/database/load_balancing_spec.rb
index c3dcfa3eb4a..f8aeafbf61a 100644
--- a/spec/lib/gitlab/database/load_balancing_spec.rb
+++ b/spec/lib/gitlab/database/load_balancing_spec.rb
@@ -182,31 +182,6 @@ RSpec.describe Gitlab::Database::LoadBalancing do
         expect(described_class.enable?).to eq(true)
       end
     end
-
-    context 'FOSS' do
-      before do
-        allow(Gitlab).to receive(:ee?).and_return(false)
-
-        stub_env('ENABLE_LOAD_BALANCING_FOR_FOSS', 'false')
-      end
-
-      it 'is disabled' do
-        expect(described_class.enable?).to eq(false)
-      end
-    end
-
-    context 'EE' do
-      before do
-        allow(Gitlab).to receive(:ee?).and_return(true)
-      end
-
-      it 'is enabled' do
-        allow(described_class).to receive(:hosts).and_return(%w(foo))
-        allow(Gitlab::Runtime).to receive(:sidekiq?).and_return(false)
-
-        expect(described_class.enable?).to eq(true)
-      end
-    end
   end
 
   describe '.configured?' do
diff --git a/spec/lib/gitlab/database/migrations/background_migration_helpers_spec.rb b/spec/lib/gitlab/database/migrations/background_migration_helpers_spec.rb
index 85083bccaca..e096e7f6e91 100644
--- a/spec/lib/gitlab/database/migrations/background_migration_helpers_spec.rb
+++ b/spec/lib/gitlab/database/migrations/background_migration_helpers_spec.rb
@@ -242,6 +242,98 @@ RSpec.describe Gitlab::Database::Migrations::BackgroundMigrationHelpers do
     end
   end
 
+  describe '#requeue_background_migration_jobs_by_range_at_intervals' do
+    let!(:job_class_name) { 'TestJob' }
+    let!(:pending_job_1) { create(:background_migration_job, class_name: job_class_name, status: :pending, arguments: [1, 2]) }
+    let!(:pending_job_2) { create(:background_migration_job, class_name: job_class_name, status: :pending, arguments: [3, 4]) }
+    let!(:successful_job_1) { create(:background_migration_job, class_name: job_class_name, status: :succeeded, arguments: [5, 6]) }
+    let!(:successful_job_2) { create(:background_migration_job, class_name: job_class_name, status: :succeeded, arguments: [7, 8]) }
+
+    around do |example|
+      freeze_time do
+        Sidekiq::Testing.fake! do
+          example.run
+        end
+      end
+    end
+
+    subject { model.requeue_background_migration_jobs_by_range_at_intervals(job_class_name, 10.minutes) }
+
+    it 'returns the expected duration' do
+      expect(subject).to eq(20.minutes)
+    end
+
+    context 'when nothing is queued' do
+      subject { model.requeue_background_migration_jobs_by_range_at_intervals('FakeJob', 10.minutes) }
+
+      it 'returns expected duration of zero when nothing gets queued' do
+        expect(subject).to eq(0)
+      end
+    end
+
+    it 'queues pending jobs' do
+      subject
+
+      expect(BackgroundMigrationWorker.jobs[0]['args']).to eq([job_class_name, [1, 2]])
+      expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
+      expect(BackgroundMigrationWorker.jobs[1]['args']).to eq([job_class_name, [3, 4]])
+      expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(10.minutes.from_now.to_f)
+    end
+
+    context 'with batch_size option' do
+      subject { model.requeue_background_migration_jobs_by_range_at_intervals(job_class_name, 10.minutes, batch_size: 1) }
+
+      it 'returns the expected duration' do
+        expect(subject).to eq(20.minutes)
+      end
+
+      it 'queues pending jobs' do
+        subject
+
+        expect(BackgroundMigrationWorker.jobs[0]['args']).to eq([job_class_name, [1, 2]])
+        expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
+        expect(BackgroundMigrationWorker.jobs[1]['args']).to eq([job_class_name, [3, 4]])
+        expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(10.minutes.from_now.to_f)
+      end
+
+      it 'retrieve jobs in batches' do
+        jobs = double('jobs')
+        expect(Gitlab::Database::BackgroundMigrationJob).to receive(:pending) { jobs }
+        allow(jobs).to receive(:where).with(class_name: job_class_name) { jobs }
+        expect(jobs).to receive(:each_batch).with(of: 1)
+
+        subject
+      end
+    end
+
+    context 'with initial_delay option' do
+      let_it_be(:initial_delay) { 3.minutes }
+
+      subject { model.requeue_background_migration_jobs_by_range_at_intervals(job_class_name, 10.minutes, initial_delay: initial_delay) }
+
+      it 'returns the expected duration' do
+        expect(subject).to eq(23.minutes)
+      end
+
+      it 'queues pending jobs' do
+        subject
+
+        expect(BackgroundMigrationWorker.jobs[0]['args']).to eq([job_class_name, [1, 2]])
+        expect(BackgroundMigrationWorker.jobs[0]['at']).to eq(3.minutes.from_now.to_f)
+        expect(BackgroundMigrationWorker.jobs[1]['args']).to eq([job_class_name, [3, 4]])
+        expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(13.minutes.from_now.to_f)
+      end
+
+      context 'when nothing is queued' do
+        subject { model.requeue_background_migration_jobs_by_range_at_intervals('FakeJob', 10.minutes) }
+
+        it 'returns expected duration of zero when nothing gets queued' do
+          expect(subject).to eq(0)
+        end
+      end
+    end
+  end
+
   describe '#perform_background_migration_inline?' do
     it 'returns true in a test environment' do
       stub_rails_env('test')
diff --git a/spec/migrations/retry_backfill_traversal_ids_spec.rb b/spec/migrations/retry_backfill_traversal_ids_spec.rb
new file mode 100644
index 00000000000..e5ebd4228ca
--- /dev/null
+++ b/spec/migrations/retry_backfill_traversal_ids_spec.rb
@@ -0,0 +1,93 @@
+# frozen_string_literal: true
+
+require 'spec_helper'
+require Rails.root.join('db', 'post_migrate', '20210604070207_retry_backfill_traversal_ids.rb')
+
+RSpec.describe RetryBackfillTraversalIds, :migration do
+  include ReloadHelpers
+
+  let_it_be(:namespaces_table) { table(:namespaces) }
+
+  context 'when BackfillNamespaceTraversalIdsRoots jobs are pending' do
+    before do
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsRoots',
+        arguments: [1, 4, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
+      )
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsRoots',
+        arguments: [5, 9, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
+      )
+    end
+
+    it 'queues pending jobs' do
+      migrate!
+
+      expect(BackgroundMigrationWorker.jobs.length).to eq(1)
+      expect(BackgroundMigrationWorker.jobs[0]['args']).to eq(['BackfillNamespaceTraversalIdsRoots', [1, 4, 100]])
+      expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
+    end
+  end
+
+  context 'when BackfillNamespaceTraversalIdsChildren jobs are pending' do
+    before do
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsChildren',
+        arguments: [1, 4, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
+      )
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsRoots',
+        arguments: [5, 9, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
+      )
+    end
+
+    it 'queues pending jobs' do
+      migrate!
+
+      expect(BackgroundMigrationWorker.jobs.length).to eq(1)
+      expect(BackgroundMigrationWorker.jobs[0]['args']).to eq(['BackfillNamespaceTraversalIdsChildren', [1, 4, 100]])
+      expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
+    end
+  end
+
+  context 'when BackfillNamespaceTraversalIdsRoots and BackfillNamespaceTraversalIdsChildren jobs are pending' do
+    before do
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsRoots',
+        arguments: [1, 4, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
+      )
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsChildren',
+        arguments: [5, 9, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['pending']
+      )
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsRoots',
+        arguments: [11, 14, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
+      )
+      table(:background_migration_jobs).create!(
+        class_name: 'BackfillNamespaceTraversalIdsChildren',
+        arguments: [15, 19, 100],
+        status: Gitlab::Database::BackgroundMigrationJob.statuses['succeeded']
+      )
+    end
+
+    it 'queues pending jobs' do
+      freeze_time do
+        migrate!
+
+        expect(BackgroundMigrationWorker.jobs.length).to eq(2)
+        expect(BackgroundMigrationWorker.jobs[0]['args']).to eq(['BackfillNamespaceTraversalIdsRoots', [1, 4, 100]])
+        expect(BackgroundMigrationWorker.jobs[0]['at']).to be_nil
+        expect(BackgroundMigrationWorker.jobs[1]['args']).to eq(['BackfillNamespaceTraversalIdsChildren', [5, 9, 100]])
+        expect(BackgroundMigrationWorker.jobs[1]['at']).to eq(RetryBackfillTraversalIds::DELAY_INTERVAL.from_now.to_f)
+      end
+    end
+  end
+end
diff --git a/spec/models/concerns/has_user_type_spec.rb b/spec/models/concerns/has_user_type_spec.rb
index c87bbf24c30..a6a0e074589 100644
--- a/spec/models/concerns/has_user_type_spec.rb
+++ b/spec/models/concerns/has_user_type_spec.rb
@@ -5,7 +5,7 @@ require 'spec_helper'
 RSpec.describe User do
   specify 'types consistency checks', :aggregate_failures do
     expect(described_class::USER_TYPES.keys)
-      .to match_array(%w[human ghost alert_bot project_bot support_bot service_user security_bot visual_review_bot migration_bot])
+      .to match_array(%w[human ghost alert_bot project_bot support_bot service_user security_bot visual_review_bot migration_bot automation_bot])
     expect(described_class::USER_TYPES).to include(*described_class::BOT_USER_TYPES)
     expect(described_class::USER_TYPES).to include(*described_class::NON_INTERNAL_USER_TYPES)
     expect(described_class::USER_TYPES).to include(*described_class::INTERNAL_USER_TYPES)
diff --git a/spec/models/concerns/token_authenticatable_strategies/encryption_helper_spec.rb b/spec/models/concerns/token_authenticatable_strategies/encryption_helper_spec.rb
index 6f322a32a3b..671e51e3913 100644
--- a/spec/models/concerns/token_authenticatable_strategies/encryption_helper_spec.rb
+++ b/spec/models/concerns/token_authenticatable_strategies/encryption_helper_spec.rb
@@ -3,25 +3,99 @@
 require 'spec_helper'
 
 RSpec.describe TokenAuthenticatableStrategies::EncryptionHelper do
-  let(:encrypted_token) { described_class.encrypt_token('my-value') }
+  let(:encrypted_token) { described_class.encrypt_token('my-value-my-value-my-value') }
 
   describe '.encrypt_token' do
-    it 'encrypts token' do
-      expect(encrypted_token).not_to eq('my-value')
+    context 'when dynamic_nonce feature flag is switched on' do
+      it 'adds nonce identifier on the beginning' do
+        expect(encrypted_token.first).to eq(described_class::DYNAMIC_NONCE_IDENTIFIER)
+      end
+
+      it 'adds nonce at the end' do
+        nonce = encrypted_token.last(described_class::NONCE_SIZE)
+
+        expect(nonce).to eq(::Digest::SHA256.hexdigest('my-value-my-value-my-value').bytes.take(described_class::NONCE_SIZE).pack('c*'))
+      end
+
+      it 'encrypts token' do
+        expect(encrypted_token[1...-described_class::NONCE_SIZE]).not_to eq('my-value-my-value-my-value')
+      end
+    end
+
+    context 'when dynamic_nonce feature flag is switched off' do
+      before do
+        stub_feature_flags(dynamic_nonce: false)
+      end
+
+      it 'does not add nonce identifier on the beginning' do
+        expect(encrypted_token.first).not_to eq(described_class::DYNAMIC_NONCE_IDENTIFIER)
+      end
+
+      it 'does not add nonce in the end' do
+        nonce = encrypted_token.last(described_class::NONCE_SIZE)
+
+        expect(nonce).not_to eq(::Digest::SHA256.hexdigest('my-value-my-value-my-value').bytes.take(described_class::NONCE_SIZE).pack('c*'))
+      end
+
+      it 'encrypts token with static iv' do
+        token = Gitlab::CryptoHelper.aes256_gcm_encrypt('my-value-my-value-my-value')
+
+        expect(encrypted_token).to eq(token)
+      end
     end
   end
 
   describe '.decrypt_token' do
-    it 'decrypts token with static iv' do
-      expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
+    context 'with feature flag switched off' do
+      before do
+        stub_feature_flags(dynamic_nonce: false)
+      end
+
+      it 'decrypts token with static iv' do
+        encrypted_token = described_class.encrypt_token('my-value')
+
+        expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
+      end
+
+      it 'decrypts token if feature flag changed after encryption' do
+        encrypted_token = described_class.encrypt_token('my-value')
+
+        expect(encrypted_token).not_to eq('my-value')
+
+        stub_feature_flags(dynamic_nonce: true)
+
+        expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
+      end
+
+      it 'decrypts token with dynamic iv' do
+        iv = ::Digest::SHA256.hexdigest('my-value').bytes.take(described_class::NONCE_SIZE).pack('c*')
+        token = Gitlab::CryptoHelper.aes256_gcm_encrypt('my-value', nonce: iv)
+        encrypted_token = "#{described_class::DYNAMIC_NONCE_IDENTIFIER}#{token}#{iv}"
+
+        expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
+      end
     end
 
-    it 'decrypts token with dynamic iv' do
-      iv = ::Digest::SHA256.hexdigest('my-value').bytes.take(described_class::NONCE_SIZE).pack('c*')
-      token = Gitlab::CryptoHelper.aes256_gcm_encrypt('my-value', nonce: iv)
-      encrypted_token = "#{described_class::DYNAMIC_NONCE_IDENTIFIER}#{token}#{iv}"
+    context 'with feature flag switched on' do
+      before do
+        stub_feature_flags(dynamic_nonce: true)
+      end
+
+      it 'decrypts token with dynamic iv' do
+        encrypted_token = described_class.encrypt_token('my-value')
+
+        expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
+      end
+
+      it 'decrypts token if feature flag changed after encryption' do
+        encrypted_token = described_class.encrypt_token('my-value')
+
+        expect(encrypted_token).not_to eq('my-value')
+
+        stub_feature_flags(dynamic_nonce: false)
 
-      expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
+        expect(described_class.decrypt_token(encrypted_token)).to eq('my-value')
+      end
     end
   end
 end
diff --git a/spec/models/milestone_spec.rb b/spec/models/milestone_spec.rb
index fac498bc94a..7cf7c360dff 100644
--- a/spec/models/milestone_spec.rb
+++ b/spec/models/milestone_spec.rb
@@ -8,7 +8,46 @@ RSpec.describe Milestone do
   let(:milestone) { create(:milestone, project: project) }
   let(:project) { create(:project, :public) }
 
-  it_behaves_like 'a timebox', :milestone
+  it_behaves_like 'a timebox', :milestone do
+    describe "#uniqueness_of_title" do
+      context "per project" do
+        it "does not accept the same title in a project twice" do
+          new_timebox = timebox.dup
+          expect(new_timebox).not_to be_valid
+        end
+
+        it "accepts the same title in another project" do
+          project = create(:project)
+          new_timebox = timebox.dup
+          new_timebox.project = project
+
+          expect(new_timebox).to be_valid
+        end
+      end
+
+      context "per group" do
+        let(:timebox) { create(:milestone, *timebox_args, group: group) }
+
+        before do
+          project.update!(group: group)
+        end
+
+        it "does not accept the same title in a group twice" do
+          new_timebox = described_class.new(group: group, title: timebox.title)
+
+          expect(new_timebox).not_to be_valid
+        end
+
+        it "does not accept the same title of a child project timebox" do
+          create(:milestone, *timebox_args, project: group.projects.first)
+
+          new_timebox = described_class.new(group: group, title: timebox.title)
+
+          expect(new_timebox).not_to be_valid
+        end
+      end
+    end
+  end
 
   describe 'MilestoneStruct#serializable_hash' do
     let(:predefined_milestone) { described_class::TimeboxStruct.new('Test Milestone', '#test', 1) }
diff --git a/spec/models/user_spec.rb b/spec/models/user_spec.rb
index d423a916d68..f1c30a646f5 100644
--- a/spec/models/user_spec.rb
+++ b/spec/models/user_spec.rb
@@ -5248,9 +5248,10 @@ RSpec.describe User do
     let_it_be(:user3) { create(:user, :ghost) }
     let_it_be(:user4) { create(:user, user_type: :support_bot) }
     let_it_be(:user5) { create(:user, state: 'blocked', user_type: :support_bot) }
+    let_it_be(:user6) { create(:user, user_type: :automation_bot) }
 
     it 'returns all active users including active bots but ghost users' do
-      expect(described_class.active_without_ghosts).to match_array([user1, user4])
+      expect(described_class.active_without_ghosts).to match_array([user1, user4, user6])
     end
   end
 
@@ -5385,7 +5386,8 @@ RSpec.describe User do
             { user_type: :ghost },
             { user_type: :alert_bot },
             { user_type: :support_bot },
-            { user_type: :security_bot }
+            { user_type: :security_bot },
+            { user_type: :automation_bot }
           ]
         end
 
@@ -5441,6 +5443,7 @@ RSpec.describe User do
         'alert_bot'         | false
         'support_bot'       | false
         'security_bot'      | false
+        'automation_bot'    | false
       end
 
       with_them do
@@ -5588,10 +5591,12 @@ RSpec.describe User do
     it_behaves_like 'bot users', :migration_bot
     it_behaves_like 'bot users', :security_bot
     it_behaves_like 'bot users', :ghost
+    it_behaves_like 'bot users', :automation_bot
 
     it_behaves_like 'bot user avatars', :alert_bot, 'alert-bot.png'
     it_behaves_like 'bot user avatars', :support_bot, 'support-bot.png'
     it_behaves_like 'bot user avatars', :security_bot, 'security-bot.png'
+    it_behaves_like 'bot user avatars', :automation_bot, 'support-bot.png'
 
     context 'when bot is the support_bot' do
       subject { described_class.support_bot }
diff --git a/spec/requests/api/graphql/mutations/todos/mark_all_done_spec.rb b/spec/requests/api/graphql/mutations/todos/mark_all_done_spec.rb
index 705ef28ffd4..8f92105dc9c 100644
--- a/spec/requests/api/graphql/mutations/todos/mark_all_done_spec.rb
+++ b/spec/requests/api/graphql/mutations/todos/mark_all_done_spec.rb
@@ -22,8 +22,8 @@ RSpec.describe 'Marking all todos done' do
     graphql_mutation(:todos_mark_all_done, input,
                      <<-QL.strip_heredoc
                        clientMutationId
+                       todos { id }
                        errors
-                       updatedIds
                      QL
     )
   end
@@ -40,7 +40,7 @@ RSpec.describe 'Marking all todos done' do
     expect(todo3.reload.state).to eq('done')
     expect(other_user_todo.reload.state).to eq('pending')
 
-    updated_todo_ids = mutation_response['updatedIds']
+    updated_todo_ids = mutation_response['todos'].map { |todo| todo['id'] }
     expect(updated_todo_ids).to contain_exactly(global_id_of(todo1), global_id_of(todo3))
   end
 
@@ -52,7 +52,7 @@ RSpec.describe 'Marking all todos done' do
     expect(todo3.reload.state).to eq('pending')
     expect(other_user_todo.reload.state).to eq('pending')
 
-    updated_todo_ids = mutation_response['updatedIds']
+    updated_todo_ids = mutation_response['todos']
     expect(updated_todo_ids).to be_empty
   end
 
diff --git a/spec/requests/api/graphql/mutations/todos/restore_many_spec.rb b/spec/requests/api/graphql/mutations/todos/restore_many_spec.rb
index 3e96d5c5058..e71a232ff7c 100644
--- a/spec/requests/api/graphql/mutations/todos/restore_many_spec.rb
+++ b/spec/requests/api/graphql/mutations/todos/restore_many_spec.rb
@@ -22,7 +22,6 @@ RSpec.describe 'Restoring many Todos' do
                      <<-QL.strip_heredoc
                        clientMutationId
                        errors
-                       updatedIds
                        todos {
                          id
                          state
@@ -44,7 +43,6 @@ RSpec.describe 'Restoring many Todos' do
 
     expect(mutation_response).to include(
       'errors' => be_empty,
-      'updatedIds' => match_array(input_ids),
       'todos' => contain_exactly(
         { 'id' => global_id_of(todo1), 'state' => 'pending' },
         { 'id' => global_id_of(todo2), 'state' => 'pending' }
diff --git a/spec/requests/api/projects_spec.rb b/spec/requests/api/projects_spec.rb
index 96390aa576b..a1532ea464e 100644
--- a/spec/requests/api/projects_spec.rb
+++ b/spec/requests/api/projects_spec.rb
@@ -53,7 +53,7 @@ RSpec.describe API::Projects do
   let_it_be(:user2) { create(:user) }
   let_it_be(:user3) { create(:user) }
   let_it_be(:admin) { create(:admin) }
-  let_it_be(:project, reload: true) { create(:project, :repository, namespace: user.namespace) }
+  let_it_be(:project, reload: true) { create(:project, :repository, create_branch: 'something_else', namespace: user.namespace) }
   let_it_be(:project2, reload: true) { create(:project, namespace: user.namespace) }
   let_it_be(:project_member) { create(:project_member, :developer, user: user3, project: project) }
   let_it_be(:user4) { create(:user, username: 'user.with.dot') }
@@ -2895,6 +2895,18 @@ RSpec.describe API::Projects do
         end
       end
 
+      it 'updates default_branch' do
+        project_param = { default_branch: 'something_else' }
+
+        put api("/projects/#{project.id}", user), params: project_param
+
+        expect(response).to have_gitlab_http_status(:ok)
+
+        project_param.each_pair do |k, v|
+          expect(json_response[k.to_s]).to eq(v)
+        end
+      end
+
       it 'updates jobs_enabled' do
         project_param = { jobs_enabled: true }
 
diff --git a/spec/support/shared_contexts/load_balancing_configuration_shared_context.rb b/spec/support/shared_contexts/load_balancing_configuration_shared_context.rb
index 8e27d7987e8..a61b8e9a074 100644
--- a/spec/support/shared_contexts/load_balancing_configuration_shared_context.rb
+++ b/spec/support/shared_contexts/load_balancing_configuration_shared_context.rb
@@ -6,8 +6,6 @@ RSpec.shared_context 'clear DB Load Balancing configuration' do
     proxy.load_balancer.release_host if proxy
     ::Gitlab::Database::LoadBalancing.instance_variable_set(:@proxy, nil)
 
-    ::Gitlab::Database::LoadBalancing.remove_instance_variable(:@feature_available) if ::Gitlab::Database::LoadBalancing.instance_variable_defined?(:@feature_available)
-
     ::Gitlab::Database::LoadBalancing::Session.clear_session
   end
 
diff --git a/spec/support/shared_examples/models/concerns/timebox_shared_examples.rb b/spec/support/shared_examples/models/concerns/timebox_shared_examples.rb
index 68142e667a4..39121b73bc5 100644
--- a/spec/support/shared_examples/models/concerns/timebox_shared_examples.rb
+++ b/spec/support/shared_examples/models/concerns/timebox_shared_examples.rb
@@ -86,45 +86,6 @@ RSpec.shared_examples 'a timebox' do |timebox_type|
         expect(timebox.errors[:project_id]).to include("#{timebox_type} should belong either to a project or a group.")
       end
     end
-
-    describe "#uniqueness_of_title" do
-      context "per project" do
-        it "does not accept the same title in a project twice" do
-          new_timebox = timebox.dup
-          expect(new_timebox).not_to be_valid
-        end
-
-        it "accepts the same title in another project" do
-          project = create(:project)
-          new_timebox = timebox.dup
-          new_timebox.project = project
-
-          expect(new_timebox).to be_valid
-        end
-      end
-
-      context "per group" do
-        let(:timebox) { create(timebox_type, *timebox_args, group: group) }
-
-        before do
-          project.update!(group: group)
-        end
-
-        it "does not accept the same title in a group twice" do
-          new_timebox = described_class.new(group: group, title: timebox.title)
-
-          expect(new_timebox).not_to be_valid
-        end
-
-        it "does not accept the same title of a child project timebox" do
-          create(timebox_type, *timebox_args, project: group.projects.first)
-
-          new_timebox = described_class.new(group: group, title: timebox.title)
-
-          expect(new_timebox).not_to be_valid
-        end
-      end
-    end
   end
 
   describe "Associations" do