Add latest changes from gitlab-org/gitlab@16-3-stable-eev16.3.0-rc42

136 files changed, 3778 insertions, 2493 deletions

diff --git a/doc/administration/application_settings_cache.md b/doc/administration/application_settings_cache.md
index 30019df44aa..d88afcbb401 100644
--- a/doc/administration/application_settings_cache.md
+++ b/doc/administration/application_settings_cache.md
@@ -45,7 +45,7 @@ To change the expiry value:
      application_settings_cache_seconds: 60
    ```
 
-1. Save the file, and then [restart](restart_gitlab.md#installations-from-source)
+1. Save the file, and then [restart](restart_gitlab.md#self-compiled-installations)
    GitLab for the changes to take effect.
 
 ::EndTabs
diff --git a/doc/administration/audit_event_streaming/audit_event_types.md b/doc/administration/audit_event_streaming/audit_event_types.md
new file mode 100644
index 00000000000..b69f1815394
--- /dev/null
+++ b/doc/administration/audit_event_streaming/audit_event_types.md
@@ -0,0 +1,291 @@
+---
+stage: Govern
+group: Compliance
+info: "See the Technical Writers assigned to Development Guidelines: https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-development-guidelines"
+---
+
+<!---
+  This documentation is auto generated by a Rake task.
+
+  Please do not edit this file directly. To update this file, run:
+  bundle exec rake gitlab:audit_event_types:compile_docs
+--->
+
+# Audit event types **(ULTIMATE)**
+
+Audit event types are used to [filter streamed audit events](index.md#update-event-filters).
+
+Every audit event is associated with an event type. The association with the event type can mean that an audit event is:
+
+- Saved to database. Audit events associated with these types are retrievable by using the audit events dashboard or the [audit events API](../../api/audit_events.md).
+- Streamed. Audit events associated with these types are [streamed to external destinations](../index.md) if a
+  destination is set.
+- Not streamed. Audit events associated with these types are not streamed to external destinations even if a destination is set.
+
+## Available audit event types
+
+| Name | Description | Saved to database | Streamed | Feature category | Introduced in |
+|:-----|:------------|:------------------|:---------|:-----------------|:--------------|
+| [`add_gpg_key`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111744) | Event triggered when a GPG Key is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/373961) |
+| [`allow_author_approval_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102256) | Event triggered on updating prevent merge request approval from authors from group merge request setting | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/373949) |
+| [`allow_committer_approval_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102256) | Event triggered on updating prevent merge request approval from committers from group merge request setting | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/373949) |
+| [`allow_merge_on_skipped_pipeline_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83922) | There is a project setting which toggles the ability to merge when a pipeline is skipped. This audit event tracks changes to that setting. This MR adds a setting to allow this (like previous GitLab versions). | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_integration` | GitLab [14.10](https://gitlab.com/gitlab-org/gitlab/-/issues/301124) |
+| [`allow_overrides_to_approver_list_per_merge_request_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102256) | Event triggered on updating prevent users from modifying MR approval rules in merge requests from group merge request setting | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/373949) |
+| [`application_setting_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124639) | Triggered when Application setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `system_access` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/282428) |
+| [`approval_rule_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89939) | Triggered when a merge request approval rule is created | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363092) |
+| [`approval_rule_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82297) | Triggered on successful approval rule deletion | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [14.9](https://gitlab.com/gitlab-org/gitlab/-/issues/329514) |
+| [`audit_events_streaming_headers_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92068) | Triggered when a streaming header for audit events is created | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/366350) |
+| [`audit_events_streaming_headers_destroy`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92068) | Triggered when a streaming header for audit events is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/366350) |
+| [`audit_events_streaming_headers_update`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92068) | Triggered when a streaming header for audit events is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/366350) |
+| [`audit_events_streaming_instance_headers_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125870) | Triggered when a streaming header for instance level external audit event destination is created | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/417433) |
+| [`audit_events_streaming_instance_headers_destroy`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/127228) | Triggered when a streaming header for instance level external audit event destination is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/417433) |
+| [`audit_events_streaming_instance_headers_update`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/127228) | Triggered when a streaming header for instance level external audit event destination is updated | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/417433) |
+| [`authenticated_with_group_saml`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28575) | Triggered after successfully signing in with SAML authentication | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [12.10](https://gitlab.com/gitlab-org/gitlab/-/issues/35710) |
+| [`ban_user`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116103) | Event triggered on user ban action | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/377620) |
+| [`change_membership_state`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87924) | Event triggered on a users membership is updated | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/362200) |
+| [`ci_group_variable_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91983) | Triggered when a CI variable is created at a group level | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_integration` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363090) |
+| [`ci_group_variable_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91983) | Triggered when a group's CI variable is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_integration` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363090) |
+| [`ci_group_variable_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91983) | Triggered when a group's CI variable is updated | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_integration` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363090) |
+| [`ci_variable_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91983) | Triggered when a CI variable is created at a project level | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_integration` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363090) |
+| [`ci_variable_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91983) | Triggered when a project's CI variable is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_integration` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363090) |
+| [`ci_variable_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91983) | Triggered when a project's CI variable is updated | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_integration` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363090) |
+| [`cluster_agent_token_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112036) | Event triggered when a user creates a cluster agent token | **{check-circle}** Yes | **{check-circle}** Yes | `deployment_management` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/382133) |
+| [`cluster_agent_token_revoked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112036) | Event triggered when a user revokes a cluster agent token | **{check-circle}** Yes | **{check-circle}** Yes | `deployment_management` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/382133) |
+| [`code_suggestions_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117174) | Code Suggestion UI group setting change | **{check-circle}** Yes | **{check-circle}** Yes | `code_suggestions` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/405295) |
+| [`comment_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120927) | Triggered when a comment is added to an issue or an MR using the project access token | **{dotted-circle}** No | **{check-circle}** Yes | `team_planning` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`compliance_framework_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65343) | Triggered when a framework gets removed from a project | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/329362) |
+| [`compliance_framework_id_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/94711) | audit when compliance framework ID is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369310) |
+| [`coverage_fuzzing_corpus_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/71992) | Event triggered on a corpus action is added | **{check-circle}** Yes | **{check-circle}** Yes | `fuzz_testing` | GitLab [14.5](https://gitlab.com/gitlab-org/gitlab/-/issues/341485) |
+| [`create_compliance_framework`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74292) | Triggered on successful compliance framework creation | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/340649) |
+| [`create_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74632) | Event triggered when an external audit event destination is created | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/344664) |
+| [`create_instance_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123882) | Event triggered when an instance level external audit event destination is created | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.2](https://gitlab.com/gitlab-org/gitlab/-/issues/404730) |
+| [`create_status_check`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84624) | Event triggered when an external status check is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/355805) |
+| [`dast_profile_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62604) | Triggered when a dynamic application security testing profile is created | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_profile_destroy`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62604) | Triggered when a dynamic application security profile is removed | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_profile_schedule_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68046) | Triggered when a dynamic application security testing profile schedule is created | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/330308) |
+| [`dast_profile_schedule_update`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66445) | Triggered when a dynamic application security testing profile schedule is updated | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/330308) |
+| [`dast_profile_update`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62604) | Triggered when a dynamic application security profile is updated | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_scanner_profile_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62007) | Triggered when a dynamic application security testing scanner profile is created | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_scanner_profile_destroy`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62007) | Triggered when a dynamic application security testing scanner profile is removed | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_scanner_profile_update`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62007) | Triggered when a dynamic application security testing scanner profile is updated | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_site_profile_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62465) | Triggered when a dynamic application security testing site profile is created | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_site_profile_destroy`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62465) | Triggered when a dynamic application security testing site profile is removed | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`dast_site_profile_update`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/62465) | Triggered when a dynamic application security testing site profile is updated | **{check-circle}** Yes | **{check-circle}** Yes | `dynamic_application_security_testing` | GitLab [14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/217872) |
+| [`delete_epic`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96773) | Event triggered on successful epic deletion | **{dotted-circle}** No | **{check-circle}** Yes | `portfolio_management` | GitLab [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/370487) |
+| [`delete_issue`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96773) | Event triggered on successful issue deletion | **{dotted-circle}** No | **{check-circle}** Yes | `team_planning` | GitLab [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/370487) |
+| [`delete_merge_request`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96773) | Event triggered on successful merge request deletion | **{dotted-circle}** No | **{check-circle}** Yes | `code_review` | GitLab [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/370487) |
+| [`delete_status_check`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84624) | Event triggered when an external status check is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/355805) |
+| [`delete_work_item`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96773) | Event triggered on successful work item deletion | **{dotted-circle}** No | **{check-circle}** Yes | `team_planning` | GitLab [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/370487) |
+| [`deploy_key_added`](https://gitlab.com/gitlab-org/gitlab/-/commit/08586a616909c7f9efe2210c2b74fd3422d4eb62) | Triggered when deploy key is added | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`deploy_key_removed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92219) | Audit event triggered when deploy key is removed | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`deploy_token_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89391) | Audit event triggered when deploy token is created | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`deploy_token_creation_failed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89391) | Audit event triggered when deploy token fails to create | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`deploy_token_destroyed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89391) | Audit event triggered when deploy token is destroyed | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`deploy_token_revoked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89391) | Triggered when project deploy token is revoked | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`destroy_compliance_framework`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74292) | Triggered on successful compliance framework deletion | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/340649) |
+| [`destroy_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74632) | Event triggered when an external audit event destination is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/344664) |
+| [`destroy_instance_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125846) | Event triggered when an instance level external audit event destination is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.2](https://gitlab.com/gitlab-org/gitlab/-/issues/404730) |
+| [`email_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114546) | Event triggered when an email is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`email_destroyed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114546) | Event triggered when an email is destroyed | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`environment_protected`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108247) | This event is triggered when a protected environment is created. | **{check-circle}** Yes | **{dotted-circle}** No | `environment_management` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/216164) |
+| [`environment_unprotected`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108247) | This event is triggered when a protected environment is deleted. | **{check-circle}** Yes | **{dotted-circle}** No | `environment_management` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/216164) |
+| [`epic_closed_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an epic is closed by a group access token | **{check-circle}** Yes | **{check-circle}** Yes | `portfolio_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`epic_created_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an epic is created by a group access token | **{check-circle}** Yes | **{check-circle}** Yes | `portfolio_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`epic_reopened_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an epic is reopened by a group access token | **{check-circle}** Yes | **{check-circle}** Yes | `portfolio_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`event_type_filters_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113081) | Event triggered when a new audit events streaming event type filter is created | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/344848) |
+| [`event_type_filters_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113489) | Event triggered when audit events streaming event type filters are deleted | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/344848) |
+| [`experiment_features_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118222) | Event triggered on toggling setting for enabling experiment AI features | **{check-circle}** Yes | **{check-circle}** Yes | `not_owned` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/404856/) |
+| [`external_status_check_name_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106095) | Event triggered on updating name of a external status check | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369333) |
+| [`external_status_check_url_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84624) | Whenever the URL that is used for external status checks for a pipeline is updated, this audit event is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/355805) |
+| [`google_cloud_logging_configuration_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122025) | Triggered when Google Cloud Logging configuration is created | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) |
+| [`google_cloud_logging_configuration_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122025) | Triggered when Google Cloud Logging configuration is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) |
+| [`google_cloud_logging_configuration_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/122025) | Triggered when Google Cloud Logging configuration is updated | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) |
+| [`group_access_token_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on creating a group access token | **{check-circle}** Yes | **{check-circle}** Yes | `subgroup` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_access_token_creation_failed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on failing to create a group access token | **{check-circle}** Yes | **{check-circle}** Yes | `subgroup` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_access_token_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on deleting a group access token | **{check-circle}** Yes | **{check-circle}** Yes | `subgroup` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_access_token_deletion_failed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on failure to delete a group access token | **{check-circle}** Yes | **{check-circle}** Yes | `subgroup` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121005) | Event triggered when a group is created. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/411595) |
+| [`group_deletion_marked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116986) | Event triggered when a group is marked for deletion. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374106) |
+| [`group_deploy_token_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93091) | Audit event triggered when a groups deploy token is created | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_deploy_token_creation_failed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93091) | Audit event triggered when a groups deploy token fails to create | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_deploy_token_destroyed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93091) | Audit event triggered when group deploy token is destroyed | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_deploy_token_revoked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/93091) | Audit event triggered when group deploy token is revoked | **{check-circle}** Yes | **{check-circle}** Yes | `continuous_delivery` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`group_destroyed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116986) | Event triggered when a group is destroyed. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374106) |
+| [`group_lfs_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups lfs enabled is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369323) |
+| [`group_membership_lock_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups membership lock is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369323) |
+| [`group_merge_request_approval_setting_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87880) | Triggered when merge request approval settings are added on a group level. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/356152) |
+| [`group_name_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups name is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369320) |
+| [`group_path_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups path is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369321) |
+| [`group_project_creation_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups project creation level is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369327) |
+| [`group_push_rules_author_email_regex_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105791) | Event triggered when a groups push rules settings is changed for author email regex. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369343) |
+| [`group_push_rules_branch_name_regex_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105791) | Event triggered when a groups push rules settings is changed for branch name regex. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369340) |
+| [`group_push_rules_commit_committer_check_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86046) | Triggered when group push rule setting is updated for reject unverified users. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/227629) |
+| [`group_push_rules_commit_message_negative_regex_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105791) | Event triggered when a groups push rules settings is changed for commit message negative regex. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369342) |
+| [`group_push_rules_commit_message_regex_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105791) | Event triggered when a groups push rules settings is changed for commit message regex. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369341) |
+| [`group_push_rules_file_name_regex_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105791) | Event triggered when a groups push rules settings is changed for file name regex. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369344) |
+| [`group_push_rules_max_file_size_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/105791) | Event triggered when a groups push rules settings is changed for max file size. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369345) |
+| [`group_push_rules_prevent_secrets_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86046) | Triggered when group push rule setting is updated to prevent pushing secret files. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/227629) |
+| [`group_push_rules_reject_deny_delete_tag_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86046) | Triggered when group push rule setting is updated to deny deletion of tags using Git push. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/227629) |
+| [`group_push_rules_reject_member_check_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86046) | Triggered when group push rule setting is updated to check if commit author is a GitLab user. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/227629) |
+| [`group_push_rules_reject_non_dco_commits_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86046) | Triggered when group push rule setting is updated for reject non DCO certified commits. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/227629) |
+| [`group_push_rules_reject_unsigned_commits_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86046) | Triggered when group push rule setting is updated for reject unsigned commits. | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/227629) |
+| [`group_repository_size_limit_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups repository size limit is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369322) |
+| [`group_request_access_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups request access enabled is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369323) |
+| [`group_require_two_factor_authentication_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups require two factor authentication setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369325) |
+| [`group_restored`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116986) | Event triggered when a group is restored. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374106) |
+| [`group_saml_provider_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111227) | Event triggered when a group SAML provider is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/373964) |
+| [`group_saml_provider_update`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111227) | Event triggered when a group SAML provider is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/373964) |
+| [`group_share_with_group_link_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112719) | This event is triggered when you proceed to invite a group to another group via the 'invite group' tab on the group's membership page | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/327909) |
+| [`group_share_with_group_link_removed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112719) | This event is triggered when you proceed to invite a group to another group via the 'invite group' tab on the group's membership page | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/327909) |
+| [`group_share_with_group_link_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112719) | This event is triggered when you proceed to invite a group to another group via the 'invite group' tab on the group's membership page | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/327909) |
+| [`group_shared_runners_minutes_limit_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups shared runners minutes limit is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369324) |
+| [`group_two_factor_grace_period_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups two factor grace period is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369326) |
+| [`group_visibility_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106079) | Event triggered when a groups visibility level is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369322) |
+| [`incident_closed_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an incident is closed using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `incident_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`incident_created_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an incident is created using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `incident_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`incident_reopened_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an incident is reopened using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `incident_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`ip_restrictions_changed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86037) | Event triggered on any changes in the IP AllowList | **{check-circle}** Yes | **{check-circle}** Yes | `system_access` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/358986) |
+| [`issue_closed_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an issue is closed using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `team_planning` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`issue_created_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an issue is created using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `team_planning` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`issue_reopened_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when an issue is reopened using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `team_planning` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`member_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109711) | Event triggered when a membership is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374112) |
+| [`member_destroyed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109711) | Event triggered when a membership is destroyed | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374112) |
+| [`member_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/109711) | Event triggered when a membership is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374112) |
+| [`merge_commit_template_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107533) | audit when merge commit template is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/369314) |
+| [`merge_request_approval_operation`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92983) | Audit event triggered when a merge request is approved | **{dotted-circle}** No | **{check-circle}** Yes | `code_review_workflow` | GitLab [15.3](https://gitlab.com/gitlab-org/gitlab/-/issues/10869) |
+| [`merge_request_closed_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120927) | Triggered when a merge request is closed using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`merge_request_create`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90911) | Event triggered when a Merge Request is created | **{dotted-circle}** No | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/367239) |
+| [`merge_request_created_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120927) | Triggered when a merge request is created using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`merge_request_invalid_approver_rules`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/100496) | Audit event triggered for an invalid rule when merge request is approved | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [15.5](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/100496) |
+| [`merge_request_merged_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120927) | Triggered when a merge request is merged using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`merge_request_reopened_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120927) | Triggered when a merge request is reopened using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`merged_merge_request_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118793) | Audit event triggered when a merged merge request is deleted | **{dotted-circle}** No | **{check-circle}** Yes | `source_code_management` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/408288) |
+| [`merged_merge_request_deletion_started`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118793) | Audit event triggered when a merged merge request's deletion is started | **{dotted-circle}** No | **{check-circle}** Yes | `source_code_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/408288) |
+| [`omniauth_login_failed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123080) | Event triggered when an OmniAuth login fails | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`password_reset_requested`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/114548) | Event triggered when a user requests a password reset using a registered email address | **{check-circle}** Yes | **{dotted-circle}** No | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`personal_access_token_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108952) | Event triggered when a user creates a personal access token | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374113) |
+| [`personal_access_token_revoked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108952) | Event triggered when a personal access token is revoked | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374113) |
+| [`policy_project_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102154) | This event is triggered whenever the security policy project is updated for a project. | **{check-circle}** Yes | **{check-circle}** Yes | `security_policy_management` | GitLab [15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/377877) |
+| [`project_access_token_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on creating a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `project` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`project_access_token_creation_failed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on failure to create a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `project` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`project_access_token_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on creating a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `project` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`project_access_token_deletion_failed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92225) | Event triggered on failure to delete a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `project` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363087) |
+| [`project_archived`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117528) | Event triggered when a project is archived. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_cicd_merge_pipelines_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107428) | audit when project cicd merge pipelines setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/369317) |
+| [`project_cicd_merge_trains_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107428) | Event triggered on updating project setting for enabling ci cd merge trains | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/369317) |
+| [`project_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117543) | Event triggered when a project is created. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_default_branch_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117543) | Event triggered when default branch of a project's repository is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_deletion_marked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117546) | Event triggered when a project is marked for deletion. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_description_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128978) | Triggered when a project's description is updated | **{dotted-circle}** No | **{check-circle}** Yes | `groups_and_projects` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/377769) |
+| [`project_destroyed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117546) | Event triggered when a project is destroyed. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_disable_overriding_approvers_per_merge_request_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | audit when project disable overriding approvers per mr setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369288) |
+| [`project_export_file_download_started`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117528) | Event triggered when download of project export file gets started. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_feature_analytics_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's analytics access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369299) |
+| [`project_feature_builds_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's builds access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369294) |
+| [`project_feature_container_registry_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's container registry access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369303) |
+| [`project_feature_environments_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's environments access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369307) |
+| [`project_feature_feature_flags_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's feature flags access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369306) |
+| [`project_feature_forking_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's feature forking access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369290) |
+| [`project_feature_infrastructure_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's infrastructure access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369305) |
+| [`project_feature_issues_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's issues access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369289) |
+| [`project_feature_merge_requests_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's merge request access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369289) |
+| [`project_feature_metrics_dashboard_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's metrics dashboard access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369289) |
+| [`project_feature_model_experiments_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121027) | Model experiments access level was updated | **{check-circle}** Yes | **{check-circle}** Yes | `mlops` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/412384) |
+| [`project_feature_monitor_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's monitor access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369304) |
+| [`project_feature_operations_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's operation access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369300) |
+| [`project_feature_package_registry_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's package registry access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369296) |
+| [`project_feature_pages_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's page access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369297) |
+| [`project_feature_releases_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's releases access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369308) |
+| [`project_feature_repository_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's repository access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369295) |
+| [`project_feature_requirements_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's requirements access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369301) |
+| [`project_feature_security_and_compliance_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's security and compliance access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369302) |
+| [`project_feature_snippets_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's snippet access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369293) |
+| [`project_feature_wiki_access_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106919) | Event triggered when a project's wiki access level setting is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369292) |
+| [`project_fork_operation`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90916) | Audit event triggered when a project is forked | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90916) |
+| [`project_fork_relationship_removed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/101017) | Event triggered on successful removal of project's fork relationship | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/272532) |
+| [`project_group_link_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108918) | Event triggered when a group is invited to a project | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374114) |
+| [`project_group_link_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108918) | Event triggered when a project group link is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374114) |
+| [`project_group_link_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/108918) | Event triggered when a project group link is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374114) |
+| [`project_imported`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117528) | Event triggered when a project is imported. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_merge_method_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83922) | Triggered when a project's merge request method has been changed. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [14.10](https://gitlab.com/gitlab-org/gitlab/-/issues/301124) |
+| [`project_merge_requests_author_approval_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | audit when project mr author approval setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369288) |
+| [`project_merge_requests_disable_committers_approval_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | Event triggered on updating project setting for disabling committers approval on merge requests | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369277) |
+| [`project_merge_requests_template_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84624) | Whenever a MR template is updated for a project, this audit event is created | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/355805) |
+| [`project_name_updated`](https://gitlab.com/gitlab-org/gitlab/-/commit/8c0b52247e717cf84bc7b248d817f8baa55b18a4) | Create this audit event whenever a project has its name updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [10.2](https://gitlab.com/gitlab-org/gitlab/-/commit/8c0b52247e717cf84bc7b248d817f8baa55b18a4) |
+| [`project_namespace_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | audit when project namespace is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369288) |
+| [`project_only_allow_merge_if_all_discussions_are_resolved_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | Event triggered on updating project setting for allowing merge only when all discussions are resolved | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369286) |
+| [`project_only_allow_merge_if_pipeline_succeeds_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | audit when project only allow merge if pipeline succeeds setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369288) |
+| [`project_packages_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/7962) | When the setting that controls packages for a project is toggled, this audit event is created | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [11.5](https://gitlab.com/gitlab-org/gitlab/-/issues/369288) |
+| [`project_path_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/100770) | Event triggered on updating a project's path | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.5](https://gitlab.com/gitlab-org/gitlab/-/issues/369271) |
+| [`project_printing_merge_request_link_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | Event triggered on updating setting for projects for enabling printing merge request link | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369283) |
+| [`project_remove_source_branch_after_merge_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83922) | Create this audit event whenever a project has its setting to remove branches after merges modified | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [14.10](https://gitlab.com/gitlab-org/gitlab/-/issues/301124) |
+| [`project_repository_size_limit_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | Event triggered on updating repository size limit of a project | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369274) |
+| [`project_require_password_to_approve_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | Event triggered on updating project setting for requiring user's password for approval of merge request | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369280) |
+| [`project_reset_approvals_on_push_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66234) | Create this audit event whenever a project has its setting on whether approvals are reset on a push is updated | **{check-circle}** Yes | **{check-circle}** Yes | `code_review_workflow` | GitLab [14.2](https://gitlab.com/gitlab-org/gitlab/-/issues/336211) |
+| [`project_resolve_outdated_diff_discussions_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | audit when project resolve outdated diff discussions setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369288) |
+| [`project_restored`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117528) | Event triggered when a project is restored. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_suggestion_commit_message_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83922) | Create this audit event whenever a project has its suggested commit message updated | **{check-circle}** Yes | **{check-circle}** Yes | `code_suggestions` | GitLab [14.10](https://gitlab.com/gitlab-org/gitlab/-/issues/301124) |
+| [`project_unarchived`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117528) | Event triggered when a project is unarchived. | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374105) |
+| [`project_visibility_level_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106652) | audit when project visiblity level setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369288) |
+| [`protected_branch_allow_force_push_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68869) | This audit event is created when a protected branch has its ability to allow force pushes is toggled | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [14.3](https://gitlab.com/gitlab-org/gitlab/-/issues/338873) |
+| [`protected_branch_code_owner_approval_required_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107530) | audit when protected branch code owner approval required setting is updated | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/369318) |
+| [`protected_branch_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92074) | Triggered when a protected branch is created | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363091) |
+| [`protected_branch_removed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92074) | Triggered when a protected branch is removed | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363091) |
+| [`protected_branch_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107530) | Event triggered on the setting for protected branches is update | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/369318) |
+| [`registration_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/123080) | Event triggered when a user registers for instance access | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [16.3](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`release_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111080) | Event triggered when a release is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374111) |
+| [`release_deleted_audit_event`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111080) | Event triggered when a release is deleted | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374111) |
+| [`release_milestones_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111080) | Event triggered when a release's associated milestones are updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374111) |
+| [`release_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111080) | Event triggered when a release is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374111) |
+| [`remove_gpg_key`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111744) | Event triggered when a GPG Key is destroyed | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/373961) |
+| [`remove_ssh_key`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65615) | Audit event triggered when a SSH key is removed | **{check-circle}** Yes | **{check-circle}** Yes | `user_profile` | GitLab [14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/220127) |
+| [`repository_download_operation`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111218) | Event triggered when a Git repository for a project is downloaded | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/374108) |
+| [`repository_git_operation`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76719) | Triggered when authenticated users push, pull, or clone a project using SSH, HTTP(S), or the UI | **{dotted-circle}** No | **{check-circle}** Yes | `source_code_management` | GitLab [14.9](https://gitlab.com/gitlab-org/gitlab/-/issues/373950) |
+| [`require_password_to_approve_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102256) | Event triggered on updating require user password for approvals from group merge request setting | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/373949) |
+| [`retain_approvals_on_push_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/102256) | Event triggered on updating require new approvals when new commits are added to an MR from group merge request setting | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.6](https://gitlab.com/gitlab-org/gitlab/-/issues/373949) |
+| [`saml_group_links_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110525) | Event triggered when a SAML Group Link is created | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/373954) |
+| [`saml_group_links_removed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/110525) | Event triggered when a SAML Group Link is destroyed | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/373954) |
+| [`secure_ci_job_token_inbound_disabled`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115350) | Event triggered when CI_JOB_TOKEN permissions disabled for inbound | **{check-circle}** Yes | **{check-circle}** Yes | `verify_security` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/338255) |
+| [`secure_ci_job_token_inbound_enabled`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115350) | Event triggered when CI_JOB_TOKEN permissions enabled for inbound | **{check-circle}** Yes | **{check-circle}** Yes | `verify_security` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/338255) |
+| [`secure_ci_job_token_project_added`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115350) | Event triggered when project added to inbound CI_JOB_TOKEN scope | **{check-circle}** Yes | **{check-circle}** Yes | `verify_security` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/338255) |
+| [`secure_ci_job_token_project_removed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115350) | Event triggered when project removed from inbound CI_JOB_TOKEN scope | **{check-circle}** Yes | **{check-circle}** Yes | `verify_security` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/338255) |
+| [`set_runner_associated_projects`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/97666) | Event triggered on successful assignment of associated projects to a CI runner | **{check-circle}** Yes | **{check-circle}** Yes | `runner` | GitLab [15.4](https://gitlab.com/gitlab-org/gitlab/-/issues/359958) |
+| [`smartcard_authentication_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/8120) | Event triggered when a user authenticates with smartcard | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/726) |
+| [`squash_commit_template_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/107533) | Event triggered on updating the merge request squash commit template for a project | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/369314) |
+| [`squash_option_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84624) | Triggered when squash option setting has been changed. | **{check-circle}** Yes | **{check-circle}** Yes | `groups_and_projects` | GitLab [15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/301124) |
+| [`task_closed_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when a task is closed using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `team_planning` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`task_created_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when a task is created using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `team_planning` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`task_reopened_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when a task is reopened using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `team_planning` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`test_case_closed_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when a test case is closed using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `quality_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`test_case_created_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when a test case is created using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `quality_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`test_case_reopened_by_project_bot`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121485) | Triggered when a test case is reopened using a project access token | **{check-circle}** Yes | **{check-circle}** Yes | `quality_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323299) |
+| [`third_party_ai_features_enabled_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/118222) | Event triggered on toggling setting for enabling third-party AI features | **{check-circle}** Yes | **{check-circle}** Yes | `not_owned` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/404856/) |
+| [`unban_user`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116221) | Event triggered on user unban action | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/377620) |
+| [`unblock_user`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115727) | Event triggered on user unblock action | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/377620) |
+| [`update_approval_rules`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89939) | Event triggered on updating a merge approval rule | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.2](https://gitlab.com/gitlab-org/gitlab/-/issues/363092) |
+| [`update_compliance_framework`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74292) | Triggered when a compliance framework is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/340649) |
+| [`update_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/74632) | Event triggered when an external audit event destination is updated | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [14.6](https://gitlab.com/gitlab-org/gitlab/-/issues/344664) |
+| [`update_instance_event_streaming_destination`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/125846) | Event triggered when an instance level external audit event destination is updated | **{check-circle}** Yes | **{check-circle}** Yes | `audit_events` | GitLab [16.2](https://gitlab.com/gitlab-org/gitlab/-/issues/404730) |
+| [`update_mismatched_group_saml_extern_uid`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/104791) | Triggered when the external UID is changed on a SAML identity. | **{check-circle}** Yes | **{check-circle}** Yes | `system_access` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/382256) |
+| [`update_status_check`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/84624) | Event triggered when an external status check is updated | **{check-circle}** Yes | **{check-circle}** Yes | `compliance_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/355805) |
+| [`user_access_locked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124169) | Event triggered when user access to the instance is locked | **{check-circle}** Yes | **{check-circle}** Yes | `system_access` | GitLab [16.2](https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/244) |
+| [`user_access_unlocked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124973) | Event triggered when user access to the instance is unlocked | **{check-circle}** Yes | **{check-circle}** Yes | `system_access` | GitLab [16.2](https://gitlab.com/gitlab-org/modelops/anti-abuse/team-tasks/-/issues/244) |
+| [`user_activate`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121708) | Event triggered on user activate action | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [16.1](https://gitlab.com/gitlab-org/gitlab/-/issues/13473) |
+| [`user_admin_status_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/65168) | Adds an audit event when a user is either made an administrator, or removed as an administrator | **{check-circle}** Yes | **{check-circle}** Yes | `user_profile` | GitLab [14.1](https://gitlab.com/gitlab-org/gitlab/-/issues/323905) |
+| [`user_approved`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113784) | Event triggered when a user is approved for an instance | **{check-circle}** Yes | **{dotted-circle}** No | `user_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`user_blocked`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113784) | Event triggered when a user is blocked | **{check-circle}** Yes | **{dotted-circle}** No | `user_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`user_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113784) | Event triggered when a user is created | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`user_deactivate`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/117776) | Event triggered on user deactivate action | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [16.0](https://gitlab.com/gitlab-org/gitlab/-/issues/13473) |
+| [`user_destroyed`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113784) | Event triggered when a user is scheduled for removal from the instance | **{check-circle}** Yes | **{dotted-circle}** No | `user_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`user_disable_two_factor`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/89598) | Audit event triggered when user disables two factor authentication | **{check-circle}** Yes | **{check-circle}** Yes | `system_access` | GitLab [15.1](https://gitlab.com/gitlab-org/gitlab/-/issues/238177) |
+| [`user_email_address_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/2103) | Adds an audit event when a user updates their email address | **{check-circle}** Yes | **{check-circle}** Yes | `user_profile` | GitLab [10.1](https://gitlab.com/gitlab-org/gitlab-ee/issues/1370) |
+| [`user_email_changed_and_user_signed_in`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106090) | audit when user emailed changed and user signed in | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [15.8](https://gitlab.com/gitlab-org/gitlab/-/issues/369331) |
+| [`user_enable_admin_mode`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/104754) | Event triggered on enabling admin mode | **{check-circle}** Yes | **{check-circle}** Yes | `system_access` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/362101) |
+| [`user_impersonation`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79340) | Triggered when an instance administrator starts or stops impersonating a user | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [14.8](https://gitlab.com/gitlab-org/gitlab/-/issues/300961) |
+| [`user_password_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106086) | audit when user password is updated | **{check-circle}** Yes | **{check-circle}** Yes | `user_management` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369330) |
+| [`user_rejected`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113784) | Event triggered when a user registration is rejected | **{check-circle}** Yes | **{dotted-circle}** No | `user_management` | GitLab [15.11](https://gitlab.com/gitlab-org/gitlab/-/issues/374107) |
+| [`user_username_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/106086) | Event triggered on updating a user's username | **{check-circle}** Yes | **{check-circle}** Yes | `user_profile` | GitLab [15.7](https://gitlab.com/gitlab-org/gitlab/-/issues/369329) |
+| [`feature_flag_created`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113453) | Triggered when a feature flag is created. | **{check-circle}** Yes | **{check-circle}** Yes | `feature_flags` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/374109) |
+| [`feature_flag_deleted`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113453) | Triggered when a feature flag is deleted. | **{check-circle}** Yes | **{check-circle}** Yes | `feature_flags` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/374109) |
+| [`feature_flag_updated`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113453) | Triggered when a feature flag is updated. | **{check-circle}** Yes | **{check-circle}** Yes | `feature_flags` | GitLab [15.10](https://gitlab.com/gitlab-org/gitlab/-/issues/374109) |
+| [`manually_trigger_housekeeping`](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112095) | Triggered when manually triggering housekeeping via API or admin UI | **{check-circle}** Yes | **{check-circle}** Yes | `source_code_management` | GitLab [15.9](https://gitlab.com/gitlab-org/gitlab/-/issues/390761) |
diff --git a/doc/administration/audit_event_streaming/examples.md b/doc/administration/audit_event_streaming/examples.md
index d741e5fd60d..1c9a14dbab0 100644
--- a/doc/administration/audit_event_streaming/examples.md
+++ b/doc/administration/audit_event_streaming/examples.md
@@ -24,7 +24,7 @@ Streaming audit events can be sent when authenticated users push, pull, or clone
 
 Audit events are not captured for users that are not signed in. For example, when downloading a public project.
 
-To configure streaming audit events for Git operations, see [Add a new streaming destination](index.md#add-a-new-streaming-destination).
+To configure streaming audit events for Git operations, see [Add a new HTTP destination](index.md#add-a-new-http-destination).
 
 ### Headers
 
diff --git a/doc/administration/audit_event_streaming/graphql_api.md b/doc/administration/audit_event_streaming/graphql_api.md
index 9f8fef0e3ca..e6584369e5a 100644
--- a/doc/administration/audit_event_streaming/graphql_api.md
+++ b/doc/administration/audit_event_streaming/graphql_api.md
@@ -4,7 +4,7 @@ group: Compliance
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Audit event streaming GraphQL API **(ULTIMATE)**
+# Audit event streaming GraphQL API **(ULTIMATE ALL)**
 
 > - API [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.5 [with a flag](../feature_flags.md) named `ff_external_audit_events_namespace`. Disabled by default.
 > - API [Enabled on GitLab.com and by default on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/338939) in GitLab 14.7.
@@ -19,15 +19,21 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 Audit event streaming destinations can be maintained using a GraphQL API.
 
-## Add a new streaming destination
+## Top-level group streaming destinations
 
-Add a new streaming destination to top-level groups or an entire instance.
+Manage streaming destinations for top-level groups.
+
+### HTTP destinations
+
+Manage HTTP streaming destinations for top-level groups.
+
+#### Add a new streaming destination
+
+Add a new streaming destination to top-level groups.
 
 WARNING:
 Streaming destinations receive **all** audit event data, which could include sensitive information. Make sure you trust the streaming destination.
 
-### Top-level group streaming destinations
-
 Prerequisites:
 
 - Owner role for a top-level group.
@@ -113,197 +119,234 @@ mutation {
 
 The header is created if the returned `errors` object is empty.
 
-### Instance streaming destinations
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
-> - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
+#### List streaming destinations
 
-FLAG:
-On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
-`ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
+List streaming destinations for a top-level groups.
 
 Prerequisites:
 
-- Administrator access on the instance.
+- Owner role for a top-level group.
 
-To enable streaming and add a destination, use the
-`instanceExternalAuditEventDestinationCreate` mutation in the GraphQL API.
+You can view a list of streaming destinations for a top-level group using the `externalAuditEventDestinations` query
+type.
 
 ```graphql
-mutation {
-  instanceExternalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest"}) {
-    errors
-    instanceExternalAuditEventDestination {
-      destinationUrl
-      id
-      name
-      verificationToken
+query {
+  group(fullPath: "my-group") {
+    id
+    externalAuditEventDestinations {
+      nodes {
+        destinationUrl
+        verificationToken
+        id
+        name
+        headers {
+          nodes {
+            key
+            value
+            id
+          }
+        }
+        eventTypeFilters
+      }
     }
   }
 }
 ```
 
-Event streaming is enabled if:
+If the resulting list is empty, then audit streaming is not enabled for that group.
 
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
+#### Update streaming destinations
 
-You can optionally specify your own destination name (instead of the default GitLab-generated one) using the GraphQL
-`instanceExternalAuditEventDestinationCreate`
-mutation. Name length must not exceed 72 characters and trailing whitespace are not trimmed. This value should be unique. For example:
+Update streaming destinations for a top-level group.
+
+Prerequisites:
+
+- Owner role for a top-level group.
+
+Users with the Owner role for a group can update streaming destinations' custom HTTP headers using the
+`auditEventsStreamingHeadersUpdate` mutation type. You can retrieve the custom HTTP headers ID
+by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
 
 ```graphql
 mutation {
-  instanceExternalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", name: "destination-name-here"}) {
+  externalAuditEventDestinationUpdate(input: {
+    id:"gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
+    destinationUrl: "https://www.new-domain.com/webhook",
+    name: "destination-name"} ) {
     errors
-    instanceExternalAuditEventDestination {
-      destinationUrl
+    externalAuditEventDestination {
       id
       name
+      destinationUrl
       verificationToken
+      group {
+        name
+      }
     }
   }
 }
 ```
 
-Instance administrators can add an HTTP header using the GraphQL `auditEventsStreamingInstanceHeadersCreate` mutation. You can retrieve the destination ID
-by [listing all the streaming destinations](#list-streaming-destinations) for the instance or from the mutation above.
+Streaming destination is updated if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
+by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
 
 ```graphql
 mutation {
-  auditEventsStreamingInstanceHeadersCreate(input:
-    {
-      destinationId: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/42",
-      key: "foo",
-      value: "bar"
-    }) {
+  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
     errors
-    header {
-      id
-      key
-      value
-    }
   }
 }
 ```
 
-The header is created if the returned `errors` object is empty.
+The header is deleted if the returned `errors` object is empty.
 
-### Google Cloud Logging streaming
+#### Delete streaming destinations
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) in GitLab 16.1.
+Delete streaming destinations for a top-level group.
+
+When the last destination is successfully deleted, streaming is disabled for the group.
 
 Prerequisites:
 
 - Owner role for a top-level group.
-- A Google Cloud project with the necessary permissions to create service accounts and enable Google Cloud Logging.
 
-To enable streaming and add a configuration, use the
-`googleCloudLoggingConfigurationCreate` mutation in the GraphQL API.
+Users with the Owner role for a group can delete streaming destinations using the
+`externalAuditEventDestinationDestroy` mutation type. You can retrieve the destinations ID
+by [listing all the streaming destinations](#list-streaming-destinations) for the group.
 
 ```graphql
 mutation {
-  googleCloudLoggingConfigurationCreate(input: { groupPath: "my-group", googleProjectIdName: "my-google-project", clientEmail: "my-email@my-google-project.iam.gservice.account.com", privateKey: "YOUR_PRIVATE_KEY", logIdName: "audit-events" } ) {
-    errors
-    googleCloudLoggingConfiguration {
-      id
-      googleProjectIdName
-      logIdName
-      privateKey
-      clientEmail
-    }
+  externalAuditEventDestinationDestroy(input: { id: destination }) {
     errors
   }
 }
 ```
 
-Event streaming is enabled if:
+Streaming destination is deleted if:
 
 - The returned `errors` object is empty.
 - The API responds with `200 OK`.
 
-## List streaming destinations
+Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
+by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
 
-List new streaming destinations for top-level groups or an entire instance.
+```graphql
+mutation {
+  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
+    errors
+  }
+}
+```
 
-### Top-level group streaming destinations
+The header is deleted if the returned `errors` object is empty.
+
+#### Event type filters
+
+> Event type filters API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344845) in GitLab 15.7.
+
+When this feature is enabled for a group, you can use an API to permit users to filter streamed audit events per destination.
+If the feature is enabled with no filters, the destination receives all audit events.
+
+A streaming destination that has an event type filter set has a **filtered** (**{filter}**) label.
+
+##### Use the API to add an event type filter
 
 Prerequisites:
 
-- Owner role for a top-level group.
+- You must have the Owner role for the group.
 
-You can view a list of streaming destinations for a top-level group using the `externalAuditEventDestinations` query
-type.
+You can add a list of event type filters using the `auditEventsStreamingDestinationEventsAdd` query type:
 
 ```graphql
-query {
-  group(fullPath: "my-group") {
-    id
-    externalAuditEventDestinations {
-      nodes {
-        destinationUrl
-        verificationToken
-        id
-        name
-        headers {
-          nodes {
-            key
-            value
-            id
-          }
-        }
+mutation {
+    auditEventsStreamingDestinationEventsAdd(input: {
+        destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
+        eventTypeFilters: ["list of event type filters"]}){
+        errors
         eventTypeFilters
-      }
     }
+}
+```
+
+Event type filters are added if:
+
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+##### Use the API to remove an event type filter
+
+Prerequisites:
+
+- You must have the Owner role for the group.
+
+You can remove a list of event type filters using the `auditEventsStreamingDestinationEventsRemove` mutation type:
+
+```graphql
+mutation {
+    auditEventsStreamingDestinationEventsRemove(input: {
+    destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
+    eventTypeFilters: ["list of event type filters"]
+  }){
+    errors
   }
 }
 ```
 
-If the resulting list is empty, then audit streaming is not enabled for that group.
+Event type filters are removed if:
 
-### Instance streaming destinations
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
-> - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
+### Google Cloud Logging destinations
 
-FLAG:
-On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
-`ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) in GitLab 16.1.
+
+Manage Google Cloud Logging destinations for top-level groups.
+
+Before setting up Google Cloud Logging streaming audit events, you must satisfy [the prerequisites](index.md#prerequisites).
+
+#### Add a new Google Cloud Logging destination
+
+Add a new Google Cloud Logging configuration destination to a top-level group.
 
 Prerequisites:
 
-- Administrator access on the instance.
+- Owner role for a top-level group.
+- A Google Cloud project with the necessary permissions to create service accounts and enable Google Cloud Logging.
 
-To view a list of streaming destinations for an instance, use the
-`instanceExternalAuditEventDestinations` query type.
+To enable streaming and add a configuration, use the
+`googleCloudLoggingConfigurationCreate` mutation in the GraphQL API.
 
 ```graphql
-query {
-  instanceExternalAuditEventDestinations {
-    nodes {
+mutation {
+  googleCloudLoggingConfigurationCreate(input: { groupPath: "my-group", googleProjectIdName: "my-google-project", clientEmail: "my-email@my-google-project.iam.gservice.account.com", privateKey: "YOUR_PRIVATE_KEY", logIdName: "audit-events" } ) {
+    errors
+    googleCloudLoggingConfiguration {
       id
-      name
-      destinationUrl
-      verificationToken
-      headers {
-        nodes {
-          id
-          key
-          value
-        }
-      }
+      googleProjectIdName
+      logIdName
+      privateKey
+      clientEmail
     }
+    errors
   }
 }
 ```
 
-If the resulting list is empty, then audit streaming is not enabled for the instance.
+Event streaming is enabled if:
 
-You need the ID values returned by this query for the update and delete mutations.
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
 
-### Google Cloud Logging configurations
+#### List Google Cloud Logging configurations
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) in GitLab 16.1.
+List all Google Cloud Logging configuration destinations for a top-level group.
 
 Prerequisite:
 
@@ -333,59 +376,68 @@ If the resulting list is empty, then audit streaming is not enabled for the grou
 
 You need the ID values returned by this query for the update and delete mutations.
 
-## Update streaming destinations
-
-Update streaming destinations for a top-level group or an entire instance.
+#### Update Google Cloud Logging configurations
 
-### Top-level group streaming destinations
+Update a Google Cloud Logging configuration destinations for a top-level group.
 
-Prerequisites:
+Prerequisite:
 
 - Owner role for a top-level group.
 
-Users with the Owner role for a group can update streaming destinations' custom HTTP headers using the
-`auditEventsStreamingHeadersUpdate` mutation type. You can retrieve the custom HTTP headers ID
-by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
+To update streaming configuration for a top-level group, use the
+`googleCloudLoggingConfigurationUpdate` mutation type. You can retrieve the configuration ID
+by [listing all the external destinations](#list-streaming-destinations).
 
 ```graphql
 mutation {
-  externalAuditEventDestinationUpdate(input: { 
-    id:"gid://gitlab/AuditEvents::ExternalAuditEventDestination/1", 
-    destinationUrl: "https://www.new-domain.com/webhook",
-    name: "destination-name"} ) {
+  googleCloudLoggingConfigurationUpdate(
+    input: {id: "gid://gitlab/AuditEvents::GoogleCloudLoggingConfiguration/1", googleProjectIdName: "my-google-project", clientEmail: "my-email@my-google-project.iam.gservice.account.com", privateKey: "YOUR_PRIVATE_KEY", logIdName: "audit-events"}
+  ) {
     errors
-    externalAuditEventDestination {
+    googleCloudLoggingConfiguration {
       id
-      name
-      destinationUrl
-      verificationToken
-      group {
-        name
-      }
+      logIdName
+      privateKey
+      googleProjectIdName
+      clientEmail
     }
   }
 }
 ```
 
-Streaming destination is updated if:
+Streaming configuration is updated if:
 
 - The returned `errors` object is empty.
 - The API responds with `200 OK`.
 
-Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
-by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
+#### Delete Google Cloud Logging configurations
+
+Delete streaming destinations for a top-level group.
+
+When the last destination is successfully deleted, streaming is disabled for the group.
+
+Prerequisite:
+
+- Owner role for a top-level group.
+
+Users with the Owner role for a group can delete streaming configurations using the
+`googleCloudLoggingConfigurationDestroy` mutation type. You can retrieve the configurations ID
+by [listing all the streaming destinations](#list-streaming-destinations) for the group.
 
 ```graphql
 mutation {
-  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
+  googleCloudLoggingConfigurationDestroy(input: { id: "gid://gitlab/AuditEvents::GoogleCloudLoggingConfiguration/1" }) {
     errors
   }
 }
 ```
 
-The header is deleted if the returned `errors` object is empty.
+Streaming configuration is deleted if:
 
-### Instance streaming destinations
+- The returned `errors` object is empty.
+- The API responds with `200 OK`.
+
+## Instance streaming destinations **(ULTIMATE SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
 > - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
@@ -394,20 +446,22 @@ FLAG:
 On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
 `ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
 
+Manage HTTP streaming destinations for an entire instance.
+
+### Add a new HTTP destination
+
+Add a new HTTP streaming destination to an instance.
+
 Prerequisites:
 
 - Administrator access on the instance.
 
-To update streaming destinations for an instance, use the
-`instanceExternalAuditEventDestinationUpdate` mutation type. You can retrieve the destination ID
-by [listing all the external destinations](#list-streaming-destinations) for the instance.
+To enable streaming and add a destination, use the
+`instanceExternalAuditEventDestinationCreate` mutation in the GraphQL API.
 
 ```graphql
 mutation {
-  instanceExternalAuditEventDestinationUpdate(input: { 
-    id: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1",
-    destinationUrl: "https://www.new-domain.com/webhook",
-    name: "destination-name"}) {
+  instanceExternalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest"}) {
     errors
     instanceExternalAuditEventDestination {
       destinationUrl
@@ -419,18 +473,40 @@ mutation {
 }
 ```
 
-Streaming destination is updated if:
+Event streaming is enabled if:
 
 - The returned `errors` object is empty.
 - The API responds with `200 OK`.
 
-Instance administrators can update streaming destinations custom HTTP headers using the
-`auditEventsStreamingInstanceHeadersUpdate` mutation type. You can retrieve the custom HTTP headers ID
-by [listing all the custom HTTP headers](#list-streaming-destinations) for the instance.
+You can optionally specify your own destination name (instead of the default GitLab-generated one) using the GraphQL
+`instanceExternalAuditEventDestinationCreate`
+mutation. Name length must not exceed 72 characters and trailing whitespace are not trimmed. This value should be unique. For example:
 
 ```graphql
 mutation {
-  auditEventsStreamingInstanceHeadersUpdate(input: { headerId: "gid://gitlab/AuditEvents::Streaming::InstanceHeader/2", key: "new-key", value: "new-value" }) {
+  instanceExternalAuditEventDestinationCreate(input: { destinationUrl: "https://mydomain.io/endpoint/ingest", name: "destination-name-here"}) {
+    errors
+    instanceExternalAuditEventDestination {
+      destinationUrl
+      id
+      name
+      verificationToken
+    }
+  }
+}
+```
+
+Instance administrators can add an HTTP header using the GraphQL `auditEventsStreamingInstanceHeadersCreate` mutation. You can retrieve the destination ID
+by [listing all the streaming destinations](#list-streaming-destinations) for the instance or from the mutation above.
+
+```graphql
+mutation {
+  auditEventsStreamingInstanceHeadersCreate(input:
+    {
+      destinationId: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/42",
+      key: "foo",
+      value: "bar"
+    }) {
     errors
     header {
       id
@@ -441,92 +517,102 @@ mutation {
 }
 ```
 
-The header is updated if the returned `errors` object is empty.
+The header is created if the returned `errors` object is empty.
 
-### Google Cloud Logging configurations
+### List streaming destinations
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) in GitLab 16.1.
+List all HTTP streaming destinations for an instance.
 
-Prerequisite:
+Prerequisites:
 
-- Owner role for a top-level group.
+- Administrator access on the instance.
 
-To update streaming configuration for a top-level group, use the
-`googleCloudLoggingConfigurationUpdate` mutation type. You can retrieve the configuration ID
-by [listing all the external destinations](#list-streaming-destinations).
+To view a list of streaming destinations for an instance, use the
+`instanceExternalAuditEventDestinations` query type.
 
 ```graphql
-mutation {
-  googleCloudLoggingConfigurationUpdate(
-    input: {id: "gid://gitlab/AuditEvents::GoogleCloudLoggingConfiguration/1", googleProjectIdName: "my-google-project", clientEmail: "my-email@my-google-project.iam.gservice.account.com", privateKey: "YOUR_PRIVATE_KEY", logIdName: "audit-events"}
-  ) {
-    errors
-    googleCloudLoggingConfiguration {
+query {
+  instanceExternalAuditEventDestinations {
+    nodes {
       id
-      logIdName
-      privateKey
-      googleProjectIdName
-      clientEmail
+      name
+      destinationUrl
+      verificationToken
+      headers {
+        nodes {
+          id
+          key
+          value
+        }
+      }
+      eventTypeFilters
     }
   }
 }
 ```
 
-Streaming configuration is updated if:
-
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
-
-## Delete streaming destinations
+If the resulting list is empty, then audit streaming is not enabled for the instance.
 
-Delete streaming destinations for a top-level group or an entire instance.
+You need the ID values returned by this query for the update and delete mutations.
 
-When the last destination is successfully deleted, streaming is disabled for the group or the instance.
+### Update streaming destinations
 
-### Top-level group streaming destinations
+Update a HTTP streaming destination for an instance.
 
 Prerequisites:
 
-- Owner role for a top-level group.
+- Administrator access on the instance.
 
-Users with the Owner role for a group can delete streaming destinations using the
-`externalAuditEventDestinationDestroy` mutation type. You can retrieve the destinations ID
-by [listing all the streaming destinations](#list-streaming-destinations) for the group.
+To update streaming destinations for an instance, use the
+`instanceExternalAuditEventDestinationUpdate` mutation type. You can retrieve the destination ID
+by [listing all the external destinations](#list-streaming-destinations-1) for the instance.
 
 ```graphql
 mutation {
-  externalAuditEventDestinationDestroy(input: { id: destination }) {
+  instanceExternalAuditEventDestinationUpdate(input: {
+    id: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1",
+    destinationUrl: "https://www.new-domain.com/webhook",
+    name: "destination-name"}) {
     errors
+    instanceExternalAuditEventDestination {
+      destinationUrl
+      id
+      name
+      verificationToken
+    }
   }
 }
 ```
 
-Streaming destination is deleted if:
+Streaming destination is updated if:
 
 - The returned `errors` object is empty.
 - The API responds with `200 OK`.
 
-Group owners can remove an HTTP header using the GraphQL `auditEventsStreamingHeadersDestroy` mutation. You can retrieve the header ID
-by [listing all the custom HTTP headers](#list-streaming-destinations) for the group.
+Instance administrators can update streaming destinations custom HTTP headers using the
+`auditEventsStreamingInstanceHeadersUpdate` mutation type. You can retrieve the custom HTTP headers ID
+by [listing all the custom HTTP headers](#list-streaming-destinations-1) for the instance.
 
 ```graphql
 mutation {
-  auditEventsStreamingHeadersDestroy(input: { headerId: "gid://gitlab/AuditEvents::Streaming::Header/1" }) {
+  auditEventsStreamingInstanceHeadersUpdate(input: { headerId: "gid://gitlab/AuditEvents::Streaming::InstanceHeader/2", key: "new-key", value: "new-value" }) {
     errors
+    header {
+      id
+      key
+      value
+    }
   }
 }
 ```
 
-The header is deleted if the returned `errors` object is empty.
+The header is updated if the returned `errors` object is empty.
 
-### Instance streaming destinations
+### Delete streaming destinations
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/335175) in GitLab 16.0 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
-> - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
+Delete streaming destinations for an entire instance.
 
-FLAG:
-On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
-`ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
+When the last destination is successfully deleted, streaming is disabled for the instance.
 
 Prerequisites:
 
@@ -534,7 +620,7 @@ Prerequisites:
 
 To delete streaming destinations, use the
 `instanceExternalAuditEventDestinationDestroy` mutation type. You can retrieve the destinations ID
-by [listing all the streaming destinations](#list-streaming-destinations) for the instance.
+by [listing all the streaming destinations](#list-streaming-destinations-1) for the instance.
 
 ```graphql
 mutation {
@@ -563,52 +649,27 @@ mutation {
 
 The header is deleted if the returned `errors` object is empty.
 
-### Google Cloud Logging configurations
+### Event type filters
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/409422) in GitLab 16.1.
+> Event type filters API [introduced](https://gitlab.com/groups/gitlab-org/-/epics/10868) in GitLab 16.2.
 
-Prerequisite:
-
-- Owner role for a top-level group.
-
-Users with the Owner role for a group can delete streaming configurations using the
-`googleCloudLoggingConfigurationDestroy` mutation type. You can retrieve the configurations ID
-by [listing all the streaming destinations](#list-streaming-destinations) for the group.
-
-```graphql
-mutation {
-  googleCloudLoggingConfigurationDestroy(input: { id: "gid://gitlab/AuditEvents::GoogleCloudLoggingConfiguration/1" }) {
-    errors
-  }
-}
-```
-
-Streaming configuration is deleted if:
-
-- The returned `errors` object is empty.
-- The API responds with `200 OK`.
-
-## Event type filters
-
-> Event type filters API [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/344845) in GitLab 15.7.
-
-When this feature is enabled for a group, you can use an API to permit users to filter streamed audit events per destination.
+When this feature is enabled for an instance, you can use an API to permit users to filter streamed audit events per destination.
 If the feature is enabled with no filters, the destination receives all audit events.
 
 A streaming destination that has an event type filter set has a **filtered** (**{filter}**) label.
 
-### Use the API to add an event type filter
+#### Use the API to add an event type filter
 
 Prerequisites:
 
-- You must have the Owner role for the group.
+- You must have the Administrator access for the instance.
 
-You can add a list of event type filters using the `auditEventsStreamingDestinationEventsAdd` query type:
+You can add a list of event type filters using the `auditEventsStreamingDestinationInstanceEventsAdd` mutation:
 
 ```graphql
 mutation {
-    auditEventsStreamingDestinationEventsAdd(input: {
-        destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
+    auditEventsStreamingDestinationInstanceEventsAdd(input: {
+        destinationId: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1",
         eventTypeFilters: ["list of event type filters"]}){
         errors
         eventTypeFilters
@@ -621,18 +682,18 @@ Event type filters are added if:
 - The returned `errors` object is empty.
 - The API responds with `200 OK`.
 
-### Use the API to remove an event type filter
+#### Use the API to remove an event type filter
 
 Prerequisites:
 
-- You must have the Owner role for the group.
+- You must have the Administrator access for the instance.
 
-You can remove a list of event type filters using the `auditEventsStreamingDestinationEventsRemove` query type:
+You can remove a list of event type filters using the `auditEventsStreamingDestinationInstanceEventsRemove` mutation:
 
 ```graphql
 mutation {
-    auditEventsStreamingDestinationEventsRemove(input: {
-    destinationId: "gid://gitlab/AuditEvents::ExternalAuditEventDestination/1",
+    auditEventsStreamingDestinationInstanceEventsRemove(input: {
+    destinationId: "gid://gitlab/AuditEvents::InstanceExternalAuditEventDestination/1",
     eventTypeFilters: ["list of event type filters"]
   }){
     errors
diff --git a/doc/administration/audit_event_streaming/index.md b/doc/administration/audit_event_streaming/index.md
index 622d29fa9a7..ae566891ac7 100644
--- a/doc/administration/audit_event_streaming/index.md
+++ b/doc/administration/audit_event_streaming/index.md
@@ -4,33 +4,41 @@ group: Compliance
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Audit event streaming **(ULTIMATE)**
+# Audit event streaming **(ULTIMATE ALL)**
 
 > - UI [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/336411) in GitLab 14.9.
 > - [Subgroup events recording](https://gitlab.com/gitlab-org/gitlab/-/issues/366878) fixed in GitLab 15.2.
 > - Custom HTTP headers UI [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/361630) in GitLab 15.2 [with a flag](../feature_flags.md) named `custom_headers_streaming_audit_events_ui`. Disabled by default.
 > - Custom HTTP headers UI [made generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) in GitLab 15.3. [Feature flag `custom_headers_streaming_audit_events_ui`](https://gitlab.com/gitlab-org/gitlab/-/issues/365259) removed.
 > - [Improved user experience](https://gitlab.com/gitlab-org/gitlab/-/issues/367963) in GitLab 15.3.
+> - [HTTP destination **Name*** field](https://gitlab.com/gitlab-org/gitlab/-/issues/411357) added in GitLab 16.3.
 
-Users can set a streaming destination for a top-level group or instance to receive all audit events about the group, subgroups, and
-projects as structured JSON.
+Users can set a streaming destination for a top-level group or instance to receive all audit events about the group,
+subgroups, and projects, as structured JSON.
 
-Top-level group owners and instance administrators can manage their audit logs in third-party systems. Any service that can receive
-structured JSON data can be used as the streaming destination.
+Top-level group owners and instance administrators can manage their audit logs in third-party systems. Any service that
+can receive structured JSON data can be used as the streaming destination.
 
 Each streaming destination can have up to 20 custom HTTP headers included with each streamed event.
 
-NOTE:
-GitLab can stream a single event more than once to the same destination. Use the `id` key in the payload to deduplicate incoming data.
+GitLab can stream a single event more than once to the same destination. Use the `id` key in the payload to deduplicate
+incoming data.
 
-## Add a new streaming destination
+WARNING:
+Streaming destinations receive **all** audit event data, which could include sensitive information. Make sure you trust
+the streaming destination.
 
-Add a new streaming destination to top-level groups or an entire instance.
+## Top-level group streaming destinations
 
-WARNING:
-Streaming destinations receive **all** audit event data, which could include sensitive information. Make sure you trust the streaming destination.
+Manage streaming destinations for top-level groups.
+
+### HTTP destinations
+
+Manage HTTP streaming destinations for top-level groups.
+
+#### Add a new HTTP destination
 
-### Top-level group streaming destinations
+Add a new HTTP streaming destination to a top-level group.
 
 Prerequisites:
 
@@ -42,7 +50,7 @@ To add streaming destinations to a top-level group:
 1. Select **Secure > Audit events**.
 1. On the main area, select **Streams** tab.
 1. Select **Add streaming destination** and select **HTTP endpoint** to show the section for adding destinations.
-1. Enter the destination URL to add.
+1. In the **Name** and **Destination URL** fields, add a destination name and URL.
 1. Optional. Locate the **Custom HTTP headers** table.
 1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
    **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
@@ -50,157 +58,172 @@ To add streaming destinations to a top-level group:
    20 headers per streaming destination.
 1. After all headers have been filled out, select **Add** to add the new streaming destination.
 
-### Instance streaming destinations **(ULTIMATE SELF)**
+#### List HTTP destinations
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
-> - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
+Prerequisites:
 
-FLAG:
-On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
-`ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
+- Owner role for a group.
+
+To list the streaming destinations for a top-level group:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select **Streams** tab.
+1. Select the stream to expand it and see all the custom HTTP headers.
+
+#### Update an HTTP destination
 
 Prerequisites:
 
-- Administrator access on the instance.
+- Owner role for a group.
 
-To add a streaming destination for an instance:
+To update a streaming destination's name:
 
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
-1. Select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
 1. On the main area, select **Streams** tab.
-1. Select **Add streaming destination** and select **HTTP endpoint** to show the section for adding destinations.
-1. Enter the destination URL to add.
-1. Optional. To add custom HTTP headers, select **Add header** to create a new name and value pair, and input their values. Repeat this step for as many name and value pairs are required. You can add up to 20 headers per streaming destination.
+1. Select the stream to expand.
+1. In the **Name** fields, add a destination name to update.
+1. Select **Save** to update the streaming destination.
+
+To update a streaming destination's custom HTTP headers:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select **Streams** tab.
+1. Select the stream to expand.
+1. Locate the **Custom HTTP headers** table.
+1. Locate the header that you wish to update.
 1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
    **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
-1. Select **Add header** to create a new name and value pair. Repeat this step for as many name and value pairs are required. You can add up to
+1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
    20 headers per streaming destination.
-1. After all headers have been filled out, select **Add** to add the new streaming destination.
+1. Select **Save** to update the streaming destination.
 
-### Google Cloud Logging streaming
+#### Delete an HTTP destination
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124384) in GitLab 16.2.
+Delete streaming destinations for a top-level group. When the last destination is successfully deleted, streaming is
+disabled for the top-level group.
 
 Prerequisites:
 
-- Owner role for a top-level group.
+- Owner role for a group.
 
-To add Google Cloud Logging streaming destinations to a top-level group:
+To delete a streaming destination:
 
 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
-1. Select **Add streaming destination** and select **Google Cloud Logging** to show the section for adding destinations.
-1. Enter the Google Project ID, Google Client Email, Log ID, and Google Private Key to add.
-1. Select **Add** to add the new streaming destination.
+1. On the main area, select the **Streams** tab.
+1. Select the stream to expand.
+1. Select **Delete destination**.
+1. Confirm by selecting **Delete destination** in the dialog.
+
+To delete only the custom HTTP headers for a streaming destination:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select the **Streams** tab.
+1. Select the stream to expand.
+1. Locate the **Custom HTTP headers** table.
+1. Locate the header that you wish to remove.
+1. To the right of the header, select **Delete** (**{remove}**).
+1. Select **Save** to update the streaming destination.
 
-## List streaming destinations
+#### Verify event authenticity
 
-List new streaming destinations for top-level groups or an entire instance.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360814) in GitLab 15.2.
 
-### For top-level group streaming destinations
+Each streaming destination has a unique verification token (`verificationToken`) that can be used to verify the authenticity of the event. This
+token is either specified by the Owner or generated automatically when the event destination is created and cannot be changed.
+
+Each streamed event contains the verification token in the `X-Gitlab-Event-Streaming-Token` HTTP header that can be verified against
+the destination's value when listing streaming destinations.
 
 Prerequisites:
 
 - Owner role for a group.
 
-To list the streaming destinations for a top-level group:
+To list streaming destinations and see the verification tokens:
 
 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
-1. Select the stream URL to expand it and see all the custom HTTP headers.
+1. On the main area, select the **Streams**.
+1. Select the stream to expand.
+1. Locate the **Verification token** input.
 
-### For instance streaming destinations
+#### Update event filters
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
-> - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
+> Event type filtering in the UI with a defined list of audit event types [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/413581) in GitLab 16.1.
 
-FLAG:
-On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
-`ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
+When this feature is enabled for a group, you can permit users to filter streamed audit events per destination.
+If the feature is enabled with no filters, the destination receives all audit events.
 
-Prerequisites:
+A streaming destination that has an event type filter set has a **filtered** (**{filter}**) label.
 
-- Administrator access on the instance.
+To update a streaming destination's event filters:
 
-To list the streaming destinations for an instance:
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Secure > Audit events**.
+1. On the main area, select the **Streams** tab.
+1. Select the stream to expand.
+1. Locate the **Filter by audit event type** dropdown list.
+1. Select the dropdown list and select or clear the required event types.
+1. Select **Save** to update the event filters.
 
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
-1. Select **Admin Area**.
-1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select **Streams** tab.
+#### Override default content type header
 
-### Google Cloud Logging streaming
+By default, streaming destinations use a `content-type` header of `application/x-www-form-urlencoded`. However, you
+might want to set the `content-type` header to something else. For example ,`application/json`.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124384) in GitLab 16.2.
+To override the `content-type` header default value for a top-level group streaming destination, use either:
 
-Prerequisites:
+- The [GitLab UI](#update-an-http-destination).
+- The [GraphQL API](graphql_api.md#update-streaming-destinations).
 
-- Owner role for a top-level group.
+### Google Cloud Logging destinations
 
-To list Google Cloud Logging streaming destinations for a top-level group:
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124384) in GitLab 16.2.
 
-1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
-1. Select **Secure > Audit events**.
-1. On the main area, select **Streams** tab.
-1. Select the Google Cloud Logging stream to expand and see all the fields.
+Manage Google Cloud Logging destinations for top-level groups.
+
+#### Prerequisites
 
-## Update streaming destinations
+Before setting up Google Cloud Logging streaming audit events, you must:
 
-Update streaming destinations for a top-level group or an entire instance.
+1. Create a service account for Google Cloud with the appropriate credentials and permissions. This account is used to configure audit log streaming authentication.
+   For more information, see [Creating and managing service accounts in the Google Cloud documentation](https://cloud.google.com/iam/docs/service-accounts-create#creating).
+1. Enable the **Logs Writer** role for the service account to enable logging on Google Cloud. For more information, see [Access control with IAM](https://cloud.google.com/logging/docs/access-control#logging.logWriter).
+1. Create a JSON key for the service account. For more information, see [Creating a service account key](https://cloud.google.com/iam/docs/keys-create-delete#creating).
 
-### Top-level group streaming destinations
+#### Add a new Google Cloud Logging destination
 
 Prerequisites:
 
-- Owner role for a group.
+- Owner role for a top-level group.
 
-To update a streaming destination's custom HTTP headers:
+To add Google Cloud Logging streaming destinations to a top-level group:
 
 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select **Secure > Audit events**.
 1. On the main area, select **Streams** tab.
-1. Select the stream URL to expand.
-1. Locate the **Custom HTTP headers** table.
-1. Locate the header that you wish to update.
-1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
-   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
-1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
-   20 headers per streaming destination.
-1. Select **Save** to update the streaming destination.
-
-### Instance streaming destinations **(ULTIMATE SELF)**
-
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
-> - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
+1. Select **Add streaming destination** and select **Google Cloud Logging** to show the section for adding destinations.
+1. Enter the Google Project ID, Google Client Email, Log ID, and Google Private Key to add.
+1. Select **Add** to add the new streaming destination.
 
-FLAG:
-On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
-`ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
+#### List Google Cloud Logging destinations
 
 Prerequisites:
 
-- Administrator access on the instance.
+- Owner role for a top-level group.
 
-To update the streaming destinations for an instance:
+To list Google Cloud Logging streaming destinations for a top-level group:
 
-1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select **Secure > Audit events**.
-1. On the main area, select the **Streams** tab.
-1. To the right of the item, select **Edit** (**{pencil}**).
-1. Locate the **Custom HTTP headers** table.
-1. Locate the header that you wish to update.
-1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
-   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
-1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
-   20 headers per streaming destination.
-1. Select **Save** to update the streaming destination.
-
-### Google Cloud Logging streaming
+1. On the main area, select **Streams** tab.
+1. Select the Google Cloud Logging stream to expand and see all the fields.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124384) in GitLab 16.2.
+#### Update a Google Cloud Logging destination
 
 Prerequisites:
 
@@ -215,38 +238,22 @@ To update Google Cloud Logging streaming destinations to a top-level group:
 1. Enter the Google Project ID, Google Client Email, Log ID, and Google Private Key to update.
 1. Select **Save** to update the streaming destination.
 
-## Delete streaming destinations
-
-Delete streaming destinations for a top-level group or an entire instance. When the last destination is successfully
-deleted, streaming is disabled for the group or the instance.
-
-### Top-level group streaming destinations
+#### Delete a Google Cloud Logging streaming destination
 
 Prerequisites:
 
-- Owner role for a group.
+- Owner role for a top-level group.
 
-To delete a streaming destination:
+To delete Google Cloud Logging streaming destinations to a top-level group:
 
 1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
 1. Select **Secure > Audit events**.
 1. On the main area, select the **Streams** tab.
-1. Select the stream URL to expand.
+1. Select the Google Cloud Logging stream to expand.
 1. Select **Delete destination**.
-1. Confirm by selecting **Delete destination** in the modal.
-
-To delete only the custom HTTP headers for a streaming destination:
-
-1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
-1. Select **Secure > Audit events**.
-1. On the main area, select the **Streams** tab.
-1. Select the stream URL to expand.
-1. Locate the **Custom HTTP headers** table.
-1. Locate the header that you wish to remove.
-1. To the right of the header, select **Delete** (**{remove}**).
-1. Select **Save** to update the streaming destination.
+1. Confirm by selecting **Delete destination** in the dialog.
 
-### Instance streaming destinations
+## Instance streaming destinations **(ULTIMATE SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
 > - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
@@ -255,76 +262,108 @@ FLAG:
 On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
 `ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
 
+Manage HTTP streaming destinations for an entire instance.
+
+### Add a new HTTP destination
+
+Add a new HTTP streaming destination to an instance.
+
 Prerequisites:
 
 - Administrator access on the instance.
 
-To delete the streaming destinations for an instance:
+To add a streaming destination for an instance:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select the **Streams** tab.
-1. Select the stream URL to expand.
-1. Select **Delete destination**.
-1. Confirm by selecting **Delete destination** in the modal.
+1. On the main area, select **Streams** tab.
+1. Select **Add streaming destination** and select **HTTP endpoint** to show the section for adding destinations.
+1. In the **Name** and **Destination URL** fields, add a destination name and URL.
+1. Optional. To add custom HTTP headers, select **Add header** to create a new name and value pair, and input their values. Repeat this step for as many name and value pairs are required. You can add up to 20 headers per streaming destination.
+1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
+   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
+1. Select **Add header** to create a new name and value pair. Repeat this step for as many name and value pairs are required. You can add up to
+   20 headers per streaming destination.
+1. After all headers have been filled out, select **Add** to add the new streaming destination.
 
-To delete only the custom HTTP headers for a streaming destination:
+### List HTTP destinations
+
+Prerequisites:
+
+- Administrator access on the instance.
+
+To list the streaming destinations for an instance:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select the **Streams** tab.
-1. To the right of the item, **Edit** (**{pencil}**).
-1. Locate the **Custom HTTP headers** table.
-1. Locate the header that you wish to remove.
-1. To the right of the header, select **Delete** (**{remove}**).
-1. Select **Save** to update the streaming destination.
-
-### Google Cloud Logging streaming
+1. On the main area, select **Streams** tab.
+1. Select the stream to expand it and see all the custom HTTP headers.
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/124384) in GitLab 16.2.
+### Update an HTTP destination
 
 Prerequisites:
 
-- Owner role for a top-level group.
+- Administrator access on the instance.
 
-To delete Google Cloud Logging streaming destinations to a top-level group:
+To update a instance streaming destination's name:
 
-1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
-1. Select **Secure > Audit events**.
-1. On the main area, select the **Streams** tab.
-1. Select the Google Cloud Logging stream to expand.
-1. Select **Delete destination**.
-1. Confirm by selecting **Delete destination** in the modal.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select **Streams** tab.
+1. Select the stream to expand.
+1. In the **Name** fields, add a destination name to update.
+1. Select **Save** to update the streaming destination.
 
-## Verify event authenticity
+To update a instance streaming destination's custom HTTP headers:
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/345424) in GitLab 14.8.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select **Streams** tab.
+1. Select the stream to expand.
+1. Locate the **Custom HTTP headers** table.
+1. Locate the header that you wish to update.
+1. Ignore the **Active** checkbox because it isn't functional. To track progress on adding functionality to the
+   **Active** checkbox, see [issue 367509](https://gitlab.com/gitlab-org/gitlab/-/issues/367509).
+1. Select **Add header** to create a new name and value pair. Enter as many name and value pairs as required. You can add up to
+   20 headers per streaming destination.
+1. Select **Save** to update the streaming destination.
 
-Each streaming destination has a unique verification token (`verificationToken`) that can be used to verify the authenticity of the event. This
-token is either specified by the Owner or generated automatically when the event destination is created and cannot be changed.
+### Delete an HTTP destination
 
-Each streamed event contains the verification token in the `X-Gitlab-Event-Streaming-Token` HTTP header that can be verified against
-the destination's value when [listing streaming destinations](#list-streaming-destinations).
+Delete streaming destinations for an entire instance. When the last destination is successfully deleted, streaming is
+disabled for the instance.
 
-### Top-level group streaming destinations
+Prerequisites:
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/360814) in GitLab 15.2.
+- Administrator access on the instance.
 
-Prerequisites:
+To delete the streaming destinations for an instance:
 
-- Owner role for a group.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
+1. Select the stream to expand.
+1. Select **Delete destination**.
+1. Confirm by selecting **Delete destination** in the dialog.
 
-To list streaming destinations and see the verification tokens:
+To delete only the custom HTTP headers for a streaming destination:
 
-1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
-1. Select **Secure > Audit events**.
-1. On the main area, select the **Streams**.
-1. Select the stream URL to expand.
-1. Locate the **Verification token** input.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
+1. On the main area, select the **Streams** tab.
+1. To the right of the item, **Edit** (**{pencil}**).
+1. Locate the **Custom HTTP headers** table.
+1. Locate the header that you wish to remove.
+1. To the right of the header, select **Delete** (**{remove}**).
+1. Select **Save** to update the streaming destination.
 
-### Instance streaming destinations
+### Verify event authenticity
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/398107) in GitLab 16.1 [with a flag](../feature_flags.md) named `ff_external_audit_events`. Disabled by default.
 > - [Feature flag `ff_external_audit_events`](https://gitlab.com/gitlab-org/gitlab/-/issues/393772) enabled by default in GitLab 16.2.
@@ -333,6 +372,12 @@ FLAG:
 On self-managed GitLab, by default this feature is enabled. To disable it, an administrator can [disable the feature flag](../feature_flags.md) named
 `ff_external_audit_events`. On GitLab.com, this feature is available but can be configured by GitLab.com administrators only. The feature is ready for production use.
 
+Each streaming destination has a unique verification token (`verificationToken`) that can be used to verify the authenticity of the event. This
+token is either specified by the Owner or generated automatically when the event destination is created and cannot be changed.
+
+Each streamed event contains the verification token in the `X-Gitlab-Event-Streaming-Token` HTTP header that can be verified against
+the destination's value when listing streaming destinations.
+
 Prerequisites:
 
 - Administrator access on the instance.
@@ -342,36 +387,38 @@ To list streaming destinations for an instance and see the verification tokens:
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Audit Events**.
-1. On the main area, select the **Streams**.
+1. On the main area, select the **Streams** tab.
 1. View the verification token on the right side of each item.
 
-## Event type filters
+### Update event filters
 
-> Event type filtering in the UI with a defined list of audit event types [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/413581) in GitLab 16.1.
+> Event type filtering in the UI with a defined list of audit event types [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/415013) in GitLab 16.3.
 
-When this feature is enabled for a group, you can permit users to filter streamed audit events per destination.
+When this feature is enabled, you can permit users to filter streamed audit events per destination.
 If the feature is enabled with no filters, the destination receives all audit events.
 
 A streaming destination that has an event type filter set has a **filtered** (**{filter}**) label.
 
 To update a streaming destination's event filters:
 
-1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
-1. Select **Secure > Audit events**.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Monitoring > Audit Events**.
 1. On the main area, select the **Streams** tab.
-1. Select the stream URL to expand.
-1. Locate the **Filter by audit event type** dropdown.
+1. Select the stream to expand.
+1. Locate the **Filter by audit event type** dropdown list.
 1. Select the dropdown list and select or clear the required event types.
 1. Select **Save** to update the event filters.
 
-## Override default content type header
+### Override default content type header
 
 By default, streaming destinations use a `content-type` header of `application/x-www-form-urlencoded`. However, you
 might want to set the `content-type` header to something else. For example ,`application/json`.
 
-To override the `content-type` header default value for either a top-level group streaming destination or an instance
-streaming destination, use either the [GitLab UI](#update-streaming-destinations) or using the
-[GraphQL API](graphql_api.md#update-streaming-destinations).
+To override the `content-type` header default value for an instance streaming destination, use either:
+
+- The [GitLab UI](#update-an-http-destination-1).
+- The [GraphQL API](graphql_api.md#update-streaming-destinations).
 
 ## Payload schema
 
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md
index 69c97982562..9657994ba8f 100644
--- a/doc/administration/audit_events.md
+++ b/doc/administration/audit_events.md
@@ -4,7 +4,7 @@ group: Compliance
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Audit events **(PREMIUM)**
+# Audit events **(PREMIUM ALL)**
 
 Use audit events to track important events, including who performed the related action and when.
 You can use audit events to track, for example:
@@ -77,6 +77,7 @@ To view instance audit events:
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/1449) in GitLab 13.4.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/285441) in GitLab 13.7.
+> - Entity type `Gitlab::Audit::InstanceScope` for instance audit events [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/418185) in GitLab 16.2.
 
 You can export the current view (including filters) of your instance audit events as a CSV file. To export the instance
 audit events to CSV:
@@ -100,22 +101,22 @@ Data is encoded with:
 
 The first row contains the headers, which are listed in the following table along with a description of the values:
 
-| Column               | Description                                        |
-|:---------------------|:---------------------------------------------------|
-| **ID**               | Audit event `id`.                                  |
-| **Author ID**        | ID of the author.                                  |
-| **Author Name**      | Full name of the author.                           |
-| **Entity ID**        | ID of the scope.                                   |
-| **Entity Type**      | Type of the scope (`Project`, `Group`, or `User`). |
-| **Entity Path**      | Path of the scope.                                 |
-| **Target ID**        | ID of the target.                                  |
-| **Target Type**      | Type of the target.                                |
-| **Target Details**   | Details of the target.                             |
-| **Action**           | Description of the action.                         |
-| **IP Address**       | IP address of the author who performed the action. |
-| **Created At (UTC)** | Formatted as `YYYY-MM-DD HH:MM:SS`.                |
-
-## View sign-in events **(FREE)**
+| Column               | Description                                                        |
+|:---------------------|:-------------------------------------------------------------------|
+| **ID**               | Audit event `id`.                                                  |
+| **Author ID**        | ID of the author.                                                  |
+| **Author Name**      | Full name of the author.                                           |
+| **Entity ID**        | ID of the scope.                                                   |
+| **Entity Type**      | Type of the scope (`Project`, `Group`, `User`, or `Gitlab::Audit::InstanceScope`). |
+| **Entity Path**      | Path of the scope.                                                 |
+| **Target ID**        | ID of the target.                                                  |
+| **Target Type**      | Type of the target.                                                |
+| **Target Details**   | Details of the target.                                             |
+| **Action**           | Description of the action.                                         |
+| **IP Address**       | IP address of the author who performed the action.                 |
+| **Created At (UTC)** | Formatted as `YYYY-MM-DD HH:MM:SS`.                                |
+
+## View sign-in events **(FREE ALL)**
 
 Successful sign-in events are the only audit events available at all tiers. To see successful sign-in events:
 
@@ -252,10 +253,10 @@ The following actions on projects generate project audit events:
   [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/377877) in GitLab 15.6.
 - Project was scheduled for deletion due to inactivity.
   [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/85689) in GitLab 15.0.
-- Project deploy token was successfully created, revoked or deleted.
-  [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/353451) in GitLab 14.9.
-- Failed attempt to create a project deploy token.
-  [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/353451) in GitLab 14.9.
+- Project deploy token was successfully created, revoked, or deleted. Introduced in GitLab 14.9.
+  GitLab team members can view more information in this confidential issue: `https://gitlab.com/gitlab-org/gitlab/-/issues/353451`.
+- Failed attempt to create a project deploy token. Introduced in GitLab 14.9.
+  GitLab team members can view more information in this confidential issue: `https://gitlab.com/gitlab-org/gitlab/-/issues/353451`.
 - When [strategies for feature flags](../operations/feature_flags.md#feature-flag-strategies) are changed.
   [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68408) in GitLab 14.3.
 
@@ -405,7 +406,7 @@ The following user actions on a GitLab instance generate instance audit events:
 
 Instance events can also be accessed using the [Instance Audit Events API](../api/audit_events.md#instance-audit-events).
 
-#### Application settings **(PREMIUM)**
+#### Application settings **(PREMIUM ALL)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/282428) in GitLab 16.2.
 
diff --git a/doc/administration/audit_reports.md b/doc/administration/audit_reports.md
index 8e91466d345..84425dd7b89 100644
--- a/doc/administration/audit_reports.md
+++ b/doc/administration/audit_reports.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 description: 'Learn how to create evidence artifacts typically requested by a 3rd party auditor.'
 ---
 
-# Audit reports **(FREE)**
+# Audit reports **(FREE ALL)**
 
 GitLab can help owners and administrators respond to auditors by generating
 comprehensive reports. These audit reports vary in scope, depending on the
diff --git a/doc/administration/auth/atlassian.md b/doc/administration/auth/atlassian.md
index 8525b3e9b98..cbfb4921e14 100644
--- a/doc/administration/auth/atlassian.md
+++ b/doc/administration/auth/atlassian.md
@@ -5,7 +5,7 @@ group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Atlassian OmniAuth Provider **(FREE SELF)**
+# Use Atlassian as an OAuth 2.0 authentication provider **(FREE SELF)**
 
 To enable the Atlassian OmniAuth provider for passwordless authentication you must register an application with Atlassian.
 
@@ -77,7 +77,7 @@ To enable the Atlassian OmniAuth provider for passwordless authentication you mu
 
 1. For the changes to take effect:
    - If you installed using the Linux package, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
-   - If you self-compiled your installation, [restart GitLab](../restart_gitlab.md#installations-from-source).
+   - If you self-compiled your installation, [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 On the sign-in page there should now be an Atlassian icon below the regular sign in form. Select the icon to begin the authentication process.
 
diff --git a/doc/administration/auth/cognito.md b/doc/administration/auth/cognito.md
index 8c8abf1524f..554b3d776ac 100644
--- a/doc/administration/auth/cognito.md
+++ b/doc/administration/auth/cognito.md
@@ -5,10 +5,10 @@ group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Amazon Web Services Cognito **(FREE SELF)**
+# Use AWS Cognito as an OAuth 2.0 authentication provider **(FREE SELF)**
 
-Amazon Cognito lets you add user sign-up, sign-in, and access control to your GitLab instance.
-The following documentation enables Cognito as an OAuth 2.0 provider.
+Amazon Web Services (AWS) Cognito lets you add user sign-up, sign-in, and access control to your GitLab instance.
+The following documentation enables AWS Cognito as an OAuth 2.0 provider.
 
 ## Configure AWS Cognito
 
diff --git a/doc/administration/auth/crowd.md b/doc/administration/auth/crowd.md
index 08c1f5e7513..6ced9f844cd 100644
--- a/doc/administration/auth/crowd.md
+++ b/doc/administration/auth/crowd.md
@@ -5,7 +5,7 @@ group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Atlassian Crowd OmniAuth provider (deprecated) **(FREE SELF)**
+# Use Atlassian Crowd as an OAuth 2.0 authentication provider (deprecated) **(FREE SELF)**
 
 WARNING:
 This feature was [deprecated](https://gitlab.com/gitlab-org/gitlab/-/issues/369117) in GitLab 15.3 and is planned for
@@ -78,7 +78,7 @@ this provider also allows Crowd authentication for Git-over-https requests.
 1. Change `YOUR_APP_PASSWORD` to the application password you've set.
 1. Save the configuration file.
 1. [Reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) (Linux package installations) or
-   [restart](../restart_gitlab.md#installations-from-source) (self-compiled installations) for the changes to take effect.
+   [restart](../restart_gitlab.md#self-compiled-installations) (self-compiled installations) for the changes to take effect.
 
 On the sign in page there should now be a Crowd tab in the sign in form.
 
diff --git a/doc/administration/auth/index.md b/doc/administration/auth/index.md
index 4a8e230a944..4e96cdf0411 100644
--- a/doc/administration/auth/index.md
+++ b/doc/administration/auth/index.md
@@ -19,7 +19,7 @@ and the following external authentication and authorization providers:
 NOTE:
 UltraAuth has removed their software which supports OmniAuth integration. We have therefore removed all references to UltraAuth integration.
 
-## SaaS vs Self-Managed Comparison
+## SaaS vs self-managed comparison
 
 The external authentication and authorization providers may support the following capabilities.
 For more information, see the links shown on this page for each external provider.
diff --git a/doc/administration/auth/jwt.md b/doc/administration/auth/jwt.md
index 9a74064136a..9f95682fc47 100644
--- a/doc/administration/auth/jwt.md
+++ b/doc/administration/auth/jwt.md
@@ -5,7 +5,7 @@ group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# JWT OmniAuth provider **(FREE SELF)**
+# Use JWT as an OAuth 2.0 authentication provider **(FREE SELF)**
 
 To enable the JWT OmniAuth provider, you must register your application with JWT.
 JWT provides you with a secret key for you to use.
@@ -77,7 +77,7 @@ JWT provides you with a secret key for you to use.
 1. Save the configuration file.
 1. For changes to take effect, if you:
    - Used the Linux package to install GitLab, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
-   - Self-compiled your GitLab installation, [restart GitLab](../restart_gitlab.md#installations-from-source).
+   - Self-compiled your GitLab installation, [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 On the sign in page there should now be a JWT icon below the regular sign in form.
 Select the icon to begin the authentication process. JWT asks the user to
diff --git a/doc/administration/auth/ldap/google_secure_ldap.md b/doc/administration/auth/ldap/google_secure_ldap.md
index d484059c79f..388288bbe49 100644
--- a/doc/administration/auth/ldap/google_secure_ldap.md
+++ b/doc/administration/auth/ldap/google_secure_ldap.md
@@ -210,7 +210,7 @@ For self-compiled installations:
              -----END PRIVATE KEY-----
    ```
 
-1. Save the file and [restart](../../restart_gitlab.md#installations-from-source) GitLab for the changes to take effect.
+1. Save the file and [restart](../../restart_gitlab.md#self-compiled-installations) GitLab for the changes to take effect.
 
 ## Using encrypted credentials
 
diff --git a/doc/administration/auth/ldap/index.md b/doc/administration/auth/ldap/index.md
index 1905a009eb6..746d1f6b7fd 100644
--- a/doc/administration/auth/ldap/index.md
+++ b/doc/administration/auth/ldap/index.md
@@ -90,7 +90,7 @@ Here's an example of setting up LDAP with only the required options.
        'port' => 636,
        'uid' => 'sAMAccountName',
        'encryption' => 'simple_tls',
-       'base' => 'dc=example,dc=com',
+       'base' => 'dc=example,dc=com'
      }
    }
    ```
@@ -155,7 +155,7 @@ For more information, see
                'port' => 636,
                'uid' => 'sAMAccountName',
                'encryption' => 'simple_tls',
-               'base' => 'dc=example,dc=com',
+               'base' => 'dc=example,dc=com'
              }
            }
    ```
@@ -237,7 +237,8 @@ These configuration settings are available:
 
 ### SSL configuration settings
 
-These SSL configuration settings are available:
+SSL configuration settings can be configured under `tls_options` name/value
+pairs. The following SSL configuration settings are available:
 
 | Setting       | Description | Required | Examples |
 |---------------|-------------|----------|----------|
@@ -247,6 +248,143 @@ These SSL configuration settings are available:
 | `cert`        | Client certificate. | **{dotted-circle}** No | `'-----BEGIN CERTIFICATE----- <REDACTED> -----END CERTIFICATE -----'` |
 | `key`         | Client private key. | **{dotted-circle}** No | `'-----BEGIN PRIVATE KEY----- <REDACTED> -----END PRIVATE KEY -----'` |
 
+The examples below illustrate how to set `ca_file` and `ssl_version` in `tls_options`:
+
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
+
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   gitlab_rails['ldap_enabled'] = true
+   gitlab_rails['ldap_servers'] = {
+     'main' => {
+       'label' => 'LDAP',
+       'host' =>  'ldap.mydomain.com',
+       'port' => 636,
+       'uid' => 'sAMAccountName',
+       'encryption' => 'simple_tls',
+       'base' => 'dc=example,dc=com'
+       'tls_options' => {
+         'ca_file' => '/path/to/ca_file.pem',
+         'ssl_version' => 'TLSv1_2'
+       }
+     }
+   }
+   ```
+
+1. Save the file and reconfigure GitLab:
+
+   ```shell
+   sudo gitlab-ctl reconfigure
+   ```
+
+:::TabTitle Helm chart (Kubernetes)
+
+1. Export the Helm values:
+
+   ```shell
+   helm get values gitlab > gitlab_values.yaml
+   ```
+
+1. Edit `gitlab_values.yaml`:
+
+   ```yaml
+   global:
+     appConfig:
+       ldap:
+         servers:
+           main:
+             label: 'LDAP'
+             host: 'ldap.mydomain.com'
+             port: 636
+             uid: 'sAMAccountName'
+             base: 'dc=example,dc=com'
+             encryption: 'simple_tls'
+             tls_options:
+               ca_file: '/path/to/ca_file.pem'
+               ssl_version: 'TLSv1_2'
+   ```
+
+1. Save the file and apply the new values:
+
+   ```shell
+   helm upgrade -f gitlab_values.yaml gitlab gitlab/gitlab
+   ```
+
+For more information, see
+[how to configure LDAP for a GitLab instance that was installed by using the Helm chart](https://docs.gitlab.com/charts/charts/globals.html#ldap).
+
+:::TabTitle Docker
+
+1. Edit `docker-compose.yml`:
+
+   ```yaml
+   version: "3.6"
+   services:
+     gitlab:
+       image: 'gitlab/gitlab-ee:latest'
+       restart: always
+       hostname: 'gitlab.example.com'
+       environment:
+         GITLAB_OMNIBUS_CONFIG: |
+           gitlab_rails['ldap_enabled'] = true
+           gitlab_rails['ldap_servers'] = {
+             'main' => {
+               'label' => 'LDAP',
+               'host' =>  'ldap.mydomain.com',
+               'port' => 636,
+               'uid' => 'sAMAccountName',
+               'encryption' => 'simple_tls',
+               'base' => 'dc=example,dc=com',
+               'tls_options' => {
+                 'ca_file' => '/path/to/ca_file.pem',
+                 'ssl_version' => 'TLSv1_2'
+               }
+             }
+           }
+   ```
+
+1. Save the file and restart GitLab:
+
+   ```shell
+   docker compose up -d
+   ```
+
+:::TabTitle Self-compiled (source)
+
+1. Edit `/home/git/gitlab/config/gitlab.yml`:
+
+   ```yaml
+   production: &base
+     ldap:
+       enabled: true
+       servers:
+         main:
+           label: 'LDAP'
+           host: 'ldap.mydomain.com'
+           port: 636
+           uid: 'sAMAccountName'
+           encryption: 'simple_tls'
+           base: 'dc=example,dc=com'
+           tls_options:
+             ca_file: '/path/to/ca_file.pem'
+             ssl_version: 'TLSv1_2'
+   ```
+
+1. Save the file and restart GitLab:
+
+   ```shell
+   # For systems running systemd
+   sudo systemctl restart gitlab.target
+
+   # For systems running SysV init
+   sudo service gitlab restart
+   ```
+
+::EndTabs
+
 ### Attribute configuration settings
 
 GitLab uses these LDAP attributes to create an account for the LDAP user. The specified
diff --git a/doc/administration/auth/oidc.md b/doc/administration/auth/oidc.md
index d48de109bd0..8ef95872ad4 100644
--- a/doc/administration/auth/oidc.md
+++ b/doc/administration/auth/oidc.md
@@ -5,7 +5,7 @@ group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# OpenID Connect OmniAuth provider **(FREE SELF)**
+# Use OpenID Connect as an OAuth 2.0 authentication provider **(FREE SELF)**
 
 GitLab can use [OpenID Connect](https://openid.net/specs/openid-connect-core-1_0.html)
 as an OmniAuth provider.
@@ -22,7 +22,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
    sudo editor /etc/gitlab/gitlab.rb
    ```
 
-   For installations from source:
+   For self-compiled installations:
 
    ```shell
    cd /home/git/gitlab
@@ -187,7 +187,7 @@ The OpenID Connect provides you with a client's details and secret for you to us
 1. For changes to take effect, if you:
 
    - Used the Linux package to install GitLab, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
-   - Self-compiled your GitLab installation, [restart GitLab](../restart_gitlab.md#installations-from-source).
+   - Self-compiled your GitLab installation, [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 On the sign in page, you have an OpenID Connect option below the regular sign in form.
 Select this option to begin the authentication process. The OpenID Connect provider
@@ -581,7 +581,7 @@ gitlab_rails['omniauth_providers'] = [
 ]
 ```
 
-Example installations from source configuration (file path: `config/gitlab.yml`):
+Example configuration for self-compiled installations (file path: `config/gitlab.yml`):
 
 ```yaml
   - { name: 'openid_connect', # do not change this parameter
@@ -750,7 +750,7 @@ def sync_missing_provider(self, user: User, extern_uid: str)
 
 For more information, see the [GitLab API user method documentation](https://python-gitlab.readthedocs.io/en/stable/gl_objects/users.html#examples).
 
-## Configure users based on OIDC group membership **(PREMIUM)**
+## Configure users based on OIDC group membership **(PREMIUM ALL)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/209898) in GitLab 15.10.
 
@@ -774,7 +774,9 @@ response to require users to be members of a certain group, configure GitLab to
 
 If you do not set `required_groups` or leave the setting empty, any user authenticated by the IdP through OIDC can use GitLab.
 
-For Linux package installations:
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -808,7 +810,7 @@ For Linux package installations:
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
-For self-compiled installations:
+:::TabTitle Self-compiled (source)
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
@@ -839,9 +841,11 @@ For self-compiled installations:
        }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#installations-from-source)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
+::EndTabs
+
 ### External groups
 
 Your IdP must pass group information to GitLab in the OIDC response. To use this
@@ -853,7 +857,9 @@ based on group membership, configure GitLab to identify:
   [external user](../external_users.md), using the
  `external_groups` setting.
 
-For Linux package installations:
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -887,7 +893,7 @@ For Linux package installations:
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
-For self-compiled installations:
+:::TabTitle Self-compiled (source)
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
@@ -918,9 +924,11 @@ For self-compiled installations:
        }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#installations-from-source)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
+::EndTabs
+
 ### Auditor groups **(PREMIUM SELF)**
 
 Your IdP must pass group information to GitLab in the OIDC response. To use this
@@ -930,7 +938,9 @@ response to assign users as auditors based on group membership, configure GitLab
 - Which group memberships grant the user auditor access, using the `auditor_groups`
   setting.
 
-For Linux package installations:
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -964,7 +974,7 @@ For Linux package installations:
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
-For self-compiled installations:
+:::TabTitle Self-compiled (source)
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
@@ -995,9 +1005,11 @@ For self-compiled installations:
        }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#installations-from-source)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
+::EndTabs
+
 ### Administrator groups
 
 Your IdP must pass group information to GitLab in the OIDC response. To use this
@@ -1007,7 +1019,9 @@ response to assign users as administrator based on group membership, configure G
 - Which group memberships grant the user administrator access, using the
  `admin_groups` setting.
 
-For Linux package installations:
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -1041,7 +1055,7 @@ For Linux package installations:
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect.
 
-For self-compiled installations:
+:::TabTitle Self-compiled (source)
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
@@ -1072,9 +1086,11 @@ For self-compiled installations:
        }
    ```
 
-1. Save the file and [reconfigure GitLab](../restart_gitlab.md#installations-from-source)
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
+::EndTabs
+
 ## Troubleshooting
 
 1. Ensure `discovery` is set to `true`. If you set it to `false`, you must
diff --git a/doc/administration/auth/smartcard.md b/doc/administration/auth/smartcard.md
index 5802db78dd6..1662639dd29 100644
--- a/doc/administration/auth/smartcard.md
+++ b/doc/administration/auth/smartcard.md
@@ -230,7 +230,7 @@ For self-compiled installations:
    Assign a value to at least one of the following variables:
    `client_certificate_required_host` or `client_certificate_required_port`.
 
-1. Save the file and [restart](../restart_gitlab.md#installations-from-source)
+1. Save the file and [restart](../restart_gitlab.md#self-compiled-installations)
    GitLab for the changes to take effect.
 
 ### Additional steps when using SAN extensions
@@ -260,7 +260,7 @@ For self-compiled installations:
       san_extensions: true
    ```
 
-1. Save the file and [restart](../restart_gitlab.md#installations-from-source)
+1. Save the file and [restart](../restart_gitlab.md#self-compiled-installations)
    GitLab for the changes to take effect.
 
 ### Additional steps when authenticating against an LDAP server
@@ -297,7 +297,7 @@ For self-compiled installations:
            smartcard_auth: optional
    ```
 
-1. Save the file and [restart](../restart_gitlab.md#installations-from-source)
+1. Save the file and [restart](../restart_gitlab.md#self-compiled-installations)
    GitLab for the changes to take effect.
 
 ### Require browser session with smartcard sign-in for Git access
@@ -325,7 +325,7 @@ For self-compiled installations:
      required_for_git_access: true
    ```
 
-1. Save the file and [restart](../restart_gitlab.md#installations-from-source)
+1. Save the file and [restart](../restart_gitlab.md#self-compiled-installations)
    GitLab for the changes to take effect.
 
 ## Passwords for users created via smartcard authentication
diff --git a/doc/administration/auth/test_oidc_oauth.md b/doc/administration/auth/test_oidc_oauth.md
index 95cca1ced86..be0ea5c963e 100644
--- a/doc/administration/auth/test_oidc_oauth.md
+++ b/doc/administration/auth/test_oidc_oauth.md
@@ -4,7 +4,7 @@ group: Authentication and Authorization
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Test OIDC/OAuth in GitLab **(FREE)**
+# Test OIDC/OAuth in GitLab **(FREE SELF)**
 
 To test OIDC/OAuth in GitLab, you must:
 
diff --git a/doc/administration/backup_restore/backup_gitlab.md b/doc/administration/backup_restore/backup_gitlab.md
index 24b7b453517..dc0724dc561 100644
--- a/doc/administration/backup_restore/backup_gitlab.md
+++ b/doc/administration/backup_restore/backup_gitlab.md
@@ -18,7 +18,9 @@ As a rough guideline, if you are using a [1k reference architecture](../referenc
 
 ## Scaling backups
 
-As the volume of GitLab data grows, the [backup command](#backup-command) takes longer to execute. At some point, the execution time becomes impractical. For example, it can take 24 hours or more.
+As the volume of GitLab data grows, the [backup command](#backup-command) takes longer to execute. [Backup options](#backup-options) such as [back up Git repositories concurrently](#back-up-git-repositories-concurrently) and [incremental repository backups](#incremental-repository-backups) can help to reduce execution time. At some point, the backup command becomes impractical by itself. For example, it can take 24 hours or more.
+
+In some cases, architecture changes may be warranted to allow backups to scale. If you are using a GitLab reference architecture, see [Back up and restore large reference architectures](backup_large_reference_architectures.md).
 
 For more information, see [alternative backup strategies](#alternative-backup-strategies).
 
@@ -27,6 +29,7 @@ For more information, see [alternative backup strategies](#alternative-backup-st
 - [PostgreSQL databases](#postgresql-databases)
 - [Git repositories](#git-repositories)
 - [Blobs](#blobs)
+- [Container Registry](#container-registry)
 - [Configuration files](#storing-configuration-files)
 - [Other data](#other-data)
 
@@ -87,6 +90,25 @@ The [backup command](#backup-command) doesn't back up blobs that aren't stored o
 - [Amazon S3 backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html)
 - [Google Cloud Storage Transfer Service](https://cloud.google.com/storage-transfer-service) and [Google Cloud Storage Object Versioning](https://cloud.google.com/storage/docs/object-versioning)
 
+### Container Registry
+
+[GitLab Container Registry](../packages/container_registry.md) storage can be configured in either:
+
+- The file system in a specific location.
+- An [Object Storage](../object_storage.md) solution. Object Storage solutions can be:
+  - Cloud based like Amazon S3 and Google Cloud Storage.
+  - Hosted by you (like MinIO).
+  - A Storage Appliance that exposes an Object Storage-compatible API.
+
+The backup command backs up registry data when they are stored in the default location on the file system.
+
+#### Object storage
+
+The [backup command](#backup-command) doesn't back up blobs that aren't stored on the file system. If you're using [object storage](../object_storage.md), be sure to enable backups with your object storage provider. For example, see:
+
+- [Amazon S3 backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/s3-backups.html)
+- [Google Cloud Storage Transfer Service](https://cloud.google.com/storage-transfer-service) and [Google Cloud Storage Object Versioning](https://cloud.google.com/storage/docs/object-versioning)
+
 ### Storing configuration files
 
 WARNING:
@@ -684,7 +706,7 @@ if you see a `411 Length Required` error message after attempting to upload,
 you may need to downgrade the `aws_signature_version` value from the default
 value to `2`, [due to this issue](https://github.com/fog/fog-aws/issues/428).
 
-For installations from source:
+For self-compiled installations:
 
 1. Edit `home/git/gitlab/config/gitlab.yml`:
 
@@ -724,7 +746,7 @@ For installations from source:
          #   server_side_encryption_kms_key_id: 'arn:aws:kms:YOUR-KEY-ID-HERE'
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect
 
 If you're uploading your backups to S3, you should create a new
@@ -813,7 +835,7 @@ For the Linux package (Omnibus):
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation)
    for the changes to take effect
 
-For installations from source:
+For self-compiled installations:
 
 1. Edit `home/git/gitlab/config/gitlab.yml`:
 
@@ -827,7 +849,7 @@ For installations from source:
          remote_directory: 'my.google.bucket'
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect
 
 ##### Using Azure Blob storage
@@ -867,7 +889,7 @@ For installations from source:
          remote_directory: '<AZURE BLOB CONTAINER>'
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect
 
 ::EndTabs
@@ -928,8 +950,8 @@ Because file system performance may affect overall GitLab performance,
 
 Don't set the following configuration keys to the same path:
 
-- `gitlab_rails['backup_path']` (`backup.path` for source installations).
-- `gitlab_rails['backup_upload_connection'].local_root` (`backup.upload.connection.local_root` for source installations).
+- `gitlab_rails['backup_path']` (`backup.path` for self-compiled installations).
+- `gitlab_rails['backup_upload_connection'].local_root` (`backup.upload.connection.local_root` for self-compiled installations).
 
 The `backup_path` configuration key sets the local location of the backup file. The `upload` configuration key is
 intended for use when the backup file is uploaded to a separate server, perhaps for archival purposes.
@@ -976,7 +998,7 @@ remaining after the failed upload attempt.
        remote_directory: 'gitlab_backups'
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
 ::EndTabs
@@ -1011,7 +1033,7 @@ setting.
      archive_permissions: 0644 # Makes the backup archives world-readable
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
 ::EndTabs
@@ -1102,7 +1124,7 @@ storage (for example, [AWS S3](https://docs.aws.amazon.com/AmazonS3/latest/user-
      keep_time: 604800
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
 ::EndTabs
@@ -1381,13 +1403,13 @@ after which users must reactivate 2FA.
    sudo gitlab-rails dbconsole --database main
    ```
 
-   For installations from source, GitLab 14.1 and earlier:
+   For self-compiled installations, GitLab 14.1 and earlier:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production
    ```
 
-   For installations from source, GitLab 14.2 and later:
+   For self-compiled installations, GitLab 14.2 and later:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production --database main
@@ -1434,13 +1456,13 @@ You may need to reconfigure or restart GitLab for the changes to take effect.
    sudo gitlab-rails dbconsole --database main
    ```
 
-   For installations from source, GitLab 14.1 and earlier:
+   For self-compiled installations, GitLab 14.1 and earlier:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production
    ```
 
-   For installations from source, GitLab 14.2 and later:
+   For self-compiled installations, GitLab 14.2 and later:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production --database main
@@ -1483,13 +1505,13 @@ You may need to reconfigure or restart GitLab for the changes to take effect.
    sudo gitlab-rails dbconsole --database main
    ```
 
-   For installations from source, GitLab 14.1 and earlier:
+   For self-compiled installations, GitLab 14.1 and earlier:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production
    ```
 
-   For installations from source, GitLab 14.2 and later:
+   For self-compiled installations, GitLab 14.2 and later:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production --database main
@@ -1538,13 +1560,13 @@ You should verify that the secrets are the root cause before deleting any data.
    sudo gitlab-rails dbconsole --database main
    ```
 
-   For installations from source, GitLab 14.1 and earlier:
+   For self-compiled installations, GitLab 14.1 and earlier:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production
    ```
 
-   For installations from source, GitLab 14.2 and later:
+   For self-compiled installations, GitLab 14.2 and later:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production --database main
@@ -1673,13 +1695,13 @@ Truncate the filenames in the `uploads` table:
    sudo gitlab-rails dbconsole
    ```
 
-   For installations from source, GitLab 14.2 and later:
+   For self-compiled installations, GitLab 14.2 and later:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production --database main
    ```
 
-   For installations from source, GitLab 14.1 and earlier:
+   For self-compiled installations, GitLab 14.1 and earlier:
 
    ```shell
    sudo -u git -H bundle exec rails dbconsole -e production
diff --git a/doc/administration/backup_restore/backup_large_reference_architectures.md b/doc/administration/backup_restore/backup_large_reference_architectures.md
new file mode 100644
index 00000000000..4e11a707052
--- /dev/null
+++ b/doc/administration/backup_restore/backup_large_reference_architectures.md
@@ -0,0 +1,341 @@
+---
+stage: Systems
+group: Geo
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Back up and restore large reference architectures **(FREE SELF)**
+
+This document describes how to:
+
+- [Configure daily backups](#configure-daily-backups)
+- Take a backup now (planned)
+- [Restore a backup](#restore-a-backup)
+
+This document is intended for environments using:
+
+- [Linux package (Omnibus) and cloud-native hybrid reference architectures 3,000 users and up](../reference_architectures/index.md)
+- [Amazon RDS](https://aws.amazon.com/rds/) for PostgreSQL data
+- [Amazon S3](https://aws.amazon.com/s3/) for object storage
+- [Object storage](../object_storage.md) to store everything possible, including [blobs](backup_gitlab.md#blobs) and [Container Registry](backup_gitlab.md#container-registry)
+
+## Configure daily backups
+
+### Configure backup of PostgreSQL and object storage data
+
+The [backup command](backup_gitlab.md) uses `pg_dump`, which is [not appropriate for databases over 100 GB](backup_gitlab.md#postgresql-databases). You must choose a PostgreSQL solution which has native, robust backup capabilities.
+
+[Object storage](../object_storage.md), ([not NFS](../nfs.md)) is recommended for storing GitLab data, including [blobs](backup_gitlab.md#blobs) and [Container registry](backup_gitlab.md#container-registry).
+
+1. [Configure AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html) to back up both RDS and S3 data. For maximum protection, [configure continuous backups as well as snapshot backups](https://docs.aws.amazon.com/aws-backup/latest/devguide/point-in-time-recovery.html).
+1. Configure AWS Backup to copy backups to a separate region. When AWS takes a backup, the backup can only be restored in the region the backup is stored.
+1. After AWS Backup has run at least one scheduled backup, then you can [create an on-demand backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-on-demand-backup.html) as needed.
+
+### Configure backup of Git repositories
+
+NOTE:
+There is a feature proposal to add the ability to back up repositories directly from Gitaly to object storage. See [epic 10077](https://gitlab.com/groups/gitlab-org/-/epics/10077).
+
+- Linux package (Omnibus):
+
+  We will continue to use the [backup command](backup_gitlab.md#backup-command) to back up Git repositories.
+
+  If utilization is low enough, you can run it from an existing GitLab Rails node. Otherwise, spin up another node.
+
+- Cloud native hybrid:
+
+  [The `backup-utility` command in a `toolbox` pod fails when there is a large amount of data](https://gitlab.com/gitlab-org/gitlab/-/issues/396343#note_1352989908). In this case, you must run the [backup command](backup_gitlab.md#backup-command) to back up Git repositories, and you must run it in a VM running the GitLab Linux package:
+
+  1. Spin up a VM with 8 vCPU and 7.2 GB memory. This node will be used to back up Git repositories. Note that
+     [a Praefect node cannot be used to back up Git data](https://gitlab.com/gitlab-org/gitlab/-/issues/396343#note_1385950340).
+  1. Configure the node as another **GitLab Rails** node as defined in your [reference architecture](../reference_architectures/index.md). As with other GitLab Rails nodes, this node must have access to your main Postgres database as well as to Gitaly Cluster.
+
+To back up the Git repositories:
+
+1. Ensure that the GitLab Rails node has enough attached storage to store Git repositories and an archive of the Git repositories. Additionally, the contents of forked repositories are duplicated into their forks during backup.
+   For example, if you have 5 GB worth of Git repositories and two forks of a 1 GB repository, then you require at least 14 GB of attached storage to account for:
+   - 7 GB of Git data.
+   - A 7 GB archive file of all Git data.
+1. SSH into the GitLab Rails node.
+1. [Configure uploading backups to remote cloud storage](backup_gitlab.md#upload-backups-to-a-remote-cloud-storage).
+1. [Configure AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html) for this bucket, or use a bucket in the same account and region as your production data object storage buckets, and ensure this bucket is included in your [preexisting AWS Backup](#configure-backup-of-postgresql-and-object-storage-data).
+1. Run the [backup command](backup_gitlab.md#backup-command), skipping PostgreSQL data:
+
+   ```shell
+   sudo gitlab-backup create SKIP=db
+   ```
+
+   The resulting tar file will include only the Git repositories and some metadata. Blobs such as uploads, artifacts, and LFS do not need to be explicitly skipped, because the command does not back up object storage by default. The tar file will be created in the [`/var/opt/gitlab/backups` directory](https://docs.gitlab.com/omnibus/settings/backups.html#creating-an-application-backup) and [the filename will end in `_gitlab_backup.tar`](backup_gitlab.md#backup-timestamp).
+
+   Since we configured uploading backups to remote cloud storage, the tar file will be uploaded to the remote region and deleted from disk.
+
+1. Note the [timestamp](backup_gitlab.md#backup-timestamp) of the backup file for the next step. For example, if the backup name is `1493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar`, the timestamp is `1493107454_2018_04_25_10.6.4-ce`.
+1. Run the [backup command](backup_gitlab.md#backup-command) again, this time specifying [incremental backup of Git repositories](backup_gitlab.md#incremental-repository-backups), and the timestamp of the source backup file. Using the example timestamp from the previous step, the command is:
+
+   ```shell
+   sudo gitlab-backup create SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1493107454_2018_04_25_10.6.4-ce
+   ```
+
+1. Check that the incremental backup succeeded and uploaded to object storage.
+1. [Configure cron to make daily backups](backup_gitlab.md#configuring-cron-to-make-daily-backups). Edit the crontab for the `root` user:
+
+   ```shell
+   sudo su -
+   crontab -e
+   ```
+
+1. There, add the following line to schedule the backup for everyday at 2 AM:
+
+   ```plaintext
+   0 2 * * * /opt/gitlab/bin/gitlab-backup create SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1493107454_2018_04_25_10.6.4-ce CRON=1
+   ```
+
+### Configure backup of configuration files
+
+If your configuration and secrets are defined outside of your deployment and then deployed into it, then the implementation of the backup strategy depends on your specific setup and requirements. As an example, you can store secrets in [AWS Secret Manager](https://aws.amazon.com/secrets-manager/) with [replication to multiple regions](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create-manage-multi-region-secrets.html) and configure a script to back up secrets automatically.
+
+If your configuration and secrets are only defined inside your deployment:
+
+1. [Storing configuration files](backup_gitlab.md#storing-configuration-files) describes how to extract configuration and secrets files.
+1. These files should be uploaded to a separate, more restrictive, object storage account.
+
+## Restore a backup
+
+Restore a backup of a GitLab instance.
+
+### Prerequisites
+
+Before restoring a backup:
+
+1. Choose a [working destination GitLab instance](restore_gitlab.md#the-destination-gitlab-instance-must-already-be-working).
+1. Ensure the destination GitLab instance is in a region where your AWS backups are stored.
+1. Check that the [destination GitLab instance uses exactly the same version and type (CE or EE) of GitLab](restore_gitlab.md#the-destination-gitlab-instance-must-have-the-exact-same-version)
+   on which the backup data was created. For example, CE 15.1.4.
+1. [Restore backed up secrets to the destination GitLab instance](restore_gitlab.md#gitlab-secrets-must-be-restored).
+1. Ensure that the [destination GitLab instance has the same repository storages configured](restore_gitlab.md#certain-gitlab-configuration-must-match-the-original-backed-up-environment).
+   Additional storages are fine.
+1. If the backed up GitLab instance had any blobs stored in object storage,
+   [ensure that object storage is configured for those kinds of blobs](restore_gitlab.md#certain-gitlab-configuration-must-match-the-original-backed-up-environment).
+1. If the backed up GitLab instance had any blobs stored on the file system, [ensure that NFS is configured](restore_gitlab.md#certain-gitlab-configuration-must-match-the-original-backed-up-environment).
+1. To use new secrets or configuration, and to avoid unexpected configuration changes during restore:
+
+   - Linux package installations on all nodes:
+     1. [Reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) the destination GitLab instance.
+     1. [Restart](../restart_gitlab.md#restart-a-linux-package-installation) the destination GitLab instance.
+
+   - Helm chart (Kubernetes) installations:
+
+     1. On all GitLab Linux package nodes, run:
+
+        ```shell
+        sudo gitlab-ctl reconfigure
+        sudo gitlab-ctl start
+        ```
+
+     1. Make sure you have a running GitLab instance by deploying the charts.
+        Ensure the Toolbox pod is enabled and running by executing the following command:
+
+        ```shell
+        kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
+        ```
+
+     1. The Webservice, Sidekiq and Toolbox pods must be restarted.
+        The safest way to restart those pods is to run:
+
+        ```shell
+        kubectl delete pods -lapp=sidekiq,release=<helm release name>
+        kubectl delete pods -lapp=webservice,release=<helm release name>
+        kubectl delete pods -lapp=toolbox,release=<helm release name>
+        ```
+
+1. Confirm the destination GitLab instance still works. For example:
+
+   - Make requests to the [health check endpoints](../monitoring/health_check.md).
+   - [Run GitLab check Rake tasks](../raketasks/maintenance.md#check-gitlab-configuration).
+
+1. Stop GitLab services which connect to the PostgreSQL database.
+
+   - Linux package installations on all nodes running Puma or Sidekiq, run:
+
+     ```shell
+     sudo gitlab-ctl stop
+     ```
+
+   - Helm chart (Kubernetes) installations:
+
+     1. Note the current number of replicas for database clients for subsequent restart:
+
+        ```shell
+        kubectl get deploy -n <namespace> -lapp=sidekiq,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
+        kubectl get deploy -n <namespace> -lapp=webservice,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
+        kubectl get deploy -n <namespace> -lapp=prometheus,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
+        ```
+
+     1. Stop the clients of the database to prevent locks interfering with the restore process:
+
+        ```shell
+        kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=0
+        kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=0
+        kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=0
+        ```
+
+### Restore object storage data
+
+Each bucket exists as a separate backup within AWS and each backup can be restored to an existing or
+new bucket.
+
+1. To restore buckets, an IAM role with the correct permissions is required:
+
+   - `AWSBackupServiceRolePolicyForBackup`
+   - `AWSBackupServiceRolePolicyForRestores`
+   - `AWSBackupServiceRolePolicyForS3Restore`
+   - `AWSBackupServiceRolePolicyForS3Backup`
+
+1. If existing buckets are being used, they must have
+   [Access Control Lists enabled](https://docs.aws.amazon.com/AmazonS3/latest/userguide/managing-acls.html).
+1. [Restore the S3 buckets using built-in tooling](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-s3.html).
+1. You can move on to [Restore PostgreSQL data](#restore-postgresql-data) while the restore job is
+   running.
+
+### Restore PostgreSQL data
+
+1. [Restore the AWS RDS database using built-in tooling](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-rds.html),
+   which creates a new RDS instance.
+1. Because the new RDS instance has a different endpoint, you must reconfigure the destination GitLab instance
+   to point to the new database:
+
+   - For Linux package installations, follow
+     [Using a non-packaged PostgreSQL database management server](https://docs.gitlab.com/omnibus/settings/database.html#using-a-non-packaged-postgresql-database-management-server).
+
+   - For Helm chart (Kubernetes) installations, follow
+     [Configure the GitLab chart with an external database](https://docs.gitlab.com/charts/advanced/external-db/index.html).
+
+1. Before moving on, wait until the new RDS instance is created and ready to use.
+
+### Restore Git repositories
+
+Select or create a node to restore:
+
+- For Linux package installations, choose a Rails node, which is a node that normally runs Puma or Sidekiq.
+- For Helm chart (Kubernetes) installations, if you don't already have [a Git repository backup node](#configure-backup-of-git-repositories),
+  create one now:
+
+  1. Spin up a VM with 8 vCPU and 7.2 GB memory.
+     This node is used to back up and restore Git repositories because a Praefect node
+     [cannot be used to back up Git data](https://gitlab.com/gitlab-org/gitlab/-/issues/396343#note_1385950340).
+  1. Configure the node as another **GitLab Rails** node as defined in your
+     [reference architecture](../reference_architectures/index.md).
+     As with other GitLab Rails nodes, this node must have access to your main PostgreSQL database as
+     well as to Gitaly Cluster.
+  1. [Restore backed up secrets to the target GitLab](restore_gitlab.md#gitlab-secrets-must-be-restored).
+
+To restore Git repositories:
+
+1. Ensure the node has enough attached storage to store both the `.tar` file of Git repositories,
+   and its extracted data.
+1. SSH into the GitLab Rails node.
+1. As part of [Restore object storage data](#restore-object-storage-data), you should have restored
+   a bucket containing the GitLab backup `.tar` file of Git repositories.
+1. Download the backup `.tar` file from its bucket into the backup directory described in the
+   `gitlab.rb` configuration `gitlab_rails['backup_path']`.
+   The default is `/var/opt/gitlab/backups`.
+   The backup file must be owned by the `git` user.
+
+   ```shell
+   sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backups/
+   sudo chown git:git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar
+   ```
+
+1. Restore the backup, specifying the timestamp of the backup you wish to restore:
+
+   WARNING:
+   The restore command requires
+   [additional parameters](backup_gitlab.md#back-up-and-restore-for-installations-using-pgbouncer)
+   when your installation is using PgBouncer, for either performance reasons or when using it with a
+   Patroni cluster.
+
+   ```shell
+   # This command will overwrite the contents of your GitLab database!
+   # NOTE: "_gitlab_backup.tar" is omitted from the name
+   sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce
+   ```
+
+   If there's a GitLab version mismatch between your backup tar file and the installed version of
+   GitLab, the restore command aborts with an error message.
+   Install the [correct GitLab version](https://packages.gitlab.com/gitlab/), and then try again.
+
+1. Restart and [check](../raketasks/maintenance.md#check-gitlab-configuration) GitLab:
+
+   - Linux package installations:
+
+     1. In all Puma or Sidekiq nodes, run:
+
+        ```shell
+        sudo gitlab-ctl restart
+        ```
+
+     1. In one Puma or Sidekiq node, run:
+
+        ```shell
+        sudo gitlab-rake gitlab:check SANITIZE=true
+        ```
+
+   - Helm chart (Kubernetes) installations:
+
+     1. Start the stopped deployments, using the number of replicas noted in [Prerequisites](#prerequisites):
+
+        ```shell
+        kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<original value>
+        kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<original value>
+        kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<original value>
+        ```
+
+     1. In the Toolbox pod, run:
+
+        ```shell
+        sudo gitlab-rake gitlab:check SANITIZE=true
+        ```
+
+1. Check that
+   [database values can be decrypted](../raketasks/check.md#verify-database-values-can-be-decrypted-using-the-current-secrets)
+   especially if `/etc/gitlab/gitlab-secrets.json` was restored, or if a different server is the
+   target for the restore:
+
+   - For Linux package installations, in a Puma or Sidekiq node, run:
+
+     ```shell
+     sudo gitlab-rake gitlab:doctor:secrets
+     ```
+
+   - For Helm chart (Kubernetes) installations, in the Toolbox pod, run:
+
+     ```shell
+     sudo gitlab-rake gitlab:doctor:secrets
+     ```
+
+1. For added assurance, you can perform
+   [an integrity check on the uploaded files](../raketasks/check.md#uploaded-files-integrity):
+
+   - For Linux package installations, in a Puma or Sidekiq node, run:
+
+     ```shell
+     sudo gitlab-rake gitlab:artifacts:check
+     sudo gitlab-rake gitlab:lfs:check
+     sudo gitlab-rake gitlab:uploads:check
+     ```
+
+   - For Helm chart (Kubernetes) installations, because these commands can take a long time because they iterate over all rows, run the following commands the GitLab Rails node,
+     rather than a Toolbox pod:
+
+     ```shell
+     sudo gitlab-rake gitlab:artifacts:check
+     sudo gitlab-rake gitlab:lfs:check
+     sudo gitlab-rake gitlab:uploads:check
+     ```
+
+   If missing or corrupted files are found, it does not always mean the back up and restore process failed.
+   For example, the files might be missing or corrupted on the source GitLab instance. You might need to cross-reference prior backups.
+   If you are migrating GitLab to a new environment, you can run the same checks on the source GitLab instance to determine whether
+   the integrity check result is preexisting or related to the backup and restore process.
+
+The restoration should be complete.
diff --git a/doc/administration/backup_restore/index.md b/doc/administration/backup_restore/index.md
index 72a0176adc1..824fa56f443 100644
--- a/doc/administration/backup_restore/index.md
+++ b/doc/administration/backup_restore/index.md
@@ -60,7 +60,7 @@ To prepare the new server:
    1. Install GitLab.
    1. Configure by copying `/etc/gitlab` files from the old server to the new server, and update as necessary.
       Read the
-      [Omnibus configuration backup and restore instructions](https://docs.gitlab.com/omnibus/settings/backups.html) for more detail.
+      [Linux package installation backup and restore instructions](https://docs.gitlab.com/omnibus/settings/backups.html) for more detail.
    1. If applicable, disable [incoming email](../incoming_email.md).
    1. Block new CI/CD jobs from starting upon initial startup after the backup and restore.
       Edit `/etc/gitlab/gitlab.rb` and set the following:
diff --git a/doc/administration/backup_restore/restore_gitlab.md b/doc/administration/backup_restore/restore_gitlab.md
index 2cc0c68c66b..784a8708de6 100644
--- a/doc/administration/backup_restore/restore_gitlab.md
+++ b/doc/administration/backup_restore/restore_gitlab.md
@@ -13,18 +13,10 @@ The [restore prerequisites section](#restore-prerequisites) includes crucial
 information. Be sure to read and test the complete restore process at least
 once before attempting to perform it in a production environment.
 
-NOTE:
-You can only restore a backup to **exactly the same version and type (CE/EE)**
-of GitLab on which it was created (for example CE 15.1.4).
-
-If your backup is a different version than the current installation, you must
-[downgrade](../../update/package/downgrade.md) or [upgrade](../../update/package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) your GitLab installation
-before restoring the backup.
-
-Each backup archive contains a full self-contained backup, including those created through the [incremental repository backup procedure](backup_gitlab.md#incremental-repository-backups). To restore an incremental repository backup, use the same instructions as restoring any other regular backup archive.
-
 ## Restore prerequisites
 
+### The destination GitLab instance must already be working
+
 You need to have a working GitLab installation before you can perform a
 restore. This is because the system user performing the restore actions (`git`)
 is usually not allowed to create or delete the SQL database needed to import
@@ -32,6 +24,17 @@ data into (`gitlabhq_production`). All existing data is either erased
 (SQL) or moved to a separate directory (such as repositories and uploads).
 Restoring SQL data skips views owned by PostgreSQL extensions.
 
+### The destination GitLab instance must have the exact same version
+
+You can only restore a backup to **exactly the same version and type (CE or EE)**
+of GitLab on which it was created. For example, CE 15.1.4.
+
+If your backup is a different version than the current installation, you must
+[downgrade](../../update/package/downgrade.md) or [upgrade](../../update/package/index.md#upgrade-to-a-specific-version-using-the-official-repositories) your GitLab installation
+before restoring the backup.
+
+### GitLab secrets must be restored
+
 To restore a backup, **you must also restore the GitLab secrets**.
 These include the database encryption key, [CI/CD variables](../../ci/variables/index.md), and
 variables used for [two-factor authentication](../../user/profile/account/two_factor_authentication.md).
@@ -41,41 +44,37 @@ and GitLab Runners cannot log in.
 
 Restore:
 
-- `/etc/gitlab/gitlab-secrets.json` (Linux package)
+- `/etc/gitlab/gitlab-secrets.json` (Linux package installations)
 - `/home/git/gitlab/.secret` (self-compiled installations)
-- Rails secret (cloud-native GitLab)
-  - [This can be converted to the Linux package format](https://docs.gitlab.com/charts/installation/migration/helm_to_package.html), if required.
+- [Restoring the secrets](https://docs.gitlab.com/charts/backup-restore/restore.html#restoring-the-secrets) (cloud-native GitLab)
+  - [GitLab Helm chart secrets can be converted to the Linux package format](https://docs.gitlab.com/charts/installation/migration/helm_to_package.html), if required.
+
+### Certain GitLab configuration must match the original backed up environment
 
-You may also want to restore your previous `/etc/gitlab/gitlab.rb` (for Omnibus packages)
-or `/home/git/gitlab/config/gitlab.yml` (for installations from source) and
+You likely also want to restore your previous `/etc/gitlab/gitlab.rb` (for Linux package installations)
+or `/home/git/gitlab/config/gitlab.yml` (for self-compiled installations) and
 any TLS keys, certificates (`/etc/gitlab/ssl`, `/etc/gitlab/trusted-certs`), or
 [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079).
 
-Depending on your case, you might want to run the restore command with one or
-more of the following options:
+Certain configuration is coupled to data in PostgreSQL. For example:
 
-- `BACKUP=timestamp_of_backup`: Required if more than one backup exists.
-  Read what the [backup timestamp is about](backup_gitlab.md#backup-timestamp).
-- `force=yes`: Doesn't ask if the `authorized_keys` file should get regenerated,
-  and assumes 'yes' for warning about database tables being removed,
-  enabling the `Write to authorized_keys file` setting, and updating LDAP
-  providers.
+- If the original environment has three repository storages (for example, `default`, `my-storage-1`, and `my-storage-2`), then the target environment must also have at least those storage names defined in configuration.
+- Restoring a backup from an environment using local storage restores to local storage even if the target environment uses object storage. Migrations to object storage must be done before or after restoration.
+
+### Restoring directories that are mount points
 
 If you're restoring into directories that are mount points, you must ensure these directories are
 empty before attempting a restore. Otherwise, GitLab attempts to move these directories before
 restoring the new data, which causes an error.
 
-Read more about [configuring NFS mounts](../nfs.md)
-
-Restoring a backup from an instance using local storage restores to local storage even if the target instance uses object storage.
-Migrations to object storage must be done before or after restoration.
+Read more about [configuring NFS mounts](../nfs.md).
 
-## Restore for Omnibus GitLab installations
+## Restore for Linux package installations
 
 This procedure assumes that:
 
 - You have installed the **exact same version and type (CE/EE)** of GitLab
-  Omnibus with which the backup was created.
+  with which the backup was created.
 - You have run `sudo gitlab-ctl reconfigure` at least once.
 - GitLab is running. If not, start it using `sudo gitlab-ctl start`.
 
@@ -203,7 +202,7 @@ docker restart <name of container>
 docker exec -it <name of container> gitlab-rake gitlab:check SANITIZE=true
 ```
 
-## Restore for installation from source
+## Restore for self-compiled installations
 
 First, ensure your backup tar file is in the backup directory described in the
 `gitlab.yml` configuration:
@@ -282,28 +281,43 @@ project or group from there:
 A feature request to provide direct restore of individual projects or groups
 is being discussed in [issue #17517](https://gitlab.com/gitlab-org/gitlab/-/issues/17517).
 
+## Restoring an incremental repository backup
+
+Each backup archive contains a full self-contained backup, including those created through the [incremental repository backup procedure](backup_gitlab.md#incremental-repository-backups). To restore an incremental repository backup, use the same instructions as restoring any other regular backup archive.
+
 ## Restore options
 
 The command line tool GitLab provides to restore from backup can accept more
 options.
 
-### Disabling prompts during restore
+### Specify backup to restore when there are more than one
 
-During a restore from backup, the restore script may ask for confirmation before
-proceeding. If you wish to disable these prompts, you can set the `GITLAB_ASSUME_YES`
-environment variable to `1`.
+By default, backup files use a naming scheme [starting with a timestamp](backup_gitlab.md#backup-timestamp). When more than one backup exists, you must specify which
+`*_gitlab_backup.tar` file to restore by setting the environment variable `BACKUP=timestamp_of_backup`.
 
-For Omnibus GitLab packages:
+### Disable prompts during restore
 
-```shell
-sudo GITLAB_ASSUME_YES=1 gitlab-backup restore
-```
+During a restore from backup, the restore script prompts for confirmation:
 
-For installations from source:
+- If the **Write to authorized_keys** setting is enabled, before the restore script deletes and rebuilds the `authorized_keys` file.
+- When restoring the database, before the restore script removes all existing tables.
+- After restoring the database, if there were errors in restoring the schema, before continuing because further problems are likely.
 
-```shell
-sudo -u git -H GITLAB_ASSUME_YES=1 bundle exec rake gitlab:backup:restore RAILS_ENV=production
-```
+To disable these prompts, set the `GITLAB_ASSUME_YES` environment variable to `1`.
+
+- Linux package installations:
+
+  ```shell
+  sudo GITLAB_ASSUME_YES=1 gitlab-backup restore
+  ```
+
+- Self-compiled installations:
+
+  ```shell
+  sudo -u git -H GITLAB_ASSUME_YES=1 bundle exec rake gitlab:backup:restore RAILS_ENV=production
+  ```
+
+The `force=yes` environment variable also disables these prompts.
 
 ### Excluding tasks on restore
 
@@ -322,17 +336,19 @@ You can exclude specific tasks on restore by adding the environment variable `SK
 - `repositories` (Git repositories data)
 - `packages` (Packages)
 
-For Omnibus GitLab packages:
+To exclude specific tasks:
 
-```shell
-sudo gitlab-backup restore BACKUP=timestamp_of_backup SKIP=db,uploads
-```
+- Linux package installations:
 
-For installations from source:
+  ```shell
+  sudo gitlab-backup restore BACKUP=timestamp_of_backup SKIP=db,uploads
+  ```
 
-```shell
-sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup SKIP=db,uploads RAILS_ENV=production
-```
+- Self-compiled installations:
+
+  ```shell
+  sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup SKIP=db,uploads RAILS_ENV=production
+  ```
 
 ### Restore specific repository storages
 
@@ -343,17 +359,19 @@ repositories from specific repository storages can be restored separately
 using the `REPOSITORIES_STORAGES` option. The option accepts a comma-separated list of
 storage names.
 
-For example, for Omnibus GitLab installations:
+For example:
 
-```shell
-sudo gitlab-backup restore BACKUP=timestamp_of_backup REPOSITORIES_STORAGES=storage1,storage2
-```
+- Linux package installations:
+
+  ```shell
+  sudo gitlab-backup restore BACKUP=timestamp_of_backup REPOSITORIES_STORAGES=storage1,storage2
+  ```
 
-For example, for installations from source:
+- Self-compiled installations:
 
-```shell
-sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup REPOSITORIES_STORAGES=storage1,storage2
-```
+  ```shell
+  sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup REPOSITORIES_STORAGES=storage1,storage2
+  ```
 
 ### Restore specific repositories
 
@@ -367,13 +385,13 @@ descendent groups are included or skipped, depending on which option you used. T
 For example, to restore all repositories for all projects in **Group A** (`group-a`), the repository for **Project C** in **Group B** (`group-b/project-c`),
 and skip the **Project D** in **Group A** (`group-a/project-d`):
 
-- Omnibus GitLab installations:
+- Linux package installations:
 
   ```shell
   sudo gitlab-backup restore BACKUP=timestamp_of_backup REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
   ```
 
-- Installations from source:
+- Self-compiled installations:
 
   ```shell
   sudo -u git -H bundle exec rake gitlab:backup:restore BACKUP=timestamp_of_backup REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d
@@ -384,24 +402,26 @@ and skip the **Project D** in **Group A** (`group-a/project-d`):
 If an [untarred backup](backup_gitlab.md#skipping-tar-creation) (made with `SKIP=tar`) is found,
 and no backup is chosen with `BACKUP=<timestamp>`, the untarred backup is used.
 
-For example, for Omnibus GitLab installations:
+For example:
 
-```shell
-sudo gitlab-backup restore
-```
+- Linux package installations:
 
-For example, for installations from source:
+  ```shell
+  sudo gitlab-backup restore
+  ```
 
-```shell
-sudo -u git -H bundle exec rake gitlab:backup:restore
-```
+- Self-compiled installations:
+
+  ```shell
+  sudo -u git -H bundle exec rake gitlab:backup:restore
+  ```
 
 ## Troubleshooting
 
 The following are possible problems you might encounter, along with potential
 solutions.
 
-### Restoring database backup using Omnibus packages outputs warnings
+### Restoring database backup using output warnings from a Linux package installation
 
 If you're using backup restore procedures, you may encounter the following
 warning messages:
diff --git a/doc/administration/broadcast_messages.md b/doc/administration/broadcast_messages.md
index 556edbd3e5e..78a4ec798d1 100644
--- a/doc/administration/broadcast_messages.md
+++ b/doc/administration/broadcast_messages.md
@@ -60,6 +60,7 @@ To add a broadcast message:
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. Select **Messages**.
+1. Select **Add new message**.
 1. Add the text for the message to the **Message** field. You can style a message's content using Markdown, emoji, and the `a` and `br` HTML tags.
    The `br` tag inserts a line break. The `a` HTML tag accepts `class` and `style` attributes with the following CSS properties:
     - `color`
diff --git a/doc/administration/cicd.md b/doc/administration/cicd.md
index a3d9a853aaf..4e98423ea60 100644
--- a/doc/administration/cicd.md
+++ b/doc/administration/cicd.md
@@ -14,13 +14,13 @@ GitLab administrators can manage the GitLab CI/CD configuration for their instan
 GitLab CI/CD is enabled by default in all new projects on an instance. You can set
 CI/CD to be disabled by default in new projects by modifying the settings in:
 
-- `gitlab.yml` for source installations.
+- `gitlab.yml` for self-compiled installations.
 - `gitlab.rb` for Linux package installations.
 
 Existing projects that already had CI/CD enabled are unchanged. Also, this setting only changes
 the project default, so project owners [can still enable CI/CD in the project settings](../ci/enable_or_disable_ci.md#enable-cicd-in-a-project).
 
-For installations from source:
+For self-compiled installations:
 
 1. Open `gitlab.yml` with your editor and set `builds` to `false`:
 
diff --git a/doc/administration/clusters/kas.md b/doc/administration/clusters/kas.md
index 583a6401c05..b7247e2251f 100644
--- a/doc/administration/clusters/kas.md
+++ b/doc/administration/clusters/kas.md
@@ -41,7 +41,7 @@ To enable the agent server on a single node:
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 For additional configuration options, see the **Enable GitLab KAS** section of the
-[`gitlab.rb.template`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/files/gitlab-config-template/gitlab.rb.template).
+[`gitlab.rb.template`](https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/be52c36c243a3422ec38b7d45d459682a07e195f/files/gitlab-config-template/gitlab.rb.template#L1951).
 
 ##### Configure KAS to listen on a UNIX socket
 
diff --git a/doc/administration/compliance.md b/doc/administration/compliance.md
index 978e43b2e2c..3f4d781e2a2 100644
--- a/doc/administration/compliance.md
+++ b/doc/administration/compliance.md
@@ -4,7 +4,7 @@ group: Compliance
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Compliance features **(FREE)**
+# Compliance features **(FREE SELF)**
 
 GitLab compliance features ensure your GitLab instance meets common compliance standards, and are available at various pricing tiers. For more information about compliance management, see the compliance
 management [solutions page](https://about.gitlab.com/solutions/compliance/).
@@ -57,7 +57,7 @@ These features can help provide visibility into GitLab and audit what is happeni
 | [Audit events](audit_events.md)                                    | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | To maintain the integrity of your code, audit events give administrators the ability to view any modifications made in the GitLab server in an advanced audit events system, so you can control, analyze, and track every change. |
 | [Audit reports](audit_reports.md)                                  | **{check-circle}** Yes | **{check-circle}** Yes | **{check-circle}** Yes | Create and access reports based on the audit events that have occurred. Use pre-built GitLab reports or the API to build your own.                                                                                                |
 | [Auditor users](auditor_users.md)                                  | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Auditor users are users who are given read-only access to all projects, groups, and other resources on the GitLab instance.                                                                                                       |
-| [Compliance report](../user/compliance/compliance_report/index.md) | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Quickly get visibility into the compliance posture of your organization.                                                                                                                                                          |
+| [Compliance center](../user/compliance/compliance_center/index.md) | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Quickly get visibility into the compliance posture of your organization.                                                                                                                                                          |
 
 ## Other compliance features
 
@@ -69,7 +69,7 @@ These features can also help with compliance requirements:
 | [Enforce ToS acceptance](settings/terms.md)                                                                      | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Enforce your users accepting new terms of service by blocking GitLab traffic.                                                                                          |
 | [External Status Checks](../user/project/merge_requests/status_checks.md)                                                           | **{dotted-circle}** No | **{dotted-circle}** No | **{check-circle}** Yes | Interface with third-party systems you already use during development to ensure you remain compliant.                                                                  |
 | [Generate reports on permission<br/>levels of users](../administration/admin_area.md#user-permission-export)                            | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Generate a report listing all users' access permissions for groups and projects in the instance.                                                                       |
-| [License compliance](../user/compliance/license_compliance/index.md)                                                                | **{dotted-circle}** No | **{dotted-circle}** No | **{check-circle}** Yes | Search dependencies for their licenses. This lets you determine if the licenses of your project's dependencies are compatible with your project's license.             |
+| [License approval policies](../user/compliance/license_approval_policies.md)                                                                | **{dotted-circle}** No | **{dotted-circle}** No | **{check-circle}** Yes | Search dependencies for their licenses. This lets you determine if the licenses of your project's dependencies are compatible with your project's license.             |
 | [Lock project membership to group](../user/group/access_and_permissions.md#prevent-members-from-being-added-to-projects-in-a-group) | **{dotted-circle}** No | **{check-circle}** Yes | **{dotted-circle}** No | Group owners can prevent new members from being added to projects in a group.                                                                                          |
 | [LDAP group sync](auth/ldap/ldap_synchronization.md#group-sync)                                                                     | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Automatically synchronize groups and manage SSH keys, permissions, and authentication, so you can focus on building your product, not configuring your tools.          |
 | [LDAP group sync filters](auth/ldap/ldap_synchronization.md#group-sync)                                                             | **{check-circle}** Yes | **{dotted-circle}** No | **{dotted-circle}** No | Gives more flexibility to synchronize with LDAP based on filters, meaning you can leverage LDAP attributes to map GitLab permissions.                                  |
diff --git a/doc/administration/consul.md b/doc/administration/consul.md
index 5a8946dbcf7..a65b2100237 100644
--- a/doc/administration/consul.md
+++ b/doc/administration/consul.md
@@ -245,6 +245,12 @@ sudo gitlab-ctl start consul
 After this, the node should start back up, and the rest of the server agents rejoin.
 Shortly after that, the client agents should rejoin as well.
 
+If they do not join, you might also need to erase the Consul data on the client:
+
+```shell
+sudo rm -rf /var/opt/gitlab/consul/data
+```
+
 #### Recover a failed node
 
 If you have taken advantage of Consul to store other data and want to restore
diff --git a/doc/administration/dedicated/index.md b/doc/administration/dedicated/index.md
index db30684ab1c..b995c837136 100644
--- a/doc/administration/dedicated/index.md
+++ b/doc/administration/dedicated/index.md
@@ -35,14 +35,41 @@ To request the creation of a new GitLab Dedicated environment for your organizat
 
 ### Maintenance window
 
-When onboarding, you must also specify your preference for the weekly four-hour time slot that GitLab uses to perform maintenance and upgrade operations on the tenant instance.
+When onboarding, you must also specify your preference for the weekly four-hour time slot that GitLab uses to perform routine maintenance and upgrade operations on all tenant instances.
 
-- APAC (outside working hours): Wednesday 1pm-5pm UTC
-- EU (outside working hours): Tuesday 1am-5am UTC
-- AMER (outside working hours): Tuesday 7am-11am UTC
+Available scheduled maintenance windows, performed outside standard working hours:
 
-NOTE:
-Some downtime may be incurred during this window. This downtime is not counting towards [the system SLA](https://about.gitlab.com/handbook/engineering/infrastructure/team/gitlab-dedicated/slas/).
+- APAC: Wednesday 1 AM - 5 AM UTC
+- EU: Tuesday 1 AM - 5 AM UTC
+- AMER Option 1: Tuesday 7 AM - 11 AM UTC
+- AMER Option 2: Sunday 9 PM - Monday 1 AM UTC
+
+Consider the following notes:
+
+- In case of a performance degradation or downtime during the scheduled maintenance window,
+  the impact to [the system SLA](https://about.gitlab.com/handbook/engineering/infrastructure/team/gitlab-dedicated/slas/) is not counted.
+- The weekly scheduled maintenance window can be postponed into another window within the same week.
+  This option needs to be agreed with the assigned Customer Success Manager at least one week in advance.
+- The scheduled weekly maintenance window is different from
+  [emergency maintenance](#emergency-maintenance).
+
+#### Emergency maintenance
+
+In an event of a platform outage, degradation or a security event requiring urgent action,
+emergency maintenance will be carried out per
+[the emergency change processes](https://about.gitlab.com/handbook/engineering/infrastructure/emergency-change-processes/).
+
+The emergency maintenance is initiated urgently when urgent actions need to be executed by GitLab
+on a Dedicated tenant instance.
+Communication with the customer will be provided on best effort basis prior to commencing the
+maintenance, and full communication will follow after the immediate action is carried out.
+
+For example, when a critical security process is initiated to address an S1 vulnerability in GitLab,
+emergency maintenance is carried out to upgrade GitLab to the non-vulnerable version and that
+can occur outside of a scheduled maintenance window.
+Postponing emergency maintenance is not possible, because the same process must be applied to all
+existing Dedicated customers, and the primary concern is to ensure safety and availability of
+Dedicated tenant instances.
 
 ## Configuration changes
 
@@ -59,10 +86,12 @@ If you want your GitLab data to be encrypted at rest, the KMS keys used must be
 
 If you use a key per service, all services must be encrypted at rest. Selective enablement of this feature is not supported.
 
-The keys provided have to reside in the same primary and secondary region specified during [onboarding](#onboarding).
+The keys provided have to reside in the same primary, secondary and backup region specified during [onboarding](#onboarding).
 
 For instructions on how to create and manage KMS keys, visit [Managing keys](https://docs.aws.amazon.com/kms/latest/developerguide/getting-started.html) in the AWS KMS documentation.
 
+GitLab Dedicated supports only AWS managed KMS keys with KMS [as key material](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#key-origin).
+
 To create a KMS key using the AWS Console:
 
 1. In `Configure key`, select:
@@ -156,13 +185,15 @@ The last page asks you to confirm the KMS key policy. It should look similar to
 }
 ```
 
+Make sure the AWS KMS keys are replicated to your desired primary, secondary and backup region specified during [onboarding](#onboarding).
+
 ### Inbound Private Link
 
 [AWS Private Link](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html) allows users and applications in your VPC on AWS to securely connect to the GitLab Dedicated endpoint without network traffic going over the public internet.
 
 To enable the Inbound Private Link:
 
-1. In the body of your [support ticket](#configuration-changes), include the IAM Principal for the AWS user or role in your own AWS Organization that's establishing the VPC endpoint in your AWS account. GitLab Dedicated uses this IAM Principal for access-control. This IAM principal is the only one able to set up an endpoint to the service.
+1. In the body of your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650), include the IAM Principal for the AWS user or role in your own AWS Organization that's establishing the VPC endpoint in your AWS account. GitLab Dedicated uses this IAM Principal for access-control. This IAM principal is the only one able to set up an endpoint to the service.
 1. After your IAM Principal has been allowlisted, GitLab [creates the Endpoint Service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) and communicates the `Service Endpoint Name` on the support ticket. The service name is generated by AWS upon creation of the service endpoint.
    - GitLab handles the domain verification for the Private DNS name, so that DNS resolution of the tenant instance domain name in your VPC resolves to the PrivateLink endpoint.
    - GitLab makes the Endpoint Service available in the Availability Zones you specified during the initial onboarding. If you did not specify any Availability Zones, GitLab randomly selects the Availability Zones IDs.
@@ -179,8 +210,8 @@ Outbound Private Links allow the GitLab Dedicated instance to securely communica
 
 To enable an Outbound Private Link:
 
-1. In your [support ticket](#configuration-changes), GitLab provides you with an IAM role ARN that connects to your endpoint service. You can then add this ARN to the allowlist on your side to restrict connections to your endpoint service.
-1. [Create the Endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) through which your internal service is available to GitLab Dedicated. Provide the associated `Service Endpoint Name` on the [support ticket](#configuration-changes).
+1. In your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650), GitLab provides you with an IAM role ARN that connects to your endpoint service. You can then add this ARN to the allowlist on your side to restrict connections to your endpoint service.
+1. [Create the Endpoint service](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) through which your internal service is available to GitLab Dedicated. Provide the associated `Service Endpoint Name` on the [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
 1. When creating the Endpoint service, you must provide GitLab with a [verified Private DNS Name](https://docs.aws.amazon.com/vpc/latest/privatelink/manage-dns-names.html#verify-domain-ownership) for your service. Optionally, if you would like GitLab Dedicated to reach your service via other aliases, you have the ability to specify a list of Private Hosted Zone (PHZ) entries. With this option, GitLab sets up a Private Hosted Zone with DNS names aliased to the verified Private DNS name. To enable this functionality, you must provide GitLab a list of PHZ entries on your support ticket. After the PHZ is created in the tenant environment, DNS resolution of any of the provided records correctly resolves to the PrivateLink endpoint.
 1. GitLab then configures the tenant instance to create the necessary Endpoint Interfaces based on the service names you provided. Any outbound calls made from the tenant GitLab instance are directed through the PrivateLink into your VPC.
 
@@ -188,7 +219,7 @@ To enable an Outbound Private Link:
 
 In some cases, the GitLab Dedicated instance can't reach an internal service you own because it exposes a certificate that can't be validated using a public Certification Authority (CA). In these cases, custom certificates are required.
 
-To request that GitLab add custom certificates when communicating with your services over PrivateLink, attach the custom public certificate files to your [support ticket](#configuration-changes).
+To request that GitLab add custom certificates when communicating with your services over PrivateLink, attach the custom public certificate files to your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
 
 #### Maximum number of reverse PrivateLink connections
 
@@ -198,22 +229,54 @@ GitLab Dedicated limits the number of reverse PrivateLink connections to 10.
 
 GitLab Dedicated allows you to control which IP addresses can access your instance through an IP allowlist.
 
-Specify a comma separated list of IP addresses that can access your GitLab Dedicated instance in your [support ticket](#configuration-changes). After the configuration has been applied, when an IP not on the allowlist tries to access your instance, the connection is refused.
+Specify a comma separated list of IP addresses that can access your GitLab Dedicated instance in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650). After the configuration has been applied, when an IP not on the allowlist tries to access your instance, the connection is refused.
 
 ### SAML
 
+NOTE:
+GitLab Dedicated supports a limited number of SAML parameters. Parameters not shown in the configuration below are unavailable for GitLab Dedicated tenant instances.
+
 Prerequisites:
 
 - You must configure the identity provider before sending the required data to GitLab.
 
 To activate SAML for your GitLab Dedicated instance:
 
-1. To make the necessary changes, include the desired [SAML configuration block](../../integration/saml.md#configure-saml-support-in-gitlab) for your GitLab application in your [support ticket](#configuration-changes). At a minimum, GitLab needs the following information to enable SAML for your instance:
-   - Assertion consumer service URL
+1. To make the necessary changes, include the desired [SAML configuration block](../../integration/saml.md#configure-saml-support-in-gitlab) for your GitLab application in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650). At a minimum, GitLab needs the following information to enable SAML for your instance:
+   - IDP SSO Target URL
    - Certificate fingerprint or certificate
    - NameID format
    - SSO login button description
 
+   ```json
+   "saml": {
+     "attribute_statements": {
+         //optional
+     },
+     "enabled": true,
+     "groups_attribute": "",
+     "admin_groups": [
+       // optional
+     ],
+     "idp_cert_fingerprint": "43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8", 
+     "idp_sso_target_url": "https://login.example.com/idp",
+     "label": "IDP Name", 
+     "name_identifier_format": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
+     "security": {
+       // optional
+     },
+     "auditor_groups": [
+       // optional
+     ],
+     "external_groups": [
+       // optional
+     ],
+     "required_groups": [
+       // optional
+     ],
+   }
+   ```
+
 1. After GitLab deploys the SAML configuration to your instance, you are notified on your support ticket.
 1. To verify the SAML configuration is successful:
    - Check that the SSO login button description is displayed on your instance's login page.
@@ -222,14 +285,14 @@ To activate SAML for your GitLab Dedicated instance:
 #### Request signing
 
 If [SAML request signing](../../integration/saml.md#sign-saml-authentication-requests-optional) is desired, a certificate must be obtained. This certificate can be self-signed which has the advantage of not having to prove ownership of an arbitrary Common Name (CN) to a public Certificate Authority (CA)).
-
-To enable SAML request signing, indicate on your SAML [support ticket](#configuration-changes) that you want request signing enabled. GitLab works with you on sending the Certificate Signing Request (CSR) for you to sign. Alternatively, the CSR can be signed with a public CA. After the certificate is signed, GitLab adds the certificate and its associated private key to the `security` section of the SAML configuration. Authentication requests from GitLab to your identity provider can then be signed.
+If you choose to enable SAML request signing, the manual steps below will need to be completed before you are able to use SAML, since it requires certificate signing to happen.
+To enable SAML request signing, indicate on your SAML [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) that you want request signing enabled. GitLab works with you on sending the Certificate Signing Request (CSR) for you to sign. Alternatively, the CSR can be signed with a public CA. After the certificate is signed, GitLab adds the certificate and its associated private key to the `security` section of the SAML configuration. Authentication requests from GitLab to your identity provider can then be signed.
 
 #### SAML groups
 
 With SAML groups you can configure GitLab users based on SAML group membership.
 
-To enable SAML groups, add the [required elements](../../integration/saml.md#configure-users-based-on-saml-group-membership) to the SAML configuration block you provide in your [support ticket](#configuration-changes).
+To enable SAML groups, add the [required elements](../../integration/saml.md#configure-users-based-on-saml-group-membership) to the SAML configuration block you provide in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
 
 #### Group sync
 
@@ -237,7 +300,7 @@ With [group sync](../../user/group/saml_sso/group_sync.md), you can sync users a
 
 To enable group sync:
 
-1. Add the [required elements](../../user/group/saml_sso/group_sync.md#configure-saml-group-sync) to the SAML configuration block you provide in your [support ticket](#configuration-changes).
+1. Add the [required elements](../../user/group/saml_sso/group_sync.md#configure-saml-group-sync) to the SAML configuration block you provide in your [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650).
 1. Configure the [Group Links](../../user/group/saml_sso/group_sync.md#configure-saml-group-links).
 
 ### Access to application logs
@@ -246,5 +309,5 @@ GitLab [application logs](../../administration/logs/index.md) are delivered to a
 
 To gain read only access to this bucket:
 
-1. Open a [support ticket](#configuration-changes) with the title "Customer Log Access". In the body of the ticket, include a list of IAM Principal ARNs (users or roles) that are fetching the logs from S3.
+1. Open a [support ticket](https://support.gitlab.com/hc/en-us/requests/new?ticket_form_id=4414917877650) with the title "Customer Log Access". In the body of the ticket, include a list of IAM Principal ARNs (users or roles) that are fetching the logs from S3.
 1. GitLab then informs you of the name of the S3 bucket. Your nominated users/roles can then able to list and get all objects in the S3 bucket.
diff --git a/doc/administration/encrypted_configuration.md b/doc/administration/encrypted_configuration.md
index 808967778fa..b8e04b6fa08 100644
--- a/doc/administration/encrypted_configuration.md
+++ b/doc/administration/encrypted_configuration.md
@@ -13,7 +13,7 @@ GitLab can read settings for certain features from encrypted settings files. The
 
 - [Incoming email `user` and `password`](incoming_email.md#use-encrypted-credentials).
 - [LDAP `bind_dn` and `password`](auth/ldap/index.md#use-encrypted-credentials).
-- [Service Desk email `user` and `password`](../user/project/service_desk.md#use-encrypted-credentials).
+- [Service Desk email `user` and `password`](../user/project/service_desk/index.md#use-encrypted-credentials).
 - [SMTP `user_name` and `password`](raketasks/smtp.md#secrets).
 
 To enable the encrypted configuration settings, a new base key must be generated for
diff --git a/doc/administration/external_users.md b/doc/administration/external_users.md
index f8ca379d10c..9be49fab95f 100644
--- a/doc/administration/external_users.md
+++ b/doc/administration/external_users.md
@@ -34,7 +34,7 @@ always take into account the
 as well as the permission level of the user.
 
 NOTE:
-External users still count towards a license seat.
+External users still count towards a license seat, unless the user has the [Guest role](../subscriptions/self_managed/index.md#free-guest-users) in the Ultimate tier.
 
 An administrator can flag a user as external by either of the following methods:
 
diff --git a/doc/administration/file_hooks.md b/doc/administration/file_hooks.md
index 904da47caff..2748984b51d 100644
--- a/doc/administration/file_hooks.md
+++ b/doc/administration/file_hooks.md
@@ -25,14 +25,13 @@ Instead of writing and supporting your own file hook, you can also make changes
 directly to the GitLab source code and contribute back upstream. In this way, we can
 ensure functionality is preserved across versions and covered by tests.
 
-## Setup
+## Set up a custom file hook
 
-The file hooks must be placed directly into the `file_hooks` directory, subdirectories
-are ignored. There is an
-[`example` directory inside `file_hooks`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/file_hooks/examples)
-where you can find some basic examples.
+File hooks must be in the `file_hooks` directory. Subdirectories are ignored.
+Find examples in the
+[`example` directory under `file_hooks`](https://gitlab.com/gitlab-org/gitlab/-/tree/master/file_hooks/examples).
 
-Follow the steps below to set up a custom hook:
+To set up a custom hook:
 
 1. On the GitLab server, locate the plugin directory. For self-compiled installations, the path is usually
    `/home/git/gitlab/file_hooks/`. For Linux package installations, the path is usually
@@ -51,8 +50,8 @@ Follow the steps below to set up a custom hook:
 1. The data to the file hook is provided as JSON on `STDIN`. It is exactly the
    same as for [system hooks](system_hooks.md).
 
-That's it! Assuming the file hook code is properly implemented, the hook fires
-as appropriate. The file hooks file list is updated for each event, there is no
+Assuming the file hook code is properly implemented, the hook fires
+as appropriate. The file hooks file list is updated for each event. There is no
 need to restart GitLab to apply a new file hook.
 
 If a file hook executes with non-zero exit code or GitLab fails to execute it, a
@@ -61,7 +60,7 @@ message is logged to:
 - `gitlab-rails/file_hook.log` in a Linux package installation.
 - `log/file_hook.log` in a self-compiled installation.
 
-## Creating file hooks
+## File hook example
 
 This example responds only on the event `project_create`, and
 the GitLab instance informs the administrators that a new project has been created.
@@ -88,7 +87,7 @@ Mail.deliver do
 end
 ```
 
-## Validation
+## Validation example
 
 Writing your own file hook can be tricky and it's easier if you can check it
 without altering the system. A Rake task is provided so that you can use it
diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md
index 6d7240a9f92..a67edc815c8 100644
--- a/doc/administration/geo/disaster_recovery/background_verification.md
+++ b/doc/administration/geo/disaster_recovery/background_verification.md
@@ -143,10 +143,7 @@ If the **primary** and **secondary** sites have a checksum verification mismatch
    1. On the left sidebar, select **Overview > Projects**.
    1. Find the project that you want to check the checksum differences and
       select its name.
-   1. On the project administration page get the **Gitaly storage name**,
-      and **Gitaly relative path**.
-
-      ![Project administration page](img/checksum-differences-admin-project-page.png)
+   1. On the project administration page, get the values in the **Storage name** and **Relative path** fields.
 
 1. On a **Gitaly node on the primary** site and a **Gitaly node on the secondary** site, go to the project's repository directory. If using Gitaly Cluster, [check that it is in a healthy state](../../gitaly/troubleshooting.md#check-cluster-health) prior to running these commands.
 
diff --git a/doc/administration/geo/disaster_recovery/img/checksum-differences-admin-project-page.png b/doc/administration/geo/disaster_recovery/img/checksum-differences-admin-project-page.png
deleted file mode 100644
index 0a7b841897b..00000000000
--- a/doc/administration/geo/disaster_recovery/img/checksum-differences-admin-project-page.png
+++ /dev/null
diff --git a/doc/administration/geo/disaster_recovery/index.md b/doc/administration/geo/disaster_recovery/index.md
index 396162fe9ef..151c0f7d9fb 100644
--- a/doc/administration/geo/disaster_recovery/index.md
+++ b/doc/administration/geo/disaster_recovery/index.md
@@ -542,7 +542,7 @@ Geo on the new **primary** site.
 
 To bring a new **secondary** site online, follow the [Geo setup instructions](../index.md#setup-instructions).
 
-### Step 6. Removing the secondary's tracking database
+### Step 6. Removing the former secondary's tracking database
 
 Every **secondary** has a special tracking database that is used to save the status of the synchronization of all the items from the **primary**.
 Because the **secondary** is already promoted, that data in the tracking database is no longer required.
diff --git a/doc/administration/geo/index.md b/doc/administration/geo/index.md
index 0ab24cc4fb8..0293caaf515 100644
--- a/doc/administration/geo/index.md
+++ b/doc/administration/geo/index.md
@@ -126,6 +126,7 @@ The following are required to run Geo:
   - If using different operating system versions between Geo sites,
     [check OS locale data compatibility](replication/troubleshooting.md#check-os-locale-data-compatibility)
     across Geo sites to avoid silent corruption of database indexes.
+- All sites must define the same [repository storages](../repository_storage_paths.md).
 
 Additionally, check the GitLab [minimum requirements](../../install/requirements.md),
 and use the latest version of GitLab for a better experience.
@@ -196,6 +197,7 @@ This list of limitations only reflects the latest version of GitLab. If you are
 - The **primary** site has to be online for OAuth login to happen. Existing sessions and Git are not affected. Support for the **secondary** site to use an OAuth provider independent from the primary is [being planned](https://gitlab.com/gitlab-org/gitlab/-/issues/208465).
 - The installation takes multiple manual steps that together can take about an hour depending on circumstances. Consider using [the GitLab Environment Toolkit](https://gitlab.com/gitlab-org/gitlab-environment-toolkit) to deploy and operate production GitLab instances based on our [Reference Architectures](../reference_architectures/index.md), including automation of common daily tasks. We are planning to [improve Geo's installation even further](https://gitlab.com/groups/gitlab-org/-/epics/1465).
 - Real-time updates of issues/merge requests (for example, via long polling) doesn't work on the **secondary** site.
+- Using Geo secondary sites to accelerate runners is not officially supported. Support for this functionality is planned and can be tracked in [epic 9779](https://gitlab.com/groups/gitlab-org/-/epics/9779). If a replication lag occurs between the primary and secondary site, and the pipeline ref is not available on the secondary site when the job is executed, the job will fail.
 - GitLab Runners cannot register with a **secondary** site. Support for this is [planned for the future](https://gitlab.com/gitlab-org/gitlab/-/issues/3294).
 - [Selective synchronization](replication/configuration.md#selective-synchronization) only limits what repositories and files are replicated. The entire PostgreSQL data is still replicated. Selective synchronization is not built to accommodate compliance / export control use cases.
 - [Pages access control](../../user/project/pages/pages_access_control.md) doesn't work on secondaries. See [GitLab issue #9336](https://gitlab.com/gitlab-org/gitlab/-/issues/9336) for details.
@@ -209,19 +211,6 @@ This list of limitations only reflects the latest version of GitLab. If you are
 
 There is a complete list of all GitLab [data types](replication/datatypes.md) and [existing support for replication and verification](replication/datatypes.md#limitations-on-replicationverification).
 
-### View replication data on the primary site
-
-If you try to view replication data on the primary site, you receive a warning that this may be inconsistent:
-
-> Viewing projects data from a primary site is not possible when using a unified URL. Visit the secondary site directly.
-
-The only way to view projects replication data for a particular secondary site is to visit that secondary site directly. For example, `https://<IP of your secondary site>/admin/geo/replication/projects`.
-An [epic exists](https://gitlab.com/groups/gitlab-org/-/epics/4623) to fix this limitation.
-
-Keep in mind that mentioned URLs don't work when [Admin Mode](../settings/sign_in_restrictions.md#admin-mode) is enabled.
-
-When using Unified URL, visiting the secondary site directly means you must route your requests to the secondary site. Exactly how this might be done depends on your networking configuration. If using DNS to route requests to the appropriate site, then you can, for example, edit your local machine's `/etc/hosts` file to route your requests to the desired secondary site. If the Geo sites are all behind a load balancer, then depending on the load balancer, you might be able to configure all requests from your IP to go to a particular secondary site.
-
 ## Setup instructions
 
 For setup instructions, see [Setting up Geo](setup/index.md).
diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md
index a5d85187812..f63f8edbc72 100644
--- a/doc/administration/geo/replication/configuration.md
+++ b/doc/administration/geo/replication/configuration.md
@@ -190,7 +190,7 @@ keys must be manually replicated to the **secondary** site.
    ```ruby
    ##
    ## The unique identifier for the Geo site. See
-   ## https://docs.gitlab.com/ee/administration/geo_nodes.html#common-settings
+   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
    ##
    gitlab_rails['geo_node_name'] = '<site_name_here>'
    ```
diff --git a/doc/administration/geo/replication/datatypes.md b/doc/administration/geo/replication/datatypes.md
index b25700ccd29..cab3ef581cb 100644
--- a/doc/administration/geo/replication/datatypes.md
+++ b/doc/administration/geo/replication/datatypes.md
@@ -34,7 +34,7 @@ verification methods:
 | Git      | Project designs repository                      | Geo with Gitaly                       | Gitaly Checksum        |
 | Git      | Project Snippets                                | Geo with Gitaly                       | Gitaly Checksum        |
 | Git      | Personal Snippets                               | Geo with Gitaly                       | Gitaly Checksum        |
-| Git      | Group wiki repository                           | Geo with Gitaly                       | _Not implemented_      |
+| Git      | Group wiki repository                           | Geo with Gitaly                       | Gitaly Checksum        |
 | Blobs    | User uploads _(file system)_                    | Geo with API                          | SHA256 checksum        |
 | Blobs    | User uploads _(object storage)_                 | Geo with API/Managed (*2*)            | _Not implemented_      |
 | Blobs    | LFS objects _(file system)_                     | Geo with API                          | SHA256 checksum        |
@@ -189,9 +189,9 @@ successfully, you must replicate their data using some other means.
 |Feature                                                                                                        | Replicated (added in GitLab version)                                    | Verified (added in GitLab version)                                         | GitLab-managed object storage replication (added in GitLab version)                | GitLab-managed object storage verification (added in GitLab version)           | Notes |
 |:--------------------------------------------------------------------------------------------------------------|:------------------------------------------------------------------------|:---------------------------------------------------------------------------|:--------------------------------------------------------------------|:----------------------------------------------------------------|:------|
 |[Application data in PostgreSQL](../../postgresql/index.md)                                                    | **Yes** (10.2)                                                          | **Yes** (10.2)                                                             | N/A                                                                 | N/A                                                             |       |
-|[Project repository](../../../user/project/repository/index.md)                                                        | **Yes** (10.2)                                                          | **Yes** (10.7)                                                             | N/A                                                                 | N/A                                                             |       |
+|[Project repository](../../../user/project/repository/index.md)                                                        | **Yes** (10.2)                                                          | **Yes** (10.7)                                                             | N/A                                                                 | N/A                                                             | Migrated to [self-service framework](../../../development/geo/framework.md) in 16.2. See GitLab issue [#367925](https://gitlab.com/gitlab-org/gitlab/-/issues/367925) for more details.<br /><br />Behind feature flag `geo_project_repository_replication`, enabled by default in (16.3).<br /><br /> All projects, including [archived projects](../../../user/project/settings/index.md#archive-a-project), are replicated. |
 |[Project wiki repository](../../../user/project/wiki/index.md)                                                         | **Yes** (10.2)<sup>2</sup>                                                          | **Yes** (10.7)<sup>2</sup>                                                             | N/A                                                                 | N/A                                                             | Migrated to [self-service framework](../../../development/geo/framework.md) in 15.11. See GitLab issue [#367925](https://gitlab.com/gitlab-org/gitlab/-/issues/367925) for more details.<br /><br />Behind feature flag `geo_project_wiki_repository_replication`, enabled by default in (15.11). |
-|[Group wiki repository](../../../user/project/wiki/group.md)                                                   | [**Yes** (13.10)](https://gitlab.com/gitlab-org/gitlab/-/issues/208147) | No                                                                         | N/A                                                                 | N/A                                                             | Behind feature flag `geo_group_wiki_repository_replication`, enabled by default. |
+|[Group wiki repository](../../../user/project/wiki/group.md)                                                   | [**Yes** (13.10)](https://gitlab.com/gitlab-org/gitlab/-/issues/208147) | [**Yes** (16.3)](https://gitlab.com/gitlab-org/gitlab/-/issues/323897)                                                                         | N/A                                                                 | N/A                                                             | Behind feature flag `geo_group_wiki_repository_replication`, enabled by default. |
 |[Uploads](../../uploads.md)                                                                                    | **Yes** (10.2)                                                          | **Yes** (14.6)                                                             | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | Replication is behind the feature flag `geo_upload_replication`, enabled by default. Verification was behind the feature flag `geo_upload_verification`, removed in 14.8. |
 |[LFS objects](../../lfs/index.md)                                                                              | **Yes** (10.2)                                                          | **Yes** (14.6)                                                             | [**Yes** (15.1)](https://gitlab.com/groups/gitlab-org/-/epics/5551) | [No](object_storage.md#verification-of-files-in-object-storage) | GitLab versions 11.11.x and 12.0.x are affected by [a bug that prevents any new LFS objects from replicating](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).<br /><br />Replication is behind the feature flag `geo_lfs_object_replication`, enabled by default. Verification was behind the feature flag `geo_lfs_object_verification`, removed in 14.7. |
 |[Personal snippets](../../../user/snippets.md)                                                                 | **Yes** (10.2)                                                          | **Yes** (10.2)                                                             | N/A                                                                 | N/A                                                             |       |
diff --git a/doc/administration/geo/replication/multiple_servers.md b/doc/administration/geo/replication/multiple_servers.md
index 29edac1be83..786030736f6 100644
--- a/doc/administration/geo/replication/multiple_servers.md
+++ b/doc/administration/geo/replication/multiple_servers.md
@@ -67,7 +67,7 @@ The following steps enable a GitLab site to serve as the Geo **primary** site.
    ```ruby
    ##
    ## The unique identifier for the Geo site. See
-   ## https://docs.gitlab.com/ee/administration/geo_nodes.html#common-settings
+   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
    ##
    gitlab_rails['geo_node_name'] = '<site_name_here>'
 
@@ -217,7 +217,7 @@ then make the following modifications:
 
    ##
    ## The unique identifier for the Geo site. See
-   ## https://docs.gitlab.com/ee/administration/geo_nodes.html#common-settings
+   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
    ##
    gitlab_rails['geo_node_name'] = '<site_name_here>'
 
@@ -318,7 +318,7 @@ application nodes above, with some changes to run only the `sidekiq` service:
 
    ##
    ## The unique identifier for the Geo site. See
-   ## https://docs.gitlab.com/ee/administration/geo_nodes.html#common-settings
+   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
    ##
    gitlab_rails['geo_node_name'] = '<site_name_here>'
 
diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md
index c63480db389..ed11307f57b 100644
--- a/doc/administration/geo/replication/troubleshooting.md
+++ b/doc/administration/geo/replication/troubleshooting.md
@@ -163,7 +163,7 @@ http://secondary.example.com/
                          Sync Settings: Full
               Database replication lag: 0 seconds
        Last event ID seen from primary: 12345 (about 2 minutes ago)
-     Last event ID processed by cursor: 12345 (about 2 minutes ago)
+               Last event ID processed: 12345 (about 2 minutes ago)
                 Last status report was: 1 minute ago
 ```
 
@@ -1271,7 +1271,7 @@ If you are using the Linux package installation, something might have failed dur
 ### GitLab indicates that more than 100% of repositories were synced
 
 This can be caused by orphaned records in the project registry. You can clear them
-[using a Rake task](../../../administration/raketasks/geo.md#remove-orphaned-project-registries).
+[using the Rake task to remove orphaned project registries](../../../administration/raketasks/geo.md#remove-orphaned-project-registries).
 
 ### Geo Admin Area returns 404 error for a secondary site
 
diff --git a/doc/administration/geo/replication/version_specific_upgrades.md b/doc/administration/geo/replication/version_specific_upgrades.md
index c0215c4551c..7e3160822b9 100644
--- a/doc/administration/geo/replication/version_specific_upgrades.md
+++ b/doc/administration/geo/replication/version_specific_upgrades.md
@@ -104,323 +104,3 @@ If you are running an affected version and need to remove your Primary site, you
 ### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
 
 GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.12
-
-### Secondary sites re-download all LFS files upon upgrade
-
-We found an issue where [secondary sites re-download all LFS files](https://gitlab.com/gitlab-org/gitlab/-/issues/334550) upon upgrade. This bug:
-
-- Only applies to Geo secondary sites that have replicated LFS objects.
-- Is _not_ a data loss risk.
-- Causes churn and wasted bandwidth re-downloading all LFS objects.
-- May impact performance for GitLab installations with a large number of LFS files.
-
-If you don't have many LFS objects or can stand a bit of churn, then it is safe to let the secondary sites re-download LFS objects.
-If you do have many LFS objects, or many Geo secondary sites, or limited bandwidth, or a combination of them all, then we recommend you skip GitLab 13.12.0 through 13.12.6 and upgrade to GitLab 13.12.7 or newer.
-
-#### If you have already upgraded to an affected version, and the re-sync is ongoing
-
-You can manually migrate the legacy sync state to the new state column by running the following command in a [Rails console](../../operations/rails_console.md). It should take under a minute:
-
-```ruby
-Geo::LfsObjectRegistry.where(state: 0, success: true).update_all(state: 2)
-```
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.11
-
-We found an [issue with Git clone/pull through HTTP(s)](https://gitlab.com/gitlab-org/gitlab/-/issues/330787) on Geo secondaries and on any GitLab instance if maintenance mode is enabled. This was caused by a regression in GitLab Workhorse. This is fixed in the [GitLab 13.11.4 patch release](https://about.gitlab.com/releases/2021/05/14/gitlab-13-11-4-released/). To avoid this issue, upgrade to GitLab 13.11.4 or later.
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.10
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.9
-
-### Error during zero-downtime upgrade: `cannot drop column asset_proxy_whitelist`
-
-We've detected an issue [with a column rename](https://gitlab.com/gitlab-org/gitlab/-/issues/324160)
-that prevents upgrades to GitLab 13.9.0, 13.9.1, 13.9.2 and 13.9.3 when following the zero-downtime steps. It is necessary
-to perform the following additional steps for the zero-downtime upgrade:
-
-1. Before running the final `sudo gitlab-rake db:migrate` command on the deploy node,
-   execute the following queries using the PostgreSQL console (or `sudo gitlab-psql`)
-   to drop the problematic triggers:
-
-   ```sql
-   drop trigger trigger_e40a6f1858e6 on application_settings;
-   drop trigger trigger_0d588df444c8 on application_settings;
-   drop trigger trigger_1572cbc9a15f on application_settings;
-   drop trigger trigger_22a39c5c25f3 on application_settings;
-   ```
-
-1. Run the final migrations:
-
-   ```shell
-   sudo gitlab-rake db:migrate
-   ```
-
-1. Hot reload `puma` and `sidekiq` services:
-
-   ```shell
-   sudo gitlab-ctl hup puma
-   sudo gitlab-ctl restart sidekiq
-   ```
-
-If you have already run the final `sudo gitlab-rake db:migrate` command on the deploy node and have
-encountered the [column rename issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160), you might
-see the following error:
-
-```shell
--- remove_column(:application_settings, :asset_proxy_whitelist)
-rake aborted!
-StandardError: An error has occurred, all later migrations canceled:
-PG::DependentObjectsStillExist: ERROR: cannot drop column asset_proxy_whitelist of table application_settings because other objects depend on it
-DETAIL: trigger trigger_0d588df444c8 on table application_settings depends on column asset_proxy_whitelist of table application_settings
-```
-
-To work around this bug, follow the previous steps to complete the upgrade.
-More details are available [in this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/324160).
-
-### Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode
-
-GitLab 13.9 through GitLab 14.3 are affected by a bug in which enabling [GitLab Maintenance Mode](../../maintenance_mode/index.md) causes Geo secondary site statuses to appear to stop upgrading and become unhealthy. For more information, see [Troubleshooting - Geo Admin Area shows 'Unhealthy' after enabling Maintenance Mode](troubleshooting.md#geo-admin-area-shows-unhealthy-after-enabling-maintenance-mode).
-
-## Upgrading to GitLab 13.7
-
-- We've detected an issue with the `FetchRemove` call used by Geo secondaries.
-  This causes performance issues as we execute reference transaction hooks for
-  each upgraded reference. Delay any upgrade attempts until this is in the
-  [13.7.5 patch release.](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/3002).
-  More details are available [in this issue](https://gitlab.com/gitlab-org/git/-/issues/79).
-- A new secret is generated in `/etc/gitlab/gitlab-secrets.json`.
-  In an HA GitLab or GitLab Geo environment, secrets need to be the same on all nodes.
-  Ensure this new secret is also accounted for if you are manually syncing the file across
-  nodes, or manually specifying secrets in `/etc/gitlab/gitlab.rb`.
-
-## Upgrading to GitLab 13.5
-
-GitLab 13.5 has a [regression that prevents viewing a list of container repositories and registries](https://gitlab.com/gitlab-org/gitlab/-/issues/285475)
-on Geo secondaries. This issue is fixed in GitLab 13.6.1 and later.
-
-## Upgrading to GitLab 13.3
-
-In GitLab 13.3, Geo removed the PostgreSQL [Foreign Data Wrapper](https://www.postgresql.org/docs/11/postgres-fdw.html)
-dependency for the tracking database.
-
-The FDW server, user, and the extension is removed during the upgrade
-process on each secondary site. The GitLab settings related to the FDW in the
-`/etc/gitlab/gitlab.rb`  have been deprecated and can be safely removed.
-
-There are some scenarios like using an external PostgreSQL instance for the
-tracking database where the FDW settings must be removed manually. Enter the
-PostgreSQL console of that instance and remove them:
-
-```shell
-DROP SERVER gitlab_secondary CASCADE;
-DROP EXTENSION IF EXISTS postgres_fdw;
-```
-
-WARNING:
-In GitLab 13.3, promoting a secondary site to a primary while the secondary is
-paused fails. Do not pause replication before promoting a secondary. If the
-site is paused, be sure to resume before promoting. To avoid this issue,
-upgrade to GitLab 13.4 or later.
-
-WARNING:
-Promoting the database during a failover can fail on XFS and filesystems ordering files lexically,
-when using `--force` or `--skip-preflight-checks`, due to [an issue](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/6076) fixed in 13.5.
-The [troubleshooting steps](troubleshooting.md#errors-when-using---skip-preflight-checks-or---force)
-contain a workaround if you run into errors during the failover.
-
-## Upgrading to GitLab 13.2
-
-In GitLab 13.2, promoting a secondary site to a primary while the secondary is
-paused fails. Do not pause replication before promoting a secondary. If the
-site is paused, be sure to resume before promoting. To avoid this issue,
-upgrade to GitLab 13.4 or later.
-
-## Upgrading to GitLab 13.0
-
-Upgrading to GitLab 13.0 requires GitLab 12.10 to already be using PostgreSQL
-version 11. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.10
-
-GitLab 12.10 doesn't attempt to upgrade the embedded PostgreSQL server when
-using Geo, because the PostgreSQL upgrade requires downtime for secondaries
-while reinitializing streaming replication. It must be upgraded manually. For
-the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.9
-
-WARNING:
-GitLab 12.9.0 through GitLab 12.9.3 are affected by
-[a bug that stops repository verification](https://gitlab.com/gitlab-org/gitlab/-/issues/213523).
-The issue is fixed in GitLab 12.9.4. Upgrade to GitLab 12.9.4 or later.
-
-By default, GitLab 12.9 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.8
-
-By default, GitLab 12.8 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.12, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.7
-
-WARNING:
-Only upgrade to GitLab 12.7.5 or later. Do not upgrade to versions 12.7.0
-through 12.7.4 because there is [an initialization order bug](https://gitlab.com/gitlab-org/gitlab/-/issues/199672) that causes Geo secondaries to set the incorrect database connection pool size.
-[The fix](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24021) was
-shipped in 12.7.5.
-
-By default, GitLab 12.7 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.6
-
-By default, GitLab 12.6 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.5
-
-By default, GitLab 12.5 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.4
-
-By default, GitLab 12.4 attempts to upgrade the embedded PostgreSQL server
-version from 9.6 to 10.9, which requires downtime on secondaries while
-reinitializing streaming replication. For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-You can temporarily disable this behavior by running the following before
-upgrading:
-
-```shell
-sudo touch /etc/gitlab/disable-postgresql-upgrade
-```
-
-## Upgrading to GitLab 12.3
-
-WARNING:
-If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
-GitLab 12.4 or later. By default, GitLab 12.3 attempts to upgrade the embedded
-PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
-requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.2
-
-WARNING:
-If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
-GitLab 12.4 or later. By default, GitLab 12.2 attempts to upgrade the embedded
-PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
-requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-GitLab 12.2 includes the following minor PostgreSQL upgrades:
-
-- To version `9.6.14`, if you run PostgreSQL 9.6.
-- To version `10.9`, if you run PostgreSQL 10.
-
-This upgrade occurs even if major PostgreSQL upgrades are disabled.
-
-Before [refreshing Foreign Data Wrapper during a Geo upgrade](../../../update/zero_downtime.md#step-4-run-post-deployment-migrations-and-checks),
-restart the Geo tracking database:
-
-```shell
-sudo gitlab-ctl restart geo-postgresql
-```
-
-The restart avoids a version mismatch when PostgreSQL tries to load the FDW
-extension.
-
-## Upgrading to GitLab 12.1
-
-WARNING:
-If the existing PostgreSQL server version is 9.6.x, we recommend upgrading to
-GitLab 12.4 or later. By default, GitLab 12.1 attempts to upgrade the embedded
-PostgreSQL server version from 9.6 to 10.9. In certain circumstances, it can
-fail. For more information, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-Additionally, if the PostgreSQL upgrade doesn't fail, a successful upgrade
-requires downtime for secondaries while reinitializing streaming replication.
-For the recommended procedure, see how
-[to upgrade a Geo instance](https://docs.gitlab.com/omnibus/settings/database.html#upgrading-a-geo-instance).
-
-## Upgrading to GitLab 12.0
-
-WARNING:
-This version is affected by a
-[bug that results in new LFS objects not being replicated to Geo secondary sites](https://gitlab.com/gitlab-org/gitlab/-/issues/32696).
-The issue is fixed in GitLab 12.1. Be sure to upgrade to GitLab 12.1 or later.
diff --git a/doc/administration/geo/secondary_proxy/index.md b/doc/administration/geo/secondary_proxy/index.md
index 2ab96a3d33d..11e5cb1b7b8 100644
--- a/doc/administration/geo/secondary_proxy/index.md
+++ b/doc/administration/geo/secondary_proxy/index.md
@@ -122,14 +122,7 @@ for details.
   To use TLS certificates with Let's Encrypt, you can manually point the domain to one of the Geo sites, generate
   the certificate, then copy it to all other sites.
 
-- [Viewing projects data from a primary site is not possible when using a unified URL](../index.md#view-replication-data-on-the-primary-site).
-
-- When secondary proxying is used together with separate URLs, registering [GitLab runners](https://docs.gitlab.com/runner/) to clone from
-secondary sites is not supported. The runner registration succeeds, but the clone URL defaults to the primary site. The runner
-[clone URL](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runners-section) is configured per GitLab deployment
-and cannot be configured per Geo site. Therefore, all runners clone from the primary site (or configured clone URL) irrespective of
-which Geo site they register on. For information about GitLab CI using a specific Geo secondary to clone from, see issue
-[3294](https://gitlab.com/gitlab-org/gitlab/-/issues/3294#note_1009488466).
+- Using Geo secondary sites to accelerate runners is not officially supported. Support for this functionality is planned and can be tracked in [epic 9779](https://gitlab.com/groups/gitlab-org/-/epics/9779). If a replication lag occurs between the primary and secondary site, and the pipeline ref is not available on the secondary site when the job is executed, the job will fail.
 
 - When secondary proxying is used together with separate URLs,
   [signing in the secondary site using SAML](../replication/single_sign_on.md#saml-with-separate-url-with-proxying-enabled)
diff --git a/doc/administration/geo/setup/database.md b/doc/administration/geo/setup/database.md
index be6e327732d..d94c44a76f2 100644
--- a/doc/administration/geo/setup/database.md
+++ b/doc/administration/geo/setup/database.md
@@ -64,7 +64,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 
 #### Step 1. Configure the **primary** site
 
-1. SSH into your GitLab **primary** site and login as root:
+1. SSH into your GitLab **primary** site and log in as root:
 
    ```shell
    sudo -i
@@ -75,7 +75,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
    ```ruby
    ##
    ## The unique identifier for the Geo site. See
-   ## https://docs.gitlab.com/ee/administration/geo_nodes.html#common-settings
+   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
    ##
    gitlab_rails['geo_node_name'] = '<site_name_here>'
    ```
@@ -320,7 +320,7 @@ There is an [issue where support is being discussed](https://gitlab.com/gitlab-o
 
 #### Step 2. Configure the **secondary** server
 
-1. SSH into your GitLab **secondary** site and login as root:
+1. SSH into your GitLab **secondary** site and log in as root:
 
    ```shell
    sudo -i
@@ -462,7 +462,7 @@ WARNING:
 Make sure to run this on the **secondary** site as it removes all PostgreSQL's
 data before running `pg_basebackup`.
 
-1. SSH into your GitLab **secondary** site and login as root:
+1. SSH into your GitLab **secondary** site and log in as root:
 
    ```shell
    sudo -i
@@ -680,7 +680,7 @@ and ensure password authentication is used.
 On each node running a Patroni instance on the primary site **starting on the Patroni
 Leader instance**:
 
-1. SSH into your Patroni instance and login as root:
+1. SSH into your Patroni instance and log in as root:
 
    ```shell
    sudo -i
@@ -791,7 +791,7 @@ see [the relevant documentation](../../postgresql/replication_and_failover.md).
 
 On each node running a PgBouncer instance on the **secondary** site:
 
-1. SSH into your PgBouncer node and login as root:
+1. SSH into your PgBouncer node and log in as root:
 
    ```shell
    sudo -i
@@ -850,7 +850,7 @@ and then you can switch over to another replica if you need to.
 
 For each node running a Patroni instance on the secondary site:
 
-1. SSH into your Patroni node and login as root:
+1. SSH into your Patroni node and log in as root:
 
    ```shell
    sudo -i
@@ -955,7 +955,7 @@ and other database best practices.
 
 On each node running the PgBouncer service for the PostgreSQL tracking database:
 
-1. SSH into your PgBouncer node and login as root:
+1. SSH into your PgBouncer node and log in as root:
 
    ```shell
    sudo -i
@@ -1017,7 +1017,7 @@ On each node running the PgBouncer service for the PostgreSQL tracking database:
 
 On each node running a Patroni instance on the secondary site for the PostgreSQL tracking database:
 
-1. SSH into your Patroni node and login as root:
+1. SSH into your Patroni node and log in as root:
 
    ```shell
    sudo -i
@@ -1083,7 +1083,7 @@ On each node running a Patroni instance on the secondary site for the PostgreSQL
 
 For each node running the `gitlab-rails`, `sidekiq`, and `geo-logcursor` services:
 
-1. SSH into your node and login as root:
+1. SSH into your node and log in as root:
 
    ```shell
    sudo -i
diff --git a/doc/administration/geo/setup/external_database.md b/doc/administration/geo/setup/external_database.md
index 50383546da3..061ae2d4eb8 100644
--- a/doc/administration/geo/setup/external_database.md
+++ b/doc/administration/geo/setup/external_database.md
@@ -39,7 +39,7 @@ developed and tested. We aim to be compatible with most external
 
    ##
    ## The unique identifier for the Geo site. See
-   ## https://docs.gitlab.com/ee/administration/geo_nodes.html#common-settings
+   ## https://docs.gitlab.com/ee/administration/geo_sites.html#common-settings
    ##
    gitlab_rails['geo_node_name'] = '<site_name_here>'
    ```
@@ -189,6 +189,8 @@ potential replication issues. The Linux package automatically configures a track
 when `roles ['geo_secondary_role']` is set.
 If you want to run this database external to your Linux package installation, use the following instructions.
 
+#### Cloud-managed database services
+
 If you are using a cloud-managed service for the tracking database, you may need
 to grant additional roles to your tracking database user (by default, this is
 `gitlab_geo`):
@@ -200,8 +202,6 @@ to grant additional roles to your tracking database user (by default, this is
 This is for the installation of extensions during installation and upgrades. As an alternative,
 [ensure the extensions are installed manually, and read about the problems that may arise during future GitLab upgrades](../../../install/postgresql_extensions.md).
 
-To setup an external tracking database, follow the instructions below:
-
 NOTE:
 If you want to use Amazon RDS as a tracking database, make sure it has access to
 the secondary database. Unfortunately, just assigning the same security group is not enough as
@@ -209,9 +209,14 @@ outbound rules do not apply to RDS PostgreSQL databases. Therefore, you need to
 rule to the read-replica's security group allowing any TCP traffic from
 the tracking database on port 5432.
 
+#### Create the tracking database
+
+Create and configure the tracking database in your PostgreSQL instance:
+
 1. Set up PostgreSQL according to the
    [database requirements document](../../../install/requirements.md#database).
-1. Set up a `gitlab_geo` user with a password of your choice, create the `gitlabhq_geo_production` database, and make the user an owner of the database. You can see an example of this setup in the [installation from source documentation](../../../install/installation.md#7-database).
+1. Set up a `gitlab_geo` user with a password of your choice, create the `gitlabhq_geo_production` database, and make the user an owner of the database.
+   You can see an example of this setup in the [self-compiled installation documentation](../../../install/installation.md#7-database).
 1. If you are **not** using a cloud-managed PostgreSQL database, ensure that your secondary
    site can communicate with your tracking database by manually changing the
    `pg_hba.conf` that is associated with your tracking database.
@@ -226,6 +231,10 @@ the tracking database on port 5432.
    host    all         all               <trusted secondary IP>/32     md5
    ```
 
+#### Configure GitLab
+
+Configure GitLab to use this database. These steps are for Linux package and Docker deployments.
+
 1. SSH into a GitLab **secondary** server and login as root:
 
    ```shell
@@ -246,14 +255,19 @@ the tracking database on port 5432.
 
 1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation)
 
-1. The reconfigure should automatically create the database. If needed, you can perform this task manually. This task (whether run by itself or during reconfigure) requires the database user to be a superuser.
+#### Set up the database schema
+
+The reconfigure in the [steps above](#configure-gitlab) for Linux package and Docker deployments should handle these steps automatically.
+
+1. This task creates the database schema. It requires the database user to be a superuser.
 
    ```shell
-   gitlab-rake db:create:geo
+   sudo gitlab-rake db:create:geo
    ```
 
-1. The reconfigure should automatically migrate the database. You can migrate the database manually if needed, for example if `geo_secondary['auto_migrate'] = false`:
+1. Applying Rails database migrations (schema and data updates) is also performed by reconfigure. If `geo_secondary['auto_migrate'] = false` is set, or
+   the schema was created manually, this step will be required:
 
    ```shell
-   gitlab-rake db:migrate:geo
+   sudo gitlab-rake db:migrate:geo
    ```
diff --git a/doc/administration/geo/setup/index.md b/doc/administration/geo/setup/index.md
index 8ac64a963bb..cb318783128 100644
--- a/doc/administration/geo/setup/index.md
+++ b/doc/administration/geo/setup/index.md
@@ -34,17 +34,28 @@ If both Geo sites are based on the [1K reference architecture](../../reference_a
    - [Using Linux package PostgreSQL instances](database.md) .
    - [Using external PostgreSQL instances](external_database.md)
 1. [Configure GitLab](../replication/configuration.md) to set the **primary** and **secondary** sites.
-1. Recommended: [Configure unified URLs](../secondary_proxy/index.md#set-up-a-unified-url-for-geo-sites) to use a single, unified URL for all Geo sites.
-1. Optional: [Configure Object storage replication](../replication/object_storage.md)
-1. Optional: [Configure a secondary LDAP server](../../auth/ldap/index.md) for the **secondary** sites. See [notes on LDAP](../index.md#ldap).
-1. Optional: [Configure Container Registry for the secondary site](../replication/container_registry.md).
 1. Follow the [Using a Geo Site](../replication/usage.md) guide.
 
+Depending on your GitLab deployment, [additional configuration](#additional-configuration) for LDAP, object storage, and the Container Registry might be required.
+
 ### Multi-node Geo sites
 
 If one or more of your sites is using the [2K reference architecture](../../reference_architectures/2k_users.md) or larger, see
 [Configure Geo for multiple nodes](../replication/multiple_servers.md).
 
+Depending on your GitLab deployment, [additional configuration](#additional-configuration) for LDAP, object storage, and the Container Registry might be required.
+
+### Additional configuration
+
+Depending on how you use GitLab, the following configuration might be required:
+
+- If the **primary** site uses object storage, [configure object storage replication](../replication/object_storage.md) for the **secondary** sites.
+- If you use LDAP, [configure a secondary LDAP server](../../auth/ldap/index.md) for the **secondary** sites.
+  For more information, see [LDAP with Geo](../replication/single_sign_on.md#ldap).
+- If you use the Container Registry, [configure the Container Registry for replication](../replication/container_registry.md) on the **primary** and **secondary** sites.
+
+You should [configure unified URLs](../secondary_proxy/index.md#set-up-a-unified-url-for-geo-sites) to use a single, unified URL for all Geo sites.
+
 ## Using GitLab Charts
 
 [Configure the GitLab chart with GitLab Geo](https://docs.gitlab.com/charts/advanced/geo/).
diff --git a/doc/administration/geo/setup/two_single_node_sites.md b/doc/administration/geo/setup/two_single_node_sites.md
new file mode 100644
index 00000000000..00002d501b2
--- /dev/null
+++ b/doc/administration/geo/setup/two_single_node_sites.md
@@ -0,0 +1,638 @@
+---
+stage: Systems
+group: Geo
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Set up Geo for two single-node sites **(PREMIUM SELF)**
+
+The following guide provides concise instructions on how to deploy GitLab Geo for a two single-node site installation using two Linux package instances.
+
+Prerequisites:
+
+- You have at least two independently working GitLab sites.
+  To create the sites, see the [GitLab reference architectures documentation](../../reference_architectures/index.md).
+  - One GitLab site serves as the **Geo primary site**. You can use different reference architecture sizes for each Geo site. If you already have a working GitLab instance, you can use it as the primary site.
+  - The second GitLab site serves as the **Geo secondary site**. Geo supports multiple secondary sites.
+- The Geo primary site has at least a [GitLab Premium](https://about.gitlab.com/pricing/) license.
+  You need only one license for all sites.
+- Confirm all sites meet the [requirements for running Geo](../index.md#requirements-for-running-geo).
+
+## Set up Geo for Linux package (Omnibus)
+
+Prerequisites:
+
+- You use PostgreSQL 12 or later,
+  which includes the [`pg_basebackup` tool](https://www.postgresql.org/docs/12/app-pgbasebackup.html).
+
+### Configure the primary site
+
+1. SSH into your GitLab primary site and sign in as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Add a unique Geo site name to `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+   ##
+   ## The unique identifier for the Geo site. See
+   ## https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html#common-settings
+   ##
+   gitlab_rails['geo_node_name'] = '<site_name_here>'
+   ```
+
+1. To apply the change, reconfigure the primary site:
+
+   ```shell
+   gitlab-ctl reconfigure
+   ```
+
+1. Define the site as your primary Geo site:
+
+   ```shell
+   gitlab-ctl set-geo-primary-node
+   ```
+
+   This command uses the `external_url` defined in `/etc/gitlab/gitlab.rb`.
+
+1. Create a password for the `gitlab` database user.
+
+   1. Generate a MD5 hash of the desired password:
+
+      ```shell
+      gitlab-ctl pg-password-md5 gitlab
+      # Enter password: <your_password_here>
+      # Confirm password: <your_password_here>
+      # fca0b89a972d69f00eb3ec98a5838484
+      ```
+
+   1. Edit `/etc/gitlab/gitlab.rb`:
+
+      ```ruby
+      # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab`
+      postgresql['sql_user_password'] = '<md5_hash_of_your_password>'
+
+      # Every node that runs Puma or Sidekiq needs to have the database
+      # password specified as below. If you have a high-availability setup, this
+      # must be present in all application nodes.
+      gitlab_rails['db_password'] = '<your_password_here>'
+      ```
+
+1. Define a password for the database [replication user](https://wiki.postgresql.org/wiki/Streaming_Replication).
+   Use the username defined in `/etc/gitlab/gitlab.rb` under the `postgresql['sql_replication_user']`
+   setting. The default value is `gitlab_replicator`.
+
+   1. Generate an MD5 hash of the desired password:
+
+      ```shell
+      gitlab-ctl pg-password-md5 gitlab_replicator
+
+      # Enter password: <your_password_here>
+      # Confirm password: <your_password_here>
+      # 950233c0dfc2f39c64cf30457c3b7f1e
+      ```
+
+   1. Edit `/etc/gitlab/gitlab.rb`:
+
+      ```ruby
+      # Fill with the hash generated by `gitlab-ctl pg-password-md5 gitlab_replicator`
+      postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
+      ```
+
+   1. Optional. If you use an external database not managed by the Linux package, you must
+      create the `gitlab_replicator` user and define a password for that user manually:
+
+      ```sql
+      --- Create a new user 'replicator'
+      CREATE USER gitlab_replicator;
+
+      --- Set/change a password and grants replication privilege
+      ALTER USER gitlab_replicator WITH REPLICATION ENCRYPTED PASSWORD '<replication_password>';
+      ```
+
+1. In `/etc/gitlab/gitlab.rb`, set the role to [`geo_primary_role`](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles):
+
+   ```ruby
+   ## Geo Primary role
+   roles(['geo_primary_role'])
+   ```
+
+1. Configure PostgreSQL to listen on network interfaces:
+
+   1. To look up the address of a Geo site, SSH into the Geo site and execute:
+
+      ```shell
+      ##
+      ## Private address
+      ##
+      ip route get 255.255.255.255 | awk '{print "Private address:", $NF; exit}'
+
+      ##
+      ## Public address
+      ##
+      echo "External address: $(curl --silent "ipinfo.io/ip")"
+      ```
+
+      In most cases, the following addresses are used to configure GitLab
+      Geo:
+
+      | Configuration                           | Address                                                               |
+      |:----------------------------------------|:----------------------------------------------------------------------|
+      | `postgresql['listen_address']`          | Primary site public or VPC private address.                     |
+      | `postgresql['md5_auth_cidr_addresses']` | Primary and secondary site public or VPC private addresses. |
+
+      If you use Google Cloud Platform, SoftLayer, or any other vendor that
+      provides a virtual private cloud (VPC), you can use the primary and secondary site
+      private addresses (which correspond to "internal address" for Google Cloud Platform) for
+      `postgresql['md5_auth_cidr_addresses']` and `postgresql['listen_address']`.
+
+      NOTE:
+      If you need to use `0.0.0.0` or `*` as the `listen_address`, you also must add
+      `127.0.0.1/32` to the `postgresql['md5_auth_cidr_addresses']` setting, to allow
+      Rails to connect through `127.0.0.1`. For more information, see [issue 5258](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5258).
+
+      Depending on your network configuration, the suggested addresses might
+      be incorrect. If your primary and secondary sites connect over a local
+      area network, or a virtual network connecting availability zones like
+      [Amazon's VPC](https://aws.amazon.com/vpc/) or [Google's VPC](https://cloud.google.com/vpc/),
+      you should use the secondary site private address for `postgresql['md5_auth_cidr_addresses']`.
+
+   1. Add the following lines to `/etc/gitlab/gitlab.rb`. Be sure to replace the IP
+   addresses with addresses appropriate to your network configuration:
+
+      ```ruby
+      ##
+      ## Primary address
+      ## - replace '<primary_node_ip>' with the public or VPC address of your Geo primary node
+      ##
+      postgresql['listen_address'] = '<primary_site_ip>'
+
+      ##
+      # Allow PostgreSQL client authentication from the primary and secondary IPs. These IPs may be
+      # public or VPC addresses in CIDR format, for example ['198.51.100.1/32', '198.51.100.2/32']
+      ##
+      postgresql['md5_auth_cidr_addresses'] = ['<primary_site_ip>/32', '<secondary_site_ip>/32']
+      ```
+
+1. Disable automatic database migrations temporarily until PostgreSQL is restarted and listening on the private address.
+   In `/etc/gitlab/gitlab.rb`, set `gitlab_rails['auto_migrate']` to false:
+
+   ```ruby
+   ## Disable automatic database migrations
+   gitlab_rails['auto_migrate'] = false
+   ```
+
+1. To apply these changes, reconfigure GitLab and restart PostgreSQL:
+
+   ```shell
+   gitlab-ctl reconfigure
+   gitlab-ctl restart postgresql
+   ```
+
+1. To re-enable migrations, edit `/etc/gitlab/gitlab.rb` and change `gitlab_rails['auto_migrate']` to `true`:
+
+   ```ruby
+   gitlab_rails['auto_migrate'] = true
+   ```
+
+   Save the file and reconfigure GitLab:
+
+   ```shell
+   gitlab-ctl reconfigure
+   ```
+
+   The PostgreSQL server is set up to accept remote connections
+
+1. Run `netstat -plnt | grep 5432` to ensure that PostgreSQL is listening on port
+   `5432` to the primary site private address.
+
+1. A certificate was automatically generated when GitLab was reconfigured. The certificate
+   is used automatically to protect your PostgreSQL traffic from
+   eavesdroppers. To protect against active ("man-in-the-middle") attackers,
+   copy the certificate to the secondary site:
+
+   1. Make a copy of `server.crt` on the primary site:
+
+      ```shell
+      cat ~gitlab-psql/data/server.crt
+      ```
+
+   1. Save the output for when you configure the secondary site.
+      The certificate is not sensitive data.
+
+   The certificate is created with a generic `PostgreSQL` common name.
+   To prevent hostname mismatch errors, you must use the `verify-ca`
+   mode when replicating the database.
+
+### Configure the secondary server
+
+1. SSH into your GitLab secondary site and sign in as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. To prevent any commands from running before the site is configured, stop the application server and Sidekiq:
+
+   ```shell
+   gitlab-ctl stop puma
+   gitlab-ctl stop sidekiq
+   ```
+
+1. [Check TCP connectivity](../../raketasks/maintenance.md) to the primary site PostgreSQL server:
+
+   ```shell
+   gitlab-rake gitlab:tcp_check[<primary_site_ip>,5432]
+   ```
+
+   If this step fails, you might be using the wrong IP address, or a firewall might
+   be preventing access to the site. Check the IP address, paying close
+   attention to the difference between public and private addresses.
+   If a firewall is present, ensure the secondary site is allowed to connect to the
+   primary site on port 5432.
+
+1. In the secondary site, create a file called `server.crt` and add the copy of the certificate you made when you configured the primary site.
+
+   ```shell
+   editor server.crt
+   ```
+
+1. To set up PostgreSQL TLS verification on the secondary site, install `server.crt`:
+
+   ```shell
+   install \
+      -D \
+      -o gitlab-psql \
+      -g gitlab-psql \
+      -m 0400 \
+      -T server.crt ~gitlab-psql/.postgresql/root.crt
+   ```
+
+   PostgreSQL now recognizes only this exact certificate when verifying TLS
+   connections. The certificate can be replicated by someone with access
+   to the private key, which is present on only the primary site.
+
+1. Test that the `gitlab-psql` user can connect to the primary site database.
+   The default Linux package name is `gitlabhq_production`:
+
+   ```shell
+   sudo \
+      -u gitlab-psql /opt/gitlab/embedded/bin/psql \
+      --list \
+      -U gitlab_replicator \
+      -d "dbname=gitlabhq_production sslmode=verify-ca" \
+      -W \
+      -h <primary_site_ip>
+   ```
+
+   When prompted, enter the plaintext password you set for the `gitlab_replicator` user.
+   If all worked correctly, you should see the list of the primary site databases.
+
+1. Edit `/etc/gitlab/gitlab.rb` and set the role to `geo_secondary_role`:
+
+   ```ruby
+   ##
+   ## Geo Secondary role
+   ## - configure dependent flags automatically to enable Geo
+   ##
+   roles(['geo_secondary_role'])
+   ```
+
+   For more information, see [Geo roles](https://docs.gitlab.com/omnibus/roles/#gitlab-geo-roles).
+
+1. To configure PostgreSQL, edit `/etc/gitlab/gitlab.rb` and add the following:
+
+   ```ruby
+   ##
+   ## Secondary address
+   ## - replace '<secondary_site_ip>' with the public or VPC address of your Geo secondary site
+   ##
+   postgresql['listen_address'] = '<secondary_site_ip>'
+   postgresql['md5_auth_cidr_addresses'] = ['<secondary_site_ip>/32']
+
+   ##
+   ## Database credentials password (defined previously in primary site)
+   ## - replicate same values here as defined in primary site
+   ##
+   postgresql['sql_replication_password'] = '<md5_hash_of_your_password>'
+   postgresql['sql_user_password'] = '<md5_hash_of_your_password>'
+   gitlab_rails['db_password'] = '<your_password_here>'
+   ```
+
+   Be sure to replace the IP addresses with addresses appropriate to your network configuration.
+
+1. To apply the changes, reconfigure GitLab:
+
+   ```shell
+   gitlab-ctl reconfigure
+   ```
+
+1. To apply the IP address change, restart PostgreSQL:
+
+   ```shell
+   gitlab-ctl restart postgresql
+   ```
+
+### Replicate the database
+
+Connect the database on the secondary site to
+the database on the primary site.
+You can use the script below to replicate the
+database and create the needed files for streaming replication.
+
+The script uses the default Linux package directories.
+If you changed the defaults, replace the directory and path
+names in the script below with your own names.
+
+WARNING:
+Run the replication script on only the secondary site.
+The script removes all PostgreSQL data before it runs `pg_basebackup`,
+which can lead to data loss.
+
+To replicate the database:
+
+1. SSH into your GitLab secondary site and sign in as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Choose a database-friendly name for your secondary site to
+   use as the replication slot name. For example, if your domain is
+   `secondary.geo.example.com`, use `secondary_example` as the slot
+   name. Replication slot names must only contain lowercase letters,
+   numbers, and the underscore character.
+
+1. Execute the following command to back up and restore the database, and begin the replication.
+
+   WARNING:
+   Each Geo secondary site must have its own unique replication slot name.
+   Using the same slot name between two secondaries breaks PostgreSQL replication.
+
+   ```shell
+   gitlab-ctl replicate-geo-database \
+      --slot-name=<secondary_site_name> \
+      --host=<primary_site_ip> \
+      --sslmode=verify-ca
+   ```
+
+   When prompted, enter the plaintext password you set up for the `gitlab_replicator`.
+
+The replication process is complete.
+
+## Configure a new secondary site
+
+After the replication process is complete, you need to [configure fast lookup of authorized SSH keys](../../operations/fast_ssh_key_lookup.md).
+
+NOTE:
+Authentication is handled by the primary site. Don't set up custom authentication for the secondary site.
+Any change that requires access to the Admin Area should be made in the primary site, because the
+secondary site is a read-only copy.
+
+### Manually replicate secret GitLab values
+
+GitLab stores a number of secret values in `/etc/gitlab/gitlab-secrets.json`.
+This JSON file must be the same across each of the site nodes.
+You must manually replicate the secret file across all of your secondary sites, although
+[issue 3789](https://gitlab.com/gitlab-org/gitlab/-/issues/3789) proposes to change this behavior.
+
+1. SSH into a Rails node on your primary site, and execute the command below:
+
+   ```shell
+   sudo cat /etc/gitlab/gitlab-secrets.json
+   ```
+
+   This displays the secrets you must replicate, in JSON format.
+
+1. SSH into each node on your secondary Geo site and sign in as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Make a backup of any existing secrets:
+
+   ```shell
+   mv /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab-secrets.json.`date +%F`
+   ```
+
+1. Copy `/etc/gitlab/gitlab-secrets.json` from the primary site Rails node to each secondary site node.
+   You can also copy-and-paste the file contents between nodes:
+
+   ```shell
+   sudo editor /etc/gitlab/gitlab-secrets.json
+
+   # paste the output of the `cat` command you ran on the primary
+   # save and exit
+   ```
+
+1. Ensure the file permissions are correct:
+
+   ```shell
+   chown root:root /etc/gitlab/gitlab-secrets.json
+   chmod 0600 /etc/gitlab/gitlab-secrets.json
+   ```
+
+1. To apply the changes, reconfigure every Rails, Sidekiq and Gitaly secondary site node:
+
+   ```shell
+   gitlab-ctl reconfigure
+   gitlab-ctl restart
+   ```
+
+### Manually replicate the primary site SSH host keys
+
+1. SSH into each node on your secondary site and sign in as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Back up any existing SSH host keys:
+
+   ```shell
+   find /etc/ssh -iname 'ssh_host_*' -exec cp {} {}.backup.`date +%F` \;
+   ```
+
+1. Copy OpenSSH host keys from the primary site.
+
+   - If you can access as root one of the primary site nodes serving SSH traffic (usually, the main GitLab Rails application nodes):
+
+     ```shell
+     # Run this from the secondary site, change `<primary_site_fqdn>` for the IP or FQDN of the server
+     scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
+     ```
+
+   - If you only have access through a user with `sudo` privileges:
+
+     ```shell
+     # Run this from the node on your primary site:
+     sudo tar --transform 's/.*\///g' -zcvf ~/geo-host-key.tar.gz /etc/ssh/ssh_host_*_key*
+
+     # Run this on each node on your secondary site:
+     scp <user_with_sudo>@<primary_site_fqdn>:geo-host-key.tar.gz .
+     tar zxvf ~/geo-host-key.tar.gz -C /etc/ssh
+     ```
+
+1. For each secondary site node, ensure the file permissions are correct:
+
+   ```shell
+   chown root:root /etc/ssh/ssh_host_*_key*
+   chmod 0600 /etc/ssh/ssh_host_*_key
+   ```
+
+1. To verify key fingerprint matches, execute the following command on both the primary and secondary nodes on each site:
+
+   ```shell
+   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
+   ```
+
+   You should get an output similar to the following:
+
+   ```shell
+   1024 SHA256:FEZX2jQa2bcsd/fn/uxBzxhKdx4Imc4raXrHwsbtP0M root@serverhostname (DSA)
+   256 SHA256:uw98R35Uf+fYEQ/UnJD9Br4NXUFPv7JAUln5uHlgSeY root@serverhostname (ECDSA)
+   256 SHA256:sqOUWcraZQKd89y/QQv/iynPTOGQxcOTIXU/LsoPmnM root@serverhostname (ED25519)
+   2048 SHA256:qwa+rgir2Oy86QI+PZi/QVR+MSmrdrpsuH7YyKknC+s root@serverhostname (RSA)
+   ```
+
+   The output should be identical on both nodes.
+
+1. Verify you have the correct public keys for the existing private keys:
+
+   ```shell
+   # This will print the fingerprint for private keys:
+   for file in /etc/ssh/ssh_host_*_key; do ssh-keygen -lf $file; done
+
+   # This will print the fingerprint for public keys:
+   for file in /etc/ssh/ssh_host_*_key.pub; do ssh-keygen -lf $file; done
+   ```
+
+   The output for the public and private key commands should generate the same fingerprint.
+
+1. For each secondary site node, restart `sshd`:
+
+   ```shell
+   # Debian or Ubuntu installations
+   sudo service ssh reload
+
+   # CentOS installations
+   sudo service sshd reload
+   ```
+
+1. To verify SSH is still functional, from a new terminal, SSH into your GitLab secondary server.
+   If you can't connect, make sure you have the correct permissions.
+
+### Add the secondary site
+
+1. SSH into each Rails and Sidekiq node on your secondary site and sign in as root:
+
+   ```shell
+   sudo -i
+   ```
+
+1. Edit `/etc/gitlab/gitlab.rb` and add a unique name for your site.
+
+   ```ruby
+   ##
+   ## The unique identifier for the Geo site. See
+   ## https://docs.gitlab.com/ee/user/admin_area/geo_nodes.html#common-settings
+   ##
+   gitlab_rails['geo_node_name'] = '<site_name_here>'
+   ```
+
+   Save the unique name for the next steps.
+
+1. To apply the changes, reconfigure each Rails and Sidekiq node on your secondary site.
+
+   ```shell
+   gitlab-ctl reconfigure
+   ```
+
+1. Navigate to the primary node GitLab instance:
+   1. On the top bar, select **Main menu > Admin**.
+   1. On the left sidebar, select **Geo > Sites**.
+   1. Select **Add site**.
+
+      ![Add secondary site](../replication/img/adding_a_secondary_v15_8.png)
+
+   1. In **Name**, enter the value for `gitlab_rails['geo_node_name']` in
+   `/etc/gitlab/gitlab.rb`. The values must match exactly.
+   1. In **External URL**, enter the value for `external_url` in `/etc/gitlab/gitlab.rb`.
+      It's okay if one values ends in `/` and the other doesn't. Otherwise, the values must
+      match exactly.
+   1. Optional. In **Internal URL (optional)**, enter an internal URL for the primary site.
+   1. Optional. Select which groups or storage shards should be replicated by the
+      secondary site. To replicate all, leave the field blank. See [selective synchronization](../replication/configuration.md#selective-synchronization).
+   1. Select **Save changes**.
+1. SSH into each Rails and Sidekiq node on your secondary site and restart the services:
+
+   ```shell
+   gitlab-ctl restart
+   ```
+
+1. Check if there are any common issues with your Geo setup by running:
+
+   ```shell
+   gitlab-rake gitlab:geo:check
+   ```
+
+   If any of the checks fail, see the [troubleshooting documentation](../replication/troubleshooting.md).
+
+1. To verify that the secondary site is reachable, SSH into a Rails or Sidekiq server on your primary site and sign in as root:
+
+   ```shell
+   gitlab-rake gitlab:geo:check
+   ```
+
+   If any of the checks fail, check the [troubleshooting documentation](../replication/troubleshooting.md).
+
+After the secondary site is added to the Geo administration page and restarted,
+the site automatically starts to replicate missing data from the primary site
+in a process known as backfill.
+
+Meanwhile, the primary site starts to notify each secondary site of any changes, so
+that the secondary site can act on the notifications immediately.
+
+Be sure the secondary site is running and accessible. You can sign in to the
+secondary site with the same credentials as were used with the primary site.
+
+### Enable Git access over HTTP/HTTPS and SSH
+
+Geo synchronizes repositories over HTTP/HTTPS, and therefore requires this clone
+method to be enabled. This is enabled by default.
+If you convert an existing site to Geo, you should check that the clone method is enabled.
+
+On the primary site:
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **Visibility and access controls**.
+1. If you use Git over SSH:
+   1. Ensure **Enabled Git access protocols** is set to **Both SSH and HTTP(S)**.
+   1. Follow [Fast lookup of authorized SSH keys in the database](../../operations/fast_ssh_key_lookup.md) on both the primary and secondary sites.
+1. If you don't use Git over SSH, set **Enabled Git access protocols** to **Only HTTP(S)**.
+
+### Verify proper functioning of the secondary site
+
+You can sign in to the secondary site with the same credentials you used with
+the primary site.
+
+After you sign in:
+
+1. On the top bar, select **Main menu > Admin**.
+1. On the left sidebar, select **Geo > Sites**.
+1. Verify that the site is correctly identified as a secondary Geo site, and that
+   Geo is enabled.
+
+The initial replication might take some time.
+You can monitor the synchronization process on each Geo site from the primary
+site **Geo Sites** dashboard in your browser.
+
+![Geo dashboard](../replication/img/geo_dashboard_v14_0.png)
+
+## Related topics
+
+- [Troubleshooting Geo](../replication/troubleshooting.md)
diff --git a/doc/administration/get_started.md b/doc/administration/get_started.md
index bf3d38657f8..978ea519305 100644
--- a/doc/administration/get_started.md
+++ b/doc/administration/get_started.md
@@ -4,7 +4,7 @@ stage: none
 group: Tutorials
 ---
 
-# Get started administering GitLab **(FREE)**
+# Get started administering GitLab **(FREE SELF)**
 
 Get started with GitLab administration. Configure your organization and its authentication, then secure, monitor,
 and back up GitLab.
@@ -36,7 +36,7 @@ Watch an overview of [groups and projects](https://www.youtube.com/watch?v=cqb2m
 
 Get started:
 
-- Create a [project](../user/project/index.md#create-a-project).
+- Create a [project](../user/project/index.md).
 - Create a [group](../user/group/index.md#create-a-group).
 - [Add members](../user/group/index.md#add-users-to-a-group) to the group.
 - Create a [subgroup](../user/group/subgroups/index.md#create-a-subgroup).
diff --git a/doc/administration/git_protocol.md b/doc/administration/git_protocol.md
index 1ece7d773ee..7fb241b8d1f 100644
--- a/doc/administration/git_protocol.md
+++ b/doc/administration/git_protocol.md
@@ -5,7 +5,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 description: "Set and configure Git protocol v2"
 ---
 
-# Configuring Git Protocol v2 **(FREE)**
+# Configuring Git Protocol v2 **(FREE SELF)**
 
 > [Re-enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/27828) in GitLab 12.8.
 
diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md
index c7fa40014d0..b26ae84eef0 100644
--- a/doc/administration/gitaly/configure_gitaly.md
+++ b/doc/administration/gitaly/configure_gitaly.md
@@ -19,7 +19,7 @@ Configure Gitaly in one of two ways:
 :::TabTitle Self-compiled (source)
 
 1. Edit `/home/git/gitaly/config.toml` and add or change the [Gitaly settings](https://gitlab.com/gitlab-org/gitaly/blob/master/config.toml.example).
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ::EndTabs
 
@@ -183,7 +183,7 @@ Edit `/etc/gitlab/gitlab.rb`:
        token: 'abc123secret'
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 1. On the Gitaly servers, edit `/home/git/gitaly/config.toml`:
 
    ```toml
@@ -191,7 +191,7 @@ Edit `/etc/gitlab/gitlab.rb`:
    token = 'abc123secret'
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ::EndTabs
 
@@ -351,7 +351,7 @@ Configure Gitaly server in one of two ways:
    gitlab_url: https://gitlab.example.com
    ```
 
-1. Save the files and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the files and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 1. Confirm that Gitaly can perform callbacks to the GitLab internal API:
    - For GitLab 15.3 and later, run `sudo /opt/gitlab/embedded/bin/gitaly check /var/opt/gitlab/gitaly/config.toml`.
    - For GitLab 15.2 and earlier, run `sudo /opt/gitlab/embedded/bin/gitaly-hooks check /var/opt/gitlab/gitaly/config.toml`.
@@ -456,7 +456,7 @@ Configure Gitaly clients in one of two ways:
    this folder. This requirement is scheduled to be removed when
    [this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 1. Run `sudo -u git -H bundle exec rake gitlab:gitaly:check RAILS_ENV=production` to confirm the
    Gitaly client can connect to Gitaly servers.
 1. Tail the logs to see the requests:
@@ -570,7 +570,7 @@ Disable Gitaly on a GitLab server in one of two ways:
    gitaly_enabled=false
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ::EndTabs
 
@@ -705,7 +705,7 @@ Configure Gitaly with TLS in one of two ways:
    in this folder. This requirement is scheduled to be removed when
    [Gitaly issue #1282](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 1. On the Gitaly servers, create or edit `/etc/default/gitlab` and add:
 
    ```shell
@@ -740,14 +740,14 @@ Configure Gitaly with TLS in one of two ways:
    key_path = '/etc/gitlab/ssl/key.pem'
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 1. Verify Gitaly traffic is being served over TLS by
    [observing the types of Gitaly connections](#observe-type-of-gitaly-connections).
 1. Optional. Improve security by:
    1. Disabling non-TLS connections by commenting out or deleting `listen_addr` in
       `/home/git/gitaly/config.toml`.
    1. Saving the file.
-   1. [Restarting GitLab](../restart_gitlab.md#installations-from-source).
+   1. [Restarting GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ::EndTabs
 
@@ -1453,7 +1453,7 @@ following keys (in this example, to disable the `hasDotgit` consistency check):
   }
   ```
 
-For source installs, edit the Gitaly configuration (`gitaly.toml`) to do the
+For self-compiled installations, edit the Gitaly configuration (`gitaly.toml`) to do the
 equivalent:
 
 ```toml
@@ -1552,7 +1552,7 @@ Configure Gitaly to sign commits made with the GitLab UI in one of two ways:
    signing_key = "/etc/gitlab/gitaly/signing_key.gpg"
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ::EndTabs
 
diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md
index 9577c4a4cb2..6eefd0a7bb5 100644
--- a/doc/administration/gitaly/praefect.md
+++ b/doc/administration/gitaly/praefect.md
@@ -671,8 +671,6 @@ Updates to example must be made at:
    }
    ```
 
-1. Enable [distribution of reads](index.md#distributed-reads).
-
 1. Save the changes to `/etc/gitlab/gitlab.rb` and
    [reconfigure Praefect](../restart_gitlab.md#reconfigure-a-linux-package-installation):
 
@@ -853,7 +851,7 @@ For self-compiled installations:
    data is stored in this folder. This requirement is scheduled to be removed when
    [this issue](https://gitlab.com/gitlab-org/gitaly/-/issues/1282) is resolved.
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 1. Copy all Praefect server certificates, or their certificate authority, to the system
    trusted certificates on each Gitaly server so the Praefect server trusts the
    certificate when called by Gitaly servers:
@@ -873,7 +871,7 @@ For self-compiled installations:
    key_path = '/etc/gitlab/ssl/key.pem'
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 #### Service discovery
 
@@ -990,7 +988,7 @@ with Praefect service discovery address, such as `praefect.service.consul`.
    data is stored in this folder. [Issue 375254](https://gitlab.com/gitlab-org/gitlab/-/issues/375254)
    proposes to remove this requirement.
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ::EndTabs
 
@@ -1020,10 +1018,10 @@ Particular attention should be shown to:
 - The `gitaly['configuration'][:auth][:token]` configured in this section must match the `token`
   value under `praefect['configuration'][:virtual_storage][<index>][:node][<index>][:token]` on the Praefect node. This value was
   set in the [previous section](#praefect). This document uses the placeholder `PRAEFECT_INTERNAL_TOKEN` throughout.
-- The storage names in `gitaly['configuration'][:storage]` configured in this section must match the
-  storage names under `praefect['configuration'][:virtual_storage]` on the Praefect node. This
+- The physical storage names in `gitaly['configuration'][:storage]` configured in this section must match the
+  physical storage names under `praefect['configuration'][:virtual_storage]` on the Praefect node. This
   was set in the [previous section](#praefect). This document uses `gitaly-1`,
-  `gitaly-2`, and `gitaly-3` as Gitaly storage names.
+  `gitaly-2`, and `gitaly-3` as physical storage names.
 
 For more information on Gitaly server configuration, see our
 [Gitaly documentation](configure_gitaly.md#configure-gitaly-servers).
@@ -1419,12 +1417,12 @@ cluster.
 
 ## Configure replication factor
 
-WARNING:
-Configurable replication factors require [repository-specific primary nodes](#repository-specific-primary-nodes) to be used.
-
 Praefect supports configuring a replication factor on a per-repository basis, by assigning
 specific storage nodes to host a repository.
 
+WARNING:
+Configurable replication factors requires [repository-specific primary nodes](#repository-specific-primary-nodes).
+
 Praefect does not store the actual replication factor, but assigns enough storages to host the repository
 so the desired replication factor is met. If a storage node is later removed from the virtual storage,
 the replication factor of repositories assigned to the storage is decreased accordingly.
@@ -1436,13 +1434,13 @@ You can configure either:
 
 ### Configure default replication factor
 
-If `default_replication_factor` is unset, the repositories are always replicated on every node defined in
-`virtual_storages`. If a new node is introduced to the virtual storage, both new and existing repositories are
+If `default_replication_factor` is unset, the repositories are always replicated on every storage node defined in
+`virtual_storages`. If a new storage node is introduced to the virtual storage, both new and existing repositories are
 replicated to the node automatically.
 
-For large Gitaly Cluster deployments with many Gitaly nodes, replicating a repository to every storage is often not
-sensible and can cause problems. The higher the replication factor, the higher the pressure on the primary repository.
-You should explicitly set the default replication factor for large Gitaly Cluster deployments.
+For large Gitaly Cluster deployments with many storage nodes, replicating a repository to every storage node is often not
+sensible and can cause problems. A replication factor of 3 is usually sufficient, which means replicate repositories to
+three storages even if more are available. Higher replication factors increase the pressure on the primary storage.
 
 To configure a default replication factor, add configuration to the `/etc/gitlab/gitlab.rb` file:
 
@@ -1453,7 +1451,7 @@ praefect['configuration'] = {
       {
          # ...
          name: 'default',
-         default_replication_factor: 1,
+         default_replication_factor: 3,
       },
    ],
 }
@@ -1718,26 +1716,3 @@ To migrate existing clusters:
       1. Uncomment the secondary Gitaly node configuration commented out in the earlier step on all Praefect nodes.
 
       1. Run `gitlab-ctl reconfigure` on all Praefect nodes to reconfigure and restart the Praefect processes.
-
-### Deprecated election strategies
-
-WARNING:
-The below election strategies are deprecated and were removed in GitLab 14.0.
-Migrate to [repository-specific primary nodes](#repository-specific-primary-nodes).
-
-- **PostgreSQL:** Enabled by default until GitLab 14.0, and equivalent to:
-  `praefect['failover_election_strategy'] = 'sql'`.
-
-  This configuration option:
-
-  - Allows multiple Praefect nodes to coordinate via the PostgreSQL database to elect a primary
-    Gitaly node.
-  - Causes Praefect nodes to elect a new primary Gitaly node, monitor its health, and elect a new primary
-    Gitaly node if the current one is not reached within 10 seconds by a majority of the Praefect
-    nodes.
-- **Memory:** Enabled by setting `praefect['failover_election_strategy'] = 'local'`
-  in `/etc/gitlab/gitlab.rb` on the Praefect node.
-
-  If a sufficient number of health checks fail for the current primary Gitaly node, a new primary is
-  elected. **Do not use with multiple Praefect nodes!** Using with multiple Praefect nodes is
-  likely to result in a split brain.
diff --git a/doc/administration/incoming_email.md b/doc/administration/incoming_email.md
index 0024c42972b..6948009aab2 100644
--- a/doc/administration/incoming_email.md
+++ b/doc/administration/incoming_email.md
@@ -16,7 +16,7 @@ GitLab has several features based on receiving incoming email messages:
 - [New merge request by email](../user/project/merge_requests/creating_merge_requests.md#by-sending-an-email):
   allow GitLab users to create a new merge request by sending an email to a
   user-specific email address.
-- [Service Desk](../user/project/service_desk.md): provide email support to
+- [Service Desk](../user/project/service_desk/index.md): provide email support to
   your customers through GitLab.
 
 ## Requirements
@@ -80,7 +80,7 @@ Email is processed correctly when a configured email address is present in one o
 
 The `References` header is also accepted, however it is used specifically to relate email responses to existing discussion threads. It is not used for creating issues by email.
 
-In GitLab 14.6 and later, [Service Desk](../user/project/service_desk.md)
+In GitLab 14.6 and later, [Service Desk](../user/project/service_desk/index.md)
 also checks accepted headers.
 
 Usually, the "To" field contains the email address of the primary receiver.
@@ -179,7 +179,7 @@ list.
 
 Reply by email should now be working.
 
-### Installations from source
+### Self-compiled installations
 
 1. Go to the GitLab installation directory:
 
@@ -312,7 +312,7 @@ gitlab_rails['incoming_email_delete_after_delivery'] = true
 gitlab_rails['incoming_email_expunge_deleted'] = true
 ```
 
-Example for source installs:
+Example for self-compiled installations:
 
 ```yaml
 incoming_email:
@@ -404,7 +404,7 @@ gitlab_rails['incoming_email_delete_after_delivery'] = true
 gitlab_rails['incoming_email_expunge_deleted'] = true
 ```
 
-Example for source installs:
+Example for self-compiled installations:
 
 ```yaml
 incoming_email:
@@ -490,7 +490,7 @@ gitlab_rails['incoming_email_ssl'] = true
 gitlab_rails['incoming_email_expunge_deleted'] = true
 ```
 
-Example for source installs:
+Example for self-compiled installations:
 
 ```yaml
 incoming_email:
@@ -529,7 +529,7 @@ incoming_email:
 
 NOTE:
 Supports [Reply by Email](reply_by_email.md) only.
-Cannot support [Service Desk](../user/project/service_desk.md).
+Cannot support [Service Desk](../user/project/service_desk/index.md).
 
 Assumes the dedicated email address `incoming@exchange.example.com`.
 
@@ -558,7 +558,7 @@ gitlab_rails['incoming_email_ssl'] = true
 gitlab_rails['incoming_email_expunge_deleted'] = true
 ```
 
-Example for source installs:
+Example for self-compiled installations:
 
 ```yaml
 incoming_email:
@@ -646,7 +646,7 @@ gitlab_rails['incoming_email_ssl'] = true
 gitlab_rails['incoming_email_expunge_deleted'] = true
 ```
 
-This example for source installs assumes the mailbox `incoming@office365.example.com`:
+This example for self-compiled installations assumes the mailbox `incoming@office365.example.com`:
 
 ```yaml
 incoming_email:
@@ -707,7 +707,7 @@ gitlab_rails['incoming_email_ssl'] = true
 gitlab_rails['incoming_email_expunge_deleted'] = true
 ```
 
-This example for source installs assumes the catch-all mailbox `incoming@office365.example.com`:
+This example for self-compiled installations assumes the catch-all mailbox `incoming@office365.example.com`:
 
 ```yaml
 incoming_email:
@@ -741,7 +741,7 @@ incoming_email:
 
 NOTE:
 Supports [Reply by Email](reply_by_email.md) only.
-Cannot support [Service Desk](../user/project/service_desk.md).
+Cannot support [Service Desk](../user/project/service_desk/index.md).
 
 This example for Linux package installations assumes the dedicated email address `incoming@office365.example.com`:
 
@@ -767,7 +767,7 @@ gitlab_rails['incoming_email_ssl'] = true
 gitlab_rails['incoming_email_expunge_deleted'] = true
 ```
 
-This example for source installs assumes the dedicated email address `incoming@office365.example.com`:
+This example for self-compiled installations assumes the dedicated email address `incoming@office365.example.com`:
 
 ```yaml
 incoming_email:
@@ -865,7 +865,7 @@ gitlab_rails['incoming_email_inbox_options'] = {
 }
 ```
 
-The Microsoft Graph API is not yet supported in source installations. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/326169) for more details.
+The Microsoft Graph API is not yet supported in self-compiled installations. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/326169) for more details.
 
 ### Use encrypted credentials
 
diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md
index 679042c3114..34f6da1d01d 100644
--- a/doc/administration/instance_limits.md
+++ b/doc/administration/instance_limits.md
@@ -760,6 +760,26 @@ You can change these limits in the [GitLab Rails console](operations/rails_conso
   ApplicationSetting.update(max_yaml_depth: 125)
   ```
 
+### Maximum size of the entire CI/CD configuration
+
+The maximum amount of memory, in bytes, that can be allocated for the full pipeline configuration,
+with all included YAML configuration files.
+
+For new self-managed instances, the default is `157286400` bytes (150 MB).
+
+For existing self-managed instances that upgrade to GitLab 16.3 or later, the default is calculated
+by multiplying [`max_yaml_size_bytes` (default 1 MB)](#maximum-size-and-depth-of-cicd-configuration-yaml-files)
+with [`ci_max_includes` (default 150)](../api/settings.md#list-of-settings-that-can-be-accessed-via-api-calls).
+If both limits are unmodified, the default is set to 1 MB x 150 = `157286400` bytes (150 MB).
+
+You can change this limit via the [GitLab Rails console](operations/rails_console.md#starting-a-rails-console-session).
+To update the maximum memory that can be allocated for the CI/CD configuration,
+update `ci_max_total_yaml_size_bytes` with the new value. For example, to set it to 20 MB:
+
+```ruby
+ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)
+```
+
 ### Limit dotenv variables
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/321552) in GitLab 14.5.
@@ -840,7 +860,7 @@ panel_groups:
       label: Legend Label
 ```
 
-## Environment Dashboard limits **(PREMIUM)**
+## Environment Dashboard limits **(PREMIUM ALL)**
 
 See [Environment Dashboard](../ci/environments/environments_dashboard.md#adding-a-project-to-the-dashboard) for the maximum number of displayed projects.
 
diff --git a/doc/administration/integration/diagrams_net.md b/doc/administration/integration/diagrams_net.md
index 335b26565e6..7f8c01ad7bd 100644
--- a/doc/administration/integration/diagrams_net.md
+++ b/doc/administration/integration/diagrams_net.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference, howto
 ---
 
-# Diagrams.net **(FREE)**
+# Diagrams.net **(FREE SELF)**
 
 With the [diagrams.net](https://www.diagrams.net/) integration, you can create and embed SVG diagrams in wikis.
 The diagram editor is available in both the plain text editor and the rich text editor.
diff --git a/doc/administration/integration/plantuml.md b/doc/administration/integration/plantuml.md
index f05197d45e7..5e499e302db 100644
--- a/doc/administration/integration/plantuml.md
+++ b/doc/administration/integration/plantuml.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference, howto
 ---
 
-# PlantUML **(FREE)**
+# PlantUML **(FREE SELF)**
 
 With the [PlantUML](https://plantuml.com) integration, you can create diagrams in snippets, wikis, and repositories.
 This integration is enabled on GitLab.com for all SaaS users and does not require any additional configuration.
@@ -291,6 +291,14 @@ The default URL is different when using this approach. The Docker-based image
 makes the service available at the root URL, with no relative path. Adjust
 the configuration below accordingly.
 
+#### `404` error when opening the PlantUML page in the browser
+
+You might get a `404` error when visiting `https://gitlab.example.com/-/plantuml/`, when the PlantUML
+server is set up [in Debian or Ubuntu](#debianubuntu).
+
+This can happen even when the integration is working.
+It does not necessarily indicate a problem with your PlantUML server or configuration.
+
 ### Configure PlantUML security
 
 PlantUML has features that allow fetching network resources. If you self-host the
diff --git a/doc/administration/integration/terminal.md b/doc/administration/integration/terminal.md
index 1ab45d6ce99..2939e227a04 100644
--- a/doc/administration/integration/terminal.md
+++ b/doc/administration/integration/terminal.md
@@ -4,7 +4,7 @@ group: Environments
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Web terminals (deprecated) **(FREE)**
+# Web terminals (deprecated) **(FREE SELF)**
 
 > - [Deprecated](https://gitlab.com/groups/gitlab-org/configure/-/epics/8) in GitLab 14.5.
 > - [Disabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/issues/353410) in GitLab 15.0.
@@ -114,5 +114,5 @@ lifetime in your GitLab instance:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
-1. Select [**Settings > Web terminal**](../../administration/settings/index.md#general).
+1. Select **Settings > Web terminal**.
 1. Set a `max session time`.
diff --git a/doc/administration/invalidate_markdown_cache.md b/doc/administration/invalidate_markdown_cache.md
index 366cbea5711..5db08075449 100644
--- a/doc/administration/invalidate_markdown_cache.md
+++ b/doc/administration/invalidate_markdown_cache.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Markdown cache **(FREE)**
+# Markdown cache **(FREE SELF)**
 
 For performance reasons, GitLab caches the HTML version of Markdown text in fields such as:
 
diff --git a/doc/administration/issue_closing_pattern.md b/doc/administration/issue_closing_pattern.md
index 1ea6b3bb49c..d179b77530a 100644
--- a/doc/administration/issue_closing_pattern.md
+++ b/doc/administration/issue_closing_pattern.md
@@ -21,11 +21,6 @@ in the project's default branch.
 The [default issue closing pattern](../user/project/issues/managing_issues.md#default-closing-pattern)
 covers a wide range of words. You can change the pattern to suit your needs.
 
-NOTE:
-To test the issue closing pattern, use <https://rubular.com>.
-However, Rubular doesn't understand `%{issue_ref}`. When testing your patterns,
-replace this string with `#\d+`, which matches only local issue references like `#123`.
-
 To change the default issue closing pattern:
 
 ::Tabs
@@ -108,3 +103,7 @@ To change the default issue closing pattern:
    ```
 
 ::EndTabs
+
+To test the issue closing pattern, use <https://rubular.com>.
+However, Rubular doesn't understand `%{issue_ref}`. When testing your patterns,
+replace this string with `#\d+`, which matches only local issue references like `#123`.
diff --git a/doc/administration/job_artifacts.md b/doc/administration/job_artifacts.md
index 106334b226d..b3778e89b19 100644
--- a/doc/administration/job_artifacts.md
+++ b/doc/administration/job_artifacts.md
@@ -399,428 +399,3 @@ an archive is a very large file.
 When selecting a specific file, [GitLab Workhorse](https://gitlab.com/gitlab-org/gitlab-workhorse) extracts it
 from the archive and the download begins. This implementation saves space,
 memory and disk I/O.
-
-## Troubleshooting
-
-### Job artifacts using too much disk space
-
-Job artifacts can fill up your disk space quicker than expected. Some possible
-reasons are:
-
-- Users have configured job artifacts expiration to be longer than necessary.
-- The number of jobs run, and hence artifacts generated, is higher than expected.
-- Job logs are larger than expected, and have accumulated over time.
-- The file system might run out of inodes because
-  [empty directories are left behind by artifact housekeeping](https://gitlab.com/gitlab-org/gitlab/-/issues/17465).
-  [The Rake task for _orphaned_ artifact files](../raketasks/cleanup.md#remove-orphan-artifact-files)
-  removes these.
-- Artifact files might be left on disk and not deleted by housekeeping. Run the
-  [Rake task for _orphaned_ artifact files](../raketasks/cleanup.md#remove-orphan-artifact-files)
-  to remove these. This script should always find work to do, as it also removes empty directories (see above).
-- [Artifact housekeeping was changed significantly](#artifacts-housekeeping-disabled-in-gitlab-146-to-152),
-  and you might need to enable a feature flag to used the updated system.
-- The [keep latest artifacts from most recent success jobs](../ci/jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs)
-  feature is enabled.
-
-In these and other cases, identify the projects most responsible
-for disk space usage, figure out what types of artifacts are using the most
-space, and in some cases, manually delete job artifacts to reclaim disk space.
-
-#### Artifacts housekeeping disabled in GitLab 14.6 to 15.2
-
-Artifact housekeeping was significantly changed in GitLab 14.10, and the changes
-were back ported to GitLab 14.6 and later. The updated housekeeping must be
-enabled with feature flags [until GitLab 15.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92931).
-
-To check if the feature flags are enabled:
-
-1. Start a [Rails console](operations/rails_console.md#starting-a-rails-console-session).
-
-1. Check if the feature flags are enabled.
-
-   - GitLab 14.10 and earlier:
-
-     ```ruby
-     Feature.enabled?(:ci_detect_wrongly_expired_artifacts, default_enabled: :yaml)
-     Feature.enabled?(:ci_update_unlocked_job_artifacts, default_enabled: :yaml)
-     Feature.enabled?(:ci_destroy_unlocked_job_artifacts, default_enabled: :yaml)
-     ```
-
-   - GitLab 15.00 and later:
-
-     ```ruby
-     Feature.enabled?(:ci_detect_wrongly_expired_artifacts)
-     Feature.enabled?(:ci_update_unlocked_job_artifacts)
-     Feature.enabled?(:ci_destroy_unlocked_job_artifacts)
-     ```
-
-1. If any of the feature flags are disabled, enable them:
-
-   ```ruby
-   Feature.enable(:ci_detect_wrongly_expired_artifacts)
-   Feature.enable(:ci_update_unlocked_job_artifacts)
-   Feature.enable(:ci_destroy_unlocked_job_artifacts)
-   ```
-
-These changes include switching artifacts from `unlocked` to `locked` if
-they [should be retained](../ci/jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs).
-
-Artifacts created before this feature was introduced have a status of `unknown`. After they expire,
-these artifacts are not processed by the new housekeeping jobs.
-
-You can check the database to confirm if your instance has artifacts with the `unknown` status:
-
-1. Start a database console:
-
-   ::Tabs
-
-   :::TabTitle Linux package (Omnibus)
-
-   ```shell
-   sudo gitlab-psql
-   ```
-
-   :::TabTitle Helm chart (Kubernetes)
-
-   ```shell
-   # Find the toolbox pod
-   kubectl --namespace <namespace> get pods -lapp=toolbox
-   # Connect to the PostgreSQL console
-   kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password --database main
-   ```
-
-   :::TabTitle Docker
-
-   ```shell
-   sudo docker exec -it <container_name> /bin/bash
-   gitlab-psql
-   ```
-
-   :::TabTitle Self-compiled (source)
-
-   ```shell
-   sudo -u git -H psql -d gitlabhq_production
-   ```
-
-   ::EndTabs
-
-1. Run the following query:
-
-   ```sql
-   select expire_at, file_type, locked, count(*) from ci_job_artifacts
-   where expire_at is not null and
-   file_type != 3
-   group by expire_at, file_type, locked having count(*) > 1;
-   ```
-
-If records are returned, then there are artifacts which the housekeeping job
-is unable to process. For example:
-
-```plaintext
-           expire_at           | file_type | locked | count
--------------------------------+-----------+--------+--------
- 2021-06-21 22:00:00+00        |         1 |      2 |  73614
- 2021-06-21 22:00:00+00        |         2 |      2 |  73614
- 2021-06-21 22:00:00+00        |         4 |      2 |   3522
- 2021-06-21 22:00:00+00        |         9 |      2 |     32
- 2021-06-21 22:00:00+00        |        12 |      2 |    163
-```
-
-Artifacts with locked status `2` are `unknown`. Check
-[issue #346261](https://gitlab.com/gitlab-org/gitlab/-/issues/346261#note_1028871458)
-for more details.
-
-The Sidekiq worker that processes all `unknown` artifacts is enabled by default in
-GitLab 15.3 and later. It analyzes the artifacts returned by the above database query and
-determines which should be `locked` or `unlocked`. Artifacts are then deleted
-by that worker if needed.
-
-The worker can be enabled on self-managed instances running GitLab 14.10 and later:
-
-1. Start a [Rails console](operations/rails_console.md#starting-a-rails-console-session).
-
-1. Check if the feature is enabled.
-
-   - GitLab 14.10:
-
-     ```ruby
-     Feature.enabled?(:ci_job_artifacts_backlog_work, default_enabled: :yaml)
-     ```
-
-   - GitLab 15.0 and later:
-
-     ```ruby
-     Feature.enabled?(:ci_job_artifacts_backlog_work)
-     ```
-
-1. Enable the feature, if needed:
-
-   ```ruby
-   Feature.enable(:ci_job_artifacts_backlog_work)
-   ```
-
-The worker processes 10,000 `unknown` artifacts every seven minutes, or roughly two million
-in 24 hours.
-
-There is a related `ci_job_artifacts_backlog_large_loop_limit` feature flag
-which causes the worker to process `unknown` artifacts
-[in batches that are five times larger](https://gitlab.com/gitlab-org/gitlab/-/issues/356319).
-This flag is not recommended for use on self-managed instances.
-
-#### List projects and builds with artifacts with a specific expiration (or no expiration)
-
-Using a [Rails console](operations/rails_console.md), you can find projects that have job artifacts with either:
-
-- No expiration date.
-- An expiration date more than 7 days in the future.
-
-Similar to [deleting artifacts](#delete-job-artifacts-from-jobs-completed-before-a-specific-date), use the following example time frames
-and alter them as needed:
-
-- `7.days.from_now`
-- `10.days.from_now`
-- `2.weeks.from_now`
-- `3.months.from_now`
-
-Each of the following scripts also limits the search to 50 results with `.limit(50)`, but this number can also be changed as needed:
-
-```ruby
-# Find builds & projects with artifacts that never expire
-builds_with_artifacts_that_never_expire = Ci::Build.with_downloadable_artifacts.where(artifacts_expire_at: nil).limit(50)
-builds_with_artifacts_that_never_expire.find_each do |build|
-  puts "Build with id #{build.id} has artifacts that don't expire and belongs to project #{build.project.full_path}"
-end
-
-# Find builds & projects with artifacts that expire after 7 days from today
-builds_with_artifacts_that_expire_in_a_week = Ci::Build.with_downloadable_artifacts.where('artifacts_expire_at > ?', 7.days.from_now).limit(50)
-builds_with_artifacts_that_expire_in_a_week.find_each do |build|
-  puts "Build with id #{build.id} has artifacts that expire at #{build.artifacts_expire_at} and belongs to project #{build.project.full_path}"
-end
-```
-
-#### List projects by total size of job artifacts stored
-
-List the top 20 projects, sorted by the total size of job artifacts stored, by
-running the following code in the Rails console (`sudo gitlab-rails console`):
-
-```ruby
-include ActionView::Helpers::NumberHelper
-ProjectStatistics.order(build_artifacts_size: :desc).limit(20).each do |s|
-  puts "#{number_to_human_size(s.build_artifacts_size)} \t #{s.project.full_path}"
-end
-```
-
-You can change the number of projects listed by modifying `.limit(20)` to the
-number you want.
-
-#### List largest artifacts in a single project
-
-List the 50 largest job artifacts in a single project by running the following
-code in the Rails console (`sudo gitlab-rails console`):
-
-```ruby
-include ActionView::Helpers::NumberHelper
-project = Project.find_by_full_path('path/to/project')
-Ci::JobArtifact.where(project: project).order(size: :desc).limit(50).map { |a| puts "ID: #{a.id} - #{a.file_type}: #{number_to_human_size(a.size)}" }
-```
-
-You can change the number of job artifacts listed by modifying `.limit(50)` to
-the number you want.
-
-#### List artifacts in a single project
-
-List the artifacts for a single project, sorted by artifact size. The output includes the:
-
-- ID of the job that created the artifact
-- artifact size
-- artifact file type
-- artifact creation date
-- on-disk location of the artifact
-
-```ruby
-p = Project.find_by_id(<project_id>)
-arts = Ci::JobArtifact.where(project: p)
-
-list = arts.order(size: :desc).limit(50).each do |art|
-    puts "Job ID: #{art.job_id} - Size: #{art.size}b - Type: #{art.file_type} - Created: #{art.created_at} - File loc: #{art.file}"
-end
-```
-
-To change the number of job artifacts listed, change the number in `limit(50)`.
-
-#### Delete job artifacts from jobs completed before a specific date
-
-WARNING:
-These commands remove data permanently from both the database and from disk. Before running them, we highly recommend seeking guidance from a Support Engineer, or running them in a test environment with a backup of the instance ready to be restored, just in case.
-
-If you need to manually remove job artifacts associated with multiple jobs while
-**retaining their job logs**, this can be done from the Rails console (`sudo gitlab-rails console`):
-
-1. Select jobs to be deleted:
-
-   To select all jobs with artifacts for a single project:
-
-   ```ruby
-   project = Project.find_by_full_path('path/to/project')
-   builds_with_artifacts =  project.builds.with_downloadable_artifacts
-   ```
-
-   To select all jobs with artifacts across the entire GitLab instance:
-
-   ```ruby
-   builds_with_artifacts = Ci::Build.with_downloadable_artifacts
-   ```
-
-1. Delete job artifacts older than a specific date:
-
-   NOTE:
-   This step also erases artifacts that users have chosen to
-   ["keep"](../ci/jobs/job_artifacts.md#download-job-artifacts).
-
-   ```ruby
-   builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
-   builds_to_clear.find_each do |build|
-     Ci::JobArtifacts::DeleteService.new(build).execute
-     build.update!(artifacts_expire_at: Time.now)
-   end
-   ```
-
-   In [GitLab 15.3 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/372537), use the following instead:
-
-   ```ruby
-   builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
-   builds_to_clear.find_each do |build|
-     build.artifacts_expire_at = Time.now
-     build.erase_erasable_artifacts!
-   end
-   ```
-
-   `1.week.ago` is a Rails `ActiveSupport::Duration` method which calculates a new
-   date or time in the past. Other valid examples are:
-
-   - `7.days.ago`
-   - `3.months.ago`
-   - `1.year.ago`
-
-   `erase_erasable_artifacts!` is a synchronous method, and upon execution the artifacts are immediately removed;
-   they are not scheduled by a background queue.
-
-#### Delete job artifacts and logs from jobs completed before a specific date
-
-WARNING:
-These commands remove data permanently from both the database and from disk. Before running them, we highly recommend seeking guidance from a Support Engineer, or running them in a test environment with a backup of the instance ready to be restored, just in case.
-
-If you need to manually remove **all** job artifacts associated with multiple jobs,
-**including job logs**, this can be done from the Rails console (`sudo gitlab-rails console`):
-
-1. Select the jobs to be deleted:
-
-   To select jobs with artifacts for a single project:
-
-   ```ruby
-   project = Project.find_by_full_path('path/to/project')
-   builds_with_artifacts =  project.builds.with_existing_job_artifacts(Ci::JobArtifact.trace)
-   ```
-
-   To select jobs with artifacts across the entire GitLab instance:
-
-   ```ruby
-   builds_with_artifacts = Ci::Build.with_existing_job_artifacts(Ci::JobArtifact.trace)
-   ```
-
-1. Select the user which is mentioned in the web UI as erasing the job:
-
-   ```ruby
-   admin_user = User.find_by(username: 'username')
-   ```
-
-1. Erase the job artifacts and logs older than a specific date:
-
-   ```ruby
-   builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
-   builds_to_clear.find_each do |build|
-     print "Ci::Build ID #{build.id}... "
-
-     if build.erasable?
-       Ci::BuildEraseService.new(build, admin_user).execute
-       puts "Erased"
-     else
-       puts "Skipped (Nothing to erase or not erasable)"
-     end
-   end
-   ```
-
-   In [GitLab 15.3 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/369132), replace
-   `Ci::BuildEraseService.new(build, admin_user).execute` with `build.erase(erased_by: admin_user)`.
-
-   `1.week.ago` is a Rails `ActiveSupport::Duration` method which calculates a new
-   date or time in the past. Other valid examples are:
-
-   - `7.days.ago`
-   - `3.months.ago`
-   - `1.year.ago`
-
-### Job artifact upload fails with error 500
-
-If you are using object storage for artifacts and a job artifact fails to upload,
-review:
-
-- The job log for an error message similar to:
-
-  ```plaintext
-  WARNING: Uploading artifacts as "archive" to coordinator... failed id=12345 responseStatus=500 Internal Server Error status=500 token=abcd1234
-  ```
-
-- The [workhorse log](logs/index.md#workhorse-logs) for an error message similar to:
-
-  ```json
-  {"error":"MissingRegion: could not find region configuration","level":"error","msg":"error uploading S3 session","time":"2021-03-16T22:10:55-04:00"}
-  ```
-
-In both cases, you might need to add `region` to the job artifact [object storage configuration](object_storage.md).
-
-### Job artifact upload fails with `500 Internal Server Error (Missing file)`
-
-Bucket names that include folder paths are not supported with [consolidated object storage](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
-For example, `bucket/path`. If a bucket name has a path in it, you might receive an error similar to:
-
-```plaintext
-WARNING: Uploading artifacts as "archive" to coordinator... POST https://gitlab.example.com/api/v4/jobs/job_id/artifacts?artifact_format=zip&artifact_type=archive&expire_in=1+day: 500 Internal Server Error (Missing file)
-FATAL: invalid argument
-```
-
-If a job artifact fails to upload with the above error when using consolidated object storage, make sure you are [using separate buckets](object_storage.md#use-separate-buckets) for each data type.
-
-### Job artifacts fail to upload with `FATAL: invalid argument` when using Windows mount
-
-If you are using a Windows mount with CIFS for job artifacts, you may see an
-`invalid argument` error when the runner attempts to upload artifacts:
-
-```plaintext
-WARNING: Uploading artifacts as "dotenv" to coordinator... POST https://<your-gitlab-instance>/api/v4/jobs/<JOB_ID>/artifacts: 500 Internal Server Error  id=1296 responseStatus=500 Internal Server Error status=500 token=*****
-FATAL: invalid argument
-```
-
-To work around this issue, you can try:
-
-- Switching to an ext4 mount instead of CIFS.
-- Upgrading to at least Linux kernel 5.15 which contains a number of important bug fixes
-  relating to CIFS file leases.
-- For older kernels, using the `nolease` mount option to disable file leasing.
-
-For more information, [see the investigation details](https://gitlab.com/gitlab-org/gitlab/-/issues/389995).
-
-### Usage quota shows incorrect artifact storage usage
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/238536) in GitLab 14.10.
-
-Sometimes the [artifacts storage usage](../user/usage_quotas.md) displays an incorrect
-value for the total storage space used by artifacts. To recalculate the artifact
-usage statistics for all projects in the instance, you can run this background script:
-
-```shell
-bin/rake 'gitlab:refresh_project_statistics_build_artifacts_size[file.csv]'
-```
-
-The artifact usage value can fluctuate to `0` while the script is running. After
-recalculation, usage should display as expected again.
diff --git a/doc/administration/job_artifacts_troubleshooting.md b/doc/administration/job_artifacts_troubleshooting.md
new file mode 100644
index 00000000000..ba60cbd7aba
--- /dev/null
+++ b/doc/administration/job_artifacts_troubleshooting.md
@@ -0,0 +1,460 @@
+---
+stage: Verify
+group: Pipeline Security
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# Job artifact troubleshooting for administrators
+
+When administering job artifacts, you might encounter the following issues.
+
+## Job artifacts using too much disk space
+
+Job artifacts can fill up your disk space quicker than expected. Some possible
+reasons are:
+
+- Users have configured job artifacts expiration to be longer than necessary.
+- The number of jobs run, and hence artifacts generated, is higher than expected.
+- Job logs are larger than expected, and have accumulated over time.
+- The file system might run out of inodes because
+  [empty directories are left behind by artifact housekeeping](https://gitlab.com/gitlab-org/gitlab/-/issues/17465).
+  [The Rake task for _orphaned_ artifact files](../raketasks/cleanup.md#remove-orphan-artifact-files)
+  removes these.
+- Artifact files might be left on disk and not deleted by housekeeping. Run the
+  [Rake task for _orphaned_ artifact files](../raketasks/cleanup.md#remove-orphan-artifact-files)
+  to remove these. This script should always find work to do, as it also removes empty directories (see above).
+- [Artifact housekeeping was changed significantly](#housekeeping-disabled-in-gitlab-146-to-152),
+  and you might need to enable a feature flag to used the updated system.
+- The [keep latest artifacts from most recent success jobs](../ci/jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs)
+  feature is enabled.
+
+In these and other cases, identify the projects most responsible
+for disk space usage, figure out what types of artifacts are using the most
+space, and in some cases, manually delete job artifacts to reclaim disk space.
+
+### Artifacts housekeeping
+
+Artifacts housekeeping is the process that identifies which artifacts are expired
+and can be deleted.
+
+#### Housekeeping disabled in GitLab 14.6 to 15.2
+
+Artifact housekeeping was disabled in GitLab 14.6. It was significantly improved
+in GitLab 14.10, and the changes were back ported to patch versions of GitLab 14.6 and later,
+introduced behind [feature flags](feature_flags.md) disabled by default. The flags were
+enabled by default [in GitLab 15.3](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92931).
+
+If artifacts housekeeping does not seem to be working in GitLab 14.6 to GitLab 15.2,
+you should check if the feature flags are enabled.
+
+To check if the feature flags are enabled:
+
+1. Start a [Rails console](operations/rails_console.md#starting-a-rails-console-session).
+
+1. Check if the feature flags are enabled.
+
+   - GitLab 14.10 and earlier:
+
+     ```ruby
+     Feature.enabled?(:ci_detect_wrongly_expired_artifacts, default_enabled: :yaml)
+     Feature.enabled?(:ci_update_unlocked_job_artifacts, default_enabled: :yaml)
+     Feature.enabled?(:ci_job_artifacts_backlog_work, default_enabled: :yaml)
+     ```
+
+   - GitLab 15.0 and later:
+
+     ```ruby
+     Feature.enabled?(:ci_detect_wrongly_expired_artifacts)
+     Feature.enabled?(:ci_update_unlocked_job_artifacts)
+     Feature.enabled?(:ci_job_artifacts_backlog_work)
+     ```
+
+1. If any of the feature flags are disabled, enable them:
+
+   ```ruby
+   Feature.enable(:ci_detect_wrongly_expired_artifacts)
+   Feature.enable(:ci_update_unlocked_job_artifacts)
+   Feature.enable(:ci_destroy_unlocked_job_artifacts)
+   ```
+
+These changes include switching artifacts from `unlocked` to `locked` if
+they [should be retained](../ci/jobs/job_artifacts.md#keep-artifacts-from-most-recent-successful-jobs).
+
+#### Artifacts with `unknown` status
+
+Artifacts created before housekeeping was updated have a status of `unknown`. After they expire,
+these artifacts are not processed by the new housekeeping.
+
+You can check the database to confirm if your instance has artifacts with the `unknown` status:
+
+1. Start a database console:
+
+   ::Tabs
+
+   :::TabTitle Linux package (Omnibus)
+
+   ```shell
+   sudo gitlab-psql
+   ```
+
+   :::TabTitle Helm chart (Kubernetes)
+
+   ```shell
+   # Find the toolbox pod
+   kubectl --namespace <namespace> get pods -lapp=toolbox
+   # Connect to the PostgreSQL console
+   kubectl exec -it <toolbox-pod-name> -- /srv/gitlab/bin/rails dbconsole --include-password --database main
+   ```
+
+   :::TabTitle Docker
+
+   ```shell
+   sudo docker exec -it <container_name> /bin/bash
+   gitlab-psql
+   ```
+
+   :::TabTitle Self-compiled (source)
+
+   ```shell
+   sudo -u git -H psql -d gitlabhq_production
+   ```
+
+   ::EndTabs
+
+1. Run the following query:
+
+   ```sql
+   select expire_at, file_type, locked, count(*) from ci_job_artifacts
+   where expire_at is not null and
+   file_type != 3
+   group by expire_at, file_type, locked having count(*) > 1;
+   ```
+
+If records are returned, then there are artifacts which the housekeeping job
+is unable to process. For example:
+
+```plaintext
+           expire_at           | file_type | locked | count
+-------------------------------+-----------+--------+--------
+ 2021-06-21 22:00:00+00        |         1 |      2 |  73614
+ 2021-06-21 22:00:00+00        |         2 |      2 |  73614
+ 2021-06-21 22:00:00+00        |         4 |      2 |   3522
+ 2021-06-21 22:00:00+00        |         9 |      2 |     32
+ 2021-06-21 22:00:00+00        |        12 |      2 |    163
+```
+
+Artifacts with locked status `2` are `unknown`. Check
+[issue #346261](https://gitlab.com/gitlab-org/gitlab/-/issues/346261#note_1028871458)
+for more details.
+
+#### Clean up `unknown` artifacts
+
+The Sidekiq worker that processes all `unknown` artifacts is enabled by default in
+GitLab 15.3 and later. It analyzes the artifacts returned by the above database query and
+determines which should be `locked` or `unlocked`. Artifacts are then deleted
+by that worker if needed.
+
+The worker can be enabled on self-managed instances running GitLab 14.10 and later:
+
+1. Start a [Rails console](operations/rails_console.md#starting-a-rails-console-session).
+
+1. Check if the feature is enabled.
+
+   - GitLab 14.10:
+
+     ```ruby
+     Feature.enabled?(:ci_job_artifacts_backlog_work, default_enabled: :yaml)
+     ```
+
+   - GitLab 15.0 and later:
+
+     ```ruby
+     Feature.enabled?(:ci_job_artifacts_backlog_work)
+     ```
+
+1. Enable the feature, if needed:
+
+   ```ruby
+   Feature.enable(:ci_job_artifacts_backlog_work)
+   ```
+
+The worker processes 10,000 `unknown` artifacts every seven minutes, or roughly two million
+in 24 hours.
+
+There is a related `ci_job_artifacts_backlog_large_loop_limit` feature flag
+which causes the worker to process `unknown` artifacts
+[in batches that are five times larger](https://gitlab.com/gitlab-org/gitlab/-/issues/356319).
+This flag is not recommended for use on self-managed instances.
+
+### List projects and builds with artifacts with a specific expiration (or no expiration)
+
+Using a [Rails console](operations/rails_console.md), you can find projects that have job artifacts with either:
+
+- No expiration date.
+- An expiration date more than 7 days in the future.
+
+Similar to [deleting artifacts](#delete-job-artifacts-from-jobs-completed-before-a-specific-date), use the following example time frames
+and alter them as needed:
+
+- `7.days.from_now`
+- `10.days.from_now`
+- `2.weeks.from_now`
+- `3.months.from_now`
+
+Each of the following scripts also limits the search to 50 results with `.limit(50)`, but this number can also be changed as needed:
+
+```ruby
+# Find builds & projects with artifacts that never expire
+builds_with_artifacts_that_never_expire = Ci::Build.with_downloadable_artifacts.where(artifacts_expire_at: nil).limit(50)
+builds_with_artifacts_that_never_expire.find_each do |build|
+  puts "Build with id #{build.id} has artifacts that don't expire and belongs to project #{build.project.full_path}"
+end
+
+# Find builds & projects with artifacts that expire after 7 days from today
+builds_with_artifacts_that_expire_in_a_week = Ci::Build.with_downloadable_artifacts.where('artifacts_expire_at > ?', 7.days.from_now).limit(50)
+builds_with_artifacts_that_expire_in_a_week.find_each do |build|
+  puts "Build with id #{build.id} has artifacts that expire at #{build.artifacts_expire_at} and belongs to project #{build.project.full_path}"
+end
+```
+
+### List projects by total size of job artifacts stored
+
+List the top 20 projects, sorted by the total size of job artifacts stored, by
+running the following code in the Rails console (`sudo gitlab-rails console`):
+
+```ruby
+include ActionView::Helpers::NumberHelper
+ProjectStatistics.order(build_artifacts_size: :desc).limit(20).each do |s|
+  puts "#{number_to_human_size(s.build_artifacts_size)} \t #{s.project.full_path}"
+end
+```
+
+You can change the number of projects listed by modifying `.limit(20)` to the
+number you want.
+
+### List largest artifacts in a single project
+
+List the 50 largest job artifacts in a single project by running the following
+code in the Rails console (`sudo gitlab-rails console`):
+
+```ruby
+include ActionView::Helpers::NumberHelper
+project = Project.find_by_full_path('path/to/project')
+Ci::JobArtifact.where(project: project).order(size: :desc).limit(50).map { |a| puts "ID: #{a.id} - #{a.file_type}: #{number_to_human_size(a.size)}" }
+```
+
+You can change the number of job artifacts listed by modifying `.limit(50)` to
+the number you want.
+
+### List artifacts in a single project
+
+List the artifacts for a single project, sorted by artifact size. The output includes the:
+
+- ID of the job that created the artifact
+- artifact size
+- artifact file type
+- artifact creation date
+- on-disk location of the artifact
+
+```ruby
+p = Project.find_by_id(<project_id>)
+arts = Ci::JobArtifact.where(project: p)
+
+list = arts.order(size: :desc).limit(50).each do |art|
+    puts "Job ID: #{art.job_id} - Size: #{art.size}b - Type: #{art.file_type} - Created: #{art.created_at} - File loc: #{art.file}"
+end
+```
+
+To change the number of job artifacts listed, change the number in `limit(50)`.
+
+### Delete job artifacts from jobs completed before a specific date
+
+WARNING:
+These commands remove data permanently from both the database and from disk. Before running them, we highly recommend seeking guidance from a Support Engineer, or running them in a test environment with a backup of the instance ready to be restored, just in case.
+
+If you need to manually remove job artifacts associated with multiple jobs while
+**retaining their job logs**, this can be done from the Rails console (`sudo gitlab-rails console`):
+
+1. Select jobs to be deleted:
+
+   To select all jobs with artifacts for a single project:
+
+   ```ruby
+   project = Project.find_by_full_path('path/to/project')
+   builds_with_artifacts =  project.builds.with_downloadable_artifacts
+   ```
+
+   To select all jobs with artifacts across the entire GitLab instance:
+
+   ```ruby
+   builds_with_artifacts = Ci::Build.with_downloadable_artifacts
+   ```
+
+1. Delete job artifacts older than a specific date:
+
+   NOTE:
+   This step also erases artifacts that users have chosen to
+   ["keep"](../ci/jobs/job_artifacts.md#download-job-artifacts).
+
+   ```ruby
+   builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
+   builds_to_clear.find_each do |build|
+     Ci::JobArtifacts::DeleteService.new(build).execute
+     build.update!(artifacts_expire_at: Time.now)
+   end
+   ```
+
+   In [GitLab 15.3 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/372537), use the following instead:
+
+   ```ruby
+   builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
+   builds_to_clear.find_each do |build|
+     build.artifacts_expire_at = Time.now
+     build.erase_erasable_artifacts!
+   end
+   ```
+
+   `1.week.ago` is a Rails `ActiveSupport::Duration` method which calculates a new
+   date or time in the past. Other valid examples are:
+
+   - `7.days.ago`
+   - `3.months.ago`
+   - `1.year.ago`
+
+   `erase_erasable_artifacts!` is a synchronous method, and upon execution the artifacts are immediately removed;
+   they are not scheduled by a background queue.
+
+### Delete job artifacts and logs from jobs completed before a specific date
+
+WARNING:
+These commands remove data permanently from both the database and from disk. Before running them, we highly recommend seeking guidance from a Support Engineer, or running them in a test environment with a backup of the instance ready to be restored, just in case.
+
+If you need to manually remove **all** job artifacts associated with multiple jobs,
+**including job logs**, this can be done from the Rails console (`sudo gitlab-rails console`):
+
+1. Select the jobs to be deleted:
+
+   To select jobs with artifacts for a single project:
+
+   ```ruby
+   project = Project.find_by_full_path('path/to/project')
+   builds_with_artifacts =  project.builds.with_downloadable_artifacts
+   ```
+
+   To select jobs with artifacts across the entire GitLab instance:
+
+   ```ruby
+   builds_with_artifacts = Ci::Build.with_downloadable_artifacts
+   ```
+
+   Occasionally, when choosing jobs with artifacts, there could be a risk of the process being terminated due to selecting a large number of rows. This can result in high memory usage and eventually lead to the process being killed due to an Out-of-Memory (OOM) error. To resolve this, you can run in small batches. The example below limits each batch to 1000.
+
+   To select jobs with artifacts for a single project:
+
+   ```ruby
+   project = Project.find_by_full_path('path/to/project')
+   builds_with_artifacts =  project.builds.with_downloadable_artifacts.find_each(batch_size: 1000)
+   ```
+
+   To select jobs with artifacts across the entire GitLab instance:
+
+   ```ruby
+   builds_with_artifacts = Ci::Build.with_downloadable_artifacts.find_each(batch_size: 1000)
+   ```
+
+1. Select the user which is mentioned in the web UI as erasing the job:
+
+   ```ruby
+   admin_user = User.find_by(username: 'username')
+   ```
+
+1. Erase the job artifacts and logs older than a specific date:
+
+   ```ruby
+   builds_to_clear = builds_with_artifacts.where("finished_at < ?", 1.week.ago)
+   builds_to_clear.find_each do |build|
+     print "Ci::Build ID #{build.id}... "
+
+     if build.erasable?
+       Ci::BuildEraseService.new(build, admin_user).execute
+       puts "Erased"
+     else
+       puts "Skipped (Nothing to erase or not erasable)"
+     end
+   end
+   ```
+
+   In [GitLab 15.3 and earlier](https://gitlab.com/gitlab-org/gitlab/-/issues/369132), replace
+   `Ci::BuildEraseService.new(build, admin_user).execute` with `build.erase(erased_by: admin_user)`.
+
+   `1.week.ago` is a Rails `ActiveSupport::Duration` method which calculates a new
+   date or time in the past. Other valid examples are:
+
+   - `7.days.ago`
+   - `3.months.ago`
+   - `1.year.ago`
+
+## Job artifact upload fails with error 500
+
+If you are using object storage for artifacts and a job artifact fails to upload,
+review:
+
+- The job log for an error message similar to:
+
+  ```plaintext
+  WARNING: Uploading artifacts as "archive" to coordinator... failed id=12345 responseStatus=500 Internal Server Error status=500 token=abcd1234
+  ```
+
+- The [workhorse log](logs/index.md#workhorse-logs) for an error message similar to:
+
+  ```json
+  {"error":"MissingRegion: could not find region configuration","level":"error","msg":"error uploading S3 session","time":"2021-03-16T22:10:55-04:00"}
+  ```
+
+In both cases, you might need to add `region` to the job artifact [object storage configuration](object_storage.md).
+
+## Job artifact upload fails with `500 Internal Server Error (Missing file)`
+
+Bucket names that include folder paths are not supported with [consolidated object storage](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
+For example, `bucket/path`. If a bucket name has a path in it, you might receive an error similar to:
+
+```plaintext
+WARNING: Uploading artifacts as "archive" to coordinator... POST https://gitlab.example.com/api/v4/jobs/job_id/artifacts?artifact_format=zip&artifact_type=archive&expire_in=1+day: 500 Internal Server Error (Missing file)
+FATAL: invalid argument
+```
+
+If a job artifact fails to upload with the above error when using consolidated object storage, make sure you are [using separate buckets](object_storage.md#use-separate-buckets) for each data type.
+
+## Job artifacts fail to upload with `FATAL: invalid argument` when using Windows mount
+
+If you are using a Windows mount with CIFS for job artifacts, you may see an
+`invalid argument` error when the runner attempts to upload artifacts:
+
+```plaintext
+WARNING: Uploading artifacts as "dotenv" to coordinator... POST https://<your-gitlab-instance>/api/v4/jobs/<JOB_ID>/artifacts: 500 Internal Server Error  id=1296 responseStatus=500 Internal Server Error status=500 token=*****
+FATAL: invalid argument
+```
+
+To work around this issue, you can try:
+
+- Switching to an ext4 mount instead of CIFS.
+- Upgrading to at least Linux kernel 5.15 which contains a number of important bug fixes
+  relating to CIFS file leases.
+- For older kernels, using the `nolease` mount option to disable file leasing.
+
+For more information, [see the investigation details](https://gitlab.com/gitlab-org/gitlab/-/issues/389995).
+
+## Usage quota shows incorrect artifact storage usage
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/238536) in GitLab 14.10.
+
+Sometimes the [artifacts storage usage](../user/usage_quotas.md) displays an incorrect
+value for the total storage space used by artifacts. To recalculate the artifact
+usage statistics for all projects in the instance, you can run this background script:
+
+```shell
+bin/rake 'gitlab:refresh_project_statistics_build_artifacts_size[file.csv]'
+```
+
+The artifact usage value can fluctuate to `0` while the script is running. After
+recalculation, usage should display as expected again.
diff --git a/doc/administration/libravatar.md b/doc/administration/libravatar.md
index 1b7406546ef..899269fb9d1 100644
--- a/doc/administration/libravatar.md
+++ b/doc/administration/libravatar.md
@@ -52,7 +52,7 @@ For self-compiled installations:
        ssl_url: https://seccdn.libravatar.org/avatar/%{hash}?s=%{size}&d=identicon"
    ```
 
-1. Save the file, and then [restart](restart_gitlab.md#installations-from-source)
+1. Save the file, and then [restart](restart_gitlab.md#self-compiled-installations)
    GitLab for the changes to take effect.
 
 ## Set the Libravatar service to default (Gravatar)
@@ -65,7 +65,7 @@ For Linux package installations:
 For self-compiled installations:
 
 1. Remove `gravatar:` section from `config/gitlab.yml`.
-1. Save the file, then [restart](restart_gitlab.md#installations-from-source)
+1. Save the file, then [restart](restart_gitlab.md#self-compiled-installations)
    GitLab to apply the changes.
 
 ## Disable Gravatar service
@@ -91,7 +91,7 @@ For self-compiled installations:
        enabled: false
    ```
 
-1. Save the file, then [restart](restart_gitlab.md#installations-from-source)
+1. Save the file, then [restart](restart_gitlab.md#self-compiled-installations)
    GitLab to apply the changes.
 
 ### Your own Libravatar server
diff --git a/doc/administration/logs/index.md b/doc/administration/logs/index.md
index 449f33fbbef..bfab17d37e8 100644
--- a/doc/administration/logs/index.md
+++ b/doc/administration/logs/index.md
@@ -66,6 +66,7 @@ Some of these services have their own environment variables to override the log
 | Sidekiq (server)     | `INFO`    |                      |
 | Snowplow Tracker     | `FATAL`   |                      |
 | gRPC Client (Gitaly) | `WARN`    | `GRPC_LOG_LEVEL`     |
+| LLM                  | `INFO`    | `LLM_DEBUG`          |
 
 ## Log Rotation
 
@@ -466,7 +467,7 @@ only. For example:
 }
 ```
 
-## `audit_json.log` **(FREE)**
+## `audit_json.log` **(FREE ALL)**
 
 NOTE:
 GitLab Free tracks a small number of different audit events.
@@ -552,7 +553,7 @@ For Linux package installations, add the configuration option:
 sidekiq['log_format'] = 'json'
 ```
 
-For installations from source, edit the `gitlab.yml` and set the Sidekiq
+For self-compiled installations, edit the `gitlab.yml` and set the Sidekiq
 `log_format` configuration option:
 
 ```yaml
@@ -819,6 +820,23 @@ This file is located at:
 This structured log file records internal activity in the `mail_room` gem.
 Its name and path are configurable, so the name and path may not match the above.
 
+## `web_hooks.log`
+
+> Introduced in GitLab 16.3.
+
+This file is located at:
+
+- `/var/log/gitlab/gitlab-rails/web_hooks.log` on Linux package installations.
+- `/home/git/gitlab/log/web_hooks.log` on self-compiled installations.
+
+The back-off, disablement, and re-enablement events for Webhook are recorded in this file. For example:
+
+```json
+{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"backoff","disabled_until":"2020-11-24T04:30:59.860Z","backoff_count":2,"recent_failures":2}
+{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"disable","disabled_until":null,"backoff_count":5,"recent_failures":100}
+{"severity":"INFO","time":"2020-11-24T02:30:59.860Z","hook_id":12,"action":"enable","disabled_until":null,"backoff_count":0,"recent_failures":0}
+```
+
 ## Reconfigure logs
 
 Reconfigure log files are in `/var/log/gitlab/reconfigure` for Linux package installations. Self-compiled installations
@@ -951,7 +969,7 @@ For example:
 
 ## `geo.log` **(PREMIUM SELF)**
 
-Geo stores structured log messages in a `geo.log` file. For Omnibus GitLab
+Geo stores structured log messages in a `geo.log` file. For Linux package
 installations, this file is at `/var/log/gitlab/gitlab-rails/geo.log`.
 
 This file contains information about when Geo attempts to sync repositories
@@ -1127,7 +1145,7 @@ GitLab also tracks [Prometheus metrics for Praefect](../gitaly/monitoring.md#mon
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/63832) in GitLab 14.1.
 
-For Omnibus installations, the backup log is located at `/var/log/gitlab/gitlab-rails/backup_json.log`.
+For Linux package installations, the backup log is located at `/var/log/gitlab/gitlab-rails/backup_json.log`.
 
 This log is populated when a [GitLab backup is created](../../administration/backup_restore/index.md). You can use this log to understand how the backup process performed.
 
diff --git a/doc/administration/maintenance_mode/index.md b/doc/administration/maintenance_mode/index.md
index 336067d1891..c5674527291 100644
--- a/doc/administration/maintenance_mode/index.md
+++ b/doc/administration/maintenance_mode/index.md
@@ -173,6 +173,8 @@ Package Registry allows you to install but not publish packages.
 ### Background jobs
 
 Background jobs (cron jobs, Sidekiq) continue running as is, because background jobs are not automatically disabled.
+As background jobs perform operations that can change the internal state of your instance, you may want to disable
+some or all of them while maintenance mode is enabled.
 
 [During a planned Geo failover](../geo/disaster_recovery/planned_failover.md#prevent-updates-to-the-primary-site),
 you should disable all cron jobs except for those related to Geo.
@@ -182,6 +184,7 @@ To monitor queues and disable jobs:
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. On the left sidebar, select **Monitoring > Background Jobs**.
+1. In the Sidekiq dashboard, select **Cron** and disable jobs individually or all at once by selecting **Disable All**.
 
 ### Incident management
 
diff --git a/doc/administration/merge_request_diffs.md b/doc/administration/merge_request_diffs.md
index 00ea1e43600..746dccb99d6 100644
--- a/doc/administration/merge_request_diffs.md
+++ b/doc/administration/merge_request_diffs.md
@@ -62,7 +62,7 @@ For self-compiled installations:
      storage_path: /mnt/storage/external-diffs
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
    GitLab then migrates your existing merge request diffs to external storage.
 
 ## Using object storage
@@ -97,7 +97,7 @@ For self-compiled installations:
    ```
 
 1. Set [object storage settings](#object-storage-settings).
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
    GitLab then migrates your existing merge request diffs to external storage.
 
 [Read more about using object storage with GitLab](object_storage.md).
@@ -108,7 +108,7 @@ In GitLab 13.2 and later, you should use the
 [consolidated object storage settings](object_storage.md#configure-a-single-storage-connection-for-all-object-types-consolidated-form).
 This section describes the earlier configuration format.
 
-For source installations, these settings are nested under `external_diffs:` and
+For self-compiled installations, these settings are nested under `external_diffs:` and
 then `object_store:`. On Linux package installations, they are prefixed by
 `external_diffs_object_store_`.
 
@@ -171,7 +171,7 @@ For self-compiled installations:
          region: eu-central-1
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Alternative in-database storage
 
@@ -203,7 +203,7 @@ For self-compiled installations:
      when: outdated
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 With this feature enabled, diffs are initially stored in the database, rather
 than externally. They are moved to external storage after any of these
diff --git a/doc/administration/monitoring/ip_allowlist.md b/doc/administration/monitoring/ip_allowlist.md
index 364c1b27d33..c5f81e65466 100644
--- a/doc/administration/monitoring/ip_allowlist.md
+++ b/doc/administration/monitoring/ip_allowlist.md
@@ -49,6 +49,6 @@ gitlab:
        - 192.168.0.1
    ```
 
-1. Save the file and [restart](../restart_gitlab.md#installations-from-source) GitLab for the changes to take effect.
+1. Save the file and [restart](../restart_gitlab.md#self-compiled-installations) GitLab for the changes to take effect.
 
 ::EndTabs
diff --git a/doc/administration/monitoring/performance/grafana_configuration.md b/doc/administration/monitoring/performance/grafana_configuration.md
index 8b3720ca8a9..72240be0b35 100644
--- a/doc/administration/monitoring/performance/grafana_configuration.md
+++ b/doc/administration/monitoring/performance/grafana_configuration.md
@@ -4,81 +4,29 @@ group: Respond
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Grafana Configuration **(FREE SELF)**
+# Configure Grafana **(FREE SELF)**
 
-> [Deprecated](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7772) in GitLab 16.0.
-
-WARNING:
-Bundled Grafana was deprecated GitLab 16.0 and is no longer supported. It will be removed in GitLab 16.3.
-For more information, see [deprecation notes](#deprecation-of-bundled-grafana).
+> - Grafana bundled with GitLab was [deprecated](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7772) in GitLab 16.0.
+> - Grafana bundled with GitLab was [removed](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7772) in GitLab 16.3.
 
 [Grafana](https://grafana.com/) is a tool that enables you to visualize time
 series metrics through graphs and dashboards. GitLab writes performance data to Prometheus,
 and Grafana allows you to query the data to display graphs.
 
-## Deprecation of bundled Grafana
-
-Bundled Grafana was an optional service for Linux package installations that provided a user interface to GitLab metrics.
-
-The version of Grafana that is bundled with Linux package installations is no longer supported. If you're using the
-bundled Grafana, you should switch to a newer version from [Grafana Labs](https://grafana.com/grafana/).
-
-### Switch to new Grafana instance
-
-To switch away from bundled Grafana to a newer version of Grafana from Grafana Labs:
-
-1. Set up a version of Grafana from Grafana Labs.
-1. [Export the existing dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#export-a-dashboard) from bundled Grafana.
-1. [Import the existing dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#import-a-dashboard) in the new Grafana instance.
-1. [Configure GitLab](#integrate-with-gitlab-ui) to use the new Grafana instance.
-
-### Temporary workaround
-
-In GitLab versions 16.0 to 16.2, you can still force Linux package installations to enable and configure Grafana by
-setting the following:
-
-- `grafana['enable'] = true`.
-- `grafana['enable_deprecated_service'] = true`.
-
-You see a deprecation message when reconfiguring GitLab.
-
-## Configure Grafana
-
-Prerequisites:
-
-- Grafana installed.
-
-1. Log in to Grafana as the administration user.
-1. Select **Data Sources** from the **Configuration** menu.
-1. Select **Add data source**.
-1. Select the required data source type. For example, [Prometheus](../prometheus/index.md#prometheus-as-a-grafana-data-source).
-1. Complete the details for the data source and select **Save & Test**.
-
-Grafana should indicate the data source is working.
+WARNING:
+Grafana bundled with GitLab was deprecated GitLab 16.0 and removed in GitLab 16.3.
+For more information, see [deprecation notes](#deprecation-of-bundled-grafana).
 
-## Import dashboards
+## Import GitLab dashboards
 
-You can now import a set of default dashboards to start displaying information.
-GitLab has published a set of default
-[Grafana dashboards](https://gitlab.com/gitlab-org/grafana-dashboards) to get you started. To use
-them:
+You can import a set of default dashboards to start displaying information. GitLab has published a set of default
+[Grafana dashboards](https://gitlab.com/gitlab-org/grafana-dashboards) to get you started. To use them:
 
 1. Clone the repository, or download a ZIP file or tarball.
-1. Follow these steps to import each JSON file individually:
-
-   1. Log in to Grafana as the administration user.
-   1. Select **Manage** from the **Dashboards** menu.
-   1. Select **Import**, then **Upload JSON file**.
-   1. Locate the JSON file to import and select **Choose for Upload**. Select **Import**.
-   1. After the dashboard is imported, select the **Save dashboard** icon in the top bar.
+1. Follow these steps to [import each dashboard JSON file individually](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#import-a-dashboard)
 
-If you don't save the dashboard after importing it, the dashboard is removed
-when you navigate away from the page. Repeat this process for each dashboard you wish to import.
-
-Alternatively, you can import all the dashboards into your Grafana
-instance. For more information about this process, see the
-[README of the Grafana dashboards](https://gitlab.com/gitlab-org/grafana-dashboards)
-repository.
+Alternatively, you can import all the dashboards into your Grafana instance. For more information about this process,
+see the [GitLab Grafana dashboards](https://gitlab.com/gitlab-org/grafana-dashboards).
 
 ## Integrate with GitLab UI
 
@@ -92,10 +40,7 @@ GitLab sidebar:
 1. On the left sidebar, select **Settings > Metrics and profiling**
    and expand **Metrics - Grafana**.
 1. Select the **Add a link to Grafana** checkbox.
-1. Configure the **Grafana URL**:
-   - If Grafana is enabled through a Linux package installation and on the same server,
-     leave **Grafana URL** unchanged. It should be `/-/grafana`.
-   - Otherwise, enter the full URL of the Grafana instance.
+1. Configure the **Grafana URL**. Enter the full URL of the Grafana instance.
 1. Select **Save changes**.
 
 GitLab displays your link in the **Main menu > Admin > Monitoring > Metrics Dashboard**.
@@ -120,57 +65,18 @@ configuration screen:
 - No scopes appear.
 - The `read_user` scope is included.
 
-> Versions of GitLab prior 13.10 use the API scope instead of `read_user`. In versions of GitLab
-> prior to 13.10, the API scope:
->
-> - Is required to access Grafana through the GitLab OAuth provider.
-> - Is set by enabling the Grafana application as shown in [Integration with GitLab UI](#integrate-with-gitlab-ui).
-
-## Security Update
-
-Users running GitLab version 12.0 or later should immediately upgrade to one of the
-following security releases due to a known vulnerability with the embedded Grafana dashboard:
-
-- 12.0.6
-- 12.1.6
-
-After upgrading, the Grafana dashboard is disabled, and the location of your
-existing Grafana data is changed from `/var/opt/gitlab/grafana/data/` to
-`/var/opt/gitlab/grafana/data.bak.#{Date.today}/`.
-
-To prevent the data from being relocated, you can run the following command prior to upgrading:
-
-```shell
-echo "0" > /var/opt/gitlab/grafana/CVE_reset_status
-```
-
-To reinstate your old data, move it back into its original location:
-
-```shell
-sudo mv /var/opt/gitlab/grafana/data.bak.xxxx/ /var/opt/gitlab/grafana/data/
-```
-
-However, you should **not** reinstate your old data _except_ under one of the following conditions:
-
-1. If you're certain that you changed your default administration password when you enabled Grafana.
-1. If you run GitLab in a private network, accessed only by trusted users, and your
-   Grafana login page has not been exposed to the internet.
-
-If you require access to your old Grafana data but don't meet one of these criteria, you may consider:
+## Deprecation of bundled Grafana
 
-1. Reinstating it temporarily.
-1. [Exporting the dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#export-and-import-dashboards) you need.
-1. Refreshing the data and [re-importing your dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#export-and-import-dashboards).
+Bundled Grafana was an optional service for Linux package installations that provided a user interface to GitLab metrics.
 
-WARNING:
-These actions pose a temporary vulnerability while your old Grafana data is in use.
-Deciding to take any of these actions should be weighed carefully with your need to access
-existing data and dashboards.
+The version of Grafana that is bundled with Linux package installations is no longer supported. If you're using the
+bundled Grafana, you should switch to a newer version from [Grafana Labs](https://grafana.com/grafana/).
 
-For more information and further mitigation details, refer to our
-[blog post on the security release](https://about.gitlab.com/releases/2019/08/12/critical-security-release-gitlab-12-dot-1-dot-6-released/).
+### Switch to new Grafana instance
 
-Read more on:
+To switch away from bundled Grafana to a newer version of Grafana from Grafana Labs:
 
-- [Introduction to GitLab Performance Monitoring](index.md)
-- [GitLab Configuration](gitlab_configuration.md)
+1. Set up a version of Grafana from Grafana Labs.
+1. [Export the existing dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#export-a-dashboard) from bundled Grafana.
+1. [Import the existing dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#import-a-dashboard) in the new Grafana instance.
+1. [Configure GitLab](#integrate-with-gitlab-ui) to use the new Grafana instance.
diff --git a/doc/administration/monitoring/prometheus/gitlab_exporter.md b/doc/administration/monitoring/prometheus/gitlab_exporter.md
index 22b73378cab..f4bc387cc8e 100644
--- a/doc/administration/monitoring/prometheus/gitlab_exporter.md
+++ b/doc/administration/monitoring/prometheus/gitlab_exporter.md
@@ -12,7 +12,7 @@ The [GitLab exporter](https://gitlab.com/gitlab-org/gitlab-exporter) enables you
 measure various GitLab metrics pulled from Redis and the database in Linux package
 instances.
 
-For installations from source you must install and configure it yourself.
+For self-compiled installations, you must install and configure it yourself.
 
 To enable the GitLab exporter in a Linux package instance:
 
diff --git a/doc/administration/monitoring/prometheus/gitlab_metrics.md b/doc/administration/monitoring/prometheus/gitlab_metrics.md
index 713a1fb3b5d..6566def823c 100644
--- a/doc/administration/monitoring/prometheus/gitlab_metrics.md
+++ b/doc/administration/monitoring/prometheus/gitlab_metrics.md
@@ -15,7 +15,7 @@ To enable the GitLab Prometheus metrics:
 1. Find the **Metrics - Prometheus** section, and select **Enable GitLab Prometheus metrics endpoint**.
 1. [Restart GitLab](../../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
-For installations from source you must configure it yourself.
+For self-compiled installations, you must configure it yourself.
 
 ## Collecting the metrics
 
@@ -170,6 +170,16 @@ The following metrics are available:
 | `gitlab_sli_rails_request_apdex_total` | Counter | 14.4 | Total number of request Apdex measurements. For more information, see [Rails request SLIs](../../../development/application_slis/rails_request.md) | `endpoint_id`, `feature_category`, `request_urgency` |
 | `gitlab_sli_rails_request_apdex_success_total` | Counter | 14.4 | Total number of successful requests that met the target duration for their urgency. Divide by `gitlab_sli_rails_requests_apdex_total` to get a success ratio | `endpoint_id`, `feature_category`, `request_urgency` |
 | `gitlab_sli_rails_request_error_total` | Counter | 15.7 | Total number of request error measurements. For more information, see [Rails request SLIs](../../../development/application_slis/rails_request.md) | `endpoint_id`, `feature_category`, `request_urgency`, `error` |
+| `job_register_attempts_failed_total` | Counter | 9.5 | Counts the times a runner fails to register a job |
+| `job_register_attempts_total` | Counter | 9.5 | Counts the times a runner tries to register a job |
+| `job_queue_duration_seconds` | Histogram | 9.5 | Request handling execution time |
+| `gitlab_ci_queue_operations_total` | Counter | 16.3 | Counts all the operations that are happening inside a queue |
+| `gitlab_ci_queue_depth_total` | Histogram | 16.3 | Size of a CI/CD builds queue in relation to the operation result |
+| `gitlab_ci_queue_size_total` | Histogram | 16.3 | Size of initialized CI/CD builds queue |
+| `gitlab_ci_current_queue_size` | Gauge | 16.3 | Current size of initialized CI/CD builds queue |
+| `gitlab_ci_queue_iteration_duration_seconds` | Histogram | 16.3 | Time it takes to find a build in CI/CD queue |
+| `gitlab_ci_queue_retrieval_duration_seconds` | Histogram | 16.3 | Time it takes to execute a SQL query to retrieve builds queue |
+| `gitlab_ci_queue_active_runners_total` | Histogram | 16.3 | The amount of active runners that can process queue in a project |
 
 ## Metrics controlled by a feature flag
 
@@ -178,6 +188,13 @@ The following metrics can be controlled by feature flags:
 | Metric                                                         | Feature flag                                                       |
 |:---------------------------------------------------------------|:-------------------------------------------------------------------|
 | `gitlab_view_rendering_duration_seconds`                       | `prometheus_metrics_view_instrumentation`                          |
+| `gitlab_ci_queue_depth_total` | `gitlab_ci_builds_queuing_metrics` |
+| `gitlab_ci_queue_size` | `gitlab_ci_builds_queuing_metrics` |
+| `gitlab_ci_queue_size_total` | `gitlab_ci_builds_queuing_metrics` |
+| `gitlab_ci_queue_iteration_duration_seconds` | `gitlab_ci_builds_queuing_metrics` |
+| `gitlab_ci_current_queue_size` | `gitlab_ci_builds_queuing_metrics` |
+| `gitlab_ci_queue_retrieval_duration_seconds` | `gitlab_ci_builds_queuing_metrics` |
+| `gitlab_ci_queue_active_runners_total` | `gitlab_ci_builds_queuing_metrics` |
 
 ## Praefect metrics
 
@@ -279,12 +296,16 @@ configuration option in `gitlab.yml`. These metrics are served from the
 | `geo_snippet_repositories_synced`              | Gauge   | 13.4  | Number of syncable snippets synced on secondary | `url` |
 | `geo_snippet_repositories_failed`              | Gauge   | 13.4  | Number of syncable snippets failed on secondary | `url` |
 | `geo_snippet_repositories_registry`            | Gauge   | 13.4  | Number of syncable snippets in the registry | `url` |
-| `geo_group_wiki_repositories`                  | Gauge   | 13.10 | Number of group wikis on primary | `url` |
-| `geo_group_wiki_repositories_checksummed`      | Gauge   | 13.10 | Number of group wikis checksummed on primary | `url` |
-| `geo_group_wiki_repositories_checksum_failed`  | Gauge   | 13.10 | Number of group wikis failed to calculate the checksum on primary | `url` |
-| `geo_group_wiki_repositories_synced`           | Gauge   | 13.10 | Number of syncable group wikis synced on secondary | `url` |
-| `geo_group_wiki_repositories_failed`           | Gauge   | 13.10 | Number of syncable group wikis failed on secondary | `url` |
-| `geo_group_wiki_repositories_registry`         | Gauge   | 13.10 | Number of syncable group wikis in the registry | `url` |
+| `geo_group_wiki_repositories`                     | Gauge   | 13.10 | Number of group wikis on primary | `url` |
+| `geo_group_wiki_repositories_checksum_total`      | Gauge   | 16.3  | Number of group wikis to checksum on primary | `url` |
+| `geo_group_wiki_repositories_checksummed`         | Gauge   | 13.10 | Number of group wikis that successfully calculated the checksum on primary | `url` |
+| `geo_group_wiki_repositories_checksum_failed`     | Gauge   | 13.10 | Number of group wikis that failed to calculate the checksum on primary | `url` |
+| `geo_group_wiki_repositories_synced`              | Gauge   | 13.10 | Number of syncable group wikis synced on secondary | `url` |
+| `geo_group_wiki_repositories_failed`              | Gauge   | 13.10 | Number of syncable group wikis failed to sync on secondary | `url` |
+| `geo_group_wiki_repositories_registry`            | Gauge   | 13.10 | Number of group wikis in the registry | `url` |
+| `geo_group_wiki_repositories_verification_total`  | Gauge   | 16.3 | Number of group wikis to attempt to verify on secondary | `url` |
+| `geo_group_wiki_repositories_verified`            | Gauge   | 16.3 | Number of group wikis successfully verified on secondary | `url` |
+| `geo_group_wiki_repositories_verification_failed` | Gauge   | 16.3 | Number of group wikis that failed verification on secondary | `url` |
 | `geo_pages_deployments`                        | Gauge   | 14.3  | Number of pages deployments on primary | `url` |
 | `geo_pages_deployments_checksum_total`         | Gauge   | 14.6  | Number of pages deployments to checksum on primary | `url` |
 | `geo_pages_deployments_checksummed`            | Gauge   | 14.6  | Number of pages deployments that successfully calculated the checksum on primary | `url` |
diff --git a/doc/administration/monitoring/prometheus/index.md b/doc/administration/monitoring/prometheus/index.md
index a9b393aab33..abdd2f1d0d3 100644
--- a/doc/administration/monitoring/prometheus/index.md
+++ b/doc/administration/monitoring/prometheus/index.md
@@ -13,7 +13,7 @@ GitLab provides out-of-the-box monitoring with Prometheus, providing access to h
 GitLab services.
 
 Prometheus and the various exporters listed in this page are bundled in Linux packages. Check each exporter's
-documentation for the timeline they got added. For installations from source you must install them
+documentation for the timeline they got added. For self-compiled installations, you must install them
 yourself. Over subsequent releases additional GitLab metrics are captured.
 
 Prometheus services are on by default.
@@ -31,7 +31,7 @@ dashboard tool like [Grafana](https://grafana.com).
 
 ## Configuring Prometheus
 
-For installations from source, you must install and configure it yourself.
+For self-compiled installations, you must install and configure it yourself.
 
 Prometheus and its exporters are on by default.
 Prometheus runs as the `gitlab-prometheus` user and listen on
diff --git a/doc/administration/monitoring/prometheus/node_exporter.md b/doc/administration/monitoring/prometheus/node_exporter.md
index f4d5d9942ca..4de05034fff 100644
--- a/doc/administration/monitoring/prometheus/node_exporter.md
+++ b/doc/administration/monitoring/prometheus/node_exporter.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 The [node exporter](https://github.com/prometheus/node_exporter) enables you to measure
 various machine resources such as memory, disk and CPU utilization.
 
-For installations from source you must install and configure it yourself.
+For self-compiled installations, you must install and configure it yourself.
 
 To enable the node exporter:
 
diff --git a/doc/administration/monitoring/prometheus/pgbouncer_exporter.md b/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
index a95dc47dc34..6f925cb7fb6 100644
--- a/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
+++ b/doc/administration/monitoring/prometheus/pgbouncer_exporter.md
@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 The [PgBouncer exporter](https://github.com/prometheus-community/pgbouncer_exporter) enables
 you to measure various [PgBouncer](https://www.pgbouncer.org/) metrics.
 
-For installations from source you must install and configure it yourself.
+For self-compiled installations, you must install and configure it yourself.
 
 To enable the PgBouncer exporter:
 
diff --git a/doc/administration/monitoring/prometheus/postgres_exporter.md b/doc/administration/monitoring/prometheus/postgres_exporter.md
index 39f6c81e8d0..20cfb078994 100644
--- a/doc/administration/monitoring/prometheus/postgres_exporter.md
+++ b/doc/administration/monitoring/prometheus/postgres_exporter.md
@@ -8,7 +8,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 The [PostgreSQL Server Exporter](https://github.com/prometheus-community/postgres_exporter) allows you to export various PostgreSQL metrics.
 
-For installations from source you must install and configure it yourself.
+For self-compiled installations, you must install and configure it yourself.
 
 To enable the PostgreSQL Server Exporter:
 
diff --git a/doc/administration/monitoring/prometheus/redis_exporter.md b/doc/administration/monitoring/prometheus/redis_exporter.md
index 5f11034dc15..25c76fac743 100644
--- a/doc/administration/monitoring/prometheus/redis_exporter.md
+++ b/doc/administration/monitoring/prometheus/redis_exporter.md
@@ -10,7 +10,7 @@ The [Redis exporter](https://github.com/oliver006/redis_exporter) enables you to
 various [Redis](https://redis.io) metrics. For more information on what is exported,
 [read the upstream documentation](https://github.com/oliver006/redis_exporter/blob/master/README.md#whats-exported).
 
-For installations from source you must install and configure it yourself.
+For self-compiled installations, you must install and configure it yourself.
 
 To enable the Redis exporter:
 
diff --git a/doc/administration/nfs.md b/doc/administration/nfs.md
index 0273c4b03b1..119f757bfbc 100644
--- a/doc/administration/nfs.md
+++ b/doc/administration/nfs.md
@@ -60,10 +60,10 @@ options:
   a good security measure when NFS shares are accessed by many different
   users. However, in this case only GitLab uses the NFS share so it
   is safe. GitLab recommends the `no_root_squash` setting because we need to
-  manage file permissions automatically. Without the setting you may receive
-  errors when the Omnibus package tries to alter permissions. GitLab
+  manage file permissions automatically. Without the setting, you may receive
+  errors when the Linux package tries to alter permissions. GitLab
   and other bundled components do **not** run as `root` but as non-privileged
-  users. The recommendation for `no_root_squash` is to allow the Omnibus package
+  users. The recommendation for `no_root_squash` is to allow the Linux package
   to set ownership and permissions on files, as needed. In some cases where the
   `no_root_squash` option is not available, the `root` flag can achieve the same
   result.
@@ -71,7 +71,7 @@ options:
   circumstances it could lead to data loss if a failure occurs before data has
   synced.
 
-Due to the complexities of running Omnibus with LDAP and the complexities of
+Due to the complexities of running the Linux package with LDAP and the complexities of
 maintaining ID mapping without LDAP, in most cases you should enable numeric UIDs
 and GIDs (which is off by default in some cases) for simplified permission
 management between systems:
@@ -210,10 +210,10 @@ mountpoint
     └── uploads
 ```
 
-To do so, configure Omnibus with the paths to each directory nested
+To do so, configure the Linux package with the paths to each directory nested
 in the mount point as follows:
 
-Mount `/gitlab-nfs` then use the following Omnibus
+Mount `/gitlab-nfs` then use the following Linux package
 configuration to move each data location to a subdirectory:
 
 ```ruby
@@ -229,7 +229,7 @@ these new locations, and then restart GitLab.
 
 ### Bind mounts
 
-Alternatively to changing the configuration in Omnibus, bind mounts can be used
+Instead of changing the configuration in the Linux package, bind mounts can be used
 to store the data on an NFS mount.
 
 Bind mounts provide a way to specify just one NFS mount and then
@@ -252,7 +252,7 @@ are empty before attempting a restore. Read more about the
 
 ### Multiple NFS mounts
 
-When using default Omnibus configuration you need to share 4 data locations
+When using default Linux package configuration, you need to share 4 data locations
 between all GitLab cluster nodes. No other locations should be shared. The
 following are the 4 locations need to be shared:
 
@@ -265,8 +265,8 @@ following are the 4 locations need to be shared:
 
 Other GitLab directories should not be shared between nodes. They contain
 node-specific files and GitLab code that does not need to be shared. To ship
-logs to a central location consider using remote syslog. Omnibus GitLab packages
-provide configuration for [UDP log shipping](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only).
+logs to a central location consider using remote syslog. The Linux package
+provides configuration for [UDP log shipping](https://docs.gitlab.com/omnibus/settings/logs.html#udp-log-shipping-gitlab-enterprise-edition-only).
 
 Having multiple NFS mounts requires you to manually make sure the data directories
 are empty before attempting a restore. Read more about the
diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md
index 2bf3ef0275c..aa17452f260 100644
--- a/doc/administration/object_storage.md
+++ b/doc/administration/object_storage.md
@@ -114,7 +114,6 @@ The following table lists the valid `objects` that can be used:
 | `dependency_proxy` | [Dependency Proxy](packages/dependency_proxy.md)                    |
 | `terraform_state`  | [Terraform state files](terraform_state.md)                                |
 | `pages`            | [Pages](pages/index.md)                                             |
-| `ci_secure_files`  | [Project-level Secure Files](secure_files.md)                              |
 
 Within each object type, three parameters can be defined:
 
diff --git a/doc/administration/operations/fast_ssh_key_lookup.md b/doc/administration/operations/fast_ssh_key_lookup.md
index 8382f3aa8b5..270bd778ea3 100644
--- a/doc/administration/operations/fast_ssh_key_lookup.md
+++ b/doc/administration/operations/fast_ssh_key_lookup.md
@@ -25,7 +25,7 @@ GitLab Shell solves this by providing a way to authorize SSH users via a fast,
 indexed lookup in the GitLab database. This page describes how to enable the fast
 lookup of authorized SSH keys.
 
-## Fast lookup is required for Geo **(PREMIUM)**
+## Fast lookup is required for Geo **(PREMIUM ALL)**
 
 Unlike [Cloud Native GitLab](https://docs.gitlab.com/charts/), by default Linux package installations
 manage an `authorized_keys` file that is located in the
@@ -105,7 +105,7 @@ means that GitLab was able to find the key in the database,
 as it is not present in the file.
 
 NOTE:
-For Installations from source, the command would be located at
+For self-compiled installations, the command would be located at
 `/home/git/gitlab-shell/bin/gitlab-shell-authorized-keys-check` if [the install from source](../../install/installation.md#install-gitlab-shell) instructions were followed.
 You might want to consider creating a wrapper script somewhere else, as this command must be
 owned by `root` and not be writable by group or others. You could also consider changing the ownership of this command
diff --git a/doc/administration/operations/gitlab_sshd.md b/doc/administration/operations/gitlab_sshd.md
index 2707c8f08a0..43ca6251a0e 100644
--- a/doc/administration/operations/gitlab_sshd.md
+++ b/doc/administration/operations/gitlab_sshd.md
@@ -112,7 +112,7 @@ To enable the PROXY protocol:
 
    ```ruby
    gitlab_sshd['proxy_protocol'] = true
-   # # Proxy protocol policy ("use", "require", "reject", "ignore"), "use" is the default value
+   # Proxy protocol policy ("use", "require", "reject", "ignore"), "use" is the default value
    gitlab_sshd['proxy_policy'] = "use"
    ```
 
diff --git a/doc/administration/operations/puma.md b/doc/administration/operations/puma.md
index f471dcd44b0..f16f1ac46ae 100644
--- a/doc/administration/operations/puma.md
+++ b/doc/administration/operations/puma.md
@@ -395,7 +395,7 @@ gitlab_rails['env'] = {
 }
 ```
 
-For source installations, set the environment variable.
+For self-compiled installations, set the environment variable.
 Refer to [Puma Worker timeout](../operations/puma.md#change-the-worker-timeout).
 
 [Reconfigure](../restart_gitlab.md#reconfigure-a-linux-package-installation) GitLab for the changes to take effect.
diff --git a/doc/administration/operations/rails_console.md b/doc/administration/operations/rails_console.md
index ac0a7e5870b..b3e7a97428a 100644
--- a/doc/administration/operations/rails_console.md
+++ b/doc/administration/operations/rails_console.md
@@ -508,7 +508,7 @@ def disable_two_factor!
       otp_grace_period_started_at: nil,
       otp_backup_codes:            nil
     )
-    self.u2f_registrations.destroy_all # rubocop: disable DestroyAll
+    self.webauthn_registrations.destroy_all # rubocop: disable DestroyAll
   end
 end
 
diff --git a/doc/administration/package_information/postgresql_versions.md b/doc/administration/package_information/postgresql_versions.md
index 101e1549d19..3a499be43b3 100644
--- a/doc/administration/package_information/postgresql_versions.md
+++ b/doc/administration/package_information/postgresql_versions.md
@@ -31,6 +31,7 @@ Read more about update policies and warnings in the PostgreSQL
 
 | GitLab version | PostgreSQL versions | Default version for fresh installs | Default version for upgrades | Notes |
 | -------------- | ------------------- | ---------------------------------- | ---------------------------- | ----- |
+| 16.2.0 | 13.11, 14.8 | 13.11 | 13.11 | For upgrades, users can manually upgrade to 14.8 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-162-and-later). |
 | 16.0.2 | 13.11 | 13.11 | 13.11 | |
 | 16.0.0 | 13.8  | 13.8  | 13.8  | |
 | 15.11.7 | 13.11 | 13.11 | 12.12 | |
diff --git a/doc/administration/package_information/supported_os.md b/doc/administration/package_information/supported_os.md
index 16f4c2cdeab..eea4b8035b7 100644
--- a/doc/administration/package_information/supported_os.md
+++ b/doc/administration/package_information/supported_os.md
@@ -22,7 +22,8 @@ architecture.
 
 | OS Version                                                   | First supported GitLab version | Arch            |                         Install Documentation                | OS EOL     | Details                                                      |
 | ------------------------------------------------------------ | ------------------------------ | --------------- | :----------------------------------------------------------: | ---------- | ------------------------------------------------------------ |
-| AlmaLinux 8                                                  | GitLab CE / GitLab EE 14.5.0   | x86_64, aarch64 | [AlmaLinux Install Documentation](https://about.gitlab.com/install/#almalinux-8) | 2029       | <https://almalinux.org/>                                     |
+| AlmaLinux 8                                                  | GitLab CE / GitLab EE 14.5.0   | x86_64, aarch64 | [AlmaLinux Install Documentation](https://about.gitlab.com/install/#almalinux) | 2029       | <https://almalinux.org/>                                     |
+| AlmaLinux 9                                                  | GitLab CE / GitLab EE 16.0.0   | x86_64, aarch64 | [AlmaLinux Install Documentation](https://about.gitlab.com/install/#almalinux) | 2032       | <https://almalinux.org/>                                     |
 | CentOS 7                                                     | GitLab CE / GitLab EE 7.10.0   | x86_64          | [CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | June 2024  | <https://wiki.centos.org/About/Product>                      |
 | Debian 10                                                    | GitLab CE / GitLab EE 12.2.0   | amd64, arm64    | [Debian Install Documentation](https://about.gitlab.com/install/#debian) | 2024       | <https://wiki.debian.org/LTS>                                |
 | Debian 11                                                    | GitLab CE / GitLab EE 14.6.0   | amd64, arm64    | [Debian Install Documentation](https://about.gitlab.com/install/#debian) | 2026       | <https://wiki.debian.org/LTS>                                |
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index 007072647a2..384df9a6e6a 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -75,7 +75,7 @@ Where:
 | `issuer`  | This should be the same value as configured in Registry's `issuer`. Read the [token auth configuration documentation](https://docs.docker.com/registry/configuration/#token). |
 
 A Registry init file is not shipped with GitLab if you install it from source.
-Hence, [restarting GitLab](../restart_gitlab.md#installations-from-source) does not restart the Registry should
+Hence, [restarting GitLab](../restart_gitlab.md#self-compiled-installations) does not restart the Registry should
 you modify its settings. Read the upstream documentation on how to achieve that.
 
 At the **absolute** minimum, make sure your [Registry configuration](https://docs.docker.com/registry/configuration/#auth)
@@ -187,7 +187,7 @@ registry_nginx['listen_port'] = 5678
      port: 5050
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
 
 ::EndTabs
@@ -256,7 +256,7 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
      host: registry.gitlab.example.com
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
 
 ::EndTabs
@@ -296,7 +296,7 @@ Registry application itself.
      enabled: false
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -334,7 +334,7 @@ the Container Registry by themselves, follow the steps below.
      container_registry: false
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -427,7 +427,7 @@ The default location where images are stored in self-compiled installations is
      path: shared/registry
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -443,7 +443,9 @@ GitLab does not back up Docker images that are not stored on the
 file system. Enable backups with your object storage provider if
 desired.
 
-#### Linux package installations
+#### Configure `s3` and `gcs` storage drivers for Linux package installations
+
+The following configuration steps are for the `s3` and `gcs` storage drivers. Other [storage drivers](#configure-storage-for-the-container-registry) are supported.
 
 To configure the `s3` storage driver for a Linux package installation:
 
@@ -515,6 +517,25 @@ To configure the `s3` storage driver for a Linux package installation:
 
 1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
+To configure the `gcs` storage driver for a Linux package installation:
+
+1. Edit `/etc/gitlab/gitlab.rb`:
+
+   ```ruby
+      registry['storage'] = {
+      'gcs' => {
+        'bucket' => 'BUCKET_NAME',
+        'keyfile' => 'PATH/TO/KEYFILE',
+        # If you have the bucket shared with other apps beyond the registry, uncomment the following:
+        # 'rootdirectory' => '/gcs/object/name/prefix'
+      }
+    }
+   ```
+
+   GitLab supports all [available parameters](https://docs.docker.com/registry/storage-drivers/gcs/).
+
+1. Save the file and [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
+
 #### Self-compiled installations
 
 Configuring the storage driver is done in the registry configuration YAML file created
@@ -705,7 +726,7 @@ However, this behavior is undesirable for registries used by internal hosts that
        enabled: true
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -756,7 +777,7 @@ on how you installed GitLab. Follow the instructions here that match your instal
        encrypt: true
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source)
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
 ::EndTabs
@@ -911,7 +932,7 @@ You can use GitLab as an auth endpoint with an external container registry.
 
    [Read more](#enable-the-container-registry) about what these parameters mean.
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Configure Container Registry notifications
 
@@ -1486,7 +1507,7 @@ Start with a value between `25000000` (25 MB) and `50000000` (50 MB).
        chunksize: 25000000
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -1572,7 +1593,7 @@ and a simple solution would be to enable relative URLs in the Registry.
        relativeurls: true
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -1618,7 +1639,7 @@ this error appears:
 
 - `Error response from daemon: manifest invalid: Schema 1 manifest not supported`
 
-For Self-Managed GitLab instances, you can regain access to these images by temporarily downgrading
+For self-managed GitLab instances, you can regain access to these images by temporarily downgrading
 the GitLab Container Registry to a version lower than `v3.0.0-gitlab`. Follow these steps to regain
 access to these images:
 
@@ -1671,7 +1692,7 @@ For Linux package installations:
 
 :::TabTitle Self-compiled (source)
 
-For source installations, locate your `registry` binary and temporarily replace it with the one
+Locate your `registry` binary and temporarily replace it with the one
 obtained from `v3.0.0-gitlab`, as explained for Linux package installations.
 Make sure to start by backing up the original registry binary, and restore it after performing the
 [images upgrade](#images-upgrade) steps.
diff --git a/doc/administration/packages/dependency_proxy.md b/doc/administration/packages/dependency_proxy.md
index ee352a82058..f84703b63e7 100644
--- a/doc/administration/packages/dependency_proxy.md
+++ b/doc/administration/packages/dependency_proxy.md
@@ -67,7 +67,7 @@ For more information, see [Configure Charts using Globals](https://docs.gitlab.c
      enabled: false
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -115,7 +115,7 @@ installations under `shared/dependency_proxy/` (relative to the Git home directo
      storage_path: shared/dependency_proxy
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -193,7 +193,7 @@ This section describes the earlier configuration format. [Migration steps still
          #  path_style: false                    # If true, use 'host/bucket_name/object' instead of 'bucket_name.host/object'.
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ::EndTabs
 
@@ -211,7 +211,7 @@ to remote storage. The processing is done in a background worker and requires no
   sudo gitlab-rake "gitlab:dependency_proxy:migrate"
   ```
 
-- For installations from source:
+- For self-compiled installations:
 
   ```shell
   RAILS_ENV=production sudo -u git -H bundle exec rake gitlab:dependency_proxy:migrate
diff --git a/doc/administration/packages/index.md b/doc/administration/packages/index.md
index 77730384623..2eb3da4b5d7 100644
--- a/doc/administration/packages/index.md
+++ b/doc/administration/packages/index.md
@@ -196,6 +196,13 @@ To change the local storage path:
 
 ::EndTabs
 
+If you already had packages stored in the old storage path, move everything
+from the old to the new location to ensure existing packages stay accessible:
+
+```shell
+mv /var/opt/gitlab/gitlab-rails/shared/packages/* /mnt/packages/
+```
+
 Docker and Kubernetes do not use local storage.
 
 - For the Helm chart (Kubernetes): Use object storage instead.
diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md
index 726307229d6..c84e5eb8c8c 100644
--- a/doc/administration/pages/index.md
+++ b/doc/administration/pages/index.md
@@ -350,7 +350,7 @@ world. Custom domains are supported, but no TLS.
 **Requirements:**
 
 - [Wildcard DNS setup](#dns-configuration)
-- Wildcard TLS certificate
+- TLS certificate. Can be either Wildcard, or any other type meeting the [requirements](../../user/project/pages/custom_domains_ssl_tls_certification/index.md#manual-addition-of-ssltls-certificates).
 - Secondary IP
 
 ---
@@ -527,11 +527,11 @@ fails to work if the custom CA is not recognized.
 This usually results in this error:
 `Post /oauth/token: x509: certificate signed by unknown authority`.
 
-For installation from source, this can be fixed by installing the custom Certificate
-Authority (CA) in the system certificate store.
-
 For Linux package installations, this is fixed by [installing a custom CA](https://docs.gitlab.com/omnibus/settings/ssl/index.html#install-custom-public-certificates).
 
+For self-compiled installations, this can be fixed by installing the custom Certificate
+Authority (CA) in the system certificate store.
+
 ### ZIP serving and cache configuration
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-pages/-/merge_requests/392) in GitLab 13.7.
@@ -968,7 +968,7 @@ See [the available connection settings for different providers](../object_storag
          region: eu-central-1
    ```
 
-1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source)
+1. Save the file and [restart GitLab](../restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
 1. [Migrate existing Pages deployments to object storage.](#migrate-pages-deployments-to-object-storage)
diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md
index 26dedd47473..97dacfc1902 100644
--- a/doc/administration/pages/source.md
+++ b/doc/administration/pages/source.md
@@ -183,8 +183,8 @@ The Pages daemon doesn't listen to the outside world.
    sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages.conf
    ```
 
-1. Restart NGINX
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. Restart NGINX.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ### Wildcard domains with TLS support
 
@@ -240,8 +240,8 @@ outside world.
    sudo ln -sf /etc/nginx/sites-{available,enabled}/gitlab-pages-ssl.conf
    ```
 
-1. Restart NGINX
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. Restart NGINX.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ## Advanced configuration
 
@@ -310,8 +310,8 @@ world. Custom domains are supported, but no TLS.
 1. Edit all GitLab related configurations in `/etc/nginx/site-available/` and replace
    `0.0.0.0` with `192.0.2.1`, where `192.0.2.1` the primary IP where GitLab
    listens to.
-1. Restart NGINX
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. Restart NGINX.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ### Custom domains with TLS support
 
@@ -378,13 +378,13 @@ world. Custom domains and TLS are supported.
 1. Edit all GitLab related configurations in `/etc/nginx/site-available/` and replace
    `0.0.0.0` with `192.0.2.1`, where `192.0.2.1` the primary IP where GitLab
    listens to.
-1. Restart NGINX
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. Restart NGINX.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ## NGINX caveats
 
 NOTE:
-The following information applies only for installations from source.
+The following information applies only to self-compiled installations.
 
 Be extra careful when setting up the domain name in the NGINX configuration. You must
 not remove the backslashes.
@@ -438,7 +438,7 @@ Pages access control is disabled by default. To enable it:
      access_control: true
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source).
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations).
 1. Create a new [system OAuth application](../../integration/oauth_provider.md#create-a-user-owned-application).
    This should be called `GitLab Pages` and have a `Redirect URL` of
    `https://projects.example.io/auth`. It does not need to be a "trusted"
@@ -471,7 +471,7 @@ are stored.
      path: /mnt/storage/pages
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source)
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations).
 
 ## Set maximum Pages size
 
diff --git a/doc/administration/pages/troubleshooting.md b/doc/administration/pages/troubleshooting.md
index 7e184631515..a103c793763 100644
--- a/doc/administration/pages/troubleshooting.md
+++ b/doc/administration/pages/troubleshooting.md
@@ -212,8 +212,13 @@ Once added, reconfigure with `sudo gitlab-ctl reconfigure` and restart GitLab wi
 
 You may see this error if `pages_external_url` was updated at some point of time. Verify the following:
 
-1. The **Callback URL**/Redirect URI in the GitLab Pages [System OAuth application](../../integration/oauth_provider.md#create-an-instance-wide-application)
-is using the protocol (HTTP or HTTPS) that `pages_external_url` is configured to use.
+1. Check the [System OAuth application](../../integration/oauth_provider.md#create-an-instance-wide-application):
+
+   1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+   1. Select **Admin Area**.
+   1. Select **Applications** and then **Add new application**.
+   1. Ensure the **Callback URL/Redirect URI** is using the protocol (HTTP or HTTPS) that
+      `pages_external_url` is configured to use.
 1. The domain and path components of `Redirect URI` are valid: they should look like `projects.<pages_external_url>/auth`.
 
 ## 500 error `cannot serve from disk`
diff --git a/doc/administration/postgresql/external.md b/doc/administration/postgresql/external.md
index 9c44d53213b..a9f857d8f00 100644
--- a/doc/administration/postgresql/external.md
+++ b/doc/administration/postgresql/external.md
@@ -17,7 +17,9 @@ If you use a cloud-managed service, or provide your own PostgreSQL instance:
 
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
-1. Set up a `gitlab` user with a password of your choice, create the `gitlabhq_production` database, and make the user an owner of the database. You can see an example of this setup in the [installation from source documentation](../../install/installation.md#7-database).
+1. Set up a `gitlab` user with a password of your choice, create the `gitlabhq_production` database, and make the user an
+   owner of the database. You can see an example of this setup in the
+   [self-compiled installation documentation](../../install/installation.md#7-database).
 1. If you are using a cloud-managed service, you may need to grant additional
    roles to your `gitlab` user:
    - Amazon RDS requires the [`rds_superuser`](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.html#Appendix.PostgreSQL.CommonDBATasks.Roles) role.
diff --git a/doc/administration/postgresql/multiple_databases.md b/doc/administration/postgresql/multiple_databases.md
index 5dcb080d707..9e5e34d930c 100644
--- a/doc/administration/postgresql/multiple_databases.md
+++ b/doc/administration/postgresql/multiple_databases.md
@@ -41,7 +41,7 @@ databases. Some examples:
 To migrate existing data from the `main` database to the `ci` database, you can
 copy the database across.
 
-### Existing source installation
+### Existing self-compiled installation
 
 1. Stop GitLab, except for PostgreSQL:
 
@@ -98,7 +98,7 @@ You must stop GitLab before setting up multiple databases. This prevents
 split-brain situations, where `main` data is written to the `ci` database, and
 the other way around.
 
-### Installations from source
+### Self-compiled installations
 
 1. For existing installations,
    [migrate the data](#migrate-existing-installations) first.
diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index 05ff6fa8a4a..c547e5c3638 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 # PostgreSQL replication and failover for Linux package installations **(PREMIUM SELF)**
 
 If you're a Free user of GitLab self-managed, consider using a cloud-hosted solution.
-This document doesn't cover installations from source.
+This document doesn't cover self-compiled installations.
 
 If a setup with replication and failover isn't what you were looking for, see
 the [database configuration document](https://docs.gitlab.com/omnibus/settings/database.html)
diff --git a/doc/administration/raketasks/maintenance.md b/doc/administration/raketasks/maintenance.md
index c2c6429ba8b..87cce30723e 100644
--- a/doc/administration/raketasks/maintenance.md
+++ b/doc/administration/raketasks/maintenance.md
@@ -33,24 +33,23 @@ System:         Ubuntu 20.04
 Proxy:          no
 Current User:   git
 Using RVM:      no
-Ruby Version:   2.6.6p146
-Gem Version:    2.7.10
-Bundler Version:1.17.3
-Rake Version:   12.3.3
-Redis Version:  5.0.9
-Git Version:    2.27.0
-Sidekiq Version:5.2.9
+Ruby Version:   2.7.6p219
+Gem Version:    3.1.6
+Bundler Version:2.3.15
+Rake Version:   13.0.6
+Redis Version:  6.2.7
+Sidekiq Version:6.4.2
 Go Version:     unknown
 
 GitLab information
-Version:        13.2.2-ee
-Revision:       618883a1f9d
+Version:        15.5.5-ee
+Revision:       5f5109f142d
 Directory:      /opt/gitlab/embedded/service/gitlab-rails
 DB Adapter:     PostgreSQL
-DB Version:     11.7
-URL:            http://gitlab.example.com
-HTTP Clone URL: http://gitlab.example.com/some-group/some-project.git
-SSH Clone URL:  git@gitlab.example.com:some-group/some-project.git
+DB Version:     13.8
+URL:            https://app.gitaly.gcp.gitlabsandbox.net
+HTTP Clone URL: https://app.gitaly.gcp.gitlabsandbox.net/some-group/some-project.git
+SSH Clone URL:  git@app.gitaly.gcp.gitlabsandbox.net:some-group/some-project.git
 Elasticsearch:  no
 Geo:            no
 Using LDAP:     no
@@ -58,10 +57,20 @@ Using Omniauth: yes
 Omniauth Providers:
 
 GitLab Shell
-Version:    13.3.0
+Version:        14.12.0
 Repository storage paths:
-- default:  /var/opt/gitlab/git-data/repositories
-GitLab Shell path:      /opt/gitlab/embedded/service/gitlab-shell
+- default:      /var/opt/gitlab/git-data/repositories
+- gitaly:       /var/opt/gitlab/git-data/repositories
+GitLab Shell path:              /opt/gitlab/embedded/service/gitlab-shell
+
+
+Gitaly
+- default Address:      unix:/var/opt/gitlab/gitaly/gitaly.socket
+- default Version:      15.5.5
+- default Git Version:  2.37.1.gl1
+- gitaly Address:       tcp://10.128.20.6:2305
+- gitaly Version:       15.5.5
+- gitaly Git Version:   2.37.1.gl1
 ```
 
 ## Show GitLab license information **(PREMIUM SELF)**
@@ -234,7 +243,7 @@ clear Redis' cache. To do this, run:
 Sometimes during version upgrades you might end up with some wrong CSS or
 missing some icons. In that case, try to precompile the assets again.
 
-This Rake task only applies to source installations. [Read more](../../update/package/index.md#missing-asset-files)
+This Rake task only applies to self-compiled installations. [Read more](../../update/package/index.md#missing-asset-files)
 about troubleshooting this problem when running the Linux package.
 The guidance for Linux package might be applicable for Kubernetes and Docker
 deployments of GitLab, though in general, container-based installations
@@ -399,6 +408,26 @@ task cleans up the temporary indexes.
 - The time it takes for database index rebuilding to complete depends on the size
 of the target database. It can take between several hours and several days.
 
+## Dump the database schema
+
+In rare circumstances, the database schema can differ from what the application code expects
+even if all database migrations are complete. If this does occur, it can lead to odd errors
+in GitLab.
+
+To dump the database schema:
+
+```shell
+SCHEMA=/tmp/structure.sql gitlab-rake db:schema:dump
+```
+
+The Rake task creates a `/tmp/structure.sql` file that contains the database schema dump.
+
+To determine if there are any differences:
+
+1. Go to the [`db/structure.sql`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/db/structure.sql) file in the [`gitlab`](https://gitlab.com/gitlab-org/gitlab) project.
+   Select the branch that matches your GitLab version. For example, the file for GitLab 16.2: <https://gitlab.com/gitlab-org/gitlab/-/blob/16-2-stable-ee/db/structure.sql>.
+1. Compare `/tmp/structure.sql` with the `db/structure.sql` file for your version.
+
 ## Import common metrics
 
 Sometimes you may need to re-import the common metrics that power the Metrics dashboards.
diff --git a/doc/administration/raketasks/service_desk_email.md b/doc/administration/raketasks/service_desk_email.md
index 9bf0846fef2..8d8585bb171 100644
--- a/doc/administration/raketasks/service_desk_email.md
+++ b/doc/administration/raketasks/service_desk_email.md
@@ -12,7 +12,7 @@ The following are Service Desk email-related Rake tasks.
 
 ## Secrets
 
-GitLab can use [Service Desk email](../../user/project/service_desk.md#configure-service-desk-alias-email) secrets read from an encrypted file instead of storing them in plaintext in the file system. The following Rake tasks are provided for updating the contents of the encrypted file.
+GitLab can use [Service Desk email](../../user/project/service_desk/index.md#configure-service-desk-alias-email) secrets read from an encrypted file instead of storing them in plaintext in the file system. The following Rake tasks are provided for updating the contents of the encrypted file.
 
 ### Show secret
 
diff --git a/doc/administration/redis/index.md b/doc/administration/redis/index.md
index 31ea879b289..ad5aca37830 100644
--- a/doc/administration/redis/index.md
+++ b/doc/administration/redis/index.md
@@ -11,32 +11,31 @@ Based on your infrastructure setup and how you have installed GitLab, there are
 multiple ways to configure Redis.
 
 You can choose to install and manage Redis and Sentinel yourself, use a hosted
-cloud solution, or you can use the ones that come bundled with the Omnibus GitLab
+cloud solution, or you can use the ones that come bundled with the Linux
 packages so you can only focus on configuration. Pick the one that suits your needs.
 
-## Redis replication and failover using Omnibus GitLab
+## Redis replication and failover using the Linux package
 
 This setup is for when you have installed GitLab using the
-[Omnibus GitLab **Enterprise Edition** (EE) package](https://about.gitlab.com/install/?version=ee).
+[Linux **Enterprise Edition** (EE) package](https://about.gitlab.com/install/?version=ee).
 
-Both Redis and Sentinel are bundled in the package, so you can it to set up the whole
-Redis infrastructure (primary, replica and sentinel).
+Both Redis and Sentinel are bundled in the package, so you can use it to set up the whole Redis infrastructure (primary,
+replica and sentinel).
 
-[> Read how to set up Redis replication and failover using Omnibus GitLab](replication_and_failover.md)
+For more information, see [Redis replication and failover with the Linux package](replication_and_failover.md).
 
 ## Redis replication and failover using the non-bundled Redis
 
-This setup is for when you have installed GitLab using the
-[Omnibus GitLab packages](https://about.gitlab.com/install/) (CE or EE),
-or installed it [from source](../../install/installation.md), but you want to use
-your own external Redis and sentinel servers.
+This setup is for when you have either a [Linux package](https://about.gitlab.com/install/) installation or a
+[self-compiled installation](../../install/installation.md), but you want to use your own external Redis and Sentinel
+servers.
 
-[> Read how to set up Redis replication and failover using the non-bundled Redis](replication_and_failover_external.md)
+For more information, see [Redis replication and failover providing your own instance](replication_and_failover_external.md).
 
-## Standalone Redis using Omnibus GitLab
+## Standalone Redis using the Linux package
 
 This setup is for when you have installed the
-[Omnibus GitLab **Community Edition** (CE) package](https://about.gitlab.com/install/?version=ce)
+[Linux **Community Edition** (CE) package](https://about.gitlab.com/install/?version=ce)
 to use the bundled Redis, so you can use the package with only the Redis service enabled.
 
-[> Read how to set up a standalone Redis instance using Omnibus GitLab](standalone.md)
+For more information, see [Standalone Redis using the Linux package](standalone.md).
diff --git a/doc/administration/redis/replication_and_failover.md b/doc/administration/redis/replication_and_failover.md
index 1db5b82e7dc..82b9a33d2c6 100644
--- a/doc/administration/redis/replication_and_failover.md
+++ b/doc/administration/redis/replication_and_failover.md
@@ -5,13 +5,11 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Redis replication and failover with Omnibus GitLab **(PREMIUM SELF)**
+# Redis replication and failover with the Linux package **(PREMIUM SELF)**
 
-NOTE:
-This is the documentation for the Omnibus GitLab packages. For using your own
-non-bundled Redis, follow the [relevant documentation](replication_and_failover_external.md).
+This documentation is for the Linux package. To use your own
+non-bundled Redis, see [Redis replication and failover providing your own instance](replication_and_failover_external.md).
 
-NOTE:
 In Redis lingo, `primary` is called `master`. In this document, `primary` is used
 instead of `master`, except the settings where `master` is required.
 
@@ -73,7 +71,7 @@ whole cluster down, invalidating the failover effort.
 
 ## Recommended setup
 
-For a minimal setup, you need to install the Omnibus GitLab package in `3`
+For a minimal setup, you need to install the Linux package in `3`
 **independent** machines, both with **Redis** and **Sentinel**:
 
 - Redis Primary + Sentinel
@@ -85,7 +83,7 @@ from, read [Redis setup overview](#redis-setup-overview) and
 [Sentinel setup overview](#sentinel-setup-overview).
 
 For a recommended setup that can resist more failures, you need to install
-the Omnibus GitLab package in `5` **independent** machines, both with
+the Linux package in `5` **independent** machines, both with
 **Redis** and **Sentinel**:
 
 - Redis Primary + Sentinel
@@ -241,9 +239,9 @@ If you fail to replicate first, you may loose data (unprocessed background jobs)
 ### Step 1. Configuring the primary Redis instance
 
 1. SSH into the **Primary** Redis server.
-1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package you want using **steps 1 and 2** from the GitLab downloads page.
-   - Make sure you select the correct Omnibus package, with the same version
+   - Make sure you select the correct Linux package, with the same version
      and type (Community, Enterprise editions) of your current install.
    - Do not complete any other steps on the download page.
 
@@ -285,9 +283,9 @@ Read more about [roles](https://docs.gitlab.com/omnibus/roles/).
 ### Step 2. Configuring the replica Redis instances
 
 1. SSH into the **replica** Redis server.
-1. [Download/install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package you want using **steps 1 and 2** from the GitLab downloads page.
-   - Make sure you select the correct Omnibus package, with the same version
+   - Make sure you select the correct Linux package, with the same version
      and type (Community, Enterprise editions) of your current install.
    - Do not complete any other steps on the download page.
 
@@ -361,19 +359,17 @@ You must have at least `3` Redis Sentinel servers, and they need to
 be each in an independent machine. You can configure them in the same
 machines where you've configured the other Redis servers.
 
-With GitLab Enterprise Edition, you can use the Omnibus package to set up
+With GitLab Enterprise Edition, you can use the Linux package to set up
 multiple machines with the Sentinel daemon.
 
----
-
 1. SSH into the server that hosts Redis Sentinel.
 1. **You can omit this step if the Sentinels is hosted in the same node as
    the other Redis instances.**
 
-   [Download/install](https://about.gitlab.com/install/) the
-   Omnibus GitLab Enterprise Edition package using **steps 1 and 2** from the
+   [Download and install](https://about.gitlab.com/install/) the
+   Linux Enterprise Edition package using **steps 1 and 2** from the
    GitLab downloads page.
-   - Make sure you select the correct Omnibus package, with the same version
+   - Make sure you select the correct Linux package, with the same version
      the GitLab application is running.
    - Do not complete any other steps on the download page.
 
@@ -644,12 +640,11 @@ gitlab_rails['redis_sentinels'] = [
 
 ## Advanced configuration
 
-Omnibus GitLab configures some things behind the curtains to make the sysadmins'
-lives easier. If you want to know what happens underneath keep reading.
+This section covers configuration options that go beyond the recommended and minimal configurations.
 
 ### Running multiple Redis clusters
 
-Omnibus GitLab supports running separate Redis and Sentinel instances for different
+The Linux package supports running separate Redis and Sentinel instances for different
 persistence classes.
 
 | Class          | Purpose                                          |
diff --git a/doc/administration/redis/replication_and_failover_external.md b/doc/administration/redis/replication_and_failover_external.md
index 14378b478da..54d13991f3f 100644
--- a/doc/administration/redis/replication_and_failover_external.md
+++ b/doc/administration/redis/replication_and_failover_external.md
@@ -11,7 +11,7 @@ If you're hosting GitLab on a cloud provider, you can optionally use a managed
 service for Redis. For example, AWS offers ElastiCache that runs Redis.
 
 Alternatively, you may opt to manage your own Redis instance separate from the
-Omnibus GitLab package.
+Linux package.
 
 ## Requirements
 
@@ -52,7 +52,7 @@ Note the Redis node's IP address or hostname, port, and password (if required).
 
 This is the documentation for configuring a scalable Redis setup when
 you have installed Redis all by yourself and not using the bundled one that
-comes with the Omnibus packages, although using the Omnibus GitLab packages is
+comes with the Linux packages, although using the Linux packages is
 highly recommend as we optimize them specifically for GitLab, and we take
 care of upgrading Redis to the latest supported version.
 
@@ -63,7 +63,7 @@ settings outlined in
 
 We cannot stress enough the importance of reading the
 [replication and failover](replication_and_failover.md) documentation of the
-Omnibus Redis HA as it provides some invaluable information to the configuration
+Linux package Redis HA because it provides some invaluable information to the configuration
 of Redis. Read it before going forward with this guide.
 
 Before proceeding on setting up the new Redis instances, here are some
@@ -79,9 +79,8 @@ requirements:
 - If you are using Redis with Sentinel, you also need to define the same
   password for the replica password definition (`masterauth`) in the same instance.
 
-In addition, read the prerequisites as described in the
-[Omnibus Redis document](replication_and_failover.md#requirements) since they provide some
-valuable information for the general setup.
+In addition, read the prerequisites as described in
+[Redis replication and failover with the Linux package](replication_and_failover.md#requirements).
 
 ### Step 1. Configuring the primary Redis instance
 
@@ -237,7 +236,7 @@ which ideally should not have Redis or Sentinels in the same machine:
          port: 26379  # point to sentinel, not to redis port
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Example of minimal configuration with 1 primary, 2 replicas and 3 sentinels
 
@@ -362,7 +361,7 @@ or a failover promotes a different **Primary** node.
          port: 26379  # point to sentinel, not to redis port
    ```
 
-1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Troubleshooting
 
diff --git a/doc/administration/redis/standalone.md b/doc/administration/redis/standalone.md
index 703601cda42..b9d00b92f95 100644
--- a/doc/administration/redis/standalone.md
+++ b/doc/administration/redis/standalone.md
@@ -5,9 +5,9 @@ group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Standalone Redis using Omnibus GitLab **(FREE SELF)**
+# Standalone Redis using the Linux package **(FREE SELF)**
 
-The Omnibus GitLab package can be used to configure a standalone Redis server.
+The Linux package can be used to configure a standalone Redis server.
 In this configuration, Redis is not scaled, and represents a single
 point of failure. However, in a scaled environment the objective is to allow
 the environment to handle more users or to increase throughput. Redis itself
@@ -18,10 +18,10 @@ page for an overview of GitLab scaling options.
 ## Set up the standalone Redis instance
 
 The steps below are the minimum necessary to configure a Redis server with
-Omnibus GitLab:
+the Linux package:
 
 1. SSH into the Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package you want by using **steps 1 and 2** from the GitLab downloads page.
    Do not complete any other steps on the download page.
 
diff --git a/doc/administration/redis/troubleshooting.md b/doc/administration/redis/troubleshooting.md
index 947db2c1d4e..5f0be709d78 100644
--- a/doc/administration/redis/troubleshooting.md
+++ b/doc/administration/redis/troubleshooting.md
@@ -88,11 +88,9 @@ You must make sure you are defining the same value in `redis['master_name']`
 and `redis['master_password']` as you defined for your sentinel node.
 
 The way the Redis connector `redis-rb` works with sentinel is a bit
-non-intuitive. We try to hide the complexity in omnibus, but it still requires
+non-intuitive. We try to hide the complexity in the Linux package, but it still requires
 a few extra configurations.
 
----
-
 To make sure your configuration is correct:
 
 1. SSH into your GitLab application server
@@ -135,7 +133,7 @@ To make sure your configuration is correct:
    You should see a different port after a few seconds delay
    (the failover/reconnect time).
 
-## Troubleshooting a non-bundled Redis with an installation from source
+## Troubleshooting a non-bundled Redis with a self-compiled installation
 
 If you get an error in GitLab like `Redis::CannotConnectError: No sentinels available.`,
 there may be something wrong with your configuration files or it can be related
diff --git a/doc/administration/reference_architectures/10k_users.md b/doc/administration/reference_architectures/10k_users.md
index e9a77d15a6c..c94c76c6532 100644
--- a/doc/administration/reference_architectures/10k_users.md
+++ b/doc/administration/reference_architectures/10k_users.md
@@ -427,9 +427,9 @@ The following IPs will be used as an example:
 To configure Consul:
 
 1. SSH in to the server that will host Consul.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-   package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+1. [Download and install](https://about.gitlab.com/install/) the Linux
+   package of your choice. Be sure to follow _only_ installation steps 1 and 2
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -453,8 +453,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -504,19 +504,19 @@ A reputable provider or solution should be used for this. [Google Cloud SQL](htt
 
 If you use a third party external service:
 
-1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. These components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. The number of nodes required to achieve HA may differ depending on the service compared to the Linux package and doesn't need to match accordingly.
 1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
-### Standalone PostgreSQL using Omnibus GitLab
+### Standalone PostgreSQL using the Linux package
 
-The recommended Omnibus GitLab configuration for a PostgreSQL cluster with
+The recommended Linux package configuration for a PostgreSQL cluster with
 replication and failover requires:
 
 - A minimum of three PostgreSQL nodes.
@@ -596,9 +596,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # available database connections.
    patroni['postgresql']['max_wal_senders'] = 7
 
-   # Incoming recommended value for max connections is 500. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   patroni['postgresql']['max_connections'] = 500
-
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
@@ -653,8 +650,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.
 For more information, see 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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -726,8 +723,6 @@ The following IPs will be used as an example:
          password: '<pgbouncer_password_hash>'
       }
    }
-   # Incoming recommended value for max db connections is 150. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   pgbouncer['max_db_connections'] = 150
 
    # Configure Consul agent
    consul['watchers'] = %w(postgresql)
@@ -742,8 +737,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -851,9 +846,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configure the primary Redis Cache node
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-   package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+1. [Download and install](https://about.gitlab.com/install/) the Linux
+   package of your choice. Be sure to follow _only_ installation steps 1 and 2
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -916,17 +911,17 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Cache nodes
 
 1. SSH in to the **replica** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-   package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+1. [Download and install](https://about.gitlab.com/install/) the Linux
+   package of your choice. Be sure to follow _only_ installation steps 1 and 2
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add same contents as the primary node in the previous section replacing `redis_master_node` with `redis_replica_node`:
 
@@ -989,8 +984,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
@@ -1016,9 +1011,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configure the primary Redis Persistent node
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-   package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+1. [Download and install](https://about.gitlab.com/install/) the Linux
+   package of your choice. Be sure to follow _only_ installation steps 1 and 2
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -1071,17 +1066,17 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Persistent nodes
 
 1. SSH in to the **replica** Redis Persistent server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-   package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+1. [Download and install](https://about.gitlab.com/install/) the Linux
+   package of your choice. Be sure to follow _only_ installation steps 1 and 2
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -1134,8 +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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
@@ -1191,7 +1186,7 @@ Praefect, the routing and transaction manager for Gitaly Cluster, requires its o
 If you want to have a highly available setup, Praefect requires a third-party PostgreSQL database.
 A built-in solution is being [worked on](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 
-#### Praefect non-HA PostgreSQL standalone using Omnibus GitLab
+#### Praefect non-HA PostgreSQL standalone using the Linux package
 
 The following IPs will be used as an example:
 
@@ -1222,7 +1217,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 
    # PostgreSQL configuration
    postgresql['listen_address'] = '0.0.0.0'
-   postgresql['max_connections'] = 500
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1253,8 +1247,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1296,11 +1290,11 @@ After the Praefect PostgreSQL server has been set up, you'll then need to config
 We recommend the user be named `praefect` and the database `praefect_production`, and these can be configured as standard in PostgreSQL.
 The password for the user is the same as the one you configured earlier as `<praefect_postgresql_password>`.
 
-This is how this would work with a Omnibus GitLab PostgreSQL setup:
+This is how this would work with a Linux package PostgreSQL setup:
 
 1. SSH in to the Praefect PostgreSQL node.
 1. Connect to the PostgreSQL server with administrative access.
-   The `gitlab-psql` user should be used here for this as it's added by default in Omnibus.
+   The `gitlab-psql` user should be used here for this as it's added by default in the Linux package.
    The database `template1` is used because it is created by default on all PostgreSQL servers.
 
    ```shell
@@ -1361,7 +1355,7 @@ The following IPs will be used as an example:
 To configure the Praefect nodes, on each one:
 
 1. SSH in to the Praefect server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux package
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
@@ -1473,8 +1467,8 @@ Updates to example must be made at:
    # 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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
@@ -1534,7 +1528,7 @@ The following IPs will be used as an example:
 
 On each node:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page, and _do not_ provide the `EXTERNAL_URL` value.
 1. Edit the Gitaly server node's `/etc/gitlab/gitlab.rb` file to configure
@@ -1656,8 +1650,8 @@ Updates to example must be made at:
      }
      ```
 
-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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
@@ -1762,7 +1756,7 @@ examples include the Object storage configuration.
 To configure the Sidekiq nodes, on each one:
 
 1. SSH in to the Sidekiq server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration:
@@ -1774,18 +1768,7 @@ Updates to example must be made at:
 -->
 
    ```ruby
-   # Avoid running unnecessary services on the Sidekiq server
-   gitaly['enable'] = false
-   postgresql['enable'] = false
-   redis['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   gitlab_workhorse['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
-   grafana['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_kas['enable'] = false
+   roles ["sidekiq_role"]
 
    # External URL
    ## This should match the URL of the external load balancer
@@ -1881,8 +1864,8 @@ Updates to example must be made at:
    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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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:
 
@@ -1926,7 +1909,7 @@ The following IPs will be used as an example:
 
 On each node perform the following:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 
@@ -2042,11 +2025,11 @@ 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. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
+1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Linux package node you configured and
    add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown
-   for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring,
+   for your users as they hit the load balanced Rails nodes. If this is the first Linux package 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:
 
@@ -2104,7 +2087,7 @@ the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.htm
 
 ## Configure Prometheus
 
-The Omnibus GitLab package can be used to configure a standalone Monitoring node
+The Linux package can be used to configure a standalone Monitoring node
 running [Prometheus](../monitoring/prometheus/index.md) and
 [Grafana](../monitoring/performance/grafana_configuration.md).
 
@@ -2115,7 +2098,7 @@ The following IP will be used as an example:
 To configure the Monitoring node:
 
 1. SSH in to the Monitoring node.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 
@@ -2214,7 +2197,7 @@ in the future.
 
 ### Enable incremental logging
 
-GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
+GitLab Runner returns job logs in chunks which the Linux package caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
 
 While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
 
@@ -2246,7 +2229,7 @@ Prometheus, and Grafana.
 Hybrid installations leverage the benefits of both cloud native and traditional
 compute deployments. With this, _stateless_ components can benefit from cloud native
 workload management benefits while _stateful_ components are deployed in compute VMs
-with Omnibus to benefit from increased permanence.
+with Linux package installations to benefit from increased permanence.
 
 Refer to the Helm charts [Advanced configuration](https://docs.gitlab.com/charts/advanced/)
 documentation for setup instructions including guidance on what GitLab secrets to sync
@@ -2281,7 +2264,7 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements
 - Nodes configuration is shown as it is forced to ensure pod vCPU / memory ratios and avoid scaling during **performance testing**.
   - In production deployments, there is no need to assign pods to specific nodes. A minimum of three nodes per node group in three different availability zones is strongly recommended to align with resilient cloud architecture practices.
 
-Next are the backend components that run on static compute VMs via Omnibus (or External PaaS
+Next are the backend components that run on static compute VMs using the Linux package (or External PaaS
 services where applicable):
 
 | Service                                  | Nodes | Configuration         | GCP              | AWS          |
diff --git a/doc/administration/reference_architectures/1k_users.md b/doc/administration/reference_architectures/1k_users.md
index adcf8eeb4c6..7f8603f294d 100644
--- a/doc/administration/reference_architectures/1k_users.md
+++ b/doc/administration/reference_architectures/1k_users.md
@@ -92,7 +92,7 @@ cluster alongside your instance, read how to
 
 Cloud Native Hybrid Reference Architecture is an alternative approach where select _stateless_
 components are deployed in Kubernetes via our official [Helm Charts](https://docs.gitlab.com/charts/),
-and _stateful_ components are deployed in compute VMs with Omnibus.
+and _stateful_ components are deployed in compute VMs with the Linux package.
 
 The [2k GitLab Cloud Native Hybrid](2k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (non HA) and [3k GitLab Cloud Native Hybrid](3k_users.md#cloud-native-hybrid-reference-architecture-with-helm-charts-alternative) (HA) reference architectures are the smallest we recommend in Kubernetes.
 For environments that serve fewer users, you can lower the node specs. Depending on your user count, you can lower all suggested node specs as desired. However, it's recommended that you don't go lower than the [general requirements](../../install/requirements.md).
diff --git a/doc/administration/reference_architectures/25k_users.md b/doc/administration/reference_architectures/25k_users.md
index 0e608a953b8..2b91d493145 100644
--- a/doc/administration/reference_architectures/25k_users.md
+++ b/doc/administration/reference_architectures/25k_users.md
@@ -444,9 +444,9 @@ The following IPs will be used as an example:
 To configure Consul:
 
 1. SSH in to the server that will host Consul.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -470,8 +470,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -521,19 +521,19 @@ A reputable provider or solution should be used for this. [Google Cloud SQL](htt
 
 If you use a third party external service:
 
-1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. These components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. The number of nodes required to achieve HA may differ depending on the service compared to the Linux package and doesn't need to match accordingly.
 1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
-### Standalone PostgreSQL using Omnibus GitLab
+### Standalone PostgreSQL using the Linux package
 
-The recommended Omnibus GitLab configuration for a PostgreSQL cluster with
+The recommended Linux package configuration for a PostgreSQL cluster with
 replication and failover requires:
 
 - A minimum of three PostgreSQL nodes.
@@ -613,9 +613,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # available database connections.
    patroni['postgresql']['max_wal_senders'] = 7
 
-   # Incoming recommended value for max connections is 500. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   patroni['postgresql']['max_connections'] = 500
-
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
@@ -670,8 +667,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.
 For more information, see 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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -743,8 +740,6 @@ The following IPs will be used as an example:
          password: '<pgbouncer_password_hash>'
       }
    }
-   # Incoming recommended value for max db connections is 150. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   pgbouncer['max_db_connections'] = 150
 
    # Configure Consul agent
    consul['watchers'] = %w(postgresql)
@@ -759,8 +754,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -868,9 +863,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configure the primary Redis Cache node
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-   package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+1. [Download and install](https://about.gitlab.com/install/) the Linux
+   package of your choice. Be sure to follow _only_ installation steps 1 and 2
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -932,17 +927,17 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Cache nodes
 
 1. SSH in to the **replica** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the same contents as the primary node in the previous section replacing `redis_master_node` with `redis_replica_node`:
 
@@ -1004,8 +999,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1031,9 +1026,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configure the primary Redis Persistent node
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -1086,17 +1081,17 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Persistent nodes
 
 1. SSH in to the **replica** Redis Persistent server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -1152,8 +1147,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1210,7 +1205,7 @@ Praefect, the routing and transaction manager for Gitaly Cluster, requires its o
 If you want to have a highly available setup, Praefect requires a third-party PostgreSQL database.
 A built-in solution is being [worked on](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 
-#### Praefect non-HA PostgreSQL standalone using Omnibus GitLab
+#### Praefect non-HA PostgreSQL standalone using the Linux package
 
 The following IPs will be used as an example:
 
@@ -1241,7 +1236,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 
    # PostgreSQL configuration
    postgresql['listen_address'] = '0.0.0.0'
-   postgresql['max_connections'] = 500
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1272,8 +1266,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1313,11 +1307,11 @@ After the Praefect PostgreSQL server has been set up, you'll then need to config
 We recommend the user be named `praefect` and the database `praefect_production`, and these can be configured as standard in PostgreSQL.
 The password for the user is the same as the one you configured earlier as `<praefect_postgresql_password>`.
 
-This is how this would work with a Omnibus GitLab PostgreSQL setup:
+This is how this would work with a Linux package PostgreSQL setup:
 
 1. SSH in to the Praefect PostgreSQL node.
 1. Connect to the PostgreSQL server with administrative access.
-   The `gitlab-psql` user should be used here for this as it's added by default in Omnibus.
+   The `gitlab-psql` user should be used here for this as it's added by default in the Linux package.
    The database `template1` is used because it is created by default on all PostgreSQL servers.
 
    ```shell
@@ -1378,7 +1372,7 @@ The following IPs will be used as an example:
 To configure the Praefect nodes, on each one:
 
 1. SSH in to the Praefect server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux package
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
@@ -1490,8 +1484,8 @@ Updates to example must be made at:
    # 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+the file of the same name on this server. If this is the first Linux package 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
@@ -1551,7 +1545,7 @@ The following IPs will be used as an example:
 
 On each node:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux package
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page, and _do not_ provide the `EXTERNAL_URL` value.
 1. Edit the Gitaly server node's `/etc/gitlab/gitlab.rb` file to configure
@@ -1673,8 +1667,8 @@ Updates to example must be made at:
      }
      ```
 
-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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
@@ -1779,7 +1773,7 @@ examples include the Object storage configuration.
 To configure the Sidekiq nodes, on each one:
 
 1. SSH in to the Sidekiq server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration:
@@ -1791,18 +1785,7 @@ Updates to example must be made at:
 -->
 
    ```ruby
-   # Avoid running unnecessary services on the Sidekiq server
-   gitaly['enable'] = false
-   postgresql['enable'] = false
-   redis['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   gitlab_workhorse['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
-   grafana['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_kas['enable'] = false
+   roles ["sidekiq_role"]
 
    # External URL
    ## This should match the URL of the external load balancer
@@ -1898,8 +1881,8 @@ Updates to example must be made at:
    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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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:
 
@@ -1945,7 +1928,7 @@ The following IPs will be used as an example:
 
 On each node perform the following:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 
@@ -2061,11 +2044,11 @@ 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. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
+1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Linux package node you configured and
    add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown
-   for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring,
+   for your users as they hit the load balanced Rails nodes. If this is the first Linux package 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:
 
@@ -2123,7 +2106,7 @@ the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.htm
 
 ## Configure Prometheus
 
-The Omnibus GitLab package can be used to configure a standalone Monitoring node
+The Linux package can be used to configure a standalone Monitoring node
 running [Prometheus](../monitoring/prometheus/index.md) and
 [Grafana](../monitoring/performance/grafana_configuration.md).
 
@@ -2134,7 +2117,7 @@ The following IP will be used as an example:
 To configure the Monitoring node:
 
 1. SSH in to the Monitoring node.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 
@@ -2232,7 +2215,7 @@ in the future.
 
 ### Enable incremental logging
 
-GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
+GitLab Runner returns job logs in chunks which the Linux package caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
 
 While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
 
@@ -2264,7 +2247,7 @@ Prometheus, and Grafana.
 Hybrid installations leverage the benefits of both cloud native and traditional
 compute deployments. With this, _stateless_ components can benefit from cloud native
 workload management benefits while _stateful_ components are deployed in compute VMs
-with Omnibus to benefit from increased permanence.
+with Linux package installations to benefit from increased permanence.
 
 Refer to the Helm charts [Advanced configuration](https://docs.gitlab.com/charts/advanced/)
 documentation for setup instructions including guidance on what GitLab secrets to sync
@@ -2299,7 +2282,7 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements
 - Nodes configuration is shown as it is forced to ensure pod vCPU / memory ratios and avoid scaling during **performance testing**.
   - In production deployments, there is no need to assign pods to specific nodes. A minimum of three nodes per node group in three different availability zones is strongly recommended to align with resilient cloud architecture practices.
 
-Next are the backend components that run on static compute VMs via Omnibus (or External PaaS
+Next are the backend components that run on static compute VMs using the Linux package (or External PaaS
 services where applicable):
 
 | Service                                  | Nodes | Configuration          | GCP              | AWS          |
diff --git a/doc/administration/reference_architectures/2k_users.md b/doc/administration/reference_architectures/2k_users.md
index e3e361db133..bd184c372b3 100644
--- a/doc/administration/reference_architectures/2k_users.md
+++ b/doc/administration/reference_architectures/2k_users.md
@@ -253,7 +253,7 @@ A reputable provider or solution should be used for this. [Google Cloud SQL](htt
 
 If you use a third party external service:
 
-1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
@@ -261,10 +261,10 @@ If you use a third party external service:
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
 
-### Standalone PostgreSQL using Omnibus GitLab
+### Standalone PostgreSQL using the Linux package
 
 1. SSH in to the PostgreSQL server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Generate a password hash for PostgreSQL. This assumes you will use the default
@@ -308,8 +308,8 @@ If you use a third party external service:
    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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Note the PostgreSQL node's IP address or hostname, port, and
@@ -336,14 +336,14 @@ You can optionally use a third party external service for Redis as long as it me
 
 A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-### Standalone Redis using Omnibus GitLab
+### Standalone Redis using the Linux package
 
-The Omnibus GitLab package can be used to configure a standalone Redis server.
+The Linux package can be used to configure a standalone Redis server.
 The steps below are the minimum necessary to configure a Redis server with
-Omnibus:
+the Linux package:
 
 1. SSH in to the Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
@@ -367,8 +367,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -432,7 +432,7 @@ installation has two repository storages: `default` and `storage1`.
 
 To configure the Gitaly server, on the server node you want to use for Gitaly:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux package
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page, and _do not_ provide the `EXTERNAL_URL` value.
 1. Edit the Gitaly server node's `/etc/gitlab/gitlab.rb` file to configure
@@ -517,8 +517,8 @@ Updates to example must be made at:
    }
    ```
 
-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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -603,7 +603,7 @@ but this is dependent on workload.
 
 On each node perform the following:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration.
@@ -717,8 +717,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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:
 
@@ -768,12 +768,12 @@ the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.htm
 
 ## Configure Prometheus
 
-The Omnibus GitLab package can be used to configure a standalone Monitoring node
+The Linux package can be used to configure a standalone Monitoring node
 running [Prometheus](../monitoring/prometheus/index.md) and
 [Grafana](../monitoring/performance/grafana_configuration.md):
 
 1. SSH in to the Monitoring node.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
@@ -908,7 +908,7 @@ in the future.
 
 ### Enable incremental logging
 
-GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
+GitLab Runner returns job logs in chunks which the Linux package caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
 
 While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
 
@@ -940,7 +940,7 @@ Prometheus, and Grafana.
 Hybrid installations leverage the benefits of both cloud native and traditional
 compute deployments. With this, _stateless_ components can benefit from cloud native
 workload management benefits while _stateful_ components are deployed in compute VMs
-with Omnibus to benefit from increased permanence.
+with Linux package installations to benefit from increased permanence.
 
 Refer to the Helm charts [Advanced configuration](https://docs.gitlab.com/charts/advanced/)
 documentation for setup instructions including guidance on what GitLab secrets to sync
@@ -979,7 +979,7 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements
 - Nodes configuration is shown as it is forced to ensure pod vCPU / memory ratios and avoid scaling during **performance testing**.
   - In production deployments, there is no need to assign pods to specific nodes. A minimum of three nodes per node group in three different availability zones is strongly recommended to align with resilient cloud architecture practices.
 
-Next are the backend components that run on static compute VMs via Omnibus (or External PaaS
+Next are the backend components that run on static compute VMs using the Linux package (or External PaaS
 services where applicable):
 
 | Service                    | Nodes | Configuration          | GCP             | AWS         |
diff --git a/doc/administration/reference_architectures/3k_users.md b/doc/administration/reference_architectures/3k_users.md
index 4b7563d9d8d..cf2d9667481 100644
--- a/doc/administration/reference_architectures/3k_users.md
+++ b/doc/administration/reference_architectures/3k_users.md
@@ -452,7 +452,7 @@ You can optionally use a third party external service for Redis as long as it me
 
 A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-### Standalone Redis using Omnibus GitLab
+### Standalone Redis using the Linux package
 
 This is the section where we install and set up the new Redis instances.
 
@@ -474,9 +474,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configuring the primary Redis instance
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -518,8 +518,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -552,9 +552,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
 #### Configuring the replica Redis instances
 
 1. SSH in to the **replica** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -603,8 +603,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
@@ -651,9 +651,9 @@ clients to report `NOAUTH Authentication required.`.
 To configure the Sentinel:
 
 1. SSH in to the server that will host Consul/Sentinel.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -739,8 +739,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -791,19 +791,19 @@ A reputable provider or solution should be used for this. [Google Cloud SQL](htt
 
 If you use a third party external service:
 
-1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. The number of nodes required to achieve HA may differ depending on the service compared to the Linux package and doesn't need to match accordingly.
 1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
-### Standalone PostgreSQL using Omnibus GitLab
+### Standalone PostgreSQL using the Linux package
 
-The recommended Omnibus GitLab configuration for a PostgreSQL cluster with
+The recommended Linux package configuration for a PostgreSQL cluster with
 replication and failover requires:
 
 - A minimum of three PostgreSQL nodes.
@@ -883,9 +883,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # available database connections.
    patroni['postgresql']['max_wal_senders'] = 7
 
-   # Incoming recommended value for max connections is 500. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   patroni['postgresql']['max_connections'] = 500
-
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
@@ -940,8 +937,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.
 For more information, see 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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1013,8 +1010,6 @@ The following IPs will be used as an example:
          password: '<pgbouncer_password_hash>'
       }
    }
-   # Incoming recommended value for max db connections is 150. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   pgbouncer['max_db_connections'] = 150
 
    # Configure Consul agent
    consul['watchers'] = %w(postgresql)
@@ -1030,8 +1025,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1138,7 +1133,7 @@ Praefect, the routing and transaction manager for Gitaly Cluster, requires its o
 If you want to have a highly available setup, Praefect requires a third-party PostgreSQL database.
 A built-in solution is being [worked on](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 
-#### Praefect non-HA PostgreSQL standalone using Omnibus GitLab
+#### Praefect non-HA PostgreSQL standalone using the Linux package
 
 The following IPs will be used as an example:
 
@@ -1169,7 +1164,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 
    # PostgreSQL configuration
    postgresql['listen_address'] = '0.0.0.0'
-   postgresql['max_connections'] = 500
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1200,8 +1194,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Follow the [post configuration](#praefect-postgresql-post-configuration).
@@ -1240,11 +1234,11 @@ After the Praefect PostgreSQL server has been set up, you'll then need to config
 We recommend the user be named `praefect` and the database `praefect_production`, and these can be configured as standard in PostgreSQL.
 The password for the user is the same as the one you configured earlier as `<praefect_postgresql_password>`.
 
-This is how this would work with a Omnibus GitLab PostgreSQL setup:
+This is how this would work with a Linux package PostgreSQL setup:
 
 1. SSH in to the Praefect PostgreSQL node.
 1. Connect to the PostgreSQL server with administrative access.
-   The `gitlab-psql` user should be used here for this as it's added by default in Omnibus.
+   The `gitlab-psql` user should be used here for this as it's added by default in the Linux package.
    The database `template1` is used because it is created by default on all PostgreSQL servers.
 
    ```shell
@@ -1305,7 +1299,7 @@ The following IPs will be used as an example:
 To configure the Praefect nodes, on each one:
 
 1. SSH in to the Praefect server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
@@ -1417,8 +1411,8 @@ Updates to example must be made at:
    # 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+the file of the same name on this server. If this is the first Linux package 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
@@ -1478,7 +1472,7 @@ The following IPs will be used as an example:
 
 On each node:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux package
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page, and _do not_ provide the `EXTERNAL_URL` value.
 1. Edit the Gitaly server node's `/etc/gitlab/gitlab.rb` file to configure
@@ -1604,8 +1598,8 @@ Updates to example must be made at:
      }
      ```
 
-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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
@@ -1712,7 +1706,7 @@ The following IPs will be used as an example:
 To configure the Sidekiq nodes, one each one:
 
 1. SSH in to the Sidekiq server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration:
@@ -1724,18 +1718,7 @@ Updates to example must be made at:
 -->
 
    ```ruby
-   # Avoid running unnecessary services on the Sidekiq server
-   gitaly['enable'] = false
-   postgresql['enable'] = false
-   redis['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   gitlab_workhorse['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
-   grafana['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_kas['enable'] = false
+   roles ["sidekiq_role"]
 
    # External URL
    ## This should match the URL of the external load balancer
@@ -1824,8 +1807,8 @@ Updates to example must be made at:
    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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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:
 
@@ -1878,7 +1861,7 @@ examples include the Object storage configuration.
 
 On each node perform the following:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration.
@@ -2011,11 +1994,11 @@ 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. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
+1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Linux package node you configured and
    add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown
-   for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring,
+   for your users as they hit the load balanced Rails nodes. If this is the first Linux package 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:
 
@@ -2080,12 +2063,12 @@ the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.htm
 
 ## Configure Prometheus
 
-The Omnibus GitLab package can be used to configure a standalone Monitoring node
+The Linux package can be used to configure a standalone Monitoring node
 running [Prometheus](../monitoring/prometheus/index.md) and
 [Grafana](../monitoring/performance/grafana_configuration.md):
 
 1. SSH in to the Monitoring node.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
@@ -2197,7 +2180,7 @@ in the future.
 
 ### Enable incremental logging
 
-GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
+GitLab Runner returns job logs in chunks which the Linux package caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
 
 While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
 
@@ -2238,7 +2221,7 @@ but with smaller performance requirements, several modifications can be consider
 - Running select components in reputable Cloud PaaS solutions: Select components of the GitLab setup can instead be run on Cloud Provider PaaS solutions. By doing this, additional dependent components can also be removed:
   - PostgreSQL: Can be run on reputable Cloud PaaS solutions such as Google Cloud SQL or Amazon RDS. In this setup, the PgBouncer and Consul nodes are no longer required:
     - Consul may still be desired if [Prometheus](../monitoring/prometheus/index.md) auto discovery is a requirement, otherwise you would need to [manually add scrape configurations](../monitoring/prometheus/index.md#adding-custom-scrape-configurations) for all nodes.
-      - As Redis Sentinel runs on the same box as Consul in this architecture, it may need to be run on a separate box if Redis is still being run via Omnibus.
+      - As Redis Sentinel runs on the same box as Consul in this architecture, it may need to be run on a separate box if Redis is still being run using the Linux package.
   - Redis: Can be run on reputable Cloud PaaS solutions such as Google Memorystore and AWS ElastiCache. In this setup, the Redis Sentinel is no longer required.
 
 ## Cloud Native Hybrid reference architecture with Helm Charts (alternative)
@@ -2253,7 +2236,7 @@ Prometheus, and Grafana.
 Hybrid installations leverage the benefits of both cloud native and traditional
 compute deployments. With this, _stateless_ components can benefit from cloud native
 workload management benefits while _stateful_ components are deployed in compute VMs
-with Omnibus to benefit from increased permanence.
+with Linux package installations to benefit from increased permanence.
 
 Refer to the Helm charts [Advanced configuration](https://docs.gitlab.com/charts/advanced/)
 documentation for setup instructions including guidance on what GitLab secrets to sync
@@ -2288,7 +2271,7 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements
 - Nodes configuration is shown as it is forced to ensure pod vCPU / memory ratios and avoid scaling during **performance testing**.
   - In production deployments, there is no need to assign pods to specific nodes. A minimum of three nodes per node group in three different availability zones is strongly recommended to align with resilient cloud architecture practices.
 
-Next are the backend components that run on static compute VMs via Omnibus (or External PaaS
+Next are the backend components that run on static compute VMs using the Linux package (or External PaaS
 services where applicable):
 
 | Service                                   | Nodes | Configuration         | GCP             | AWS         |
diff --git a/doc/administration/reference_architectures/50k_users.md b/doc/administration/reference_architectures/50k_users.md
index 6dc7f7affab..2187b0ff02c 100644
--- a/doc/administration/reference_architectures/50k_users.md
+++ b/doc/administration/reference_architectures/50k_users.md
@@ -436,9 +436,9 @@ The following IPs will be used as an example:
 To configure Consul:
 
 1. SSH in to the server that will host Consul.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
-   package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+1. [Download and install](https://about.gitlab.com/install/) the Linux
+   package of your choice. Be sure to follow _only_ installation steps 1 and 2
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -462,8 +462,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -513,19 +513,19 @@ A reputable provider or solution should be used for this. [Google Cloud SQL](htt
 
 If you use a third party external service:
 
-1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. The number of nodes required to achieve HA may differ depending on the service compared to the Linux package and doesn't need to match accordingly.
 1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
-### Standalone PostgreSQL using Omnibus GitLab
+### Standalone PostgreSQL using the Linux package
 
-The recommended Omnibus GitLab configuration for a PostgreSQL cluster with
+The recommended Linux package configuration for a PostgreSQL cluster with
 replication and failover requires:
 
 - A minimum of three PostgreSQL nodes.
@@ -605,9 +605,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # available database connections.
    patroni['postgresql']['max_wal_senders'] = 7
 
-   # Incoming recommended value for max connections is 500. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   patroni['postgresql']['max_connections'] = 500
-
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
@@ -663,8 +660,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.
 For more information, see 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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -736,8 +733,6 @@ The following IPs will be used as an example:
          password: '<pgbouncer_password_hash>'
       }
    }
-   # Incoming recommended value for max db connections is 150. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   pgbouncer['max_db_connections'] = 150
 
    # Configure Consul agent
    consul['watchers'] = %w(postgresql)
@@ -752,8 +747,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -861,9 +856,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configure the primary Redis Cache node
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -926,17 +921,17 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Cache nodes
 
 1. SSH in to the **replica** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the same contents as the primary node in the previous section by replacing `redis_master_node` with `redis_replica_node`:
 
@@ -999,9 +994,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
+   1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package
       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
+      server. If this is the first Linux package node you are configuring then you
       can skip this step.
 
    1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes
@@ -1029,9 +1024,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configure the primary Redis Persistent node
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -1084,17 +1079,17 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 #### Configure the replica Redis Persistent nodes
 
 1. SSH in to the **replica** Redis Persistent server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -1147,8 +1142,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1204,7 +1199,7 @@ Praefect, the routing and transaction manager for Gitaly Cluster, requires its o
 If you want to have a highly available setup, Praefect requires a third-party PostgreSQL database.
 A built-in solution is being [worked on](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 
-#### Praefect non-HA PostgreSQL standalone using Omnibus GitLab
+#### Praefect non-HA PostgreSQL standalone using the Linux package
 
 The following IPs will be used as an example:
 
@@ -1235,7 +1230,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 
    # PostgreSQL configuration
    postgresql['listen_address'] = '0.0.0.0'
-   postgresql['max_connections'] = 500
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1266,8 +1260,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1309,11 +1303,11 @@ After the Praefect PostgreSQL server has been set up, you'll then need to config
 We recommend the user be named `praefect` and the database `praefect_production`, and these can be configured as standard in PostgreSQL.
 The password for the user is the same as the one you configured earlier as `<praefect_postgresql_password>`.
 
-This is how this would work with a Omnibus GitLab PostgreSQL setup:
+This is how this would work with a Linux package PostgreSQL setup:
 
 1. SSH in to the Praefect PostgreSQL node.
 1. Connect to the PostgreSQL server with administrative access.
-   The `gitlab-psql` user should be used here for this as it's added by default in Omnibus.
+   The `gitlab-psql` user should be used here for this as it's added by default in the Linux package.
    The database `template1` is used because it is created by default on all PostgreSQL servers.
 
    ```shell
@@ -1374,7 +1368,7 @@ The following IPs will be used as an example:
 To configure the Praefect nodes, on each one:
 
 1. SSH in to the Praefect server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
@@ -1486,8 +1480,8 @@ Updates to example must be made at:
    # 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+the file of the same name on this server. If this is the first Linux package 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
@@ -1547,7 +1541,7 @@ The following IPs will be used as an example:
 
 On each node:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page, and _do not_ provide the `EXTERNAL_URL` value.
 1. Edit the Gitaly server node's `/etc/gitlab/gitlab.rb` file to configure
@@ -1669,8 +1663,8 @@ Updates to example must be made at:
      }
      ```
 
-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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
@@ -1775,7 +1769,7 @@ examples include the Object storage configuration.
 To configure the Sidekiq nodes, on each one:
 
 1. SSH in to the Sidekiq server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration:
@@ -1787,18 +1781,7 @@ Updates to example must be made at:
 -->
 
    ```ruby
-   # Avoid running unnecessary services on the Sidekiq server
-   gitaly['enable'] = false
-   postgresql['enable'] = false
-   redis['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   gitlab_workhorse['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
-   grafana['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_kas['enable'] = false
+   roles ["sidekiq_role"]
 
    # External URL
    ## This should match the URL of the external load balancer
@@ -1894,8 +1877,8 @@ Updates to example must be made at:
    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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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:
 
@@ -1948,7 +1931,7 @@ The following IPs will be used as an example:
 
 On each node perform the following:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 
@@ -2064,8 +2047,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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
@@ -2122,7 +2105,7 @@ the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.htm
 
 ## Configure Prometheus
 
-The Omnibus GitLab package can be used to configure a standalone Monitoring node
+The Linux package can be used to configure a standalone Monitoring node
 running [Prometheus](../monitoring/prometheus/index.md) and
 [Grafana](../monitoring/performance/grafana_configuration.md).
 
@@ -2133,7 +2116,7 @@ The following IP will be used as an example:
 To configure the Monitoring node:
 
 1. SSH in to the Monitoring node.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 
@@ -2231,7 +2214,7 @@ in the future.
 
 ### Enable incremental logging
 
-GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
+GitLab Runner returns job logs in chunks which the Linux package caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
 
 While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
 
@@ -2263,7 +2246,7 @@ Prometheus, and Grafana.
 Hybrid installations leverage the benefits of both cloud native and traditional
 compute deployments. With this, _stateless_ components can benefit from cloud native
 workload management benefits while _stateful_ components are deployed in compute VMs
-with Omnibus to benefit from increased permanence.
+with Linux package installations to benefit from increased permanence.
 
 Refer to the Helm charts [Advanced configuration](https://docs.gitlab.com/charts/advanced/)
 documentation for setup instructions including guidance on what GitLab secrets to sync
@@ -2289,7 +2272,7 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements
 
 | Service Node Group  | Nodes | Configuration           | GCP             | AWS          | Min Allocatable CPUs and Memory |
 |---------------------|-------|-------------------------|-----------------|--------------|---------------------------------|
-| Webservice          | 16    | 32 vCPU, 28.8 GB memory | `n1-highcpu-32` | `m5.8xlarge` | 510 vCPU, 472 GB memory         |
+| Webservice          | 16    | 32 vCPU, 28.8 GB memory | `n1-highcpu-32` | `c5.9xlarge` | 510 vCPU, 472 GB memory         |
 | Sidekiq             | 4     | 4 vCPU, 15 GB memory    | `n1-standard-4` | `m5.xlarge`  | 15.5 vCPU, 50 GB memory         |
 | Supporting services | 2     | 4 vCPU, 15 GB memory    | `n1-standard-4` | `m5.xlarge`  | 7.75 vCPU, 25 GB memory         |
 
@@ -2298,7 +2281,7 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements
 - Nodes configuration is shown as it is forced to ensure pod vCPU / memory ratios and avoid scaling during **performance testing**.
   - In production deployments, there is no need to assign pods to specific nodes. A minimum of three nodes per node group in three different availability zones is strongly recommended to align with resilient cloud architecture practices.
 
-Next are the backend components that run on static compute VMs via Omnibus (or External PaaS
+Next are the backend components that run on static compute VMs using the Linux package (or External PaaS
 services where applicable):
 
 | Service                                  | Nodes | Configuration          | GCP              | AWS           |
diff --git a/doc/administration/reference_architectures/5k_users.md b/doc/administration/reference_architectures/5k_users.md
index 754a844df3f..2b85426de58 100644
--- a/doc/administration/reference_architectures/5k_users.md
+++ b/doc/administration/reference_architectures/5k_users.md
@@ -446,7 +446,7 @@ You can optionally use a third party external service for Redis as long as it me
 
 A reputable provider or solution should be used for this. [Google Memorystore](https://cloud.google.com/memorystore/docs/redis/redis-overview) and [AWS Elasticache](https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/WhatIs.html) are known to work. However, note that the Redis Cluster mode specifically isn't supported by GitLab. See [Recommended cloud providers and services](index.md#recommended-cloud-providers-and-services) for more information.
 
-### Standalone Redis using Omnibus GitLab
+### Standalone Redis using the Linux package
 
 This is the section where we install and set up the new Redis instances.
 
@@ -468,9 +468,9 @@ a node and change its status from primary to replica (and vice versa).
 #### Configuring the primary Redis instance
 
 1. SSH in to the **Primary** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -512,8 +512,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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -546,9 +546,9 @@ run: redis-exporter: (pid 30075) 76861s; run: log: (pid 29674) 76896s
 #### Configuring the replica Redis instances
 
 1. SSH in to the **replica** Redis server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -597,8 +597,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other replica nodes, and
@@ -645,9 +645,9 @@ clients to report `NOAUTH Authentication required.`.
 To configure the Sentinel:
 
 1. SSH in to the server that hosts Consul/Sentinel.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to both follow _only_ installation steps 1 and 2
-   on the page, and to select the correct Omnibus GitLab package, with the same version
+   on the page, and to select the correct Linux package, with the same version
    and type (Community or Enterprise editions) as your current install.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
 
@@ -733,8 +733,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. Go through the steps again for all the other Consul/Sentinel nodes, and
@@ -784,19 +784,19 @@ A reputable provider or solution should be used for this. [Google Cloud SQL](htt
 
 If you use a third party external service:
 
-1. Note that the HA Omnibus PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
+1. Note that the HA Linux package PostgreSQL setup encompasses PostgreSQL, PgBouncer and Consul. All of these components would no longer be required when using a third party external service.
 1. Set up PostgreSQL according to the
    [database requirements document](../../install/requirements.md#database).
 1. Set up a `gitlab` username with a password of your choice. The `gitlab` user
    needs privileges to create the `gitlabhq_production` database.
 1. Configure the GitLab application servers with the appropriate details.
    This step is covered in [Configuring the GitLab Rails application](#configure-gitlab-rails).
-1. The number of nodes required to achieve HA may differ depending on the service compared to Omnibus and doesn't need to match accordingly.
+1. The number of nodes required to achieve HA may differ depending on the service compared to the Linux package and doesn't need to match accordingly.
 1. However, if [Database Load Balancing](../postgresql/database_load_balancing.md) via Read Replicas is desired for further improved performance it's recommended to follow the node count for the Reference Architecture.
 
-### Standalone PostgreSQL using Omnibus GitLab
+### Standalone PostgreSQL using the Linux package
 
-The recommended Omnibus GitLab configuration for a PostgreSQL cluster with
+The recommended Linux package configuration for a PostgreSQL cluster with
 replication and failover requires:
 
 - A minimum of three PostgreSQL nodes.
@@ -876,9 +876,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
    # available database connections.
    patroni['postgresql']['max_wal_senders'] = 7
 
-   # Incoming recommended value for max connections is 500. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   patroni['postgresql']['max_connections'] = 500
-
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
 
@@ -933,8 +930,8 @@ PostgreSQL, with Patroni managing its failover, defaults to use `pg_rewind` by d
 Like most failover handling methods, this has a small chance of leading to data loss.
 For more information, see 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 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1006,8 +1003,6 @@ The following IPs are used as an example:
          password: '<pgbouncer_password_hash>'
       }
    }
-   # Incoming recommended value for max db connections is 150. See https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5691.
-   pgbouncer['max_db_connections'] = 150
 
    # Configure Consul agent
    consul['watchers'] = %w(postgresql)
@@ -1023,8 +1018,8 @@ The following IPs are 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1131,7 +1126,7 @@ Praefect, the routing and transaction manager for Gitaly Cluster, requires its o
 If you want to have a highly available setup, Praefect requires a third-party PostgreSQL database.
 A built-in solution is being [worked on](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/7292).
 
-#### Praefect non-HA PostgreSQL standalone using Omnibus GitLab
+#### Praefect non-HA PostgreSQL standalone using the Linux package
 
 The following IPs are used as an example:
 
@@ -1162,7 +1157,6 @@ in the second step, do not supply the `EXTERNAL_URL` value.
 
    # PostgreSQL configuration
    postgresql['listen_address'] = '0.0.0.0'
-   postgresql['max_connections'] = 500
 
    # Prevent database migrations from running on upgrade automatically
    gitlab_rails['auto_migrate'] = false
@@ -1193,8 +1187,8 @@ 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. [Reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
@@ -1234,11 +1228,11 @@ After the Praefect PostgreSQL server has been set up, you then need to configure
 We recommend the user be named `praefect` and the database `praefect_production`, and these can be configured as standard in PostgreSQL.
 The password for the user is the same as the one you configured earlier as `<praefect_postgresql_password>`.
 
-This is how this would work with a Omnibus GitLab PostgreSQL setup:
+This is how this would work with a Linux package PostgreSQL setup:
 
 1. SSH in to the Praefect PostgreSQL node.
 1. Connect to the PostgreSQL server with administrative access.
-   The `gitlab-psql` user should be used here for this as it's added by default in Omnibus.
+   The `gitlab-psql` user should be used here for this as it's added by default in the Linux package.
    The database `template1` is used because it is created by default on all PostgreSQL servers.
 
    ```shell
@@ -1299,7 +1293,7 @@ The following IPs are used as an example:
 To configure the Praefect nodes, on each one:
 
 1. SSH in to the Praefect server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit the `/etc/gitlab/gitlab.rb` file to configure Praefect:
@@ -1411,8 +1405,8 @@ Updates to example must be made at:
    # 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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+the file of the same name on this server. If this is the first Linux package 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
@@ -1472,7 +1466,7 @@ The following IPs are used as an example:
 
 On each node:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page, and _do not_ provide the `EXTERNAL_URL` value.
 1. Edit the Gitaly server node's `/etc/gitlab/gitlab.rb` file to configure
@@ -1594,8 +1588,8 @@ Updates to example must be made at:
      }
      ```
 
-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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
 
 1. Save the file, and then [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation).
 
@@ -1700,7 +1694,7 @@ examples include the Object storage configuration.
 To configure the Sidekiq nodes, one each one:
 
 1. SSH in to the Sidekiq server.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux package
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration:
@@ -1712,18 +1706,7 @@ Updates to example must be made at:
 -->
 
    ```ruby
-   # Avoid running unnecessary services on the Sidekiq server
-   gitaly['enable'] = false
-   postgresql['enable'] = false
-   redis['enable'] = false
-   nginx['enable'] = false
-   puma['enable'] = false
-   gitlab_workhorse['enable'] = false
-   prometheus['enable'] = false
-   alertmanager['enable'] = false
-   grafana['enable'] = false
-   gitlab_exporter['enable'] = false
-   gitlab_kas['enable'] = false
+   roles ["sidekiq_role"]
 
    # External URL
    ## This should match the URL of the external load balancer
@@ -1813,8 +1796,8 @@ Updates to example must be made at:
    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. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package 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:
 
@@ -1867,7 +1850,7 @@ examples include the Object storage configuration.
 
 On each node perform the following:
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Create or edit `/etc/gitlab/gitlab.rb` and use the following configuration.
@@ -2003,11 +1986,11 @@ 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. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Omnibus node you configured and
+1. Copy the `/etc/gitlab/gitlab-secrets.json` file from the first Linux package node you configured and add or replace
+   the file of the same name on this server. If this is the first Linux package node you are configuring then you can skip this step.
+1. Copy the SSH host keys (all in the name format `/etc/ssh/ssh_host_*_key*`) from the first Linux package node you configured and
    add or replace the files of the same name on this server. This ensures host mismatch errors aren't thrown
-   for your users as they hit the load balanced Rails nodes. If this is the first Omnibus node you are configuring,
+   for your users as they hit the load balanced Rails nodes. If this is the first Linux package 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:
 
@@ -2072,12 +2055,12 @@ the [HTTPS documentation](https://docs.gitlab.com/omnibus/settings/ssl/index.htm
 
 ## Configure Prometheus
 
-The Omnibus GitLab package can be used to configure a standalone Monitoring node
+The Linux package can be used to configure a standalone Monitoring node
 running [Prometheus](../monitoring/prometheus/index.md) and
 [Grafana](../monitoring/performance/grafana_configuration.md):
 
 1. SSH in to the Monitoring node.
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab
+1. [Download and install](https://about.gitlab.com/install/) the Linux
    package of your choice. Be sure to follow _only_ installation steps 1 and 2
    on the page.
 1. Edit `/etc/gitlab/gitlab.rb` and add the contents:
@@ -2189,7 +2172,7 @@ in the future.
 
 ### Enable incremental logging
 
-GitLab Runner returns job logs in chunks which Omnibus GitLab caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
+GitLab Runner returns job logs in chunks which the Linux package caches temporarily on disk in `/var/opt/gitlab/gitlab-ci/builds` by default, even when using consolidated object storage. With default configuration, this directory needs to be shared through NFS on any GitLab Rails and Sidekiq nodes.
 
 While sharing the job logs through NFS is supported, it's recommended to avoid the need to use NFS by enabling [incremental logging](../job_logs.md#incremental-logging-architecture) (required when no NFS node has been deployed). Incremental logging uses Redis instead of disk space for temporary caching of job logs.
 
@@ -2221,7 +2204,7 @@ Prometheus, and Grafana.
 Hybrid installations leverage the benefits of both cloud native and traditional
 compute deployments. With this, _stateless_ components can benefit from cloud native
 workload management benefits while _stateful_ components are deployed in compute VMs
-with Omnibus to benefit from increased permanence.
+with Linux package installations to benefit from increased permanence.
 
 Refer to the Helm charts [Advanced configuration](https://docs.gitlab.com/charts/advanced/)
 documentation for setup instructions including guidance on what GitLab secrets to sync
@@ -2256,7 +2239,7 @@ the overall makeup as desired as long as the minimum CPU and Memory requirements
 - Nodes configuration is shown as it is forced to ensure pod vCPU / memory ratios and avoid scaling during **performance testing**.
   - In production deployments, there is no need to assign pods to nodes. A minimum of three nodes in three different availability zones is strongly recommended to align with resilient cloud architecture practices.
 
-Next are the backend components that run on static compute VMs via Omnibus (or External PaaS
+Next are the backend components that run on static compute VMs using the Linux package (or External PaaS
 services where applicable):
 
 | Service                                   | Nodes | Configuration         | GCP             | AWS          |
diff --git a/doc/administration/reference_architectures/index.md b/doc/administration/reference_architectures/index.md
index 8fc9fbce119..98bbcc464b8 100644
--- a/doc/administration/reference_architectures/index.md
+++ b/doc/administration/reference_architectures/index.md
@@ -93,7 +93,7 @@ If you still need to have HA for a lower number of users, this can be achieved w
 
 #### Zero Downtime Upgrades
 
-[Zero Downtime Upgrades](../../update/zero_downtime.md) are available for standard Reference Architecture environments with HA (Cloud Native Hybrid is not supported at this time). This allows for an environment to stay up during an upgrade, but the process is more complex as a result and has some limitations as detailed in the documentation.
+[Zero Downtime Upgrades](../../update/zero_downtime.md) are available for standard Reference Architecture environments with HA (Cloud Native Hybrid is [not supported](https://gitlab.com/groups/gitlab-org/cloud-native/-/epics/52)). This allows for an environment to stay up during an upgrade, but the process is more complex as a result and has some limitations as detailed in the documentation.
 
 When going through this process it's worth noting that there may still be brief moments of downtime when the HA mechanisms take effect.
 
@@ -268,7 +268,7 @@ Through testing and real life usage, the Reference Architectures are validated a
 </thead>
 <tbody>
   <tr>
-    <td>Omnibus</td>
+    <td>Linux package</td>
     <td>🟢</td>
     <td>🟢</td>
     <td>🟡<sup>1</sup></td>
diff --git a/doc/administration/repository_checks.md b/doc/administration/repository_checks.md
index 8cc635b50fc..1a33b6b5746 100644
--- a/doc/administration/repository_checks.md
+++ b/doc/administration/repository_checks.md
@@ -93,6 +93,10 @@ If periodic repository checks cause false alarms, you can clear all repository c
 1. Expand the **Repository maintenance** section.
 1. Select **Clear all repository checks**.
 
+## Troubleshooting
+
+When working with repository checks, you might encounter the following issues.
+
 ### Error: `failed to parse commit <commit SHA> from object database for commit-graph`
 
 You can see a `failed to parse commit <commit SHA> from object database for commit-graph` error in repository check logs. This error occurs if your `commit-graph` cache is out
diff --git a/doc/administration/repository_storage_paths.md b/doc/administration/repository_storage_paths.md
index 9967b623773..c09c88ee020 100644
--- a/doc/administration/repository_storage_paths.md
+++ b/doc/administration/repository_storage_paths.md
@@ -87,7 +87,7 @@ moving things between mount points, and problems can occur.
 
 Ideally, `/home/git` is the mount point, so things remain inside the same mount point. Linux package
 installations guarantee this because they don't specify the full repository path but instead
-the parent path, but source installations do not.
+the parent path, but self-compiled installations do not.
 
 ### Example configuration
 
@@ -118,7 +118,7 @@ For self-compiled installations:
          path: /mnt/storage2/repositories
    ```
 
-1. [Restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. [Restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 1. [Configure where new repositories are stored](#configure-where-new-repositories-are-stored).
 
diff --git a/doc/administration/repository_storage_types.md b/doc/administration/repository_storage_types.md
index e1512038286..6e47d3099bd 100644
--- a/doc/administration/repository_storage_types.md
+++ b/doc/administration/repository_storage_types.md
@@ -29,9 +29,7 @@ The repository storage types documented here apply to any repository storage def
 
 ## Hashed storage
 
-> - [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/28283) in GitLab 10.0.
-> - Made the default for new installations in GitLab 12.0.
-> - Enabled by default for new and renamed projects in GitLab 13.0.
+> **Storage name** field [renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128416) from **Gitaly storage name** and **Relative path** field [renamed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128416) from **Gitaly relative path** in GitLab 16.3.
 
 Hashed storage stores projects on disk in a location based on a hash of the project's ID. Hashed
 storage is different to [legacy storage](#legacy-storage) where a project is stored based on:
@@ -81,12 +79,11 @@ To look up a project's hash path in the Admin Area:
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. On the left sidebar, select **Overview > Projects** and select the project.
+1. Locate the **Relative path** field. The value is similar to:
 
-The **Gitaly relative path** is displayed there and looks similar to:
-
-```plaintext
-"@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"
-```
+   ```plaintext
+   "@hashed/b1/7e/b17ef6d19c7a5b1ee83b907c595526dcb1eb06db8227d650d5dda0a9f4ce8cd9.git"
+   ```
 
 To look up a project's hash path using a Rails console:
 
@@ -100,7 +97,7 @@ To look up a project's hash path using a Rails console:
 
 #### From hashed path to project name
 
-Administrators can look up a project's name from its hashed storage path using:
+Administrators can look up a project's name from its hashed relative path using:
 
 - A Rails console.
 - The `config` file in the `*.git` directory.
diff --git a/doc/administration/restart_gitlab.md b/doc/administration/restart_gitlab.md
index 51a4fe40b16..d0e4beccb3a 100644
--- a/doc/administration/restart_gitlab.md
+++ b/doc/administration/restart_gitlab.md
@@ -97,10 +97,10 @@ If you manually edit any files in `/var/opt/gitlab` that are managed by Chef,
 running `reconfigure` reverts the changes and restarts the services that
 depend on those files.
 
-## Installations from source
+## Self-compiled installations
 
 If you have followed the official installation guide to
-[install GitLab from source](../install/installation.md), run the following command to restart GitLab:
+[self-compile your installation](../install/installation.md), run the following command to restart GitLab:
 
 ```shell
 # For systems running systemd
diff --git a/doc/administration/secure_files.md b/doc/administration/secure_files.md
index 3c9d40c3e73..d4a57ed5d51 100644
--- a/doc/administration/secure_files.md
+++ b/doc/administration/secure_files.md
@@ -4,7 +4,7 @@ group: Mobile DevOps
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Secure Files administration **(FREE)**
+# Secure Files administration **(FREE SELF)**
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78227) in GitLab 14.8 [with a flag](feature_flags.md) named `ci_secure_files`. Disabled by default.
 > - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/issues/350748) in GitLab 15.7. Feature flag `ci_secure_files` removed.
@@ -42,11 +42,7 @@ Prerequisite:
    gitlab_rails['ci_secure_files_enabled'] = false
    ```
 
-1. Save the file and reconfigure GitLab:
-
-   ```shell
-   sudo gitlab-ctl reconfigure
-   ```
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 **For self-compiled installations**
 
@@ -57,7 +53,7 @@ Prerequisite:
      enabled: false
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Using local storage
 
@@ -73,12 +69,7 @@ are stored locally, follow the steps below.
    gitlab_rails['ci_secure_files_storage_path'] = "/mnt/storage/ci_secure_files"
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation)
-1. Save the file and reconfigure GitLab:
-
-   ```shell
-   sudo gitlab-ctl reconfigure
-   ```
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
 
 **For self-compiled installations**
 
@@ -91,7 +82,7 @@ are stored locally, follow the steps below.
      storage_path: /mnt/storage/ci_secure_files
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source)
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations)
    for the changes to take effect.
 
 ## Using object storage **(FREE SELF)**
@@ -109,7 +100,7 @@ Adding support is proposed in [issue 414673](https://gitlab.com/gitlab-org/gitla
 
 The following settings are:
 
-- Nested under `ci_secure_files:` and then `object_store:` on source installations.
+- Nested under `ci_secure_files:` and then `object_store:` on self-compiled installations.
 - Prefixed by `ci_secure_files_object_store_` on Linux package installations.
 
 | Setting | Description | Default |
@@ -149,14 +140,8 @@ See [the available connection settings for different providers](object_storage.m
    }
    ```
 
-1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation)
-1. Save the file and reconfigure GitLab:
-
-   ```shell
-   sudo gitlab-ctl reconfigure
-   ```
-
-1. [Migrate any existing local states to the object storage](#migrate-to-object-storage)
+1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation).
+1. [Migrate any existing local states to the object storage](#migrate-to-object-storage).
 
 **For self-compiled installations**
 
@@ -175,8 +160,8 @@ See [the available connection settings for different providers](object_storage.m
          region: eu-central-1
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
-1. [Migrate any existing local states to the object storage](#migrate-to-object-storage)
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
+1. [Migrate any existing local states to the object storage](#migrate-to-object-storage).
 
 ### Migrate to object storage
 
diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md
index 82360581504..104eaafd8ad 100644
--- a/doc/administration/server_hooks.md
+++ b/doc/administration/server_hooks.md
@@ -74,7 +74,8 @@ To create server hooks for a repository:
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. Go to **Overview > Projects** and select the project you want to add a server hook to.
-1. On the page that appears, locate the value of **Gitaly relative path**. This path is where server hooks must be located.
+1. On the page that appears, locate the value of **Relative path**. This path is where server
+   hooks must be located.
    - If you are using [hashed storage](repository_storage_types.md#hashed-storage), see
      [Translate hashed storage paths](repository_storage_types.md#translate-hashed-storage-paths) for information on
      interpreting the relative path.
@@ -134,7 +135,7 @@ For Linux package installations, the directory is set in `gitlab.rb` under `gita
 - Use the default suggestion of the `/var/opt/gitlab/gitaly/custom_hooks` directory by uncommenting it.
 - Add your own setting.
 
-For installations from source:
+For self-compiled installations:
 
 - The directory is set in a configuration file. The location of the configuration file depends on the GitLab version:
   - For GitLab 13.1 and later, the directory is set in `gitaly/config.toml` under the `[hooks]` section. However,
diff --git a/doc/administration/settings/account_and_limit_settings.md b/doc/administration/settings/account_and_limit_settings.md
index ca56a322237..3d632880113 100644
--- a/doc/administration/settings/account_and_limit_settings.md
+++ b/doc/administration/settings/account_and_limit_settings.md
@@ -107,6 +107,54 @@ details.
 
 For GitLab.com repository size limits, read [accounts and limit settings](../../user/gitlab_com/index.md#account-and-limit-settings).
 
+## Maximum remote file size for imports
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384976) in GitLab 16.3.
+
+You can modify the maximum remote file size for imports from external object storages (for example, AWS) in GitLab.
+
+To modify the maximum import remote file size:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Account and limit**.
+1. Increase or decrease by changing the value in **Maximum import remote file size (MB)**. Set to `0` to set no file size limit.
+
+## Maximum download file size for imports by direct transfer
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/384976) in GitLab 16.3.
+
+You can modify the maximum download file size for imports by direct transfer in GitLab.
+
+To modify the maximum download file size for imports by direct transfer:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Account and limit**.
+1. Increase or decrease by changing the value in **Direct transfer maximum download file size (MB)**. Set to `0` to set no download file size limit.
+
+## Maximum decompressed file size for imported archives
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128218) in GitLab 16.3.
+
+When you import a project using [file exports](../../user/project/settings/import_export.md) or [direct transfer](../../user/group/import/index.md#migrate-groups-by-direct-transfer-recommended), you can specify the maximum decompressed file size for imported archives. The default value is 25 GB.
+
+When you import a compressed file, the decompressed size cannot exceed the maximum decompressed file size limit. If the decompressed size exceeds the configured limit, the following error is returned:
+
+```plaintext
+Decompressed archive size validation failed.
+```
+
+To modify the maximum decompressed file size for imports in GitLab:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > General**.
+1. Expand **Account and limit**.
+1. Set another value for **Maximum decompressed size (MiB)**.
+
 ## Personal access token prefix
 
 > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20968) in GitLab 13.7.
@@ -147,7 +195,7 @@ For instance, consider the following workflow:
 
 1. Your team develops apps which require large files to be stored in
    the application repository.
-1. Although you have enabled [Git LFS](../../topics/git/lfs/index.md#git-large-file-storage-lfs)
+1. Although you have enabled [Git LFS](../../topics/git/lfs/index.md)
    to your project, your storage has grown significantly.
 1. Before you exceed available storage, you set up a limit of 10 GB
    per repository.
diff --git a/doc/administration/settings/continuous_integration.md b/doc/administration/settings/continuous_integration.md
index eaa240d4c96..edf61701a33 100644
--- a/doc/administration/settings/continuous_integration.md
+++ b/doc/administration/settings/continuous_integration.md
@@ -139,7 +139,7 @@ NOTE:
 Any changes to this setting applies to new artifacts only. The expiration time is not
 be updated for artifacts created before this setting was changed.
 The administrator may need to manually search for and expire previously-created
-artifacts, as described in the [troubleshooting documentation](../../administration/job_artifacts.md#delete-job-artifacts-from-jobs-completed-before-a-specific-date).
+artifacts, as described in the [troubleshooting documentation](../../administration/job_artifacts_troubleshooting.md#delete-job-artifacts-from-jobs-completed-before-a-specific-date).
 
 ## Keep the latest artifacts for all jobs in the latest successful pipelines
 
@@ -172,9 +172,12 @@ All application settings have a [customizable cache expiry interval](../../admin
 
 ## Archive jobs
 
-Archiving jobs is useful for reducing the CI/CD footprint on the system by removing some
-of the capabilities of the jobs (metadata stored in the database needed to run the job),
-but persisting the traces and artifacts for auditing purposes.
+You can archive old jobs to prevent them from being re-run individually. Archived jobs
+display a lock icon (**{lock}**) and **This job is archived** at the top of the job log.
+
+Future work is planned to reduce the CI/CD footprint on the system for archived jobs
+by removing metadata stored in the database needed to run the job. See the [CI/CD data time decay](../../architecture/blueprints/ci_data_decay/index.md)
+blueprint for more details.
 
 To set the duration for which the jobs are considered as old and expired:
 
diff --git a/doc/administration/settings/img/protected_paths.png b/doc/administration/settings/img/protected_paths.png
deleted file mode 100644
index 2233a71a139..00000000000
--- a/doc/administration/settings/img/protected_paths.png
+++ /dev/null
diff --git a/doc/administration/settings/index.md b/doc/administration/settings/index.md
index 5fc0c029c30..a5746ad26e4 100644
--- a/doc/administration/settings/index.md
+++ b/doc/administration/settings/index.md
@@ -21,180 +21,8 @@ To access the **Admin Area**:
 1. Sign in to your GitLab instance as an administrator.
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
-1. Select **Settings**, and the group of settings to view:
-   - [General](#general)
-   - [Geo](#geo)
-   - [CI/CD](#cicd)
-   - [Integrations](#integrations)
-   - [Metrics and profiling](#metrics-and-profiling)
-   - [Network](#network)
-   - [Preferences](#preferences)
-   - [Reporting](#reporting)
-   - [Repository](#repository)
-   - [Templates](#templates)
 
-### General
-
-The **General** settings contain:
-
-- [Visibility and access controls](../settings/visibility_and_access_controls.md) - Set default and
- restrict visibility levels. Configure import sources and Git access protocol.
-- [Account and limit](../settings/account_and_limit_settings.md) - Set projects and maximum size limits,
- session duration, user options, and check feature availability for namespace plan.
-- [Diff limits](../diff_limits.md) - Diff content limits.
-- [Sign-up restrictions](../settings/sign_up_restrictions.md) - Configure the way a user creates a new account.
-- [Sign in restrictions](../settings/sign_in_restrictions.md) - Set requirements for a user to sign in.
- Enable mandatory two-factor authentication.
-- [Terms of Service and Privacy Policy](../settings/terms.md) - Include a Terms of Service agreement
- and Privacy Policy that all users must accept.
-- [External Authentication](../../administration/settings/external_authorization.md#configuration) - External Classification Policy Authorization.
-- [Web terminal](../integration/terminal.md#limiting-websocket-connection-time) -
- Set max session time for web terminal.
-- [FLoC](floc.md) - Enable or disable
- [Federated Learning of Cohorts (FLoC)](https://en.wikipedia.org/wiki/Federated_Learning_of_Cohorts) tracking.
-- [GitLab for Slack app](../../user/admin_area/settings/slack_app.md) - Enable and configure the GitLab for Slack app.
-
-### CI/CD
-
-The **CI/CD** settings contain:
-
-- [Continuous Integration and Deployment](../../administration/settings/continuous_integration.md) -
-  Auto DevOps, runners and job artifacts.
-- [Required pipeline configuration](../../administration/settings/continuous_integration.md#required-pipeline-configuration) -
-  Set an instance-wide auto included [pipeline configuration](../../ci/yaml/index.md).
-  This pipeline configuration is run after the project's own configuration.
-- [Package Registry](../../administration/settings/continuous_integration.md#package-registry-configuration) -
-  Settings related to the use and experience of using the GitLab Package Registry. Some
-  [risks are involved](../../user/packages/container_registry/reduce_container_registry_storage.md#use-with-external-container-registries)
-  in enabling some of these settings.
-
-## Security and Compliance settings
-
-- [License compliance settings](security_and_compliance.md#choose-package-registry-metadata-to-sync): Enable or disable synchronization of package metadata by a registry type.
-
-### Geo **(PREMIUM SELF)**
-
-The **Geo** setting contains:
-
-- [Geo](../geo/index.md) - Replicate your GitLab instance to other
-  geographical locations. Redirects to **Admin Area > Geo > Settings** are no
-  longer available at **Admin Area > Settings > Geo** in [GitLab 13.0](https://gitlab.com/gitlab-org/gitlab/-/issues/36896).
-
-### Integrations
-
-The **Integrations** settings contain:
-
-- [Elasticsearch](../../integration/advanced_search/elasticsearch.md#enable-advanced-search) -
-  Elasticsearch integration. Elasticsearch AWS IAM.
-- [Kroki](../integration/kroki.md#enable-kroki-in-gitlab) -
-  Allow rendering of diagrams in AsciiDoc and Markdown documents using [kroki.io](https://kroki.io).
-- [Mailgun](../integration/mailgun.md) - Enable your GitLab instance
-  to receive invite email bounce events from Mailgun, if it is your email provider.
-- [PlantUML](../integration/plantuml.md) - Allow rendering of PlantUML
-  diagrams in documents.
-- [Customer experience improvement and third-party offers](../settings/third_party_offers.md) -
-  Control the display of customer experience improvement content and third-party offers.
-- [Snowplow](../../development/internal_analytics/snowplow/index.md) - Configure the Snowplow integration.
-- [Google GKE](../../user/project/clusters/add_gke_clusters.md) - Google GKE integration enables
-  you to provision GKE clusters from GitLab.
-- [Amazon EKS](../../user/project/clusters/add_eks_clusters.md) - Amazon EKS integration enables
-  you to provision EKS clusters from GitLab.
-
-### Metrics and profiling
-
-The **Metrics and profiling** settings contain:
-
-- [Metrics - Prometheus](../monitoring/prometheus/gitlab_metrics.md) -
-  Enable and configure Prometheus metrics.
-- [Metrics - Grafana](../monitoring/performance/grafana_configuration.md#integrate-with-gitlab-ui) -
-  Enable and configure Grafana.
-- [Profiling - Performance bar](../monitoring/performance/performance_bar.md#enable-the-performance-bar-for-non-administrators) -
-  Enable access to the Performance Bar for non-administrator users in a given group.
-- [Usage statistics](../settings/usage_statistics.md) - Enable or disable version check and Service Ping.
-
-### Network
-
-The **Network** settings contain:
-
-- Performance optimization - Various settings that affect GitLab performance, including:
-  - [Write to `authorized_keys` file](../operations/fast_ssh_key_lookup.md#set-up-fast-lookup).
-  - [Push event activities limit and bulk push events](../settings/push_event_activities_limit.md).
-- [User and IP rate limits](../settings/user_and_ip_rate_limits.md) - Configure limits for web and API requests.
-  These rate limits can be overridden:
-  - [Package Registry Rate Limits](../settings/package_registry_rate_limits.md) - Configure specific
-    limits for Packages API requests that supersede the user and IP rate limits.
-  - [Git LFS Rate Limits](../settings/git_lfs_rate_limits.md) - Configure specific limits for
-    Git LFS requests that supersede the user and IP rate limits.
-  - [Files API Rate Limits](../settings/files_api_rate_limits.md) - Configure specific limits for
-    Files API requests that supersede the user and IP rate limits.
-  - [Search rate limits](../instance_limits.md#search-rate-limit) - Configure global search request rate limits for authenticated and unauthenticated users.
-  - [Deprecated API Rate Limits](../settings/deprecated_api_rate_limits.md) - Configure specific limits
-    for deprecated API requests that supersede the user and IP rate limits.
-- [Outbound requests](../../security/webhooks.md) - Allow requests to the local network from webhooks and integrations, or deny all outbound requests.
-- [Protected Paths](../settings/protected_paths.md) - Configure paths to be protected by Rack Attack.
-- [Incident Management Limits](../../operations/incident_management/index.md) - Limit the
-  number of inbound alerts that can be sent to a project.
-- [Notes creation limit](../settings/rate_limit_on_notes_creation.md) - Set a rate limit on the note creation requests.
-- [Get single user limit](../settings/rate_limit_on_users_api.md) - Set a rate limit on users API endpoint to get a user by ID.
-- [Projects API rate limits for unauthenticated requests](../settings/rate_limit_on_projects_api.md) - Set a rate limit on Projects list API endpoint for unauthenticated requests.
-
-### Preferences
-
-The **Preferences** settings contain:
-
-- [Email](../settings/email.md) - Various email settings.
-- [What's new](../whats-new.md) - Configure **What's new** drawer and content.
-- [Help page](help_page.md) - Help page text and support page URL.
-- [Pages](../pages/index.md#custom-domain-verification) -
-  Size and domain settings for static websites.
-- [Polling interval multiplier](../polling.md) -
-  Configure how frequently the GitLab UI polls for updates.
-- [Gitaly timeouts](gitaly_timeouts.md) - Configure Gitaly timeouts.
-- Localization:
-  - [Default first day of the week](../../user/profile/preferences.md).
-  - [Time tracking](../../user/project/time_tracking.md#limit-displayed-units-to-hours).
-- [Sidekiq Job Limits](../settings/sidekiq_job_limits.md) - Limit the size of Sidekiq jobs stored in Redis.
-
-### Reporting
-
-The **Reporting** settings contain:
-
-- Spam and Anti-bot protection:
-  - Anti-spam services, such as [reCAPTCHA](../../integration/recaptcha.md),
-    [Akismet](../../integration/akismet.md), or [Spamcheck](../reporting/spamcheck.md).
-  - [IP address restrictions](../reporting/ip_addr_restrictions.md).
-- [Abuse reports](../review_abuse_reports.md) - Set notification email for abuse reports.
-- [Git abuse rate limit](../reporting/git_abuse_rate_limit.md) - Configure Git abuse rate limit settings. **(ULTIMATE SELF)**
-
-### Repository
-
-The **Repository** settings contain:
-
-- [Repository's custom initial branch name](../../user/project/repository/branches/default.md#instance-level-custom-initial-branch-name) -
-  Set a custom branch name for new repositories created in your instance.
-- [Repository's initial default branch protection](../../user/project/repository/branches/default.md#instance-level-default-branch-protection) -
-  Configure the branch protections to apply to every repository's default branch.
-- [Repository mirror](visibility_and_access_controls.md#enable-project-mirroring) -
-  Configure repository mirroring.
-- [Repository storage](../repository_storage_types.md) - Configure storage path settings.
-- Repository maintenance:
-  - [Repository checks](../repository_checks.md) - Configure
-    automatic Git checks on repositories.
-  - [Housekeeping](../housekeeping.md). Configure automatic
-    Git housekeeping on repositories.
-  - [Inactive project deletion](../inactive_project_deletion.md). Configure inactive
-    project deletion.
-- [Repository static objects](../static_objects_external_storage.md) -
-  Serve repository static objects (for example, archives and blobs) from an external storage (for example, a CDN).
-
-### Templates **(PREMIUM SELF)**
-
-The **Templates** settings contain:
-
-- [Templates](instance_template_repository.md#configuration) - Set instance-wide template repository.
-- [Custom project templates](../custom_project_templates.md) - Select the custom project template source group.
-
-## Default first day of the week
+## Change the default first day of the week
 
 You can change the [Default first day of the week](../../user/profile/preferences.md)
 for the entire GitLab instance:
@@ -204,7 +32,7 @@ for the entire GitLab instance:
 1. Select **Settings > Preferences**.
 1. Scroll to the **Localization** section, and select your desired first day of the week.
 
-## Default language
+## Change the default language
 
 You can change the [Default language](../../user/profile/preferences.md)
 for the entire GitLab instance:
diff --git a/doc/administration/settings/project_integration_management.md b/doc/administration/settings/project_integration_management.md
index 1bb4465020c..95dddf34182 100644
--- a/doc/administration/settings/project_integration_management.md
+++ b/doc/administration/settings/project_integration_management.md
@@ -4,7 +4,7 @@ group: Import and Integrate
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Project integration management **(FREE)**
+# Project integration management **(FREE SELF)**
 
 Project integrations can be configured and enabled by project administrators. As a GitLab instance
 administrator, you can set default configuration parameters for a given integration that all projects
@@ -15,18 +15,19 @@ You can update these default settings at any time, changing the settings used fo
 are set to use instance-level or group-level defaults. Updating the default settings also enables the integration
 for all projects that didn't have it already enabled.
 
-Only the complete settings for an integration can be inherited. Per-field inheritance is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137).
+Only the entire settings for an integration can be inherited. Per-field inheritance
+is proposed in [epic 2137](https://gitlab.com/groups/gitlab-org/-/epics/2137).
 
 ## Manage instance-level default settings for a project integration **(FREE SELF)**
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2137) in GitLab 13.3 for project-level integrations.
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6 for group-level integrations.
+To manage instance-level default settings for a project integration:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. Select **Settings > Integrations**.
 1. Select an integration.
-1. Enter configuration details and select **Save changes**.
+1. Complete the fields.
+1. Select **Save changes**.
 
 WARNING:
 This may affect all or most of the groups and projects on your GitLab instance. Review the details
@@ -48,13 +49,17 @@ When you make further changes to the instance defaults:
 - Groups and projects with custom settings selected for the integration are not immediately affected and may
   choose to use the latest defaults at any time.
 
-Only the complete settings for an integration can be inherited. Per-field inheritance
-is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allow
-administrators to update settings inherited by groups and projects without enabling the
-integration on all non-configured groups and projects by default.
+If [group-level settings](#manage-group-level-default-settings-for-a-project-integration) have also
+been configured for the same integration, projects in that group inherit the group-level settings
+instead of the instance-level settings.
+
+Only the entire settings for an integration can be inherited. Per-field inheritance
+is proposed in [epic 2137](https://gitlab.com/groups/gitlab-org/-/epics/2137).
 
 ### Remove an instance-level default setting
 
+To remove an instance-level default setting:
+
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. Select **Settings > Integrations**.
@@ -63,12 +68,11 @@ integration on all non-configured groups and projects by default.
 
 Resetting an instance-level default setting removes the integration from all projects that have the integration set to use default settings.
 
-### View projects that override the default settings
+### View projects that use custom settings
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/218252) in GitLab 14.2.
 
-You can view which projects in your instance use custom settings that [override the instance-level default settings](#use-custom-settings-for-a-group-or-project-integration)
-for an integration.
+To view projects in your instance that [use custom settings](#use-custom-settings-for-a-project-or-group-integration):
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
@@ -78,11 +82,13 @@ for an integration.
 
 ## Manage group-level default settings for a project integration
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6.
+To manage group-level default settings for a project integration:
 
-1. Navigate to the group's **Settings > Integrations**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Integrations**.
 1. Select an integration.
-1. Enter configuration details and select **Save changes**.
+1. Complete the fields.
+1. Select **Save changes**.
 
 WARNING:
 This may affect all or most of the subgroups and projects belonging to the group. Review the details below.
@@ -102,18 +108,21 @@ When you make further changes to the group defaults:
 - They are immediately applied to newer subgroups and projects, even those created after you last saved defaults for the
   integration. If your group-level default setting has the **Enable integration** toggle turned on,
   the integration is automatically enabled for all such subgroups and projects.
-
 - Subgroups and projects with custom settings selected for the integration are not immediately affected and
   may choose to use the latest defaults at any time.
 
-Only the complete settings for an integration can be inherited. Per-field inheritance
-is [planned](https://gitlab.com/groups/gitlab-org/-/epics/2137). This would allow
-administrators to update settings inherited by subgroups and projects without enabling the
-integration on all non-configured groups and projects by default.
+If [instance-level settings](#manage-instance-level-default-settings-for-a-project-integration)
+have also been configured for the same integration, projects in the group inherit settings from the group.
+
+Only the entire settings for an integration can be inherited. Per-field inheritance
+is proposed in [epic 2137](https://gitlab.com/groups/gitlab-org/-/epics/2137).
 
 ### Remove a group-level default setting
 
-1. Navigate to the group's **Settings > Integrations**.
+To remove a group-level default setting:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your group.
+1. Select **Settings > Integrations**.
 1. Select an integration.
 1. Select **Reset** and confirm.
 
@@ -121,18 +130,24 @@ Resetting a group-level default setting removes integrations that use default se
 
 ## Use instance-level or group-level default settings for a project integration
 
-> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2543) in GitLab 13.6 for group-level settings.
+To use instance-level or group-level default settings for a project integration:
 
-1. Navigate to **Project > Settings > Integrations**.
-1. Choose the integration you want to enable or update.
-1. From the dropdown list, select **Use default settings**.
-1. Ensure the toggle is set to **Enable integration**.
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project.
+1. Select **Settings > Integrations**.
+1. Select an integration.
+1. On the right, from the dropdown list, select **Use default settings**.
+1. Under **Enable integration**, ensure the **Active** checkbox is selected.
+1. Complete the fields.
 1. Select **Save changes**.
 
-## Use custom settings for a group or project integration
+## Use custom settings for a project or group integration
 
-1. Navigate to project or group's **Settings > Integrations**.
-1. Choose the integration you want to enable or update.
-1. From the dropdown list, select **Use custom settings**.
-1. Ensure the toggle is set to **Enable integration** and enter all required settings.
+To use custom settings for a project or group integration:
+
+1. On the left sidebar, at the top, select **Search GitLab** (**{search}**) to find your project or group.
+1. Select **Settings > Integrations**.
+1. Select an integration.
+1. On the right, from the dropdown list, select **Use custom settings**.
+1. Under **Enable integration**, ensure the **Active** checkbox is selected.
+1. Complete the fields.
 1. Select **Save changes**.
diff --git a/doc/administration/settings/protected_paths.md b/doc/administration/settings/protected_paths.md
index ba257983619..5deba7dca11 100644
--- a/doc/administration/settings/protected_paths.md
+++ b/doc/administration/settings/protected_paths.md
@@ -11,7 +11,7 @@ Rate limiting is a technique that improves the security and durability of a web
 application. For more details, see [Rate limits](../../security/rate_limits.md).
 
 You can rate limit (protect) specified paths. For these paths, GitLab responds with HTTP status
-code `429` to POST requests at protected paths that exceed 10 requests per minute per IP address.
+code `429` to POST requests that exceed 10 requests per minute per IP address and GET requests that exceed 10 requests per minute per IP address at protected paths.
 
 For example, the following are limited to a maximum 10 requests per minute:
 
@@ -32,12 +32,11 @@ See also:
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31246) in GitLab 12.4.
 
 Throttling of protected paths is enabled by default and can be disabled or
-customized on **Admin > Network > Protected Paths**, along with these options:
+customized.
 
-- Maximum number of requests per period per user.
-- Rate limit period in seconds.
-- Paths to be protected.
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. Select **Settings > Network**.
+1. Expand **Protected paths**.
 
-![protected-paths](img/protected_paths.png)
-
-Requests over the rate limit are logged into `auth.log`.
+Requests that exceed the rate limit are logged in `auth.log`.
diff --git a/doc/administration/settings/push_event_activities_limit.md b/doc/administration/settings/push_event_activities_limit.md
index 117e7322e30..ff924e0d208 100644
--- a/doc/administration/settings/push_event_activities_limit.md
+++ b/doc/administration/settings/push_event_activities_limit.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# Push event activities limit and bulk push events **(FREE)**
+# Push event activities limit and bulk push events **(FREE SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31007) in GitLab 12.4.
 
diff --git a/doc/administration/settings/rate_limit_on_issues_creation.md b/doc/administration/settings/rate_limit_on_issues_creation.md
index d8bc04fcdd3..20f3febbf28 100644
--- a/doc/administration/settings/rate_limit_on_issues_creation.md
+++ b/doc/administration/settings/rate_limit_on_issues_creation.md
@@ -5,12 +5,18 @@ group: Project Management
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Rate limits on issue creation **(FREE SELF)**
+# Rate limits on issue and epic creation **(FREE SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28129) in GitLab 12.10.
 
-This setting allows you to rate limit the requests to the issue and epic creation endpoints.
-To can change its value:
+Rate limits control the pace at which new epics and issues can be created.
+For example, if you set the limit to `300`, the
+[Projects::IssuesController#create](https://gitlab.com/gitlab-org/gitlab/blob/master/app/controllers/projects/issues_controller.rb)
+action blocks requests that exceed a rate of 300 per minute. Access to the endpoint is available after one minute.
+
+## Set the rate limit
+
+To limit the number of requests made to the issue and epic creation endpoints:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
@@ -19,18 +25,12 @@ To can change its value:
 1. Under **Max requests per minute**, enter the new value.
 1. Select **Save changes**.
 
-For example, if you set a limit of 300, requests using the
-[Projects::IssuesController#create](https://gitlab.com/gitlab-org/gitlab/blob/master/app/controllers/projects/issues_controller.rb)
-action exceeding a rate of 300 per minute are blocked. Access to the endpoint is allowed after one minute.
-
-When using [epics](../../user/group/epics/index.md), epic creation shares this rate limit with issues.
-
 ![Rate limits on issues creation](img/rate_limit_on_issues_creation_v14_2.png)
 
-This limit is:
+The limit for [epic](../../user/group/epics/index.md) creation is the same limit applied to issue creation. The rate limit:
 
-- Applied independently per project and per user.
-- Not applied per IP address.
-- Disabled by default. To enable it, set the option to any value other than `0`.
+- Is applied independently per project and per user.
+- Is not applied per IP address.
+- Can be set to `0` to disable the rate limit.
 
 Requests over the rate limit are logged into the `auth.log` file.
diff --git a/doc/administration/settings/sign_up_restrictions.md b/doc/administration/settings/sign_up_restrictions.md
index f213794eb75..f255e15c1be 100644
--- a/doc/administration/settings/sign_up_restrictions.md
+++ b/doc/administration/settings/sign_up_restrictions.md
@@ -64,7 +64,7 @@ A [user cap](#user-cap) can also be used to enforce approvals for new users.
 You can send confirmation emails during sign up and require that users confirm
 their email address before they are allowed to sign in.
 
-For example, to enforce confirmation of the email address used for new sign ups:
+To enforce confirmation of the email address used for new sign ups:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
@@ -75,33 +75,37 @@ For example, to enforce confirmation of the email address used for new sign ups:
 The following settings are available:
 
 - **Hard** - Send a confirmation email during sign up. New users must confirm their email address before they can log in.
-- **Soft** - Send a confirmation email during sign up. New users can log in immediately, but must confirm their email in three days. Unconfirmed accounts are deleted.
+- **Soft** - Send a confirmation email during sign up. New users can sign in immediately, but must confirm their email in three days. After three days, the user is not able to sign in until they confirm their email.
 - **Off** - New users can sign up without confirming their email address.
 
 ## User cap
 
-> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4315) in GitLab 13.7.
-> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/292600) in GitLab 13.9.
+The user cap is the maximum number of billable users who can sign up or be added to a subscription
+without administrator approval. After the user cap is reached, users who sign up or are
+added must be [approved](../../administration/moderate_users.md#approve-or-reject-a-user-sign-up)
+by an administrator. Users can use their account only after they have been approved by an administrator.
 
-When the number of billable users reaches the user cap, any user who is added or requests access must be
-[approved](../../administration/moderate_users.md#approve-or-reject-a-user-sign-up) by an administrator before they can start using
-their account.
-
-If an administrator [increases](#set-the-user-cap-number) or [removes](#remove-the-user-cap) the
-user cap, the users in pending approval state are automatically approved in a background job.
+If an administrator increases or removes the user cap, users pending approval are automatically approved.
 
 NOTE:
-The amount of billable users [is updated once a day](../../subscriptions/self_managed/index.md#billable-users).
-This means the user cap might apply only retrospectively after the cap has already been exceeded.
-To ensure the cap is enabled immediately, set it to a low value below the current number of
-billable users, for example: `1`.
+For instances that use LDAP or OmniAuth, when [administrator approval for new sign-ups](#require-administrator-approval-for-new-sign-ups)
+is enabled or disabled, downtime might occur due to changes in the Rails configuration.
+You can set a user cap to enforce approvals for new users. To ensure the user cap applies immediately, set the cap to a value below the current number of billable users (for example, `1`).
+
+### Set a user cap
+
+Set a user cap to restrict the number of users who can sign up without administrator approval.
 
-On instances that use LDAP or OmniAuth, enabling and disabling
-[administrator approval for new sign ups](#require-administrator-approval-for-new-sign-ups)
-involves changing the Rails configuration, and may require downtime.
-User cap can be used instead. As noted above, set the cap to value that ensures it is enforced immediately.
+The number of [billable users](../../subscriptions/self_managed/index.md#billable-users) is updated once a day.
+The user cap might apply only retrospectively after the cap has already been exceeded.
+To ensure the cap is enabled immediately, set the cap to a value below the current number of
+billable users (for example, `1`).
 
-### Set the user cap number
+Prerequisite:
+
+- You must be an administrator.
+
+To set a user cap:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
@@ -110,9 +114,18 @@ User cap can be used instead. As noted above, set the cap to value that ensures
 1. Enter a number in **User cap**.
 1. Select **Save changes**.
 
-New user sign ups are subject to the user cap restriction.
+### Remove the user cap
+
+Remove the user cap so that the number of new users who can sign up without
+administrator approval is not restricted.
 
-## Remove the user cap
+After you remove the user cap, users pending approval are automatically approved.
+
+Prerequisite:
+
+- You must be an administrator.
+
+To remove the user cap:
 
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
@@ -121,9 +134,6 @@ New user sign ups are subject to the user cap restriction.
 1. Remove the number from **User cap**.
 1. Select **Save changes**.
 
-New users sign ups are not subject to the user cap restriction. Users in pending approval state are
-automatically approved in a background job.
-
 ## Minimum password length limit
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) in GitLab 12.6
diff --git a/doc/administration/settings/slack_app.md b/doc/administration/settings/slack_app.md
new file mode 100644
index 00000000000..a8e672bc8fa
--- /dev/null
+++ b/doc/administration/settings/slack_app.md
@@ -0,0 +1,113 @@
+---
+stage: Manage
+group: Import and Integrate
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
+---
+
+# GitLab for Slack app administration **(FREE SELF)**
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/358872) for self-managed instances in GitLab 16.2.
+
+NOTE:
+This page contains information about administering the GitLab for Slack app for self-managed instances. For user documentation, see [GitLab for Slack app](../../user/project/integrations/gitlab_slack_application.md).
+
+The GitLab for Slack app distributed through the Slack App Directory only works with GitLab.com.
+On self-managed GitLab, you can create your own copy of the GitLab for Slack app from a [manifest file](https://api.slack.com/reference/manifests#creating_apps) and configure your instance.
+
+The app is a private one-time copy installed in your Slack workspace only and not distributed through the Slack App Directory. To have the [GitLab for Slack app](../../user/project/integrations/gitlab_slack_application.md) on your self-managed instance, you must enable the integration.
+
+## Create a GitLab for Slack app
+
+Prerequisite:
+
+- You must be at least a [Slack workspace administrator](https://slack.com/help/articles/360018112273-Types-of-roles-in-Slack).
+
+To create a GitLab for Slack app:
+
+- **In GitLab**:
+
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. On the left sidebar, select **Settings > General**.
+  1. Expand **GitLab for Slack app**.
+  1. Select **Create Slack app**.
+
+You're then redirected to Slack for the next steps.
+
+- **In Slack**:
+
+  1. Select the Slack workspace to create the app in, then select **Next**.
+  1. Slack displays a summary of the app for review. To view the complete manifest, select **Edit Configurations**. To go back to the review summary, select **Next**.
+  1. Select **Create**.
+  1. Select **Got it** to close the dialog.
+  1. Select **Install to Workspace**.
+
+## Configure the settings
+
+After you've [created a GitLab for Slack app](#create-a-gitlab-for-slack-app), you can configure the settings in GitLab:
+
+1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+1. Select **Admin Area**.
+1. On the left sidebar, select **Settings > General**.
+1. Expand **GitLab for Slack app**.
+1. Select the **Enable GitLab for Slack app** checkbox.
+1. Enter the details of your GitLab for Slack app:
+   1. Go to [Slack API](https://api.slack.com/apps).
+   1. Search for and select **GitLab (\<your host name\>)**.
+   1. Scroll to **App Credentials**.
+1. Select **Save changes**.
+
+### Test your configuration
+
+To test your GitLab for Slack app configuration:
+
+1. Enter the `/gitlab help` slash command into a channel in your Slack workspace.
+1. Press <kbd>Enter</kbd>.
+
+You should see a list of available Slash commands.
+
+To use Slash commands for a project, configure the [GitLab for Slack app](../../user/project/integrations/gitlab_slack_application.md) for the project.
+
+## Update the GitLab for Slack app
+
+Prerequisite:
+
+- You must be at least a [Slack workspace administrator](https://slack.com/help/articles/360018112273-Types-of-roles-in-Slack).
+
+When GitLab releases new features for the GitLab for Slack app, you might have to manually update your copy to use the new features.
+
+To update your copy of the GitLab for Slack app:
+
+- **In GitLab**:
+
+  1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
+  1. Select **Admin Area**.
+  1. On the left sidebar, select **Settings > General**.
+  1. Expand **GitLab for Slack app**.
+  1. Select **Download latest manifest file** to download `slack_manifest.json`.
+
+- **In Slack**:
+
+  1. Go to [Slack API](https://api.slack.com/apps).
+  1. Search for and select **GitLab (\<your host name\>)**.
+  1. On the left sidebar, select **App Manifest**.
+  1. Select the **JSON** tab to switch to a JSON view of the manifest.
+  1. Copy the contents of the `slack_manifest.json` file you've downloaded from GitLab.
+  1. Paste the contents into the JSON viewer to replace any existing contents.
+  1. Select **Save Changes**.
+
+## Connectivity requirements
+
+To enable the GitLab for Slack app functionality, your network must allow inbound and outbound connections between GitLab and Slack.
+
+- For [Slack notifications](../../user/project/integrations/gitlab_slack_application.md#slack-notifications), the GitLab instance must be able to send requests to `https://slack.com`.
+- For [Slash commands](../../user/project/integrations/gitlab_slack_application.md#slash-commands) and other features, the GitLab instance must be able to receive requests from `https://slack.com`.
+
+## Troubleshooting
+
+### Slash commands return `/gitlab failed with the error "dispatch_failed"` in Slack
+
+Slash commands might return `/gitlab failed with the error "dispatch_failed"` in Slack. To resolve this issue, ensure:
+
+- The GitLab for Slack app is properly [configured](#configure-the-settings), and the **Enable GitLab for Slack app** checkbox is selected.
+- Your GitLab instance [allows requests to and from Slack](#connectivity-requirements).
diff --git a/doc/administration/settings/terraform_limits.md b/doc/administration/settings/terraform_limits.md
index 90ab1c25522..5ba8bfe63e0 100644
--- a/doc/administration/settings/terraform_limits.md
+++ b/doc/administration/settings/terraform_limits.md
@@ -19,10 +19,6 @@ To add a storage limit:
 1. Select **Admin Area**.
 1. Select **Settings > Preferences**.
 1. Expand **Terraform limits**.
-1. Adjust the size limit.
+1. Enter a size limit in bytes. Set to `0` to allow files of unlimited size.
 
-## Available settings
-
-| Setting                            | Default | Description                                                                                                                                             |
-|------------------------------------|---------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
-| Terraform state size limit (bytes) | 0       | Terraform state files that exceed this size are not saved, and associated Terraform operations are rejected. Set to 0 to allow files of unlimited size. |
+When Terraform state files exceed this limit, they are not saved, and associated Terraform operations are rejected.
diff --git a/doc/administration/settings/usage_statistics.md b/doc/administration/settings/usage_statistics.md
index ba15ee4e33e..f77298dd038 100644
--- a/doc/administration/settings/usage_statistics.md
+++ b/doc/administration/settings/usage_statistics.md
@@ -141,9 +141,11 @@ The method to disable Service Ping in the GitLab configuration file does not wor
 GitLab versions 9.3 to 13.12.3. For more information about how to disable it, see [troubleshooting](../../development/internal_analytics/service_ping/troubleshooting.md#cannot-disable-service-ping-with-the-configuration-file).
 
 To disable Service Ping and prevent it from being configured in the future through
-the Admin Area:
+the Admin Area.
 
-**For installations using the Linux package:**
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
 
 1. Edit `/etc/gitlab/gitlab.rb`:
 
@@ -157,7 +159,7 @@ the Admin Area:
    sudo gitlab-ctl reconfigure
    ```
 
-**For installations from source:**
+:::TabTitle Self-compiled (source)
 
 1. Edit `/home/git/gitlab/config/gitlab.yml`:
 
@@ -175,6 +177,8 @@ the Admin Area:
    sudo service gitlab restart
    ```
 
+::EndTabs
+
 ## View the Service Ping payload
 
 You can view the exact JSON payload sent to GitLab Inc. in the Admin Area. To view the payload:
@@ -205,7 +209,7 @@ To upload the payload manually:
 1. Select **Download payload**.
 1. Save the JSON file.
 1. Visit [Service usage data center](https://version.gitlab.com/usage_data/new).
-1. Select **Choose file** and choose the file from p5.
+1. Select **Choose file**, then select the JSON file that contains the downloaded payload.
 1. Select **Upload**.
 
 The uploaded file is encrypted and sent using secure HTTPS protocol. HTTPS creates a secure
diff --git a/doc/administration/settings/user_and_ip_rate_limits.md b/doc/administration/settings/user_and_ip_rate_limits.md
index 44bd08a8824..822ba4dd03e 100644
--- a/doc/administration/settings/user_and_ip_rate_limits.md
+++ b/doc/administration/settings/user_and_ip_rate_limits.md
@@ -143,7 +143,7 @@ GitLab. For example:
 1. Set the environment variable  `GITLAB_THROTTLE_BYPASS_HEADER`.
    - For [Linux package installations](https://docs.gitlab.com/omnibus/settings/environment-variables.html),
      set `'GITLAB_THROTTLE_BYPASS_HEADER' => 'Gitlab-Bypass-Rate-Limiting'` in `gitlab_rails['env']`.
-   - For source installations, set `export GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limiting`
+   - For self-compiled installations, set `export GITLAB_THROTTLE_BYPASS_HEADER=Gitlab-Bypass-Rate-Limiting`
      in `/etc/default/gitlab`.
 
 It is important that your load balancer erases or overwrites the bypass
@@ -175,7 +175,7 @@ the allowlist configuration would be `1,53,217`.
 
 - For [Linux package installations](https://docs.gitlab.com/omnibus/settings/environment-variables.html),
   set `'GITLAB_THROTTLE_USER_ALLOWLIST' => '1,53,217'` in `gitlab_rails['env']`.
-- For source installations, set `export GITLAB_THROTTLE_USER_ALLOWLIST=1,53,217`
+- For self-compiled installations, set `export GITLAB_THROTTLE_USER_ALLOWLIST=1,53,217`
   in `/etc/default/gitlab`.
 
 Requests that bypassed the rate limiter because of the user allowlist
diff --git a/doc/administration/sidekiq/extra_sidekiq_processes.md b/doc/administration/sidekiq/extra_sidekiq_processes.md
index 3a522c7171d..d85eae7a7f6 100644
--- a/doc/administration/sidekiq/extra_sidekiq_processes.md
+++ b/doc/administration/sidekiq/extra_sidekiq_processes.md
@@ -11,7 +11,7 @@ at a higher rate on a single instance. By default, Sidekiq starts one worker
 process and only uses a single core.
 
 NOTE:
-The information in this page applies only to Omnibus GitLab.
+The information in this page applies only to Linux package installations.
 
 ## Start multiple processes
 
diff --git a/doc/administration/sidekiq/index.md b/doc/administration/sidekiq/index.md
index c3e1182cb05..10fadc40a82 100644
--- a/doc/administration/sidekiq/index.md
+++ b/doc/administration/sidekiq/index.md
@@ -82,7 +82,7 @@ By default, GitLab uses UNIX sockets and is not set up to communicate via TCP. T
    telnet <GitLab host> 6379 # Redis
    ```
 
-1. [Download and install](https://about.gitlab.com/install/) the Omnibus GitLab package
+1. [Download and install](https://about.gitlab.com/install/) the Linux package
    using steps 1 and 2. **Do not complete any other steps.**
 
 1. Copy the `/etc/gitlab/gitlab.rb` file from the GitLab instance and add the following settings. Make sure
@@ -227,7 +227,6 @@ node than Sidekiq, follow the steps below.
 1. Edit `/etc/gitlab/gitlab.rb`, and configure the registry URL:
 
    ```ruby
-   registry_external_url 'https://registry.example.com'
    gitlab_rails['registry_api_url'] = "https://registry.example.com"
    ```
 
diff --git a/doc/administration/sidekiq/sidekiq_memory_killer.md b/doc/administration/sidekiq/sidekiq_memory_killer.md
index 63d93919129..01eda32ded0 100644
--- a/doc/administration/sidekiq/sidekiq_memory_killer.md
+++ b/doc/administration/sidekiq/sidekiq_memory_killer.md
@@ -13,10 +13,9 @@ for a certain amount of time.
 We use the same approach to the Sidekiq processes used by GitLab
 to process background jobs.
 
-GitLab monitors the available RSS limit by default only for installations using
-the Linux packages (Omnibus) or Docker. The reason for this is that GitLab
-relies on runit to restart Sidekiq after a memory-induced shutdown, and GitLab
-self-compiled or Helm chart based installations don't use runit or an equivalent tool.
+GitLab monitors the available RSS limit by default only for Linux package or Docker installations. The reason for this
+is that GitLab relies on runit to restart Sidekiq after a memory-induced shutdown, and self-compiled and Helm chart
+installations don't use runit or an equivalent tool.
 
 With the default settings, Sidekiq restarts no
 more often than once every 15 minutes, with the restart causing about one
@@ -24,7 +23,7 @@ minute of delay for incoming background jobs.
 
 Some background jobs rely on long-running external processes. To ensure these
 are cleanly terminated when Sidekiq is restarted, each Sidekiq process should be
-run as a process group leader (for example, using `chpst -P`). If using Omnibus or the
+run as a process group leader (for example, using `chpst -P`). If using a Linux package installation or the
 `bin/background_jobs` script with `runit` installed, this is handled for you.
 
 ## Configuring the limits
diff --git a/doc/administration/sidekiq/sidekiq_troubleshooting.md b/doc/administration/sidekiq/sidekiq_troubleshooting.md
index 6802bb68b31..9ae2a59251a 100644
--- a/doc/administration/sidekiq/sidekiq_troubleshooting.md
+++ b/doc/administration/sidekiq/sidekiq_troubleshooting.md
@@ -63,7 +63,7 @@ and delays before CI pipelines start running.
 
 Potential causes include:
 
-- The GitLab instance may need more Sidekiq workers. By default, a single-node Omnibus GitLab
+- The GitLab instance may need more Sidekiq workers. By default, a single-node Linux package installation
   runs one worker, restricting the execution of Sidekiq jobs to a maximum of one CPU core.
   [Read more about running multiple Sidekiq workers](extra_sidekiq_processes.md).
 
@@ -105,7 +105,14 @@ Gather data on the state of the Sidekiq workers with the following Ruby script.
 
    If the performance issue is intermittent:
 
-   - Run this in a cron job every five minutes. Write the files to a location with enough space: allow for 500 KB per file.
+   - Run this in a cron job every five minutes. Write the files to a location with enough space: allow for at least 500 KB per file.
+
+     ```shell
+     cat > /etc/cron.d/sidekiqcheck <<EOF
+     */5 * * * *  root  /opt/gitlab/bin/gitlab-rails runner /var/opt/gitlab/sidekiqcheck.rb > /tmp/sidekiqcheck_$(date '+\%Y\%m\%d-\%H:\%M').out 2>&1
+     EOF
+     ```
+
    - Refer back to the data to see what went wrong.
 
 1. Analyze the output. The following commands assume that you have a directory of output files.
@@ -555,9 +562,9 @@ but if you want to clear the idempotency key immediately, follow the following s
   dj.delete!
   ```
 
-## Omnibus GitLab 14.0 and later: remove the `sidekiq-cluster` service
+## GitLab 14.0 and later: remove the `sidekiq-cluster` service (Linux package installations)
 
-Omnibus GitLab instances that were configured to run `sidekiq-cluster` prior to GitLab 14.0
+Linux package instances that were configured to run `sidekiq-cluster` prior to GitLab 14.0
 might still have this service running along side `sidekiq` in later releases.
 
 The code to manage `sidekiq-cluster` was removed in GitLab 14.0.
diff --git a/doc/administration/silent_mode/index.md b/doc/administration/silent_mode/index.md
index 0b04654beaa..005add1d2f4 100644
--- a/doc/administration/silent_mode/index.md
+++ b/doc/administration/silent_mode/index.md
@@ -63,11 +63,15 @@ This section documents the current behavior of GitLab when Silent Mode is enable
 
 ### Service Desk
 
-Incoming emails still raise issues, but the users who sent the emails to [Service Desk](../../user/project/service_desk.md) are not notified of issue creation or comments on their issues.
+Incoming emails still raise issues, but the users who sent the emails to [Service Desk](../../user/project/service_desk/index.md) are not notified of issue creation or comments on their issues.
 
 ### Webhooks
 
-[Project and group webhooks](../../user/project/integrations/webhooks.md), and [system hooks](../system_hooks.md) are suppressed. The relevant Sidekiq jobs fail 4 times and then disappear, while Silent Mode is enabled. [Issue 393639](https://gitlab.com/gitlab-org/gitlab/-/issues/393639) discusses preventing the Sidekiq jobs from running in the first place.
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/393639) in GitLab 16.3.
+
+[Project and group webhooks](../../user/project/integrations/webhooks.md) and [system hooks](../system_hooks.md) are suppressed.
+
+In GitLab 16.2 and earlier, webhooks were triggered when Silent Mode was enabled, but the [webhook HTTP request was blocked](#outbound-http-requests).
 
 Triggering webhook tests via the UI results in HTTP status 500 responses.
 
diff --git a/doc/administration/smime_signing_email.md b/doc/administration/smime_signing_email.md
index 5748c4d32d4..06bf4978a6b 100644
--- a/doc/administration/smime_signing_email.md
+++ b/doc/administration/smime_signing_email.md
@@ -65,7 +65,7 @@ For self-compiled installations:
      ca_certs_file: /etc/pki/smime/certs/gitlab_cas.crt
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 The key must be readable by the GitLab system user (`git` by default).
 
diff --git a/doc/administration/snippets/index.md b/doc/administration/snippets/index.md
index 9b485140070..b59432b0b9e 100644
--- a/doc/administration/snippets/index.md
+++ b/doc/administration/snippets/index.md
@@ -5,47 +5,28 @@ group: Source Code
 info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments"
 ---
 
-# Snippets settings **(FREE SELF)**
+# Snippets **(FREE SELF)**
 
-Adjust the snippets' settings of your GitLab instance.
-
-## Snippets content size limit
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31133) in GitLab 12.6.
-
-You can set a maximum content size limit for snippets. This limit can prevent
-abuse of the feature. The default value is **52428800 Bytes** (50 MB).
-
-### How does it work?
-
-The content size limit is applied when a snippet is created or updated.
-
-This limit doesn't affect existing snippets until they're updated and their
+You can configure a maximum size for a snippet to prevent abuse.
+The default limit is 52428800 bytes (50 MB).
+The limit is applied when a snippet is created or updated.
+The limit does not affect existing snippets unless they are updated and their
 content changes.
 
-### Snippets size limit configuration
+## Configure the snippet size limit
 
-This setting is not available through the [Admin Area settings](../settings/index.md).
-To configure this setting, use either the Rails console
+To configure the snippet size limit, you can use the Rails console
 or the [Application settings API](../../api/settings.md).
 
-NOTE:
-The value of the limit **must** be in bytes.
-
-#### Through the Rails console
+The limit **must** be in bytes.
 
-The steps to configure this setting through the Rails console are:
+This setting is not available in the [Admin Area settings](../settings/index.md).
 
-1. Start the Rails console:
+### Use the Rails console
 
-   ```shell
-   # For Omnibus installations
-   sudo gitlab-rails console
-
-   # For installations from source
-   sudo -u git -H bundle exec rails console -e production
-   ```
+To configure this setting through the Rails console:
 
+1. [Start the Rails console](../operations/rails_console.md#starting-a-rails-console-session).
 1. Update the snippets maximum file size:
 
    ```ruby
@@ -58,19 +39,23 @@ To retrieve the current value, start the Rails console and run:
   Gitlab::CurrentSettings.snippet_size_limit
   ```
 
-#### Through the API
+### Use the API
 
-To set the snippets size limit through the Application Settings API (similar to
-[updating any other setting](../../api/settings.md#change-application-settings)), use this command:
+To set the limit by using the Application Settings API
+(similar to [updating any other setting](../../api/settings.md#change-application-settings)),
+use this command:
 
 ```shell
-curl --request PUT --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/application/settings?snippet_size_limit=52428800"
+curl --request PUT \
+  --header "PRIVATE-TOKEN: <your_access_token>"
+  --url "https://gitlab.example.com/api/v4/application/settings?snippet_size_limit=52428800"
 ```
 
 You can also use the API to [retrieve the current value](../../api/settings.md#get-current-application-settings).
 
 ```shell
-curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/application/settings"
+curl --header "PRIVATE-TOKEN: <your_access_token>" \
+  --url "https://gitlab.example.com/api/v4/application/settings"
 ```
 
 ## Related topics
diff --git a/doc/administration/static_objects_external_storage.md b/doc/administration/static_objects_external_storage.md
index c7a22da38de..6b232ddc25f 100644
--- a/doc/administration/static_objects_external_storage.md
+++ b/doc/administration/static_objects_external_storage.md
@@ -5,7 +5,7 @@ info: "To determine the technical writer assigned to the Stage/Group associated
 type: reference
 ---
 
-# External storage for static objects **(FREE)**
+# External storage for static objects **(FREE SELF)**
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31025) in GitLab 12.3.
 
diff --git a/doc/administration/system_hooks.md b/doc/administration/system_hooks.md
index dcacacaf47b..1c84d4fadb8 100644
--- a/doc/administration/system_hooks.md
+++ b/doc/administration/system_hooks.md
@@ -57,6 +57,7 @@ To create a system hook:
 1. On the left sidebar, expand the top-most chevron (**{chevron-down}**).
 1. Select **Admin Area**.
 1. On the left sidebar, select **System Hooks**.
+1. Select **Add new webhook**.
 1. Provide the **URL** and **Secret Token**.
 1. Select the checkbox next to each optional **Trigger** you want to enable.
 1. Select **Enable SSL verification**, if desired.
diff --git a/doc/administration/terraform_state.md b/doc/administration/terraform_state.md
index 2b738f975ba..90b030e6e13 100644
--- a/doc/administration/terraform_state.md
+++ b/doc/administration/terraform_state.md
@@ -4,7 +4,7 @@ group: Environments
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments
 ---
 
-# Terraform state administration **(FREE)**
+# Terraform state administration **(FREE SELF)**
 
 > [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/2673) in GitLab 12.10.
 
@@ -14,7 +14,7 @@ files. The files are encrypted before being stored. This feature is enabled by d
 The storage location of these files defaults to:
 
 - `/var/opt/gitlab/gitlab-rails/shared/terraform_state` for Linux package installations.
-- `/home/git/gitlab/shared/terraform_state` for source installations.
+- `/home/git/gitlab/shared/terraform_state` for self-compiled installations.
 
 These locations can be configured using the options described below.
 
@@ -59,7 +59,7 @@ For self-compiled installations:
      enabled: false
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Using local storage
 
@@ -88,7 +88,7 @@ For self-compiled installations:
      storage_path: /mnt/storage/terraform_state
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Using object storage **(FREE SELF)**
 
@@ -102,8 +102,8 @@ This configuration relies on valid credentials to be configured already.
 
 The following settings are:
 
-- Nested under `terraform_state:` and then `object_store:` on source installations.
 - Prefixed by `terraform_state_object_store_` on Linux package installations.
+- Nested under `terraform_state:` and then `object_store:` on self-compiled installations.
 
 | Setting | Description | Default |
 |---------|-------------|---------|
@@ -180,7 +180,9 @@ This section describes the earlier configuration format.
 
 See [the available connection settings for different providers](object_storage.md#configure-the-connection-settings).
 
-**In Omnibus installations:**
+::Tabs
+
+:::TabTitle Linux package (Omnibus)
 
 1. Edit `/etc/gitlab/gitlab.rb` and add the following lines; replacing with
    the values you want:
@@ -210,7 +212,7 @@ See [the available connection settings for different providers](object_storage.m
 1. Save the file and [reconfigure GitLab](restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 1. [Migrate any existing local states to the object storage](#migrate-to-object-storage)
 
-**In installations from source:**
+:::TabTitle Self-compiled (source)
 
 1. Edit `/home/git/gitlab/config/gitlab.yml` and add or amend the following
    lines:
@@ -228,5 +230,7 @@ See [the available connection settings for different providers](object_storage.m
          region: eu-central-1
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 1. [Migrate any existing local states to the object storage](#migrate-to-object-storage)
+
+::EndTabs
diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
index f164e8ccbad..00e56568a1b 100644
--- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
+++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
@@ -40,7 +40,7 @@ This content has been converted to a Rake task, see [verify database values can
 
 ### Transfer mirror users and tokens to a single service account
 
-This content has been moved to [Troubleshooting Repository mirroring](../../user/project/repository/mirror/index.md#transfer-mirror-users-and-tokens-to-a-single-service-account-in-rails-console).
+This content has been moved to [Troubleshooting Repository mirroring](../../user/project/repository/mirror/troubleshooting.md#transfer-mirror-users-and-tokens-to-a-single-service-account-in-rails-console).
 
 ## Merge requests
 
diff --git a/doc/administration/troubleshooting/postgresql.md b/doc/administration/troubleshooting/postgresql.md
index 88e0d4e6c6b..53bde005232 100644
--- a/doc/administration/troubleshooting/postgresql.md
+++ b/doc/administration/troubleshooting/postgresql.md
@@ -26,7 +26,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 
 - [Connect to the PostgreSQL console](https://docs.gitlab.com/omnibus/settings/database.html#connecting-to-the-bundled-postgresql-database).
 
-- [Omnibus database procedures](https://docs.gitlab.com/omnibus/settings/database.html) including:
+- [Database procedures for Linux package installations](https://docs.gitlab.com/omnibus/settings/database.html) including:
   - SSL: enabling, disabling, and verifying.
   - Enabling Write Ahead Log (WAL) archiving.
   - Using an external (non-Omnibus) PostgreSQL installation; and backing it up.
@@ -44,7 +44,7 @@ This section is for links to information elsewhere in the GitLab documentation.
 
 - Consuming PostgreSQL from [within CI runners](../../ci/services/postgres.md).
 
-- Managing Omnibus PostgreSQL versions [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html).
+- Managing PostgreSQL versions on Linux package installations [from the development docs](https://docs.gitlab.com/omnibus/development/managing-postgresql-versions.html).
 
 - [PostgreSQL scaling](../postgresql/replication_and_failover.md)
   - Including [troubleshooting](../postgresql/replication_and_failover.md#troubleshooting)
@@ -107,7 +107,7 @@ PostgreSQL defaults:
 
 Comments in issue [#30528](https://gitlab.com/gitlab-org/gitlab/-/issues/30528)
 indicate that these should both be set to at least a number of minutes for all
-Omnibus GitLab installations (so they don't hang indefinitely). However, 15 s
+Linux package installations (so they don't hang indefinitely). However, 15 s
 for `statement_timeout` is very short, and is only effective if the
 underlying infrastructure is very performant.
 
@@ -138,7 +138,8 @@ postgresql['idle_in_transaction_session_timeout'] = '60s'
 Once saved, [reconfigure GitLab](../restart_gitlab.md#reconfigure-a-linux-package-installation) for the changes to take effect.
 
 NOTE:
-These are Omnibus GitLab settings. If an external database, such as a customer's PostgreSQL installation or Amazon RDS is being used, these values don't get set, and would have to be set externally.
+These are Linux package settings. If an external database, such as a customer's PostgreSQL installation
+or Amazon RDS is being used, these values don't get set, and would have to be set externally.
 
 ### Temporarily changing the statement timeout
 
@@ -211,10 +212,8 @@ To resolve the error, run `VACUUM` manually:
 
 ### GitLab database requirements
 
-The [database requirements](../../install/requirements.md#database) for GitLab include:
-
-- Support for MySQL was removed in [GitLab 12.1](../../update/index.md#1210).
-- Review and install the [required extension list](../../install/postgresql_extensions.md).
+See [database requirements](../../install/requirements.md#database) and review and install the
+[required extension list](../../install/postgresql_extensions.md).
 
 ### Serialization errors in the `production/sidekiq` log
 
diff --git a/doc/administration/uploads.md b/doc/administration/uploads.md
index d8f82f13875..6259304d68e 100644
--- a/doc/administration/uploads.md
+++ b/doc/administration/uploads.md
@@ -52,7 +52,7 @@ _The uploads are stored by default in
      base_dir: uploads
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 
 ## Using object storage **(FREE SELF)**
 
@@ -134,5 +134,5 @@ _The uploads are stored by default in
          region: eu-central-1
    ```
 
-1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
+1. Save the file and [restart GitLab](restart_gitlab.md#self-compiled-installations) for the changes to take effect.
 1. Migrate any existing local uploads to the object storage with the [`gitlab:uploads:migrate:all` Rake task](raketasks/uploads/migrate.md).
diff --git a/doc/administration/user_settings.md b/doc/administration/user_settings.md
index f480f05f6a2..43e88bf6eac 100644
--- a/doc/administration/user_settings.md
+++ b/doc/administration/user_settings.md
@@ -38,7 +38,7 @@ For self-compiled installations:
    # default_can_create_group: false  # default: true
    ```
 
-1. [Restart GitLab](restart_gitlab.md#installations-from-source).
+1. [Restart GitLab](restart_gitlab.md#self-compiled-installations).
 
 ### Prevent existing users from creating top-level groups
 
@@ -70,4 +70,4 @@ For self-compiled installations:
    # username_changing_enabled: false # default: true - User can change their username/namespace
    ```
 
-1. [Restart GitLab](restart_gitlab.md#installations-from-source).
+1. [Restart GitLab](restart_gitlab.md#self-compiled-installations).
diff --git a/doc/administration/whats-new.md b/doc/administration/whats-new.md
index b34b054d87c..8e1fc412a62 100644
--- a/doc/administration/whats-new.md
+++ b/doc/administration/whats-new.md
@@ -4,7 +4,7 @@ group: unassigned
 info: For assistance with this What's new page, see https://about.gitlab.com/handbook/product/ux/technical-writing/#assignments-to-other-projects-and-subjects.
 ---
 
-# What's new **(FREE)**
+# What's new **(FREE ALL)**
 
 You can view some of the highlights from the last 10
 GitLab versions in the **What's new** feature. It lists new features available in different