From 5fcbfcefe70fe671b4df1b9d95bf837334d997c3 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Tue, 4 Mar 2025 15:37:56 +0100
Subject: [PATCH 01/26] apply link changes for 8.6

---
 .../amazon/openshift/terraform-setup.md       |  7 ++---
 .../deploy/openshift/redhat-openshift.md      | 26 +++++++++----------
 2 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 6244bd4fc07..0101210d7cf 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -160,7 +160,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -278,7 +278,8 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/cluster.tf
+
    ```
 
    :::caution Camunda Terraform module
@@ -333,7 +334,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/main/aws/rosa-hcp/camunda-versions/8.6)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index 0cd7b349b07..47e588bb924 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -62,7 +62,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -180,7 +180,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/zeebe-gateway-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
    ```
 
    The domain used by the Zeebe Gateway for gRPC is `zeebe-$DOMAIN_NAME` which different from the one used for the rest, namely `$DOMAIN_NAME`, to avoid any conflicts. It is also important to note that the port used for gRPC is `443`.
@@ -190,7 +190,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/operate-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/operate-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
@@ -200,7 +200,7 @@ The actual configuration properties can be reviewed [in the Operate configuratio
    Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/tasklist-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/tasklist-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
@@ -208,7 +208,7 @@ The actual configuration properties can be reviewed [in the Tasklist configurati
 1. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -218,7 +218,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -251,7 +251,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -271,7 +271,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -280,7 +280,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -305,7 +305,7 @@ cat generated-values.yml
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -313,7 +313,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -323,13 +323,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.6/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/install-chart.sh
 ```
 
 This command:

From dcbaecebfc7aac8aa154bc6192f7162d034a75c7 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 5 Mar 2025 11:00:49 +0100
Subject: [PATCH 02/26] wip files

---
 .../setup/deploy/amazon/openshift/terraform-setup.md        | 6 +++---
 .../deploy/amazon/openshift/terraform-setup-dual-region.md  | 6 +++---
 .../setup/deploy/amazon/openshift/terraform-setup.md        | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 0101210d7cf..6daf0011e1f 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -185,7 +185,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-tf-rosa) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -286,7 +286,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -298,7 +298,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access, if you want to grant access to other users, please follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md).
+5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 2b8c9770e9d..d7bbb03d605 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -161,7 +161,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-tf-rosa) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
 It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html).
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-dual-region/README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
 
 :::
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index ad771e0e119..3d0a37285df 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -181,7 +181,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-tf-rosa) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -281,7 +281,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -293,7 +293,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md).
+5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 

From 97e4b9c28233f042a96eb42df215af29045adfd5 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 5 Mar 2025 11:17:50 +0100
Subject: [PATCH 03/26] update links

---
 .../deploy/amazon/openshift/terraform-setup-dual-region.md  | 6 +++---
 .../setup/deploy/amazon/openshift/terraform-setup.md        | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 2b8c9770e9d..7f931d27e9e 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -161,7 +161,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-tf-rosa) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
 It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html).
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-dual-region//README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
 
 :::
 
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 60fc898ed65..196c6e16605 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -181,7 +181,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-tf-rosa) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-single-region/) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -281,7 +281,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -293,7 +293,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-tf-rosa/blob/v2.0.0/modules/rosa-hcp/README.md).
+5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 

From 1a335c547204cde9c56a07c78ad014d7f6c8a743 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Thu, 6 Mar 2025 11:43:42 +0100
Subject: [PATCH 04/26] re-integrate proper link structure

---
 .../setup/deploy/amazon/aws-ec2.md            |  4 +-
 .../openshift/terraform-setup-dual-region.md  | 22 ++++----
 .../amazon/openshift/terraform-setup.md       | 12 ++---
 .../setup/deploy/openshift/dual-region.md     | 46 ++++++++--------
 .../deploy/openshift/redhat-openshift.md      | 24 ++++-----
 .../amazon/openshift/terraform-setup.md       | 12 ++---
 .../deploy/openshift/redhat-openshift.md      | 26 ++++-----
 .../openshift/terraform-setup-dual-region.md  | 22 ++++----
 .../amazon/openshift/terraform-setup.md       | 12 ++---
 .../setup/deploy/openshift/dual-region.md     | 54 +++++++++----------
 .../deploy/openshift/redhat-openshift.md      | 22 ++++----
 11 files changed, 129 insertions(+), 127 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/aws-ec2.md b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
index e84d23ee40f..85a81294329 100644
--- a/docs/self-managed/setup/deploy/amazon/aws-ec2.md
+++ b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
@@ -55,7 +55,7 @@ Alternatively, the same setup can run with a single AWS EC2 instance, but be awa
 
 - An AWS account to create any resources within AWS.
   - On a high level, permissions are required on the **ec2**, **iam**, **elasticloadbalancing**, **kms**, **logs**, and **es** level.
-  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/blob/main/aws/ec2/example/policy.json).
+  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/ec2/example/policy.json).
 - Terraform (1.7+)
 - Unix based Operating System (OS) with ssh and sftp
   - Windows may be used with [Cygwin](https://www.cygwin.com/) or [Windows WSL](https://learn.microsoft.com/en-us/windows/wsl/install) but has not been tested
@@ -80,6 +80,8 @@ Therefore, we recommend extending or reusing some elements of the Terraform exam
 
 The provided reference architecture repository allows you to directly reuse and extend the existing Terraform example base. This sample implementation is flexible to extend to your own needs without the potential limitations of a Terraform module.
 
+# TODO: fix this one
+
 ```sh
 wget https://github.com/camunda/camunda-deployment-references/archive/refs/heads/main.zip
 ```
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 7f931d27e9e..e600de4b1b1 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -161,7 +161,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
 It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html).
@@ -287,21 +287,21 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
    This configuration will use the previously created S3 bucket for storing the Terraform state file:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/clusters/config.tf
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
    ```
 
 5. Create a file named `cluster_region_1.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 1:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
    ```
 
 6. Create a file named `cluster_region_2.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 2:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
    ```
 
 7. After setting up the terraform files and ensuring your AWS authentication is configured, initialize your Terraform project, then, initialize Terraform to configure the backend and download necessary provider plugins:
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-dual-region//README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region//README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
 
 :::
 
@@ -417,13 +417,13 @@ We'll re-use the previously configured S3 bucket to store the state of the peeri
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/peering/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
 ```
 
 Alongside the `config.tf` file, create a file called `peering.tf` to reference the peering configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/peering/peering.tf
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
 ```
 
 One cluster will be referenced as the **owner**, and the other as the **accepter**.
@@ -497,13 +497,13 @@ We'll re-use the previously configured S3 bucket to store the state of the backu
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
 ```
 
 Finally, create a file called `backup_bucket.tf` to reference the elastic backup bucket configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
 ```
 
 This bucket configuration follows [multiple best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).  
@@ -568,7 +568,7 @@ The `BACKUP_BUCKET_REGION` will define the region of the bucket, you can pick on
 
 ### Reference files
 
-You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/main/aws/rosa-hcp-dual-region/terraform)
+You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 196c6e16605..9661196d1ab 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -156,7 +156,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -181,7 +181,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-single-region/) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -274,14 +274,14 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/cluster.tf
    ```
 
    :::caution Camunda Terraform module
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -293,7 +293,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.8/aws/openshift/rosa-hcp-single-region/README.md).
+5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -329,7 +329,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/feature/openshift-ra-standard/aws/rosa-hcp/camunda-versions/8.7)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/docs/self-managed/setup/deploy/openshift/dual-region.md b/docs/self-managed/setup/deploy/openshift/dual-region.md
index 2fe3290fa94..0f1e6ba1480 100644
--- a/docs/self-managed/setup/deploy/openshift/dual-region.md
+++ b/docs/self-managed/setup/deploy/openshift/dual-region.md
@@ -110,7 +110,7 @@ Later in this guide, we will refer to it as **first cluster**.
 2. The following manifest will create a namespace for the management cluster, enable the [open-cluster-management operator](https://open-cluster-management.io/) and the [associated subscription](https://docs.openshift.com/container-platform/4.17/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster).
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Apply the manifests to enable ACM:
@@ -133,7 +133,7 @@ Later in this guide, we will refer to it as **first cluster**.
    In this setup, the first cluster will act as the central hub, managing the second cluster. This capability enables the deployment and management of components on the second cluster directly from the first cluster.
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    :::caution Known issue: may not work correctly with the manifest
@@ -170,7 +170,7 @@ Later in this guide, we will refer to it as **first cluster**.
 4. With the MultiClusterHub created, the last step is to create a `ManagedClusterSet` which is a group of managed clusters. With a `ManagedClusterSet`, you can manage access to all of the managed clusters in the group together
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
    Apply the manifest:
@@ -188,7 +188,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `managed-cluster.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
      ```
 
    - The cluster’s associated addon configuration will be managed using the following manifest.
@@ -196,7 +196,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save it as `klusterlet-config.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
      ```
 
    - To import a cluster, you must store the associated authentication token.
@@ -204,13 +204,13 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `auto-import-cluster-secret.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
      ```
 
    - Finally, import each cluster into the Managed Cluster Set and verify that they can be reached and managed successfully:
 
      ```bash reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
+     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
      ```
 
 ### Submariner
@@ -258,7 +258,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    Select the first node and apply the required label:
 
    ```bash reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
    ```
 
 3. Deployment of Submariner on the clusters:
@@ -266,7 +266,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    - Save the following file as `submariner.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
      ```
 
      :::note Cluster naming
@@ -314,7 +314,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    <summary>Example Submariner check successfull output</summary>
 
 ```text reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/output.txt
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
 ```
 
 </details>
@@ -323,7 +323,7 @@ For more comprehensive details regarding the verification tests for Submariner u
 
 **Debugging the Submariner setup:**
 
-If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
+If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
 With this pod, you will be able to check flow openings, service resolution, and other network-related aspects.  
 Troubleshooting requires examining all the underlying mechanisms of Submariner. Therefore, we also encourage you to read the [Submariner troubleshooting guide](https://submariner.io/operations/troubleshooting/).
 
@@ -337,7 +337,7 @@ Before proceeding with the installation, ensure the required information is avai
 Review and adjust the following environment script to match your specific configuration:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/export_environment_prerequisites.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
 ```
 
 _If you are unsure about the values of the backup bucket, please refer to the [S3 backup bucket module setup](/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md#s3-backup-bucket-module-setup) as a reference for implementation._
@@ -363,7 +363,7 @@ The Elasticsearch backup [bucket is tied to a specific region](https://docs.aws.
 The following script will create the required namespaces and secrets used to reference the bucket access.
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/setup_ns_secrets.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
 ```
 
 Save it as `setup_ns_secrets.sh` and execute it:
@@ -380,7 +380,7 @@ Throughout this guide, you will add and merge values into these files to configu
 
 - Save the following file as both `values-region-1.yml` and `values-region-2.yml` to serve as the base configuration:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/helm-values/values-base.yml
+  https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
   ```
 
 :::warning Merging YAML files
@@ -396,12 +396,12 @@ Set up the region ID using a unique integer for each region:
 
 - Add the following YAML configuration to your `values-region-1.yml`:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/helm-values/values-region-1.yml
+  https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
   ```
 - Add the following YAML configuration to your `values-region-2.yml`:
 
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/helm-values/values-region-2.yml
+  https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
   ```
 
 **Security Context Constraints (SCCs)**
@@ -416,7 +416,7 @@ For custom configurations or specific requirements, please refer to the [install
 Before deploying, some values in the value files need to be updated. To assist with generating these values, save the following Bash script as `generate_zeebe_helm_values.sh`:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/generate_zeebe_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
 ```
 
 Then, source the output of the script. By doing so, we can reuse the values later for substitution, instead of manually adjusting the values files. You will be prompted to specify the number of Zeebe brokers (total number of Zeebe brokers in both Kubernetes clusters), for a dual-region setup we recommend `8`, resulting in four brokers per region:
@@ -438,7 +438,7 @@ Make sure that the variable `CLUSTER_1_NAME` is set to the name of your first cl
 Once you've prepared each region's value file (`values-region-1.yml` and `values-region-2.yml`) file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/generate_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -446,7 +446,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-
 With the value files for each region configured, you can now install Camunda 8 using Helm. Execute the following commands:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/install_chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
 ```
 
 This command:
@@ -468,7 +468,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 Once Camunda is deployed across the two clusters, the next step is to expose each service to Submariner so it can be resolved by the other cluster:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/export_services_submariner.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
 ```
 
 Alternatively, you can manage each service individually using the `ServiceExport` Custom Resource Definition (CRD).
@@ -489,13 +489,13 @@ metadata:
 For each cluster, verify the status of the exported services with this script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/verify_exported_services.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
 ```
 
 To monitor the progress of the installation, save and execute the following script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/verify_installation_completed.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
 ```
 
 Save it as `verify_installation_completed.sh`, make it executable, and run it:
@@ -525,7 +525,7 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/zeebe-http-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
    ```
 
    </details>
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 8b98b2b1a12..80e5f307142 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -66,7 +66,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -189,7 +189,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -201,7 +201,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -211,7 +211,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -231,7 +231,7 @@ For guidance on installing an Ingress controller, you can refer to the [Ingress
 
 Do not confuse the [ingress-nginx controller](https://github.com/kubernetes/ingress-nginx) with the [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift) that is endorsed by Red Hat for usage with OpenShift. Despite very similar names, they are two different products.
 
-If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/main/examples/ingress-resources/grpc-services/README.md).
+If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/tree/stable/8.8/examples/ingress-resources/grpc-services/README.md).
 
 :::
 
@@ -244,7 +244,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -264,7 +264,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -273,7 +273,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -298,7 +298,7 @@ cat generated-values.yml
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -306,7 +306,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -316,13 +316,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
 ```
 
 This command:
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 6daf0011e1f..24034dffc6e 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -160,7 +160,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -185,7 +185,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.6/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -278,7 +278,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/cluster.tf
 
    ```
 
@@ -286,7 +286,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.6/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -298,7 +298,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access, if you want to grant access to other users, please follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md).
+5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.6/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -334,7 +334,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index 47e588bb924..ff774575a54 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -62,7 +62,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -180,7 +180,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
    ```
 
    The domain used by the Zeebe Gateway for gRPC is `zeebe-$DOMAIN_NAME` which different from the one used for the rest, namely `$DOMAIN_NAME`, to avoid any conflicts. It is also important to note that the port used for gRPC is `443`.
@@ -190,7 +190,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/operate-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/operate-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
@@ -200,7 +200,7 @@ The actual configuration properties can be reviewed [in the Operate configuratio
    Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/tasklist-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/tasklist-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
@@ -208,7 +208,7 @@ The actual configuration properties can be reviewed [in the Tasklist configurati
 1. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -218,7 +218,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -251,7 +251,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -271,7 +271,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -280,7 +280,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -305,7 +305,7 @@ cat generated-values.yml
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -313,7 +313,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -323,13 +323,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/install-chart.sh
 ```
 
 This command:
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index d7bbb03d605..03509a6162b 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -161,7 +161,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
 It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html).
@@ -287,21 +287,21 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
    This configuration will use the previously created S3 bucket for storing the Terraform state file:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/clusters/config.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
    ```
 
 5. Create a file named `cluster_region_1.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 1:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
    ```
 
 6. Create a file named `cluster_region_2.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 2:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
    ```
 
 7. After setting up the terraform files and ensuring your AWS authentication is configured, initialize your Terraform project, then, initialize Terraform to configure the backend and download necessary provider plugins:
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-dual-region/README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
 
 :::
 
@@ -417,13 +417,13 @@ We'll re-use the previously configured S3 bucket to store the state of the peeri
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/peering/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
 ```
 
 Alongside the `config.tf` file, create a file called `peering.tf` to reference the peering configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/peering/peering.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
 ```
 
 One cluster will be referenced as the **owner**, and the other as the **accepter**.
@@ -497,13 +497,13 @@ We'll re-use the previously configured S3 bucket to store the state of the backu
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
 ```
 
 Finally, create a file called `backup_bucket.tf` to reference the elastic backup bucket configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
 ```
 
 This bucket configuration follows [multiple best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).  
@@ -568,7 +568,7 @@ The `BACKUP_BUCKET_REGION` will define the region of the bucket, you can pick on
 
 ### Reference files
 
-You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/main/aws/rosa-hcp-dual-region/terraform)
+You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 3d0a37285df..27b43f8a2e6 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -156,7 +156,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -181,7 +181,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -274,14 +274,14 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/cluster.tf
    ```
 
    :::caution Camunda Terraform module
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -293,7 +293,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/camunda/8.7/aws/openshift/rosa-hcp-single-region/README.md).
+5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -329,7 +329,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/main/aws/rosa-hcp/camunda-versions/8.7)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
index 3722ab2d172..581f6159c63 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
@@ -110,13 +110,13 @@ Later in this guide, we will refer to it as **first cluster**.
 2. The following manifest will create a namespace for the management cluster, enable the [open-cluster-management operator](https://open-cluster-management.io/) and the [associated subscription](https://docs.openshift.com/container-platform/4.17/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster).
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Apply the manifests to enable ACM:
 
    ```bash
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/main/aws/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Verify that the installation succeeded:
@@ -133,7 +133,7 @@ Later in this guide, we will refer to it as **first cluster**.
    In this setup, the first cluster will act as the central hub, managing the second cluster. This capability enables the deployment and management of components on the second cluster directly from the first cluster.
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    :::caution Known issue: may not work correctly with the manifest
@@ -147,7 +147,7 @@ Later in this guide, we will refer to it as **first cluster**.
    Apply the manifest:
 
    ```bash
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/main/aws/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    Wait until the status shows as "Running." This process can take up to 10 minutes:
@@ -170,7 +170,7 @@ Later in this guide, we will refer to it as **first cluster**.
 4. With the MultiClusterHub created, the last step is to create a `ManagedClusterSet` which is a group of managed clusters. With a `ManagedClusterSet`, you can manage access to all of the managed clusters in the group together
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
    Apply the manifest:
@@ -178,7 +178,7 @@ Later in this guide, we will refer to it as **first cluster**.
    ```bash
    oc --context $CLUSTER_1_NAME get mch -A
 
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/main/aws/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
 5. After creating the Managed Cluster Set, the next step is to import clusters into the set.
@@ -188,7 +188,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `managed-cluster.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
      ```
 
    - The cluster’s associated addon configuration will be managed using the following manifest.
@@ -196,7 +196,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save it as `klusterlet-config.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
      ```
 
    - To import a cluster, you must store the associated authentication token.
@@ -204,13 +204,13 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `auto-import-cluster-secret.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
      ```
 
    - Finally, import each cluster into the Managed Cluster Set and verify that they can be reached and managed successfully:
 
      ```bash reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
      ```
 
 ### Submariner
@@ -258,7 +258,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    Select the first node and apply the required label:
 
    ```bash reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
    ```
 
 3. Deployment of Submariner on the clusters:
@@ -266,7 +266,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    - Save the following file as `submariner.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
      ```
 
      :::note Cluster naming
@@ -314,7 +314,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    <summary>Example Submariner check successfull output</summary>
 
 ```text reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/output.txt
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
 ```
 
 </details>
@@ -323,7 +323,7 @@ For more comprehensive details regarding the verification tests for Submariner u
 
 **Debugging the Submariner setup:**
 
-If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
+If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
 With this pod, you will be able to check flow openings, service resolution, and other network-related aspects.  
 Troubleshooting requires examining all the underlying mechanisms of Submariner. Therefore, we also encourage you to read the [Submariner troubleshooting guide](https://submariner.io/operations/troubleshooting/).
 
@@ -337,7 +337,7 @@ Before proceeding with the installation, ensure the required information is avai
 Review and adjust the following environment script to match your specific configuration:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/export_environment_prerequisites.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
 ```
 
 _If you are unsure about the values of the backup bucket, please refer to the [S3 backup bucket module setup](/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md#s3-backup-bucket-module-setup) as a reference for implementation._
@@ -363,7 +363,7 @@ The Elasticsearch backup [bucket is tied to a specific region](https://docs.aws.
 The following script will create the required namespaces and secrets used to reference the bucket access.
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/setup_ns_secrets.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
 ```
 
 Save it as `setup_ns_secrets.sh` and execute it:
@@ -380,7 +380,7 @@ Throughout this guide, you will add and merge values into these files to configu
 
 - Save the following file as both `values-region-1.yml` and `values-region-2.yml` to serve as the base configuration:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/helm-values/values-base.yml
+  https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
   ```
 
 :::warning Merging YAML files
@@ -396,12 +396,12 @@ Set up the region ID using a unique integer for each region:
 
 - Add the following YAML configuration to your `values-region-1.yml`:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/helm-values/values-region-1.yml
+  https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
   ```
 - Add the following YAML configuration to your `values-region-2.yml`:
 
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/helm-values/values-region-2.yml
+  https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
   ```
 
 **Security Context Constraints (SCCs)**
@@ -416,7 +416,7 @@ For custom configurations or specific requirements, please refer to the [install
 Before deploying, some values in the value files need to be updated. To assist with generating these values, save the following Bash script as `generate_zeebe_helm_values.sh`:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/generate_zeebe_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
 ```
 
 Then, source the output of the script. By doing so, we can reuse the values later for substitution, instead of manually adjusting the values files. You will be prompted to specify the number of Zeebe brokers (total number of Zeebe brokers in both Kubernetes clusters), for a dual-region setup we recommend `8`, resulting in four brokers per region:
@@ -438,7 +438,7 @@ Make sure that the variable `CLUSTER_1_NAME` is set to the name of your first cl
 Once you've prepared each region's value file (`values-region-1.yml` and `values-region-2.yml`) file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/generate_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -446,7 +446,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-
 With the value files for each region configured, you can now install Camunda 8 using Helm. Execute the following commands:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/install_chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
 ```
 
 This command:
@@ -468,7 +468,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 Once Camunda is deployed across the two clusters, the next step is to expose each service to Submariner so it can be resolved by the other cluster:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/export_services_submariner.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
 ```
 
 Alternatively, you can manage each service individually using the `ServiceExport` Custom Resource Definition (CRD).
@@ -489,13 +489,13 @@ metadata:
 For each cluster, verify the status of the exported services with this script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/verify_exported_services.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
 ```
 
 To monitor the progress of the installation, save and execute the following script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/verify_installation_completed.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
 ```
 
 Save it as `verify_installation_completed.sh`, make it executable, and run it:
@@ -528,7 +528,7 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/zeebe-http-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
    ```
 
    </details>
@@ -552,7 +552,7 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp-dual-region/procedure/camunda/8.7/zbctl-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/zbctl-output.txt
    ```
 
    </details>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 8b98b2b1a12..b870a223ad0 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -66,7 +66,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -189,7 +189,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -201,7 +201,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -211,7 +211,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -244,7 +244,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -264,7 +264,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -273,7 +273,7 @@ https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -298,7 +298,7 @@ cat generated-values.yml
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -306,7 +306,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -316,13 +316,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/main/aws/rosa-hcp/camunda-versions/8.7/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
 ```
 
 This command:

From 23421bcf5ebe9251c094adf1411a86b5e3064399 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Thu, 6 Mar 2025 11:50:07 +0100
Subject: [PATCH 05/26] fix blob

---
 .../setup/deploy/amazon/aws-ec2.md            |  2 +-
 .../openshift/terraform-setup-dual-region.md  | 14 +++---
 .../amazon/openshift/terraform-setup.md       |  4 +-
 .../setup/deploy/openshift/dual-region.md     | 46 +++++++++----------
 .../deploy/openshift/redhat-openshift.md      | 24 +++++-----
 5 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/aws-ec2.md b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
index 85a81294329..a2eced6490f 100644
--- a/docs/self-managed/setup/deploy/amazon/aws-ec2.md
+++ b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
@@ -55,7 +55,7 @@ Alternatively, the same setup can run with a single AWS EC2 instance, but be awa
 
 - An AWS account to create any resources within AWS.
   - On a high level, permissions are required on the **ec2**, **iam**, **elasticloadbalancing**, **kms**, **logs**, and **es** level.
-  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/ec2/example/policy.json).
+  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/ec2/example/policy.json).
 - Terraform (1.7+)
 - Unix based Operating System (OS) with ssh and sftp
   - Windows may be used with [Cygwin](https://www.cygwin.com/) or [Windows WSL](https://learn.microsoft.com/en-us/windows/wsl/install) but has not been tested
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index e600de4b1b1..a339b2e2f6c 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -287,21 +287,21 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
    This configuration will use the previously created S3 bucket for storing the Terraform state file:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
    ```
 
 5. Create a file named `cluster_region_1.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 1:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
    ```
 
 6. Create a file named `cluster_region_2.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 2:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
    ```
 
 7. After setting up the terraform files and ensuring your AWS authentication is configured, initialize your Terraform project, then, initialize Terraform to configure the backend and download necessary provider plugins:
@@ -417,13 +417,13 @@ We'll re-use the previously configured S3 bucket to store the state of the peeri
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
 ```
 
 Alongside the `config.tf` file, create a file called `peering.tf` to reference the peering configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
 ```
 
 One cluster will be referenced as the **owner**, and the other as the **accepter**.
@@ -497,13 +497,13 @@ We'll re-use the previously configured S3 bucket to store the state of the backu
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
 ```
 
 Finally, create a file called `backup_bucket.tf` to reference the elastic backup bucket configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
 ```
 
 This bucket configuration follows [multiple best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).  
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 9661196d1ab..b15fa83523a 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -156,7 +156,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -274,7 +274,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/cluster.tf
    ```
 
    :::caution Camunda Terraform module
diff --git a/docs/self-managed/setup/deploy/openshift/dual-region.md b/docs/self-managed/setup/deploy/openshift/dual-region.md
index 0f1e6ba1480..71b1fcab059 100644
--- a/docs/self-managed/setup/deploy/openshift/dual-region.md
+++ b/docs/self-managed/setup/deploy/openshift/dual-region.md
@@ -110,7 +110,7 @@ Later in this guide, we will refer to it as **first cluster**.
 2. The following manifest will create a namespace for the management cluster, enable the [open-cluster-management operator](https://open-cluster-management.io/) and the [associated subscription](https://docs.openshift.com/container-platform/4.17/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster).
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Apply the manifests to enable ACM:
@@ -133,7 +133,7 @@ Later in this guide, we will refer to it as **first cluster**.
    In this setup, the first cluster will act as the central hub, managing the second cluster. This capability enables the deployment and management of components on the second cluster directly from the first cluster.
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    :::caution Known issue: may not work correctly with the manifest
@@ -170,7 +170,7 @@ Later in this guide, we will refer to it as **first cluster**.
 4. With the MultiClusterHub created, the last step is to create a `ManagedClusterSet` which is a group of managed clusters. With a `ManagedClusterSet`, you can manage access to all of the managed clusters in the group together
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
    Apply the manifest:
@@ -188,7 +188,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `managed-cluster.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
      ```
 
    - The cluster’s associated addon configuration will be managed using the following manifest.
@@ -196,7 +196,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save it as `klusterlet-config.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
      ```
 
    - To import a cluster, you must store the associated authentication token.
@@ -204,13 +204,13 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `auto-import-cluster-secret.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
      ```
 
    - Finally, import each cluster into the Managed Cluster Set and verify that they can be reached and managed successfully:
 
      ```bash reference
-     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
      ```
 
 ### Submariner
@@ -258,7 +258,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    Select the first node and apply the required label:
 
    ```bash reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
    ```
 
 3. Deployment of Submariner on the clusters:
@@ -266,7 +266,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    - Save the following file as `submariner.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
      ```
 
      :::note Cluster naming
@@ -314,7 +314,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    <summary>Example Submariner check successfull output</summary>
 
 ```text reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
 ```
 
 </details>
@@ -323,7 +323,7 @@ For more comprehensive details regarding the verification tests for Submariner u
 
 **Debugging the Submariner setup:**
 
-If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
+If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
 With this pod, you will be able to check flow openings, service resolution, and other network-related aspects.  
 Troubleshooting requires examining all the underlying mechanisms of Submariner. Therefore, we also encourage you to read the [Submariner troubleshooting guide](https://submariner.io/operations/troubleshooting/).
 
@@ -337,7 +337,7 @@ Before proceeding with the installation, ensure the required information is avai
 Review and adjust the following environment script to match your specific configuration:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
 ```
 
 _If you are unsure about the values of the backup bucket, please refer to the [S3 backup bucket module setup](/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md#s3-backup-bucket-module-setup) as a reference for implementation._
@@ -363,7 +363,7 @@ The Elasticsearch backup [bucket is tied to a specific region](https://docs.aws.
 The following script will create the required namespaces and secrets used to reference the bucket access.
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
 ```
 
 Save it as `setup_ns_secrets.sh` and execute it:
@@ -380,7 +380,7 @@ Throughout this guide, you will add and merge values into these files to configu
 
 - Save the following file as both `values-region-1.yml` and `values-region-2.yml` to serve as the base configuration:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
+  https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
   ```
 
 :::warning Merging YAML files
@@ -396,12 +396,12 @@ Set up the region ID using a unique integer for each region:
 
 - Add the following YAML configuration to your `values-region-1.yml`:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
+  https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
   ```
 - Add the following YAML configuration to your `values-region-2.yml`:
 
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
+  https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
   ```
 
 **Security Context Constraints (SCCs)**
@@ -416,7 +416,7 @@ For custom configurations or specific requirements, please refer to the [install
 Before deploying, some values in the value files need to be updated. To assist with generating these values, save the following Bash script as `generate_zeebe_helm_values.sh`:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
 ```
 
 Then, source the output of the script. By doing so, we can reuse the values later for substitution, instead of manually adjusting the values files. You will be prompted to specify the number of Zeebe brokers (total number of Zeebe brokers in both Kubernetes clusters), for a dual-region setup we recommend `8`, resulting in four brokers per region:
@@ -438,7 +438,7 @@ Make sure that the variable `CLUSTER_1_NAME` is set to the name of your first cl
 Once you've prepared each region's value file (`values-region-1.yml` and `values-region-2.yml`) file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -446,7 +446,7 @@ https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aw
 With the value files for each region configured, you can now install Camunda 8 using Helm. Execute the following commands:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
 ```
 
 This command:
@@ -468,7 +468,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 Once Camunda is deployed across the two clusters, the next step is to expose each service to Submariner so it can be resolved by the other cluster:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
 ```
 
 Alternatively, you can manage each service individually using the `ServiceExport` Custom Resource Definition (CRD).
@@ -489,13 +489,13 @@ metadata:
 For each cluster, verify the status of the exported services with this script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
 ```
 
 To monitor the progress of the installation, save and execute the following script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
 ```
 
 Save it as `verify_installation_completed.sh`, make it executable, and run it:
@@ -525,7 +525,7 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
    ```
 
    </details>
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 80e5f307142..dd23eec7d28 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -66,7 +66,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -189,7 +189,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -201,7 +201,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -211,7 +211,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -231,7 +231,7 @@ For guidance on installing an Ingress controller, you can refer to the [Ingress
 
 Do not confuse the [ingress-nginx controller](https://github.com/kubernetes/ingress-nginx) with the [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift) that is endorsed by Red Hat for usage with OpenShift. Despite very similar names, they are two different products.
 
-If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/tree/stable/8.8/examples/ingress-resources/grpc-services/README.md).
+If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/stable/8.8/examples/ingress-resources/grpc-services/README.md).
 
 :::
 
@@ -244,7 +244,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -264,7 +264,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -273,7 +273,7 @@ https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aw
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -298,7 +298,7 @@ cat generated-values.yml
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -306,7 +306,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -316,13 +316,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
 ```
 
 This command:

From 0cc377961540d6fc2e19515d3cfafc56868043ac Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Thu, 6 Mar 2025 12:10:16 +0100
Subject: [PATCH 06/26] fix 8.6 broker

---
 .../self-managed/setup/deploy/openshift/redhat-openshift.md    | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index ff774575a54..bc6c1f85f85 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -176,7 +176,8 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 
    - The second TLS secret is used on the exposed route, referenced as `camunda-platform-external-certificate`. For example, this would be the same TLS secret used for Ingress. We also configure the Zeebe Gateway Ingress to create a [Re-encrypt Route](https://docs.openshift.com/container-platform/latest/networking/routes/route-configuration.html#nw-ingress-creating-a-route-via-an-ingress_route-configuration).
 
-   Finally, we mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Zeebe Gateway Pod.
+   Finally, we mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Zeebe Gateway Pod and the Zeebe Pod to configure both [broker security](/self-managed/zeebe-deployment/configuration/broker.md#zeebebrokernetworksecurity) and gateway security.
+
    Update your `values.yml` file with the following:
 
    ```yaml reference

From 6177ba06ceb22f9e8af6a9f162346e6a42c35b5a Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Thu, 6 Mar 2025 12:16:13 +0100
Subject: [PATCH 07/26] extract check topology command

---
 .../setup/deploy/amazon/amazon-eks/eks-helm.md   | 16 ++++------------
 .../setup/deploy/amazon/amazon-eks/eks-helm.md   | 16 ++++------------
 .../setup/deploy/amazon/amazon-eks/eks-helm.md   | 16 ++++------------
 3 files changed, 12 insertions(+), 36 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 98546da1333..cdb4e3bf12e 100644
--- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -654,21 +654,13 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 
 </Tabs>
 
-Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token.
+Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
-```shell
-export TOKEN=$(curl --location --request POST "${ZEEBE_AUTHORIZATION_SERVER_URL}" \
---header "Content-Type: application/x-www-form-urlencoded" \
---data-urlencode "client_id=${ZEEBE_CLIENT_ID}" \
---data-urlencode "client_secret=${ZEEBE_CLIENT_SECRET}" \
---data-urlencode "grant_type=client_credentials" | jq '.access_token' -r)
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
-Use the stored token, in our case `TOKEN`, to use the REST API to print the cluster topology.
-
-```shell
-curl --header "Authorization: Bearer ${TOKEN}" "${ZEEBE_ADDRESS_REST}/v2/topology"
-```
+<!-- TODO: also integrate the expected output as part of golden files -->
 
 ...and results in the following output:
 
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 306ef0a96b7..510d5da2cbf 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -656,21 +656,13 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 
 </Tabs>
 
-Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token.
+Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
-```shell
-export TOKEN=$(curl --location --request POST "${ZEEBE_AUTHORIZATION_SERVER_URL}" \
---header "Content-Type: application/x-www-form-urlencoded" \
---data-urlencode "client_id=${ZEEBE_CLIENT_ID}" \
---data-urlencode "client_secret=${ZEEBE_CLIENT_SECRET}" \
---data-urlencode "grant_type=client_credentials" | jq '.access_token' -r)
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
-Use the stored token, in our case `TOKEN`, to use the REST API to print the cluster topology.
-
-```shell
-curl --header "Authorization: Bearer ${TOKEN}" "${ZEEBE_ADDRESS_REST}/v2/topology"
-```
+<!-- TODO: also integrate the expected output as part of golden files -->
 
 ...and results in the following output:
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 71244313b09..111809e3052 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -657,21 +657,13 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 
 </Tabs>
 
-Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token.
+Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
-```shell
-export TOKEN=$(curl --location --request POST "${ZEEBE_AUTHORIZATION_SERVER_URL}" \
---header "Content-Type: application/x-www-form-urlencoded" \
---data-urlencode "client_id=${ZEEBE_CLIENT_ID}" \
---data-urlencode "client_secret=${ZEEBE_CLIENT_SECRET}" \
---data-urlencode "grant_type=client_credentials" | jq '.access_token' -r)
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
-Use the stored token, in our case `TOKEN`, to use the REST API to print the cluster topology.
-
-```shell
-curl --header "Authorization: Bearer ${TOKEN}" "${ZEEBE_ADDRESS_REST}/v2/topology"
-```
+<!-- TODO: also integrate the expected output as part of golden files -->
 
 ...and results in the following output:
 

From 35319a4edf97c72d93bab2064eb7dda7f5801d22 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Thu, 6 Mar 2025 12:30:42 +0100
Subject: [PATCH 08/26] doc as code inc

---
 .../deploy/amazon/amazon-eks/eks-helm.md      | 95 +------------------
 .../deploy/openshift/redhat-openshift.md      | 39 ++------
 .../deploy/amazon/amazon-eks/eks-helm.md      | 95 +------------------
 .../deploy/openshift/redhat-openshift.md      | 39 ++------
 .../deploy/amazon/amazon-eks/eks-helm.md      | 95 +------------------
 .../deploy/openshift/redhat-openshift.md      | 39 ++------
 6 files changed, 39 insertions(+), 363 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index cdb4e3bf12e..9ffd8bfc278 100644
--- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -452,17 +452,8 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 
 You can track the progress of the installation using the following command:
 
-```bash
-watch -n 5 '
-  kubectl get pods -n camunda --output=wide;
-  if [ $(kubectl get pods -n camunda --field-selector=status.phase!=Running -o name | wc -l) -eq 0 ] &&
-     [ $(kubectl get pods -n camunda -o json | jq -r ".items[] | select(.status.containerStatuses[]?.ready == false)" | wc -l) -eq 0 ];
-  then
-    echo "All pods are Running and Healthy - Installation completed!";
-  else
-    echo "Some pods are not Running or Healthy";
-  fi
-'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -660,92 +651,14 @@ Generate a temporary token to access the REST API, then capture the value of the
 https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
-<!-- TODO: also integrate the expected output as part of golden files -->
-
 ...and results in the following output:
 
 <details>
   <summary>Example output</summary>
   <summary>
 
-```shell
-{
-  "brokers": [
-    {
-      "nodeId": 0,
-      "host": "camunda-zeebe-0.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "leader",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "follower",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    },
-    {
-      "nodeId": 1,
-      "host": "camunda-zeebe-1.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "leader",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "follower",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    },
-    {
-      "nodeId": 2,
-      "host": "camunda-zeebe-2.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "leader",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    }
-  ],
-  "clusterSize": 3,
-  "partitionsCount": 3,
-  "replicationFactor": 3,
-  "gatewayVersion": "8.6.0"
-}
+```json reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index dd23eec7d28..22cc872e476 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -95,18 +95,10 @@ To use these routes for the Zeebe Gateway, configure this through Ingress as wel
 
 The route created by OpenShift will use a domain to provide access to the platform. By default, you can use the OpenShift applications domain, but any other domain supported by the router can also be used.
 
-To retrieve the OpenShift applications domain (used as an example here), run the following command:
+To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
-```bash
-export OPENSHIFT_APPS_DOMAIN=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}')
-```
-
-Next, define the route domain that will be used for the Camunda 8 deployment. For example:
-
-```bash
-export DOMAIN_NAME="camunda.$OPENSHIFT_APPS_DOMAIN"
-
-echo "Camunda 8 will be reachable from $DOMAIN_NAME"
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -123,12 +115,8 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 
 Alternatively, if you use a dedicated IngressController for the deployment:
 
-```bash
-# List your IngressControllers
-oc -n openshift-ingress-operator get ingresscontrollers
-
-# Replace <ingresscontroller_name> with your IngressController name
-oc -n openshift-ingress-operator get ingresscontrollers/<ingresscontroller_name> -o json | jq '.metadata.annotations."ingress.operator.openshift.io/default-enable-http2"'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -141,8 +129,8 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 
 **IngressController configuration:**
 
-```bash
-oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**
@@ -339,17 +327,8 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 
 You can track the progress of the installation using the following command:
 
-```bash
-watch -n 5 '
-  kubectl get pods -n camunda --output=wide;
-  if [ $(kubectl get pods -n camunda --field-selector=status.phase!=Running -o name | wc -l) -eq 0 ] &&
-     [ $(kubectl get pods -n camunda -o json | jq -r ".items[] | select(.status.containerStatuses[]?.ready == false)" | wc -l) -eq 0 ];
-  then
-    echo "All pods are Running and Healthy - Installation completed!";
-  else
-    echo "Some pods are not Running or Healthy";
-  fi
-'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 510d5da2cbf..ebc33d2a1a2 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -451,17 +451,8 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 
 You can track the progress of the installation using the following command:
 
-```bash
-watch -n 5 '
-  kubectl get pods -n camunda --output=wide;
-  if [ $(kubectl get pods -n camunda --field-selector=status.phase!=Running -o name | wc -l) -eq 0 ] &&
-     [ $(kubectl get pods -n camunda -o json | jq -r ".items[] | select(.status.containerStatuses[]?.ready == false)" | wc -l) -eq 0 ];
-  then
-    echo "All pods are Running and Healthy - Installation completed!";
-  else
-    echo "Some pods are not Running or Healthy";
-  fi
-'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -662,92 +653,14 @@ Generate a temporary token to access the REST API, then capture the value of the
 https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
-<!-- TODO: also integrate the expected output as part of golden files -->
-
 ...and results in the following output:
 
 <details>
   <summary>Example output</summary>
   <summary>
 
-```shell
-{
-  "brokers": [
-    {
-      "nodeId": 0,
-      "host": "camunda-zeebe-0.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "leader",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "follower",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    },
-    {
-      "nodeId": 1,
-      "host": "camunda-zeebe-1.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "leader",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "follower",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    },
-    {
-      "nodeId": 2,
-      "host": "camunda-zeebe-2.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "leader",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    }
-  ],
-  "clusterSize": 3,
-  "partitionsCount": 3,
-  "replicationFactor": 3,
-  "gatewayVersion": "8.6.0"
-}
+```json reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index bc6c1f85f85..cec74d93b0b 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -91,18 +91,10 @@ To use these routes for the Zeebe Gateway, configure this through Ingress as wel
 
 The route created by OpenShift will use a domain to provide access to the platform. By default, you can use the OpenShift applications domain, but any other domain supported by the router can also be used.
 
-To retrieve the OpenShift applications domain (used as an example here), run the following command:
+To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
-```bash
-export OPENSHIFT_APPS_DOMAIN=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}')
-```
-
-Next, define the route domain that will be used for the Camunda 8 deployment. For example:
-
-```bash
-export DOMAIN_NAME="camunda.$OPENSHIFT_APPS_DOMAIN"
-
-echo "Camunda 8 will be reachable from $DOMAIN_NAME"
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -119,12 +111,8 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 
 Alternatively, if you use a dedicated IngressController for the deployment:
 
-```bash
-# List your IngressControllers
-oc -n openshift-ingress-operator get ingresscontrollers
-
-# Replace <ingresscontroller_name> with your IngressController name
-oc -n openshift-ingress-operator get ingresscontrollers/<ingresscontroller_name> -o json | jq '.metadata.annotations."ingress.operator.openshift.io/default-enable-http2"'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -137,8 +125,8 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 
 **IngressController configuration:**
 
-```bash
-oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**
@@ -347,17 +335,8 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 
 You can track the progress of the installation using the following command:
 
-```bash
-watch -n 5 '
-  kubectl get pods -n camunda --output=wide;
-  if [ $(kubectl get pods -n camunda --field-selector=status.phase!=Running -o name | wc -l) -eq 0 ] &&
-     [ $(kubectl get pods -n camunda -o json | jq -r ".items[] | select(.status.containerStatuses[]?.ready == false)" | wc -l) -eq 0 ];
-  then
-    echo "All pods are Running and Healthy - Installation completed!";
-  else
-    echo "Some pods are not Running or Healthy";
-  fi
-'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 111809e3052..e7a79c5ebff 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -452,17 +452,8 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 
 You can track the progress of the installation using the following command:
 
-```bash
-watch -n 5 '
-  kubectl get pods -n camunda --output=wide;
-  if [ $(kubectl get pods -n camunda --field-selector=status.phase!=Running -o name | wc -l) -eq 0 ] &&
-     [ $(kubectl get pods -n camunda -o json | jq -r ".items[] | select(.status.containerStatuses[]?.ready == false)" | wc -l) -eq 0 ];
-  then
-    echo "All pods are Running and Healthy - Installation completed!";
-  else
-    echo "Some pods are not Running or Healthy";
-  fi
-'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -663,92 +654,14 @@ Generate a temporary token to access the REST API, then capture the value of the
 https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
-<!-- TODO: also integrate the expected output as part of golden files -->
-
 ...and results in the following output:
 
 <details>
   <summary>Example output</summary>
   <summary>
 
-```shell
-{
-  "brokers": [
-    {
-      "nodeId": 0,
-      "host": "camunda-zeebe-0.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "leader",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "follower",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    },
-    {
-      "nodeId": 1,
-      "host": "camunda-zeebe-1.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "leader",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "follower",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    },
-    {
-      "nodeId": 2,
-      "host": "camunda-zeebe-2.camunda-zeebe",
-      "port": 26501,
-      "partitions": [
-        {
-          "partitionId": 1,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 2,
-          "role": "follower",
-          "health": "healthy"
-        },
-        {
-          "partitionId": 3,
-          "role": "leader",
-          "health": "healthy"
-        }
-      ],
-      "version": "8.6.0"
-    }
-  ],
-  "clusterSize": 3,
-  "partitionsCount": 3,
-  "replicationFactor": 3,
-  "gatewayVersion": "8.6.0"
-}
+```json reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index b870a223ad0..5915ed64eb9 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -95,18 +95,10 @@ To use these routes for the Zeebe Gateway, configure this through Ingress as wel
 
 The route created by OpenShift will use a domain to provide access to the platform. By default, you can use the OpenShift applications domain, but any other domain supported by the router can also be used.
 
-To retrieve the OpenShift applications domain (used as an example here), run the following command:
+To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
-```bash
-export OPENSHIFT_APPS_DOMAIN=$(oc get ingresses.config.openshift.io cluster -o jsonpath='{.spec.domain}')
-```
-
-Next, define the route domain that will be used for the Camunda 8 deployment. For example:
-
-```bash
-export DOMAIN_NAME="camunda.$OPENSHIFT_APPS_DOMAIN"
-
-echo "Camunda 8 will be reachable from $DOMAIN_NAME"
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -123,12 +115,8 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 
 Alternatively, if you use a dedicated IngressController for the deployment:
 
-```bash
-# List your IngressControllers
-oc -n openshift-ingress-operator get ingresscontrollers
-
-# Replace <ingresscontroller_name> with your IngressController name
-oc -n openshift-ingress-operator get ingresscontrollers/<ingresscontroller_name> -o json | jq '.metadata.annotations."ingress.operator.openshift.io/default-enable-http2"'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -141,8 +129,8 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 
 **IngressController configuration:**
 
-```bash
-oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**
@@ -339,17 +327,8 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 
 You can track the progress of the installation using the following command:
 
-```bash
-watch -n 5 '
-  kubectl get pods -n camunda --output=wide;
-  if [ $(kubectl get pods -n camunda --field-selector=status.phase!=Running -o name | wc -l) -eq 0 ] &&
-     [ $(kubectl get pods -n camunda -o json | jq -r ".items[] | select(.status.containerStatuses[]?.ready == false)" | wc -l) -eq 0 ];
-  then
-    echo "All pods are Running and Healthy - Installation completed!";
-  else
-    echo "Some pods are not Running or Healthy";
-  fi
-'
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8

From 260afa1e86b36201aadc06045e46489a9bbecde9 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Fri, 7 Mar 2025 13:12:39 +0100
Subject: [PATCH 09/26] update instructions

---
 .../deploy/amazon/amazon-eks/eks-helm.md      |  8 +---
 .../amazon/openshift/terraform-setup.md       | 28 ++++++++-----
 .../deploy/openshift/redhat-openshift.md      |  9 ++--
 .../deploy/amazon/amazon-eks/eks-helm.md      |  8 +---
 .../amazon/openshift/terraform-setup.md       | 38 +++++++++--------
 .../deploy/openshift/redhat-openshift.md      | 41 +++++++++----------
 .../deploy/amazon/amazon-eks/eks-helm.md      |  8 +---
 .../amazon/openshift/terraform-setup.md       | 28 ++++++++-----
 .../deploy/openshift/redhat-openshift.md      |  9 ++--
 9 files changed, 87 insertions(+), 90 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 9ffd8bfc278..d8b902d3dd1 100644
--- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -408,12 +408,8 @@ identity:
 
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
-```bash
-# generate the final values
-envsubst < values.yml > generated-values.yml
-
-# print the result
-cat generated-values.yml
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/8.8/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index b15fa83523a..7f27edc62df 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -73,6 +73,16 @@ Following this tutorial and steps will result in:
 
 ## 1. Configure AWS and initialize Terraform
 
+### Obtain a copy of the reference architecture
+
+The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
+
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
+```
+
+With the reference architecture downloaded and extracted, you can proceed with the remaining steps outlined in this documentation. Ensure that you are in the correct directory before continuing with further instructions.
+
 ### Terraform prerequisites
 
 To manage the infrastructure for Camunda 8 on AWS using Terraform, we need to set up Terraform's backend to store the state file remotely in an S3 bucket. This ensures secure and persistent storage of the state file.
@@ -151,7 +161,7 @@ Now, follow these steps to create the S3 bucket with versioning enabled:
 
 This S3 bucket will now securely store your Terraform state files with versioning enabled.
 
-#### Create a `config.tf` with the following setup
+#### Edit the `config.tf` with the following setup
 
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
@@ -259,8 +269,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 #### Set up the ROSA cluster module
 
-1. Create a `cluster.tf` file in the same directory as your `config.tf` file.
-2. Add the following content to your newly created `cluster.tf` file to utilize the provided module:
+1. Edit the `cluster.tf` file in the same directory as your `config.tf` file:
 
    :::note Configure your cluster
 
@@ -285,15 +294,15 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    :::
 
-3. [Initialize](#initialize-terraform) Terraform for this module using the following Terraform command:
+2. [Initialize](#initialize-terraform) Terraform for this module using the following Terraform command:
 
    ```bash
    terraform init -backend-config="bucket=$S3_TF_BUCKET_NAME" -backend-config="key=$S3_TF_BUCKET_KEY"
    ```
 
-4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
+3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -339,11 +348,8 @@ You can access the created OpenShift cluster using the following steps:
 
 Set up the required environment variables:
 
-```shell
-export CLUSTER_NAME="$(terraform console <<<local.rosa_cluster_name | jq -r)"
-export CLUSTER_API_URL=$(terraform output -raw openshift_api_url)
-export CLUSTER_ADMIN_USERNAME="$(terraform console <<<local.rosa_admin_username | jq -r)"
-export CLUSTER_ADMIN_PASSWORD="$(terraform console <<<local.rosa_admin_password | jq -r)"
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/8.8/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
 ```
 
 If you want to give cluster administrator access to the created user, this is not required for a standard installation but can be useful for debugging:
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 22cc872e476..626a1e8c372 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -31,6 +31,7 @@ We conduct testing and ensure compatibility against the following OpenShift vers
 
 | OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
 | ----------------- | --------------------------------------------------------------------------------- |
+| 4.18.x            | GA of 4.19 + 3 Months                                                             |
 | 4.17.x            | June 27, 2025                                                                     |
 | 4.16.x            | December 27, 2025                                                                 |
 | 4.15.x            | August 27, 2025                                                                   |
@@ -275,12 +276,8 @@ Some components are not enabled by default in this deployment. For more informat
 
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
-```bash
-# generate the final values
-envsubst < values.yml > generated-values.yml
-
-# print the result
-cat generated-values.yml
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/8.8/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index ebc33d2a1a2..7b0d1d40ded 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -407,12 +407,8 @@ identity:
 
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
-```bash
-# generate the final values
-envsubst < values.yml > generated-values.yml
-
-# print the result
-cat generated-values.yml
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 24034dffc6e..f4985e838d9 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -77,6 +77,16 @@ Following this tutorial and steps will result in:
 
 ## 1. Configure AWS and initialize Terraform
 
+### Obtain a copy of the reference architecture
+
+The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
+
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
+```
+
+With the reference architecture downloaded and extracted, you can proceed with the remaining steps outlined in this documentation. Ensure that you are in the correct directory before continuing with further instructions.
+
 ### Terraform prerequisites
 
 To manage the infrastructure for Camunda 8 on AWS using Terraform, we need to set up Terraform's backend to store the state file remotely in an S3 bucket. This ensures secure and persistent storage of the state file.
@@ -155,12 +165,12 @@ Now, follow these steps to create the S3 bucket with versioning enabled:
 
 This S3 bucket will now securely store your Terraform state files with versioning enabled.
 
-#### Create a `config.tf` with the following setup
+#### Edit the `config.tf` with the following setup
 
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -185,7 +195,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.6/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -263,8 +273,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 #### Set up the ROSA cluster module
 
-1. Create a `cluster.tf` file in the same directory as your `config.tf` file.
-2. Add the following content to your newly created `cluster.tf` file to utilize the provided module:
+1. Edit the `cluster.tf` file in the same directory as your `config.tf` file:
 
    :::note Configure your cluster
 
@@ -278,7 +287,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/cluster.tf
 
    ```
 
@@ -286,19 +295,19 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.6/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
-3. [Initialize](#initialize-terraform) Terraform for this module using the following Terraform command:
+2. [Initialize](#initialize-terraform) Terraform for this module using the following Terraform command:
 
    ```bash
    terraform init -backend-config="bucket=$S3_TF_BUCKET_NAME" -backend-config="key=$S3_TF_BUCKET_KEY"
    ```
 
-4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access, if you want to grant access to other users, please follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
+3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access, if you want to grant access to other users, please follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.6/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -334,7 +343,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
@@ -344,11 +353,8 @@ You can access the created OpenShift cluster using the following steps:
 
 Set up the required environment variables:
 
-```shell
-export CLUSTER_NAME="$(terraform console <<<local.rosa_cluster_name | jq -r)"
-export CLUSTER_API_URL=$(terraform output -raw openshift_api_url)
-export CLUSTER_ADMIN_USERNAME="$(terraform console <<<local.rosa_admin_username | jq -r)"
-export CLUSTER_ADMIN_PASSWORD="$(terraform console <<<local.rosa_admin_password | jq -r)"
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
 ```
 
 If you want to give cluster administrator access to the created user, this is not required for a standard installation but can be useful for debugging:
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index cec74d93b0b..30090563039 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -31,6 +31,7 @@ We conduct testing and ensure compatibility against the following OpenShift vers
 
 | OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
 | ----------------- | --------------------------------------------------------------------------------- |
+| 4.18.x            | GA of 4.19 + 3 Months                                                             |
 | 4.17.x            | June 27, 2025                                                                     |
 | 4.16.x            | December 27, 2025                                                                 |
 | 4.15.x            | August 27, 2025                                                                   |
@@ -62,7 +63,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -94,7 +95,7 @@ The route created by OpenShift will use a domain to provide access to the platfo
 To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/setup-application-domain.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -112,7 +113,7 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 Alternatively, if you use a dedicated IngressController for the deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -169,7 +170,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
    ```
 
    The domain used by the Zeebe Gateway for gRPC is `zeebe-$DOMAIN_NAME` which different from the one used for the rest, namely `$DOMAIN_NAME`, to avoid any conflicts. It is also important to note that the port used for gRPC is `443`.
@@ -179,7 +180,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/operate-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/operate-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
@@ -189,7 +190,7 @@ The actual configuration properties can be reviewed [in the Operate configuratio
    Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/tasklist-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/tasklist-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
@@ -197,7 +198,7 @@ The actual configuration properties can be reviewed [in the Tasklist configurati
 1. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -207,7 +208,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -240,7 +241,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -260,7 +261,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -269,7 +270,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -283,18 +284,14 @@ Some components are not enabled by default in this deployment. For more informat
 
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
-```bash
-# generate the final values
-envsubst < values.yml > generated-values.yml
-
-# print the result
-cat generated-values.yml
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -302,7 +299,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -312,13 +309,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/install-chart.sh
 ```
 
 This command:
@@ -336,7 +333,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index e7a79c5ebff..d055a3aa411 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -408,12 +408,8 @@ identity:
 
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
-```bash
-# generate the final values
-envsubst < values.yml > generated-values.yml
-
-# print the result
-cat generated-values.yml
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 27b43f8a2e6..064a15b38d2 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -73,6 +73,16 @@ Following this tutorial and steps will result in:
 
 ## 1. Configure AWS and initialize Terraform
 
+### Obtain a copy of the reference architecture
+
+The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
+
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
+```
+
+With the reference architecture downloaded and extracted, you can proceed with the remaining steps outlined in this documentation. Ensure that you are in the correct directory before continuing with further instructions.
+
 ### Terraform prerequisites
 
 To manage the infrastructure for Camunda 8 on AWS using Terraform, we need to set up Terraform's backend to store the state file remotely in an S3 bucket. This ensures secure and persistent storage of the state file.
@@ -151,7 +161,7 @@ Now, follow these steps to create the S3 bucket with versioning enabled:
 
 This S3 bucket will now securely store your Terraform state files with versioning enabled.
 
-#### Create a `config.tf` with the following setup
+#### Edit the `config.tf` with the following setup
 
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
@@ -259,8 +269,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 #### Set up the ROSA cluster module
 
-1. Create a `cluster.tf` file in the same directory as your `config.tf` file.
-2. Add the following content to your newly created `cluster.tf` file to utilize the provided module:
+1. Edit the `cluster.tf` file in the same directory as your `config.tf` file:
 
    :::note Configure your cluster
 
@@ -285,15 +294,15 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    :::
 
-3. [Initialize](#initialize-terraform) Terraform for this module using the following Terraform command:
+2. [Initialize](#initialize-terraform) Terraform for this module using the following Terraform command:
 
    ```bash
    terraform init -backend-config="bucket=$S3_TF_BUCKET_NAME" -backend-config="key=$S3_TF_BUCKET_KEY"
    ```
 
-4. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
+3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-5. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -339,11 +348,8 @@ You can access the created OpenShift cluster using the following steps:
 
 Set up the required environment variables:
 
-```shell
-export CLUSTER_NAME="$(terraform console <<<local.rosa_cluster_name | jq -r)"
-export CLUSTER_API_URL=$(terraform output -raw openshift_api_url)
-export CLUSTER_ADMIN_USERNAME="$(terraform console <<<local.rosa_admin_username | jq -r)"
-export CLUSTER_ADMIN_PASSWORD="$(terraform console <<<local.rosa_admin_password | jq -r)"
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/8.7/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
 ```
 
 If you want to give cluster administrator access to the created user, this is not required for a standard installation but can be useful for debugging:
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 5915ed64eb9..1536dd4fe83 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -31,6 +31,7 @@ We conduct testing and ensure compatibility against the following OpenShift vers
 
 | OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
 | ----------------- | --------------------------------------------------------------------------------- |
+| 4.18.x            | GA of 4.19 + 3 Months                                                             |
 | 4.17.x            | June 27, 2025                                                                     |
 | 4.16.x            | December 27, 2025                                                                 |
 | 4.15.x            | August 27, 2025                                                                   |
@@ -275,12 +276,8 @@ Some components are not enabled by default in this deployment. For more informat
 
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
-```bash
-# generate the final values
-envsubst < values.yml > generated-values.yml
-
-# print the result
-cat generated-values.yml
+```bash reference
+https://github.com/camunda/camunda-deployment-references/blob/8.7/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:

From 6888e8f0dba2c1f213911f700950193c62021e64 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Tue, 11 Mar 2025 14:55:18 +0100
Subject: [PATCH 10/26] update links for 8.7

---
 .../deploy/amazon/amazon-eks/eks-helm.md      |  8 +--
 .../openshift/terraform-setup-dual-region.md  | 22 ++++----
 .../amazon/openshift/terraform-setup.md       | 16 +++---
 .../setup/deploy/openshift/dual-region.md     | 54 +++++++++----------
 .../deploy/openshift/redhat-openshift.md      | 28 +++++-----
 5 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index d055a3aa411..39a1f7b5b56 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -409,7 +409,7 @@ identity:
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
@@ -449,7 +449,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -647,7 +647,7 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
 ...and results in the following output:
@@ -657,7 +657,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic
   <summary>
 
 ```json reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 03509a6162b..3c4e7cc63c8 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -161,7 +161,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
 It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html).
@@ -287,21 +287,21 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
    This configuration will use the previously created S3 bucket for storing the Terraform state file:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
    ```
 
 5. Create a file named `cluster_region_1.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 1:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
    ```
 
 6. Create a file named `cluster_region_2.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 2:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
    ```
 
 7. After setting up the terraform files and ensuring your AWS authentication is configured, initialize your Terraform project, then, initialize Terraform to configure the backend and download necessary provider plugins:
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
 
 :::
 
@@ -417,13 +417,13 @@ We'll re-use the previously configured S3 bucket to store the state of the peeri
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
 ```
 
 Alongside the `config.tf` file, create a file called `peering.tf` to reference the peering configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
 ```
 
 One cluster will be referenced as the **owner**, and the other as the **accepter**.
@@ -497,13 +497,13 @@ We'll re-use the previously configured S3 bucket to store the state of the backu
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
 ```
 
 Finally, create a file called `backup_bucket.tf` to reference the elastic backup bucket configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
 ```
 
 This bucket configuration follows [multiple best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).  
@@ -568,7 +568,7 @@ The `BACKUP_BUCKET_REGION` will define the region of the bucket, you can pick on
 
 ### Reference files
 
-You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-dual-region/terraform)
+You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 064a15b38d2..12a54a9bf7f 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -75,10 +75,10 @@ Following this tutorial and steps will result in:
 
 ### Obtain a copy of the reference architecture
 
-The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
+The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
 ```
 
 With the reference architecture downloaded and extracted, you can proceed with the remaining steps outlined in this documentation. Ensure that you are in the correct directory before continuing with further instructions.
@@ -166,7 +166,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -191,7 +191,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -283,14 +283,14 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/cluster.tf
    ```
 
    :::caution Camunda Terraform module
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -302,7 +302,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -338,7 +338,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/stable/8.7/aws/openshift/rosa-hcp-single-region/)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
index 581f6159c63..20089bab784 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
@@ -110,13 +110,13 @@ Later in this guide, we will refer to it as **first cluster**.
 2. The following manifest will create a namespace for the management cluster, enable the [open-cluster-management operator](https://open-cluster-management.io/) and the [associated subscription](https://docs.openshift.com/container-platform/4.17/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster).
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Apply the manifests to enable ACM:
 
    ```bash
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Verify that the installation succeeded:
@@ -133,7 +133,7 @@ Later in this guide, we will refer to it as **first cluster**.
    In this setup, the first cluster will act as the central hub, managing the second cluster. This capability enables the deployment and management of components on the second cluster directly from the first cluster.
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    :::caution Known issue: may not work correctly with the manifest
@@ -147,7 +147,7 @@ Later in this guide, we will refer to it as **first cluster**.
    Apply the manifest:
 
    ```bash
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    Wait until the status shows as "Running." This process can take up to 10 minutes:
@@ -170,7 +170,7 @@ Later in this guide, we will refer to it as **first cluster**.
 4. With the MultiClusterHub created, the last step is to create a `ManagedClusterSet` which is a group of managed clusters. With a `ManagedClusterSet`, you can manage access to all of the managed clusters in the group together
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
    Apply the manifest:
@@ -178,7 +178,7 @@ Later in this guide, we will refer to it as **first cluster**.
    ```bash
    oc --context $CLUSTER_1_NAME get mch -A
 
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
 5. After creating the Managed Cluster Set, the next step is to import clusters into the set.
@@ -188,7 +188,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `managed-cluster.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
      ```
 
    - The cluster’s associated addon configuration will be managed using the following manifest.
@@ -196,7 +196,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save it as `klusterlet-config.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
      ```
 
    - To import a cluster, you must store the associated authentication token.
@@ -204,13 +204,13 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `auto-import-cluster-secret.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
      ```
 
    - Finally, import each cluster into the Managed Cluster Set and verify that they can be reached and managed successfully:
 
      ```bash reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
      ```
 
 ### Submariner
@@ -258,7 +258,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    Select the first node and apply the required label:
 
    ```bash reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
    ```
 
 3. Deployment of Submariner on the clusters:
@@ -266,7 +266,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    - Save the following file as `submariner.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
      ```
 
      :::note Cluster naming
@@ -314,7 +314,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    <summary>Example Submariner check successfull output</summary>
 
 ```text reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
 ```
 
 </details>
@@ -323,7 +323,7 @@ For more comprehensive details regarding the verification tests for Submariner u
 
 **Debugging the Submariner setup:**
 
-If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
+If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
 With this pod, you will be able to check flow openings, service resolution, and other network-related aspects.  
 Troubleshooting requires examining all the underlying mechanisms of Submariner. Therefore, we also encourage you to read the [Submariner troubleshooting guide](https://submariner.io/operations/troubleshooting/).
 
@@ -337,7 +337,7 @@ Before proceeding with the installation, ensure the required information is avai
 Review and adjust the following environment script to match your specific configuration:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
 ```
 
 _If you are unsure about the values of the backup bucket, please refer to the [S3 backup bucket module setup](/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md#s3-backup-bucket-module-setup) as a reference for implementation._
@@ -363,7 +363,7 @@ The Elasticsearch backup [bucket is tied to a specific region](https://docs.aws.
 The following script will create the required namespaces and secrets used to reference the bucket access.
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
 ```
 
 Save it as `setup_ns_secrets.sh` and execute it:
@@ -380,7 +380,7 @@ Throughout this guide, you will add and merge values into these files to configu
 
 - Save the following file as both `values-region-1.yml` and `values-region-2.yml` to serve as the base configuration:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
+  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
   ```
 
 :::warning Merging YAML files
@@ -396,12 +396,12 @@ Set up the region ID using a unique integer for each region:
 
 - Add the following YAML configuration to your `values-region-1.yml`:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
+  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
   ```
 - Add the following YAML configuration to your `values-region-2.yml`:
 
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
+  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
   ```
 
 **Security Context Constraints (SCCs)**
@@ -416,7 +416,7 @@ For custom configurations or specific requirements, please refer to the [install
 Before deploying, some values in the value files need to be updated. To assist with generating these values, save the following Bash script as `generate_zeebe_helm_values.sh`:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
 ```
 
 Then, source the output of the script. By doing so, we can reuse the values later for substitution, instead of manually adjusting the values files. You will be prompted to specify the number of Zeebe brokers (total number of Zeebe brokers in both Kubernetes clusters), for a dual-region setup we recommend `8`, resulting in four brokers per region:
@@ -438,7 +438,7 @@ Make sure that the variable `CLUSTER_1_NAME` is set to the name of your first cl
 Once you've prepared each region's value file (`values-region-1.yml` and `values-region-2.yml`) file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -446,7 +446,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/ope
 With the value files for each region configured, you can now install Camunda 8 using Helm. Execute the following commands:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
 ```
 
 This command:
@@ -468,7 +468,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 Once Camunda is deployed across the two clusters, the next step is to expose each service to Submariner so it can be resolved by the other cluster:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
 ```
 
 Alternatively, you can manage each service individually using the `ServiceExport` Custom Resource Definition (CRD).
@@ -489,13 +489,13 @@ metadata:
 For each cluster, verify the status of the exported services with this script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
 ```
 
 To monitor the progress of the installation, save and execute the following script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
 ```
 
 Save it as `verify_installation_completed.sh`, make it executable, and run it:
@@ -528,7 +528,7 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
    ```
 
    </details>
@@ -552,7 +552,7 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-dual-region/procedure/zbctl-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/zbctl-output.txt
    ```
 
    </details>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 1536dd4fe83..cddda088620 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -67,7 +67,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -99,7 +99,7 @@ The route created by OpenShift will use a domain to provide access to the platfo
 To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/openshift/single-region/procedure/setup-application-domain.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -117,7 +117,7 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 Alternatively, if you use a dedicated IngressController for the deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -178,7 +178,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -190,7 +190,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -200,7 +200,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -233,7 +233,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -253,7 +253,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -262,7 +262,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/ope
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -283,7 +283,7 @@ https://github.com/camunda/camunda-deployment-references/blob/8.7/generic/opensh
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -291,7 +291,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -301,13 +301,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
 ```
 
 This command:
@@ -325,7 +325,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8

From 77b7fd2c2e9a9c6be03732d97097f902b24a4767 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 10:08:09 +0100
Subject: [PATCH 11/26] fix 8.8 links

---
 .../deploy/amazon/amazon-eks/eks-helm.md      |  6 +--
 .../setup/deploy/amazon/aws-ec2.md            |  2 +-
 .../openshift/terraform-setup-dual-region.md  | 22 ++++-----
 .../amazon/openshift/terraform-setup.md       | 16 +++----
 .../setup/deploy/openshift/dual-region.md     | 46 +++++++++----------
 .../deploy/openshift/redhat-openshift.md      | 32 ++++++-------
 .../deploy/openshift/redhat-openshift.md      |  2 +-
 .../deploy/openshift/redhat-openshift.md      |  2 +-
 8 files changed, 64 insertions(+), 64 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index d8b902d3dd1..0cc6cb637c2 100644
--- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -449,7 +449,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -644,7 +644,7 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
 ...and results in the following output:
@@ -654,7 +654,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic
   <summary>
 
 ```json reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/docs/self-managed/setup/deploy/amazon/aws-ec2.md b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
index a2eced6490f..1de97ed28d4 100644
--- a/docs/self-managed/setup/deploy/amazon/aws-ec2.md
+++ b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
@@ -55,7 +55,7 @@ Alternatively, the same setup can run with a single AWS EC2 instance, but be awa
 
 - An AWS account to create any resources within AWS.
   - On a high level, permissions are required on the **ec2**, **iam**, **elasticloadbalancing**, **kms**, **logs**, and **es** level.
-  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/ec2/example/policy.json).
+  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/ec2/example/policy.json).
 - Terraform (1.7+)
 - Unix based Operating System (OS) with ssh and sftp
   - Windows may be used with [Cygwin](https://www.cygwin.com/) or [Windows WSL](https://learn.microsoft.com/en-us/windows/wsl/install) but has not been tested
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index a339b2e2f6c..79ba8385c0f 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -161,7 +161,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
 It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html).
@@ -287,21 +287,21 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
    This configuration will use the previously created S3 bucket for storing the Terraform state file:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
    ```
 
 5. Create a file named `cluster_region_1.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 1:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
    ```
 
 6. Create a file named `cluster_region_2.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 2:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
    ```
 
 7. After setting up the terraform files and ensuring your AWS authentication is configured, initialize your Terraform project, then, initialize Terraform to configure the backend and download necessary provider plugins:
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region//README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region//README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
 
 :::
 
@@ -417,13 +417,13 @@ We'll re-use the previously configured S3 bucket to store the state of the peeri
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
 ```
 
 Alongside the `config.tf` file, create a file called `peering.tf` to reference the peering configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
 ```
 
 One cluster will be referenced as the **owner**, and the other as the **accepter**.
@@ -497,13 +497,13 @@ We'll re-use the previously configured S3 bucket to store the state of the backu
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
 ```
 
 Finally, create a file called `backup_bucket.tf` to reference the elastic backup bucket configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
 ```
 
 This bucket configuration follows [multiple best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).  
@@ -568,7 +568,7 @@ The `BACKUP_BUCKET_REGION` will define the region of the bucket, you can pick on
 
 ### Reference files
 
-You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-dual-region/terraform)
+You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 7f27edc62df..a7c358f71a4 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -75,10 +75,10 @@ Following this tutorial and steps will result in:
 
 ### Obtain a copy of the reference architecture
 
-The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
+The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
 ```
 
 With the reference architecture downloaded and extracted, you can proceed with the remaining steps outlined in this documentation. Ensure that you are in the correct directory before continuing with further instructions.
@@ -166,7 +166,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -191,7 +191,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -283,14 +283,14 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/cluster.tf
    ```
 
    :::caution Camunda Terraform module
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/README.md) for more information.
 
    :::
 
@@ -302,7 +302,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/README.md).
 
 ### Define outputs
 
@@ -338,7 +338,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/stable/8.8/aws/openshift/rosa-hcp-single-region/)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/docs/self-managed/setup/deploy/openshift/dual-region.md b/docs/self-managed/setup/deploy/openshift/dual-region.md
index 71b1fcab059..67a15e728c6 100644
--- a/docs/self-managed/setup/deploy/openshift/dual-region.md
+++ b/docs/self-managed/setup/deploy/openshift/dual-region.md
@@ -110,7 +110,7 @@ Later in this guide, we will refer to it as **first cluster**.
 2. The following manifest will create a namespace for the management cluster, enable the [open-cluster-management operator](https://open-cluster-management.io/) and the [associated subscription](https://docs.openshift.com/container-platform/4.17/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster).
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Apply the manifests to enable ACM:
@@ -133,7 +133,7 @@ Later in this guide, we will refer to it as **first cluster**.
    In this setup, the first cluster will act as the central hub, managing the second cluster. This capability enables the deployment and management of components on the second cluster directly from the first cluster.
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    :::caution Known issue: may not work correctly with the manifest
@@ -170,7 +170,7 @@ Later in this guide, we will refer to it as **first cluster**.
 4. With the MultiClusterHub created, the last step is to create a `ManagedClusterSet` which is a group of managed clusters. With a `ManagedClusterSet`, you can manage access to all of the managed clusters in the group together
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
    Apply the manifest:
@@ -188,7 +188,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `managed-cluster.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
      ```
 
    - The cluster’s associated addon configuration will be managed using the following manifest.
@@ -196,7 +196,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save it as `klusterlet-config.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
      ```
 
    - To import a cluster, you must store the associated authentication token.
@@ -204,13 +204,13 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `auto-import-cluster-secret.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
      ```
 
    - Finally, import each cluster into the Managed Cluster Set and verify that they can be reached and managed successfully:
 
      ```bash reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
      ```
 
 ### Submariner
@@ -258,7 +258,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    Select the first node and apply the required label:
 
    ```bash reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
    ```
 
 3. Deployment of Submariner on the clusters:
@@ -266,7 +266,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    - Save the following file as `submariner.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
      ```
 
      :::note Cluster naming
@@ -314,7 +314,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    <summary>Example Submariner check successfull output</summary>
 
 ```text reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
 ```
 
 </details>
@@ -323,7 +323,7 @@ For more comprehensive details regarding the verification tests for Submariner u
 
 **Debugging the Submariner setup:**
 
-If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
+If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
 With this pod, you will be able to check flow openings, service resolution, and other network-related aspects.  
 Troubleshooting requires examining all the underlying mechanisms of Submariner. Therefore, we also encourage you to read the [Submariner troubleshooting guide](https://submariner.io/operations/troubleshooting/).
 
@@ -337,7 +337,7 @@ Before proceeding with the installation, ensure the required information is avai
 Review and adjust the following environment script to match your specific configuration:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
 ```
 
 _If you are unsure about the values of the backup bucket, please refer to the [S3 backup bucket module setup](/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md#s3-backup-bucket-module-setup) as a reference for implementation._
@@ -363,7 +363,7 @@ The Elasticsearch backup [bucket is tied to a specific region](https://docs.aws.
 The following script will create the required namespaces and secrets used to reference the bucket access.
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
 ```
 
 Save it as `setup_ns_secrets.sh` and execute it:
@@ -380,7 +380,7 @@ Throughout this guide, you will add and merge values into these files to configu
 
 - Save the following file as both `values-region-1.yml` and `values-region-2.yml` to serve as the base configuration:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
+  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
   ```
 
 :::warning Merging YAML files
@@ -396,12 +396,12 @@ Set up the region ID using a unique integer for each region:
 
 - Add the following YAML configuration to your `values-region-1.yml`:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
+  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
   ```
 - Add the following YAML configuration to your `values-region-2.yml`:
 
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
+  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
   ```
 
 **Security Context Constraints (SCCs)**
@@ -416,7 +416,7 @@ For custom configurations or specific requirements, please refer to the [install
 Before deploying, some values in the value files need to be updated. To assist with generating these values, save the following Bash script as `generate_zeebe_helm_values.sh`:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
 ```
 
 Then, source the output of the script. By doing so, we can reuse the values later for substitution, instead of manually adjusting the values files. You will be prompted to specify the number of Zeebe brokers (total number of Zeebe brokers in both Kubernetes clusters), for a dual-region setup we recommend `8`, resulting in four brokers per region:
@@ -438,7 +438,7 @@ Make sure that the variable `CLUSTER_1_NAME` is set to the name of your first cl
 Once you've prepared each region's value file (`values-region-1.yml` and `values-region-2.yml`) file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -446,7 +446,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/ope
 With the value files for each region configured, you can now install Camunda 8 using Helm. Execute the following commands:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
 ```
 
 This command:
@@ -468,7 +468,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 Once Camunda is deployed across the two clusters, the next step is to expose each service to Submariner so it can be resolved by the other cluster:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
 ```
 
 Alternatively, you can manage each service individually using the `ServiceExport` Custom Resource Definition (CRD).
@@ -489,13 +489,13 @@ metadata:
 For each cluster, verify the status of the exported services with this script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
 ```
 
 To monitor the progress of the installation, save and execute the following script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
 ```
 
 Save it as `verify_installation_completed.sh`, make it executable, and run it:
@@ -525,7 +525,7 @@ oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
    ```
 
    </details>
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 626a1e8c372..4d85ffbb027 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -67,7 +67,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -99,7 +99,7 @@ The route created by OpenShift will use a domain to provide access to the platfo
 To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/setup-application-domain.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -117,7 +117,7 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 Alternatively, if you use a dedicated IngressController for the deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -131,7 +131,7 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 **IngressController configuration:**
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/enable-ingress-http2.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**
@@ -178,7 +178,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -190,7 +190,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -200,7 +200,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -220,7 +220,7 @@ For guidance on installing an Ingress controller, you can refer to the [Ingress
 
 Do not confuse the [ingress-nginx controller](https://github.com/kubernetes/ingress-nginx) with the [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift) that is endorsed by Red Hat for usage with OpenShift. Despite very similar names, they are two different products.
 
-If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/stable/8.8/examples/ingress-resources/grpc-services/README.md).
+If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/feature/rosa-8.8/examples/ingress-resources/grpc-services/README.md).
 
 :::
 
@@ -233,7 +233,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -253,7 +253,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -262,7 +262,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/ope
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -283,7 +283,7 @@ https://github.com/camunda/camunda-deployment-references/blob/8.8/generic/opensh
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -291,7 +291,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -301,13 +301,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
 ```
 
 This command:
@@ -325,7 +325,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index 30090563039..f3c470f9360 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -127,7 +127,7 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 **IngressController configuration:**
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/enable-ingress-http2.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index cddda088620..2763d7e68cf 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -131,7 +131,7 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 **IngressController configuration:**
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.8/generic/openshift/single-region/procedure/enable-ingress-http2.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**

From 1747e9dbace7928935833b376f7bd0a7a0ff0458 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 10:14:04 +0100
Subject: [PATCH 12/26] fix links

---
 .../self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md | 2 +-
 .../setup/deploy/amazon/openshift/terraform-setup.md        | 2 +-
 .../self-managed/setup/deploy/openshift/redhat-openshift.md | 2 +-
 .../self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md | 6 +++---
 .../setup/deploy/amazon/openshift/terraform-setup.md        | 2 +-
 .../self-managed/setup/deploy/openshift/redhat-openshift.md | 2 +-
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 0cc6cb637c2..c61452ccb3a 100644
--- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -409,7 +409,7 @@ identity:
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/8.8/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index a7c358f71a4..de6d6df337c 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -349,7 +349,7 @@ You can access the created OpenShift cluster using the following steps:
 Set up the required environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/8.8/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
 ```
 
 If you want to give cluster administrator access to the created user, this is not required for a standard installation but can be useful for debugging:
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 4d85ffbb027..a41eae898fd 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -277,7 +277,7 @@ Some components are not enabled by default in this deployment. For more informat
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/8.8/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 7b0d1d40ded..cc353a1455b 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -448,7 +448,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -646,7 +646,7 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
 ...and results in the following output:
@@ -656,7 +656,7 @@ https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic
   <summary>
 
 ```json reference
-https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 12a54a9bf7f..1db5a3f70dc 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -349,7 +349,7 @@ You can access the created OpenShift cluster using the following steps:
 Set up the required environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/8.7/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
 ```
 
 If you want to give cluster administrator access to the created user, this is not required for a standard installation but can be useful for debugging:
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 2763d7e68cf..955c0527ab9 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -277,7 +277,7 @@ Some components are not enabled by default in this deployment. For more informat
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/8.7/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:

From a7d9319ec74020e508a6cf2aae074ad7644d871d Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 11:34:41 +0100
Subject: [PATCH 13/26] fix link

---
 .../setup/deploy/openshift/redhat-openshift.md     | 14 +++++++-------
 .../setup/deploy/openshift/redhat-openshift.md     | 14 +++++++-------
 2 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index a41eae898fd..407e55a93d3 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -67,7 +67,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -178,7 +178,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/core-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -190,7 +190,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -200,7 +200,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -233,7 +233,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -253,7 +253,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -262,7 +262,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/a
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/no-scc.yml
 ```
 
 </TabItem>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 955c0527ab9..2671248a7e0 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -67,7 +67,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -178,7 +178,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/core-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -190,7 +190,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -200,7 +200,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -233,7 +233,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -253,7 +253,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -262,7 +262,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/a
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/no-scc.yml
 ```
 
 </TabItem>

From 7b39ff1c69d3f39ae01cd122f6d3de2d6efd3473 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 12:05:03 +0100
Subject: [PATCH 14/26] fix some broken links

---
 docs/self-managed/setup/deploy/amazon/aws-ec2.md       |  2 --
 .../amazon/openshift/terraform-setup-dual-region.md    |  2 +-
 .../setup/deploy/openshift/redhat-openshift.md         | 10 +++++-----
 .../amazon/openshift/terraform-setup-dual-region.md    |  2 +-
 .../setup/deploy/openshift/redhat-openshift.md         |  8 ++++----
 5 files changed, 11 insertions(+), 13 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/aws-ec2.md b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
index 1de97ed28d4..9f11396eb7e 100644
--- a/docs/self-managed/setup/deploy/amazon/aws-ec2.md
+++ b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
@@ -80,8 +80,6 @@ Therefore, we recommend extending or reusing some elements of the Terraform exam
 
 The provided reference architecture repository allows you to directly reuse and extend the existing Terraform example base. This sample implementation is flexible to extend to your own needs without the potential limitations of a Terraform module.
 
-# TODO: fix this one
-
 ```sh
 wget https://github.com/camunda/camunda-deployment-references/archive/refs/heads/main.zip
 ```
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 79ba8385c0f..3163283a6e3 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -568,7 +568,7 @@ The `BACKUP_BUCKET_REGION` will define the region of the bucket, you can pick on
 
 ### Reference files
 
-You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/terraform)
+You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 407e55a93d3..4fcd0fd2d61 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -220,7 +220,7 @@ For guidance on installing an Ingress controller, you can refer to the [Ingress
 
 Do not confuse the [ingress-nginx controller](https://github.com/kubernetes/ingress-nginx) with the [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift) that is endorsed by Red Hat for usage with OpenShift. Despite very similar names, they are two different products.
 
-If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/feature/rosa-8.8/examples/ingress-resources/grpc-services/README.md).
+If you should decide to use the Red Hat endorsed [NGINX Ingress Controller](https://www.redhat.com/en/blog/using-nginx-ingress-controller-red-hat-openshift), you would require additional adjustments done to the Camunda 8 Ingress objects and the NGINX Ingress Controller itself to make `gRPC` and `HTTP/2` connections work. In that case, please refer to the [example and the prerequisites](https://github.com/nginxinc/kubernetes-ingress/blob/main/examples/ingress-resources/grpc-services/README.md).
 
 :::
 
@@ -283,7 +283,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/g
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -291,7 +291,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -301,13 +301,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/procedure/install-chart.sh
 ```
 
 This command:
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 3c4e7cc63c8..1420979dfce 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -568,7 +568,7 @@ The `BACKUP_BUCKET_REGION` will define the region of the bucket, you can pick on
 
 ### Reference files
 
-You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform)
+You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 2671248a7e0..2ae28fe768d 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -283,7 +283,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/g
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -291,7 +291,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/create-identity-secret.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/create-identity-secret.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -301,13 +301,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/install/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/install-chart.sh
 ```
 
 This command:

From 9004290bb80648327c504beea8114ded1cbac6b6 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 13:25:27 +0100
Subject: [PATCH 15/26] restore Modeler check section

---
 .../deploy/amazon/amazon-eks/eks-helm.md      | 48 +++++++++++++++++++
 .../deploy/amazon/amazon-eks/eks-helm.md      |  2 +-
 2 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index c61452ccb3a..cd670434643 100644
--- a/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/docs/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -609,6 +609,9 @@ Console:
 
 ### Use the token
 
+<Tabs groupId="c8-connectivity">
+  <TabItem value="rest-api" label="REST API" default>
+
 For a detailed guide on generating and using a token, please conduct the relevant documentation on [authenticating with the REST API](./../../../../../apis-tools/camunda-api-rest/camunda-api-rest-authentication.md?environment=self-managed).
 
 <Tabs groupId="domain">
@@ -660,6 +663,51 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/g
   </summary>
 </details>
 
+  </TabItem>
+  <TabItem value="modeler" label="Desktop Modeler">
+
+Follow our existing [Modeler guide on deploying a diagram](/self-managed/modeler/desktop-modeler/deploy-to-self-managed.md). Below are the helper values required to be filled in Modeler:
+
+<Tabs groupId="domain" defaultValue="with" queryString values={
+[
+{label: 'With domain', value: 'with' },
+{label: 'Without domain', value: 'without' },
+]}>
+
+<TabItem value="with">
+
+The following values are required for the OAuth authentication:
+
+- **Cluster endpoint:** `https://zeebe.$DOMAIN_NAME`, replacing `$DOMAIN_NAME` with your domain
+- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application
+- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application
+- **OAuth Token URL:** `https://$DOMAIN_NAME/auth/realms/camunda-platform/protocol/openid-connect/token`, replacing `$DOMAIN_NAME` with your domain
+- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed
+
+</TabItem>
+
+<TabItem value="without">
+
+This requires port-forwarding the Zeebe Gateway to be able to connect to the cluster:
+
+```shell
+kubectl port-forward services/camunda-zeebe-gateway 26500:26500 --namespace camunda
+```
+
+The following values are required for OAuth authentication:
+
+- **Cluster endpoint:** `http://localhost:26500`
+- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application
+- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application
+- **OAuth Token URL:** `http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token`
+- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed
+
+</TabItem>
+</Tabs>
+
+</TabItem>
+</Tabs>
+
 ## Test the installation with payment example application
 
 To test your installation with the deployment of a sample application, refer to the [installing payment example guide](../../../guides/installing-payment-example.md).
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index cc353a1455b..c04cbde64e1 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -744,7 +744,7 @@ Brokers:
 For more advanced topics, like deploying a process or registering a worker, consult the [zbctl docs](/apis-tools/community-clients/cli-client/cli-get-started.md).
 
   </TabItem>
-    <TabItem value="modeler" label="Desktop Modeler">
+  <TabItem value="modeler" label="Desktop Modeler">
 
 Follow our existing [Modeler guide on deploying a diagram](/self-managed/modeler/desktop-modeler/deploy-to-self-managed.md). Below are the helper values required to be filled in Modeler:
 

From 7eda9865d0e5228828c4b4c600eb72a65972b696 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 13:36:37 +0100
Subject: [PATCH 16/26] update link for module

---
 .../deploy/amazon/openshift/terraform-setup-dual-region.md    | 2 +-
 .../setup/deploy/amazon/openshift/terraform-setup.md          | 4 ++--
 .../setup/deploy/amazon/openshift/terraform-setup.md          | 4 ++--
 .../deploy/amazon/openshift/terraform-setup-dual-region.md    | 4 ++--
 .../setup/deploy/amazon/openshift/terraform-setup.md          | 4 ++--
 5 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 3163283a6e3..db7ac097058 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -334,7 +334,7 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region//README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/modules/rosa-hcp/README.md).
 
 :::caution Camunda Terraform module
 
diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index de6d6df337c..cf826484922 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -290,7 +290,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/modules/rosa-hcp/README.md) for more information.
 
    :::
 
@@ -302,7 +302,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/aws/modules/rosa-hcp/README.md).
 
 ### Define outputs
 
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index f4985e838d9..de89512014e 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -295,7 +295,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/modules/rosa-hcp/README.md) for more information.
 
    :::
 
@@ -307,7 +307,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access, if you want to grant access to other users, please follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/modules/rosa-hcp/README.md).
 
 ### Define outputs
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index 1420979dfce..a120e6b29e1 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md) for more information.
 
 :::
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index 1db5a3f70dc..e149e14eb73 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -290,7 +290,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md) for more information.
 
    :::
 
@@ -302,7 +302,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md).
 
 ### Define outputs
 

From 3831488b57d815d441da7569d83b92f0c9cf72ea Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 13:38:13 +0100
Subject: [PATCH 17/26] update link for module

---
 .../deploy/amazon/openshift/terraform-setup-dual-region.md      | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index db7ac097058..1af50bb3321 100644
--- a/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/docs/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -340,7 +340,7 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/openshift/rosa-hcp-dual-region/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/modules/rosa-hcp/README.md) for more information.
 
 :::
 

From 97d56393650f0cd1be02cb26e4dbf962f6c22c2b Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 13:44:14 +0100
Subject: [PATCH 18/26] fix indent

---
 docs/self-managed/setup/deploy/openshift/dual-region.md | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/docs/self-managed/setup/deploy/openshift/dual-region.md b/docs/self-managed/setup/deploy/openshift/dual-region.md
index 67a15e728c6..d65fbd3ea37 100644
--- a/docs/self-managed/setup/deploy/openshift/dual-region.md
+++ b/docs/self-managed/setup/deploy/openshift/dual-region.md
@@ -509,9 +509,9 @@ chmod +x verify_installation_completed.sh
 
 1. Open a terminal and port-forward the Zeebe Gateway via `oc` from one of your clusters. Zeebe is stretching over both clusters and is `active-active`, meaning it doesn't matter which Zeebe Gateway to use to interact with your Zeebe cluster.
 
-```shell
-oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/$HELM_RELEASE_NAME-zeebe-gateway" 8080:8080
-```
+   ```shell
+   oc --context "$CLUSTER_1_NAME" -n "$CAMUNDA_NAMESPACE_1" port-forward "services/$HELM_RELEASE_NAME-zeebe-gateway" 8080:8080
+   ```
 
 2. Open another terminal and use e.g. `cURL` to print the Zeebe cluster topology:
 

From ea64c64d62efad5fef98a86449a9b0b5ef5ed054 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 13:50:10 +0100
Subject: [PATCH 19/26] remove dates from openshift support

---
 .../setup/deploy/openshift/redhat-openshift.md     | 14 +++++++-------
 .../setup/deploy/openshift/redhat-openshift.md     | 14 +++++++-------
 .../setup/deploy/openshift/redhat-openshift.md     | 14 +++++++-------
 3 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 4fcd0fd2d61..1592700441b 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -29,13 +29,13 @@ If you need to set up an OpenShift cluster on a cloud provider, we recommend our
 
 We conduct testing and ensure compatibility against the following OpenShift versions:
 
-| OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
-| ----------------- | --------------------------------------------------------------------------------- |
-| 4.18.x            | GA of 4.19 + 3 Months                                                             |
-| 4.17.x            | June 27, 2025                                                                     |
-| 4.16.x            | December 27, 2025                                                                 |
-| 4.15.x            | August 27, 2025                                                                   |
-| 4.14.x            | May 1, 2025                                                                       |
+| OpenShift Version |
+| ----------------- |
+| 4.18.x            |
+| 4.17.x            |
+| 4.16.x            |
+| 4.15.x            |
+| 4.14.x            |
 
 :::caution Versions compatibility
 
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index f3c470f9360..f329c98a133 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -29,13 +29,13 @@ If you need to set up an OpenShift cluster on a cloud provider, we recommend our
 
 We conduct testing and ensure compatibility against the following OpenShift versions:
 
-| OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
-| ----------------- | --------------------------------------------------------------------------------- |
-| 4.18.x            | GA of 4.19 + 3 Months                                                             |
-| 4.17.x            | June 27, 2025                                                                     |
-| 4.16.x            | December 27, 2025                                                                 |
-| 4.15.x            | August 27, 2025                                                                   |
-| 4.14.x            | May 1, 2025                                                                       |
+| OpenShift Version |
+| ----------------- |
+| 4.18.x            |
+| 4.17.x            |
+| 4.16.x            |
+| 4.15.x            |
+| 4.14.x            |
 
 :::caution Version compatibility
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 2ae28fe768d..03ef5fcca7b 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -29,13 +29,13 @@ If you need to set up an OpenShift cluster on a cloud provider, we recommend our
 
 We conduct testing and ensure compatibility against the following OpenShift versions:
 
-| OpenShift Version | [End of Support Date](https://access.redhat.com/support/policy/updates/openshift) |
-| ----------------- | --------------------------------------------------------------------------------- |
-| 4.18.x            | GA of 4.19 + 3 Months                                                             |
-| 4.17.x            | June 27, 2025                                                                     |
-| 4.16.x            | December 27, 2025                                                                 |
-| 4.15.x            | August 27, 2025                                                                   |
-| 4.14.x            | May 1, 2025                                                                       |
+| OpenShift Version |
+| ----------------- |
+| 4.18.x            |
+| 4.17.x            |
+| 4.16.x            |
+| 4.15.x            |
+| 4.14.x            |
 
 :::caution Versions compatibility
 

From 379daa616d56d8ab283d9f5cd167cc4a15d515e3 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 15:36:24 +0100
Subject: [PATCH 20/26] fix indentation

---
 .../deploy/openshift/redhat-openshift.md      | 24 ++++++++++++++++++-
 .../deploy/openshift/redhat-openshift.md      |  8 +++----
 .../deploy/openshift/redhat-openshift.md      | 10 ++++----
 3 files changed, 32 insertions(+), 10 deletions(-)

diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index 1592700441b..bed68c5cc62 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -175,7 +175,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 
      - We mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Core pod and configure a secure TLS connection.
 
-     Update your `values.yml` file with the following:
+   Update your `values.yml` file with the following:
 
    ```yaml reference
    https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.8/generic/openshift/single-region/helm-values/core-route.yml
@@ -187,6 +187,28 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    - [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection),
    - [in the Zeebe Gateway configuration documentation](/self-managed/zeebe-deployment/configuration/gateway.md).
 
+# TODO:; fix it
+
+2. **Operate:** mount the **Service Certificate Secret** to the Operate pod and configure the secure TLS connection. Here, only the `tls.crt` file is required.
+
+Update your `values.yml` file with the following:
+
+```yaml reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/operate-route.yml
+```
+
+The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
+
+1. **Tasklist:** mount the **Service Certificate Secret** to the Tasklist pod and configure the secure TLS connection. Here, only the `tls.crt` file is required.
+
+   Update your `values.yml` file with the following:
+
+```yaml reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/tasklist-route.yml
+```
+
+The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
+
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index f329c98a133..ce7afd77875 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -208,7 +208,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -298,9 +298,9 @@ Use these environment variables in the `kubectl` command to create the secret.
 
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
-```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/create-identity-secret.sh
-```
+  ```bash reference
+  https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/create-identity-secret.sh
+  ```
 
 ### Install Camunda 8 using Helm
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 03ef5fcca7b..4473cedd1d6 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -175,10 +175,10 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 
      - We mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Core pod and configure a secure TLS connection.
 
-     Update your `values.yml` file with the following:
+   Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/core-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
    ```
 
    The actual configuration properties can be reviewed:
@@ -290,9 +290,9 @@ Use these environment variables in the `kubectl` command to create the secret.
 
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
-```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/create-identity-secret.sh
-```
+  ```bash reference
+  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/create-identity-secret.sh
+  ```
 
 ### Install Camunda 8 using Helm
 

From 25350894ab82f7c7ae273b9638ab76cd6c854c1e Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 15:56:12 +0100
Subject: [PATCH 21/26] update 8.7 openshift

---
 .../deploy/openshift/redhat-openshift.md      | 35 +++++++++++++------
 1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 4473cedd1d6..4c718f811ee 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -148,9 +148,9 @@ This will add the necessary annotation to [enable HTTP/2 for Ingress in your Ope
 
 Additionally, the Zeebe Gateway should be configured to use an encrypted connection with TLS. In OpenShift, the connection from HAProxy to the Zeebe Gateway service can use HTTP/2 only for re-encryption or pass-through routes, and not for edge-terminated or insecure routes.
 
-1. **Core Pod:** two [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) for the Zeebe Gateway are required, one for the **service** and the other one for the **route**:
+1. **Zeebe Gateway:** two [TLS secrets](https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets) for the Zeebe Gateway are required, one for the **service** and the other one for the **route**:
 
-   - The first TLS secret is issued to the Zeebe Gateway Service Name. This must use the [PKCS #8 syntax](https://en.wikipedia.org/wiki/PKCS_8) or [PKCS #1 syntax](https://en.wikipedia.org/wiki/PKCS_1) as Zeebe only supports these, referenced as `camunda-platform-internal-service-certificate`. This certificate is also use in the other components such as Operate, Tasklist.
+   - The first TLS secret is issued to the Zeebe Gateway Service Name. This must use the [PKCS #8 syntax](https://en.wikipedia.org/wiki/PKCS_8) or [PKCS #1 syntax](https://en.wikipedia.org/wiki/PKCS_1) as Zeebe only supports these, referenced as `camunda-platform-internal-service-certificate`.
 
      In the example below, a TLS certificate is generated for the Zeebe Gateway service with an [annotation](https://docs.openshift.com/container-platform/latest/security/certificates/service-serving-certificate.html). The generated certificate will be in the form of a secret.
 
@@ -174,6 +174,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
      - We enable gRPC ingress for the Core pod, which sets up a secure proxy that we'll use to communicate with the Zeebe cluster. To avoid conflicts with other services, we use a specific domain (`zeebe-$DOMAIN_NAME`) for the gRPC proxy, different from the one used by other services (`$DOMAIN_NAME`). We also note that the port used for gRPC is `443`.
 
      - We mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Core pod and configure a secure TLS connection.
+       Finally, we mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Zeebe Gateway Pod and the Zeebe Pod to configure both [broker security](/self-managed/zeebe-deployment/configuration/broker.md#zeebebrokernetworksecurity) and gateway security.
 
    Update your `values.yml` file with the following:
 
@@ -181,13 +182,29 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
    ```
 
-   The actual configuration properties can be reviewed:
+   The domain used by the Zeebe Gateway for gRPC is `zeebe-$DOMAIN_NAME` which different from the one used for the rest, namely `$DOMAIN_NAME`, to avoid any conflicts. It is also important to note that the port used for gRPC is `443`.
 
-   - [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection),
-   - [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection),
-   - [in the Zeebe Gateway configuration documentation](/self-managed/zeebe-deployment/configuration/gateway.md).
+2. **Operate:** mount the **Service Certificate Secret** to the Operate pod and configure the secure TLS connection. Here, only the `tls.crt` file is required.
 
-2. **Connectors:** update your `values.yml` file with the following:
+Update your `values.yml` file with the following:
+
+```yaml reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/operate-route.yml
+```
+
+The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
+
+1. **Tasklist:** mount the **Service Certificate Secret** to the Tasklist pod and configure the secure TLS connection. Here, only the `tls.crt` file is required.
+
+   Update your `values.yml` file with the following:
+
+```yaml reference
+https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/tasklist-route.yml
+```
+
+The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
+
+1. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
 https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/connectors-route.yml
@@ -330,9 +347,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/g
 
 ## Verify connectivity to Camunda 8
 
-Please follow our [guide to verify connectivity to Camunda 8](/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md#verify-connectivity-to-camunda-8).
-
-The username of the first user is `demo`, the password is the one generated previously and stored in the environment variable `FIRST_USER_PASSWORD`.
+Please follow our [guide to verify connectivity to Camunda 8](/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md#verify-connectivity-to-camunda-8)
 
 :::caution Domain name for gRPC Zeebe
 

From f69d0261d0fc166625d6911b9a2739e797d22bfe Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 15:57:49 +0100
Subject: [PATCH 22/26] update 8.7 openshift

---
 .../self-managed/setup/deploy/openshift/redhat-openshift.md     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 4c718f811ee..5398031a4fe 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -171,7 +171,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 
      To configure a Zeebe cluster securely, it's essential to set up a secure communication configuration between pods:
 
-     - We enable gRPC ingress for the Core pod, which sets up a secure proxy that we'll use to communicate with the Zeebe cluster. To avoid conflicts with other services, we use a specific domain (`zeebe-$DOMAIN_NAME`) for the gRPC proxy, different from the one used by other services (`$DOMAIN_NAME`). We also note that the port used for gRPC is `443`.
+     - We enable gRPC ingress for the ZeebeGateway pod, which sets up a secure proxy that we'll use to communicate with the Zeebe cluster. To avoid conflicts with other services, we use a specific domain (`zeebe-$DOMAIN_NAME`) for the gRPC proxy, different from the one used by other services (`$DOMAIN_NAME`). We also note that the port used for gRPC is `443`.
 
      - We mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Core pod and configure a secure TLS connection.
        Finally, we mount the **Service Certificate Secret** (`camunda-platform-internal-service-certificate`) to the Zeebe Gateway Pod and the Zeebe Pod to configure both [broker security](/self-managed/zeebe-deployment/configuration/broker.md#zeebebrokernetworksecurity) and gateway security.

From 3a81d9292885ec76a2da55e5e179e6d68d600ef7 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 16:03:59 +0100
Subject: [PATCH 23/26] remove outdate

---
 .../deploy/openshift/redhat-openshift.md      | 22 -------------------
 1 file changed, 22 deletions(-)

diff --git a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
index bed68c5cc62..e1c5a14cf00 100644
--- a/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/docs/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -187,28 +187,6 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    - [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection),
    - [in the Zeebe Gateway configuration documentation](/self-managed/zeebe-deployment/configuration/gateway.md).
 
-# TODO:; fix it
-
-2. **Operate:** mount the **Service Certificate Secret** to the Operate pod and configure the secure TLS connection. Here, only the `tls.crt` file is required.
-
-Update your `values.yml` file with the following:
-
-```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/operate-route.yml
-```
-
-The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
-
-1. **Tasklist:** mount the **Service Certificate Secret** to the Tasklist pod and configure the secure TLS connection. Here, only the `tls.crt` file is required.
-
-   Update your `values.yml` file with the following:
-
-```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/tasklist-route.yml
-```
-
-The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
-
 2. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference

From aaa55f71d8034703527399e6de8e1e1b78df8219 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Wed, 12 Mar 2025 16:46:36 +0100
Subject: [PATCH 24/26] fix the token

---
 .../deploy/amazon/amazon-eks/eks-helm.md      |  3 ++
 .../deploy/amazon/amazon-eks/eks-helm.md      | 47 +++++++++++++++++++
 2 files changed, 50 insertions(+)

diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index a1875628aca..513ecf9b04a 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -608,6 +608,9 @@ Console:
 
 ### Use the token
 
+<Tabs groupId="c8-connectivity">
+  <TabItem value="rest-api" label="REST API" default>
+
 For a detailed guide on generating and using a token, please conduct the relevant documentation on [authenticating with the REST API](./../../../../../apis-tools/camunda-api-rest/camunda-api-rest-authentication.md?environment=self-managed).
 
 <Tabs groupId="domain">
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 66b1561cc15..57b6a263e11 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -609,6 +609,9 @@ Console:
 
 ### Use the token
 
+<Tabs groupId="c8-connectivity">
+  <TabItem value="rest-api" label="REST API" default>
+
 For a detailed guide on generating and using a token, please conduct the relevant documentation on [authenticating with the REST API](./../../../../../apis-tools/camunda-api-rest/camunda-api-rest-authentication.md?environment=self-managed).
 
 <Tabs groupId="domain">
@@ -659,6 +662,50 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/g
 
   </summary>
 </details>
+  </TabItem>
+  <TabItem value="modeler" label="Desktop Modeler">
+
+Follow our existing [Modeler guide on deploying a diagram](/self-managed/modeler/desktop-modeler/deploy-to-self-managed.md). Below are the helper values required to be filled in Modeler:
+
+<Tabs groupId="domain" defaultValue="with" queryString values={
+[
+{label: 'With domain', value: 'with' },
+{label: 'Without domain', value: 'without' },
+]}>
+
+<TabItem value="with">
+
+The following values are required for the OAuth authentication:
+
+- **Cluster endpoint:** `https://zeebe.$DOMAIN_NAME`, replacing `$DOMAIN_NAME` with your domain
+- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application
+- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application
+- **OAuth Token URL:** `https://$DOMAIN_NAME/auth/realms/camunda-platform/protocol/openid-connect/token`, replacing `$DOMAIN_NAME` with your domain
+- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed
+
+</TabItem>
+
+<TabItem value="without">
+
+This requires port-forwarding the Zeebe Gateway to be able to connect to the cluster:
+
+```shell
+kubectl port-forward services/camunda-zeebe-gateway 26500:26500 --namespace camunda
+```
+
+The following values are required for OAuth authentication:
+
+- **Cluster endpoint:** `http://localhost:26500`
+- **Client ID:** Retrieve the client ID value from the identity page of your created M2M application
+- **Client Secret:** Retrieve the client secret value from the Identity page of your created M2M application
+- **OAuth Token URL:** `http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token`
+- **Audience:** `zeebe-api`, the default for Camunda 8 Self-Managed
+
+</TabItem>
+</Tabs>
+
+</TabItem>
+</Tabs>
 
 ## Test the installation with payment example application
 

From 3d37b3ceeb62aa1d012c6511f2aaff0ef06739f3 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Thu, 13 Mar 2025 09:58:15 +0100
Subject: [PATCH 25/26] update 8.6 links

---
 .../setup/deploy/amazon/aws-ec2.md            |  2 +-
 .../deploy/amazon/amazon-eks/eks-helm.md      |  8 ++---
 .../amazon/openshift/terraform-setup.md       | 18 +++++-----
 .../deploy/openshift/redhat-openshift.md      | 36 +++++++++----------
 4 files changed, 32 insertions(+), 32 deletions(-)

diff --git a/docs/self-managed/setup/deploy/amazon/aws-ec2.md b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
index 9f11396eb7e..e4bc1b527e1 100644
--- a/docs/self-managed/setup/deploy/amazon/aws-ec2.md
+++ b/docs/self-managed/setup/deploy/amazon/aws-ec2.md
@@ -55,7 +55,7 @@ Alternatively, the same setup can run with a single AWS EC2 instance, but be awa
 
 - An AWS account to create any resources within AWS.
   - On a high level, permissions are required on the **ec2**, **iam**, **elasticloadbalancing**, **kms**, **logs**, and **es** level.
-  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.8/aws/ec2/example/policy.json).
+  - For a more fine-grained view of the permissions, check this [example policy](https://github.com/camunda/camunda-deployment-references/tree/main/aws/ec2/example/policy.json).
 - Terraform (1.7+)
 - Unix based Operating System (OS) with ssh and sftp
   - Windows may be used with [Cygwin](https://www.cygwin.com/) or [Windows WSL](https://learn.microsoft.com/en-us/windows/wsl/install) but has not been tested
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 513ecf9b04a..f4eaa1ace64 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -408,7 +408,7 @@ identity:
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
@@ -448,7 +448,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -646,7 +646,7 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
 ...and results in the following output:
@@ -656,7 +656,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-
   <summary>
 
 ```json reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index de89512014e..4d81b307c73 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -79,10 +79,10 @@ Following this tutorial and steps will result in:
 
 ### Obtain a copy of the reference architecture
 
-The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
+The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
 ```
 
 With the reference architecture downloaded and extracted, you can proceed with the remaining steps outlined in this documentation. Ensure that you are in the correct directory before continuing with further instructions.
@@ -170,7 +170,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -195,7 +195,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/stable/8.6/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -287,7 +287,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/cluster.tf
 
    ```
 
@@ -295,7 +295,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/modules/rosa-hcp/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/modules/rosa-hcp/README.md) for more information.
 
    :::
 
@@ -307,7 +307,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access, if you want to grant access to other users, please follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/modules/rosa-hcp/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/modules/rosa-hcp/README.md).
 
 ### Define outputs
 
@@ -343,7 +343,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
@@ -354,7 +354,7 @@ You can access the created OpenShift cluster using the following steps:
 Set up the required environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
 ```
 
 If you want to give cluster administrator access to the created user, this is not required for a standard installation but can be useful for debugging:
diff --git a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
index ce7afd77875..a4b459736e7 100644
--- a/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.6/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -63,7 +63,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -95,7 +95,7 @@ The route created by OpenShift will use a domain to provide access to the platfo
 To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/setup-application-domain.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -113,7 +113,7 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 Alternatively, if you use a dedicated IngressController for the deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -127,7 +127,7 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 **IngressController configuration:**
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/enable-ingress-http2.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**
@@ -170,7 +170,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
    ```
 
    The domain used by the Zeebe Gateway for gRPC is `zeebe-$DOMAIN_NAME` which different from the one used for the rest, namely `$DOMAIN_NAME`, to avoid any conflicts. It is also important to note that the port used for gRPC is `443`.
@@ -180,7 +180,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/operate-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/operate-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
@@ -190,7 +190,7 @@ The actual configuration properties can be reviewed [in the Operate configuratio
    Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/tasklist-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/tasklist-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
@@ -198,7 +198,7 @@ The actual configuration properties can be reviewed [in the Tasklist configurati
 1. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -208,7 +208,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -241,7 +241,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -261,7 +261,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -270,7 +270,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -285,13 +285,13 @@ Some components are not enabled by default in this deployment. For more informat
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -299,7 +299,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
   ```bash reference
-  https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/create-identity-secret.sh
+  https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/create-identity-secret.sh
   ```
 
 ### Install Camunda 8 using Helm
@@ -309,13 +309,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/openshift/single-region/procedure/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/openshift/single-region/procedure/install-chart.sh
 ```
 
 This command:
@@ -333,7 +333,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/integrate-tests-rosa/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/stable/8.6/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8

From 7d0bf3728690965611d729910bcc4976049e60b5 Mon Sep 17 00:00:00 2001
From: "Leo J." <153937047+leiicamundi@users.noreply.github.com>
Date: Thu, 13 Mar 2025 17:04:11 +0100
Subject: [PATCH 26/26] update feature/rosa-8.7 to main

---
 .../deploy/amazon/amazon-eks/eks-helm.md      |  8 +--
 .../openshift/terraform-setup-dual-region.md  | 22 ++++----
 .../amazon/openshift/terraform-setup.md       | 18 +++----
 .../setup/deploy/openshift/dual-region.md     | 52 +++++++++----------
 .../deploy/openshift/redhat-openshift.md      | 36 ++++++-------
 5 files changed, 68 insertions(+), 68 deletions(-)

diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
index 57b6a263e11..419c5f0e332 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/amazon-eks/eks-helm.md
@@ -409,7 +409,7 @@ identity:
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/kubernetes/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
@@ -449,7 +449,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 <details>
@@ -647,7 +647,7 @@ export ZEEBE_AUTHORIZATION_SERVER_URL=http://localhost:18080/auth/realms/camunda
 Generate a temporary token to access the REST API, then capture the value of the `access_token` property and store it as your token. Use the stored token (referred to as `TOKEN` in this case) to interact with the REST API and display the cluster topology:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology.sh
 ```
 
 ...and results in the following output:
@@ -657,7 +657,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/g
   <summary>
 
 ```json reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/kubernetes/single-region/procedure/check-zeebe-cluster-topology-output.json
 ```
 
   </summary>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
index a120e6b29e1..dbc457330fd 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md
@@ -161,7 +161,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/main/aws/openshift/rosa-hcp-dual-region/) is publicly available and serves as a starting point for deploying Red Hat OpenShift clusters on AWS using a Hosted Control Plane.
 It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html).
@@ -287,21 +287,21 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
    This configuration will use the previously created S3 bucket for storing the Terraform state file:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/terraform/clusters/config.tf
    ```
 
 5. Create a file named `cluster_region_1.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 1:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_1.tf
    ```
 
 6. Create a file named `cluster_region_2.tf` in the same directory as your `config.tf`.
    This file describes the cluster of the region 2:
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/terraform/clusters/cluster_region_2.tf
    ```
 
 7. After setting up the terraform files and ensuring your AWS authentication is configured, initialize your Terraform project, then, initialize Terraform to configure the backend and download necessary provider plugins:
@@ -334,13 +334,13 @@ this guide uses a dedicated [aws terraform provider](https://registry.terraform.
 
 1. Configure user access to the clusters. By default, the user who creates an OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster will be created.
 
-1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md).
+1. Customize the clusters setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/main/aws/modules/rosa-hcp/README.md).
 
 :::caution Camunda Terraform module
 
 This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md) for more information.
+We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/main/aws/modules/rosa-hcp/README.md) for more information.
 
 :::
 
@@ -417,13 +417,13 @@ We'll re-use the previously configured S3 bucket to store the state of the peeri
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/terraform/peering/config.tf
 ```
 
 Alongside the `config.tf` file, create a file called `peering.tf` to reference the peering configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/terraform/peering/peering.tf
 ```
 
 One cluster will be referenced as the **owner**, and the other as the **accepter**.
@@ -497,13 +497,13 @@ We'll re-use the previously configured S3 bucket to store the state of the backu
 Begin by setting up the `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/config.tf
 ```
 
 Finally, create a file called `backup_bucket.tf` to reference the elastic backup bucket configuration:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/terraform/backup_bucket/backup_bucket.tf
 ```
 
 This bucket configuration follows [multiple best practices](https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html).  
@@ -568,7 +568,7 @@ The `BACKUP_BUCKET_REGION` will define the region of the bucket, you can pick on
 
 ### Reference files
 
-You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/)
+You can find the reference files used on [this page](https://github.com/camunda/camunda-deployment-references/tree/main/aws/openshift/rosa-hcp-dual-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
index e149e14eb73..3b76d99eaf2 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/amazon/openshift/terraform-setup.md
@@ -75,10 +75,10 @@ Following this tutorial and steps will result in:
 
 ### Obtain a copy of the reference architecture
 
-The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
+The first step is to download a copy of the reference architecture from the [GitHub repository](https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-single-region/). This archive will be used throughout the rest of this documentation, the reference architecture are versioned using the same Camunda versions (`stable/8.x`).
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-single-region/procedure/get-your-copy.sh
 ```
 
 With the reference architecture downloaded and extracted, you can proceed with the remaining steps outlined in this documentation. Ensure that you are in the correct directory before continuing with further instructions.
@@ -166,7 +166,7 @@ This S3 bucket will now securely store your Terraform state files with versionin
 Once the S3 bucket is created, configure your `config.tf` file to use the S3 backend for managing the Terraform state:
 
 ```hcl reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/config.tf
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-single-region/config.tf
 ```
 
 #### Initialize Terraform
@@ -191,7 +191,7 @@ This module sets up the foundational configuration for ROSA HCP and Terraform us
 
 We will leverage [Terraform modules](https://developer.hashicorp.com/terraform/language/modules), which allow us to abstract resources into reusable components, simplifying infrastructure management.
 
-The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
+The [Camunda-provided module](https://github.com/camunda/camunda-deployment-references/tree/main/aws/openshift/rosa-hcp-single-region) is publicly available and serves as a robust starting point for deploying a Red Hat OpenShift cluster on AWS using a Hosted Control Plane. It is highly recommended to review this module before implementation to understand its structure and capabilities.
 
 Please note that this module is based on the official [ROSA HCP Terraform module documentation](https://docs.openshift.com/rosa/rosa_hcp/terraform/rosa-hcp-creating-a-cluster-quickly-terraform.html). It is presented as an example for running Camunda 8 in ROSA. For advanced use cases or custom setups, we encourage you to use the official module, which includes vendor-supported features.
 
@@ -283,14 +283,14 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
    :::
 
    ```hcl reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/cluster.tf
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-single-region/cluster.tf
    ```
 
    :::caution Camunda Terraform module
 
    This ROSA module is based on the [official Red Hat Terraform module for ROSA HCP](https://registry.terraform.io/modules/terraform-redhat/rosa-hcp/rhcs/latest). Please be aware of potential differences and choices in implementation between this module and the official one.
 
-   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md) for more information.
+   We invite you to consult the [Camunda ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/main/aws/modules/rosa-hcp/README.md) for more information.
 
    :::
 
@@ -302,7 +302,7 @@ To set up a ROSA cluster, certain prerequisites must be configured on your AWS a
 
 3. Configure user access to the cluster. By default, the user who creates the OpenShift cluster has administrative access. If you want to grant access to other users, follow the [Red Hat documentation for granting admin rights to users](https://docs.openshift.com/rosa/cloud_experts_tutorials/cloud-experts-getting-started/cloud-experts-getting-started-admin-rights.html) when the cluster is created.
 
-4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/modules/rosa-hcp/README.md).
+4. Customize the cluster setup. The module offers various input options that allow you to further customize the cluster configuration. For a comprehensive list of available options and detailed usage instructions, refer to the [ROSA module documentation](https://github.com/camunda/camunda-deployment-references/tree/main/aws/modules/rosa-hcp/README.md).
 
 ### Define outputs
 
@@ -338,7 +338,7 @@ Terraform will now create the OpenShift cluster with all the necessary configura
 
 Depending on the installation path you have chosen, you can find the reference files used on this page:
 
-- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/)
+- **Standard installation:** [Reference Files](https://github.com/camunda/camunda-deployment-references/tree/main/aws/openshift/rosa-hcp-single-region/)
 
 ## 2. Preparation for Camunda 8 installation
 
@@ -349,7 +349,7 @@ You can access the created OpenShift cluster using the following steps:
 Set up the required environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-single-region/procedure/gather-cluster-login-id.sh
 ```
 
 If you want to give cluster administrator access to the created user, this is not required for a standard installation but can be useful for debugging:
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
index c642e997a72..34ab0fbed03 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/dual-region.md
@@ -110,13 +110,13 @@ Later in this guide, we will refer to it as **first cluster**.
 2. The following manifest will create a namespace for the management cluster, enable the [open-cluster-management operator](https://open-cluster-management.io/) and the [associated subscription](https://docs.openshift.com/container-platform/4.17/operators/admin/olm-adding-operators-to-cluster.html#olm-installing-operator-from-operatorhub-using-cli_olm-adding-operators-to-a-cluster).
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Apply the manifests to enable ACM:
 
    ```bash
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/install-manifest.yml
    ```
 
    Verify that the installation succeeded:
@@ -133,7 +133,7 @@ Later in this guide, we will refer to it as **first cluster**.
    In this setup, the first cluster will act as the central hub, managing the second cluster. This capability enables the deployment and management of components on the second cluster directly from the first cluster.
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    :::caution Known issue: may not work correctly with the manifest
@@ -147,7 +147,7 @@ Later in this guide, we will refer to it as **first cluster**.
    Apply the manifest:
 
    ```bash
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/multi-cluster-hub.yml
    ```
 
    Wait until the status shows as "Running." This process can take up to 10 minutes:
@@ -170,7 +170,7 @@ Later in this guide, we will refer to it as **first cluster**.
 4. With the MultiClusterHub created, the last step is to create a `ManagedClusterSet` which is a group of managed clusters. With a `ManagedClusterSet`, you can manage access to all of the managed clusters in the group together
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
    Apply the manifest:
@@ -178,7 +178,7 @@ Later in this guide, we will refer to it as **first cluster**.
    ```bash
    oc --context $CLUSTER_1_NAME get mch -A
 
-   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
+   oc --context $CLUSTER_1_NAME apply -f https://raw.githubusercontent.com/camunda/camunda-deployment-references/refs/heads/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster-set.yml
    ```
 
 5. After creating the Managed Cluster Set, the next step is to import clusters into the set.
@@ -188,7 +188,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `managed-cluster.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/managed-cluster.yml.tpl
      ```
 
    - The cluster’s associated addon configuration will be managed using the following manifest.
@@ -196,7 +196,7 @@ Later in this guide, we will refer to it as **first cluster**.
      Save it as `klusterlet-config.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/klusterlet-config.yml.tpl
      ```
 
    - To import a cluster, you must store the associated authentication token.
@@ -204,13 +204,13 @@ Later in this guide, we will refer to it as **first cluster**.
      Save the following file as `auto-import-cluster-secret.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/auto-import-cluster-secret.yml.tpl
      ```
 
    - Finally, import each cluster into the Managed Cluster Set and verify that they can be reached and managed successfully:
 
      ```bash reference
-     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
+     https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/acm/initiate_cluster_set.sh
      ```
 
 ### Submariner
@@ -258,7 +258,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    Select the first node and apply the required label:
 
    ```bash reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/submariner/label_nodes_brokers.sh
    ```
 
 3. Deployment of Submariner on the clusters:
@@ -266,7 +266,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    - Save the following file as `submariner.yml.tpl`:
 
      ```yaml reference
-     https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
+     https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/submariner/submariner.yml.tpl
      ```
 
      :::note Cluster naming
@@ -314,7 +314,7 @@ Installing Submariner in OpenShift **requires** [Advanced Cluster Management](#a
    <summary>Example Submariner check successfull output</summary>
 
 ```text reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/submariner/output.txt
 ```
 
 </details>
@@ -323,7 +323,7 @@ For more comprehensive details regarding the verification tests for Submariner u
 
 **Debugging the Submariner setup:**
 
-If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
+If you are experiencing connectivity issues, we recommend spawning a pod in the `default` namespace that contains networking debugging tools. You can find an [example here](https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/submariner/debug-utils-submariner.yml).  
 With this pod, you will be able to check flow openings, service resolution, and other network-related aspects.  
 Troubleshooting requires examining all the underlying mechanisms of Submariner. Therefore, we also encourage you to read the [Submariner troubleshooting guide](https://submariner.io/operations/troubleshooting/).
 
@@ -337,7 +337,7 @@ Before proceeding with the installation, ensure the required information is avai
 Review and adjust the following environment script to match your specific configuration:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/export_environment_prerequisites.sh
 ```
 
 _If you are unsure about the values of the backup bucket, please refer to the [S3 backup bucket module setup](/self-managed/setup/deploy/amazon/openshift/terraform-setup-dual-region.md#s3-backup-bucket-module-setup) as a reference for implementation._
@@ -363,7 +363,7 @@ The Elasticsearch backup [bucket is tied to a specific region](https://docs.aws.
 The following script will create the required namespaces and secrets used to reference the bucket access.
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/setup_ns_secrets.sh
 ```
 
 Save it as `setup_ns_secrets.sh` and execute it:
@@ -380,7 +380,7 @@ Throughout this guide, you will add and merge values into these files to configu
 
 - Save the following file as both `values-region-1.yml` and `values-region-2.yml` to serve as the base configuration:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
+  https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-base.yml
   ```
 
 :::warning Merging YAML files
@@ -396,12 +396,12 @@ Set up the region ID using a unique integer for each region:
 
 - Add the following YAML configuration to your `values-region-1.yml`:
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
+  https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-1.yml
   ```
 - Add the following YAML configuration to your `values-region-2.yml`:
 
   ```yaml reference
-  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
+  https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/helm-values/values-region-2.yml
   ```
 
 **Security Context Constraints (SCCs)**
@@ -416,7 +416,7 @@ For custom configurations or specific requirements, please refer to the [install
 Before deploying, some values in the value files need to be updated. To assist with generating these values, save the following Bash script as `generate_zeebe_helm_values.sh`:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/generate_zeebe_helm_values.sh
 ```
 
 Then, source the output of the script. By doing so, we can reuse the values later for substitution, instead of manually adjusting the values files. You will be prompted to specify the number of Zeebe brokers (total number of Zeebe brokers in both Kubernetes clusters), for a dual-region setup we recommend `8`, resulting in four brokers per region:
@@ -438,7 +438,7 @@ Make sure that the variable `CLUSTER_1_NAME` is set to the name of your first cl
 Once you've prepared each region's value file (`values-region-1.yml` and `values-region-2.yml`) file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/generate_helm_values.sh
 ```
 
 ### Install Camunda 8 using Helm
@@ -446,7 +446,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/a
 With the value files for each region configured, you can now install Camunda 8 using Helm. Execute the following commands:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/install_chart.sh
 ```
 
 This command:
@@ -468,7 +468,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 Once Camunda is deployed across the two clusters, the next step is to expose each service to Submariner so it can be resolved by the other cluster:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/export_services_submariner.sh
 ```
 
 Alternatively, you can manage each service individually using the `ServiceExport` Custom Resource Definition (CRD).
@@ -489,13 +489,13 @@ metadata:
 For each cluster, verify the status of the exported services with this script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/verify_exported_services.sh
 ```
 
 To monitor the progress of the installation, save and execute the following script:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/verify_installation_completed.sh
 ```
 
 Save it as `verify_installation_completed.sh`, make it executable, and run it:
@@ -525,7 +525,7 @@ chmod +x verify_installation_completed.sh
       <summary>Example output</summary>
 
    ```text reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
+   https://github.com/camunda/camunda-deployment-references/blob/main/aws/openshift/rosa-hcp-dual-region/procedure/zeebe-http-output.txt
    ```
 
    </details>
diff --git a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
index 5398031a4fe..7569cc0fbef 100644
--- a/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
+++ b/versioned_docs/version-8.7/self-managed/setup/deploy/openshift/redhat-openshift.md
@@ -67,7 +67,7 @@ Over this guide, you will add and merge values in this file to configure your de
 You can find a reference example of this file here:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/base.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/base.yml
 ```
 
 :::danger Merging YAML files
@@ -99,7 +99,7 @@ The route created by OpenShift will use a domain to provide access to the platfo
 To retrieve the OpenShift applications domain (used as an example here), run the following command and define the route domain that will be used for the Camunda 8 deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/setup-application-domain.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/setup-application-domain.sh
 ```
 
 If you choose to use a custom domain instead, ensure it is supported by your router configuration and replace the example domain with your desired domain. For more details on configuring custom domains in OpenShift, refer to the official [custom domain OpenShift documentation](https://docs.openshift.com/dedicated/applications/deployments/osd-config-custom-domains-applications.html).
@@ -117,7 +117,7 @@ oc get ingresses.config/cluster -o json | jq '.metadata.annotations."ingress.ope
 Alternatively, if you use a dedicated IngressController for the deployment:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/get-ingress-http2-status.sh
 ```
 
 - If the output is `"true"`, it means HTTP/2 is enabled.
@@ -131,7 +131,7 @@ If HTTP/2 is not enabled, you can enable it by running the following command:
 **IngressController configuration:**
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/enable-ingress-http2.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/enable-ingress-http2.sh
 ```
 
 **Global cluster configuration:**
@@ -179,7 +179,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
    Update your `values.yml` file with the following:
 
    ```yaml reference
-   https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
+   https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/zeebe-gateway-route.yml
    ```
 
    The domain used by the Zeebe Gateway for gRPC is `zeebe-$DOMAIN_NAME` which different from the one used for the rest, namely `$DOMAIN_NAME`, to avoid any conflicts. It is also important to note that the port used for gRPC is `443`.
@@ -189,7 +189,7 @@ Additionally, the Zeebe Gateway should be configured to use an encrypted connect
 Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/operate-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/operate-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Operate configuration documentation](/self-managed/operate-deployment/operate-configuration.md#zeebe-broker-connection).
@@ -199,7 +199,7 @@ The actual configuration properties can be reviewed [in the Operate configuratio
    Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/tasklist-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/tasklist-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Tasklist configuration documentation](/self-managed/tasklist-deployment/tasklist-configuration.md#zeebe-broker-connection).
@@ -207,7 +207,7 @@ The actual configuration properties can be reviewed [in the Tasklist configurati
 1. **Connectors:** update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/connectors-route.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/connectors-route.yml
 ```
 
 The actual configuration properties can be reviewed [in the Connectors configuration documentation](/self-managed/connectors-deployment/connectors-configuration.md#zeebe-broker-connection).
@@ -217,7 +217,7 @@ The actual configuration properties can be reviewed [in the Connectors configura
 1. Set up the global configuration to enable the single Ingress definition with the host. Update your configuration file as shown below:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/domain.yml
 ```
 
 <!--Intended space left for not breaking the build!-->
@@ -250,7 +250,7 @@ However, you can use `kubectl port-forward` to access the Camunda platform witho
 To make this work, you will need to configure the deployment to reference `localhost` with the forwarded port. Update your `values.yml` file with the following:
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/no-domain.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/no-domain.yml
 ```
 
   </TabItem>
@@ -270,7 +270,7 @@ The `global.compatibility.openshift.adaptSecurityContext` variable in your value
 - `disabled`: The `runAsUser` and `fsGroup` values will not be modified (default).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/scc.yml
 ```
 
 </TabItem>
@@ -279,7 +279,7 @@ https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/g
 To use permissive SCCs, simply install the charts as they are. Follow the [general Helm deployment guide](/self-managed/setup/install.md).
 
 ```yaml reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/helm-values/no-scc.yml
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/helm-values/no-scc.yml
 ```
 
 </TabItem>
@@ -294,13 +294,13 @@ Some components are not enabled by default in this deployment. For more informat
 Once you've prepared the `values.yml` file, run the following `envsubst` command to substitute the environment variables with their actual values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/assemble-envsubst-values.sh
 ```
 
 Next, store various passwords in a Kubernetes secret, which will be used by the Helm chart. Below is an example of how to set up the required secret. You can use `openssl` to generate random secrets and store them in environment variables:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/generate-passwords.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/generate-passwords.sh
 ```
 
 Use these environment variables in the `kubectl` command to create the secret.
@@ -308,7 +308,7 @@ Use these environment variables in the `kubectl` command to create the secret.
 - The `smtp-password` should be replaced with the appropriate external value ([see how it's used by Web Modeler](/self-managed/modeler/web-modeler/configuration/configuration.md#smtp--email)).
 
   ```bash reference
-  https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/create-identity-secret.sh
+  https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/create-identity-secret.sh
   ```
 
 ### Install Camunda 8 using Helm
@@ -318,13 +318,13 @@ Now that the `generated-values.yml` is ready, you can install Camunda 8 using He
 The following are the required environment variables with some example values:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/chart-env.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/chart-env.sh
 ```
 
 Then run the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/openshift/single-region/procedure/install-chart.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/openshift/single-region/procedure/install-chart.sh
 ```
 
 This command:
@@ -342,7 +342,7 @@ This guide uses `helm upgrade --install` as it runs install on initial deploymen
 You can track the progress of the installation using the following command:
 
 ```bash reference
-https://github.com/camunda/camunda-deployment-references/blob/feature/rosa-8.7/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
+https://github.com/camunda/camunda-deployment-references/blob/main/generic/kubernetes/single-region/procedure/check-deployment-ready.sh
 ```
 
 ## Verify connectivity to Camunda 8