diff --git a/docs/guides/modules/deploy/pages/deploys-overview.adoc b/archive/deploys-overview.adoc
similarity index 99%
rename from docs/guides/modules/deploy/pages/deploys-overview.adoc
rename to archive/deploys-overview.adoc
index 752c0cdf3e..1d204e4f8b 100644
--- a/docs/guides/modules/deploy/pages/deploys-overview.adoc
+++ b/archive/deploys-overview.adoc
@@ -50,12 +50,12 @@ Configure environment integrations to install the CircleCI release agent into yo
 
 Developers can monitor deployments in the CircleCI web app, and run commands to manage those deployments from the UI. Commands are monitored by CircleCI and relayed to the release agent, which then runs the commands for you.
 
-[#releases-concepts]
+
 == Concepts
 
 The sections below explain some key software delivery concepts. Understanding these concepts will help you take full advantage of CircleCI deploys.
 
-[#component]
+
 === Component
 
 A _component_ in CircleCI is a collection of code and configuration that is deployed and released as a single unit. In Kubernetes terms, this would be a Deployment or Rollout object along with the related objects such as Pods, ReplicaSets, etc. that share a common `circleci.com/component-name` label.
diff --git a/docs/guides/modules/deploy/pages/rollback-a-project-by-workflow-rerun.adoc b/archive/rollback-a-project-by-workflow-rerun.adoc
similarity index 100%
rename from docs/guides/modules/deploy/pages/rollback-a-project-by-workflow-rerun.adoc
rename to archive/rollback-a-project-by-workflow-rerun.adoc
diff --git a/docs/guides/modules/deploy/pages/rollback-a-project-using-the-rollback-pipeline.adoc b/archive/rollback-a-project-using-the-rollback-pipeline.adoc
similarity index 100%
rename from docs/guides/modules/deploy/pages/rollback-a-project-using-the-rollback-pipeline.adoc
rename to archive/rollback-a-project-using-the-rollback-pipeline.adoc
diff --git a/docs/guides/modules/ROOT/nav.adoc b/docs/guides/modules/ROOT/nav.adoc
index 245a735946..b0bc000e97 100644
--- a/docs/guides/modules/ROOT/nav.adoc
+++ b/docs/guides/modules/ROOT/nav.adoc
@@ -161,19 +161,16 @@
 *** xref:test:troubleshoot-test-splitting.adoc[Troubleshoot test splitting]
 
 * Deploy with CircleCI
-** xref:deploy:deployment-overview.adoc[Overview of deployment on CircleCI]
-** xref:deploy:deploys-overview.adoc[CircleCI deploys overview]
+** xref:deploy:deployment-overview.adoc[Deployment and deploy management]
+** Setup
+*** xref:deploy:configure-deploy-markers.adoc[Configure deploy markers]
+*** xref:deploy:set-up-rollbacks.adoc[Rollbacks]
 ** Release agent setup
 *** xref:deploy:set-up-circleci-deploys.adoc[Set up CircleCI deploys]
 *** xref:deploy:set-up-the-release-agent.adoc[Set up the release agent]
 *** xref:deploy:configure-your-kubernetes-components.adoc[Configure your Kubernetes components]
 *** xref:deploy:update-the-kubernetes-release-agent.adoc[Update the Kubernetes release agent]
 *** xref:deploy:manage-deploys.adoc[Manage deploys]
-** Agentless setup
-*** xref:deploy:configure-deploy-markers.adoc[Configure deploy markers]
-*** xref:deploy:set-up-rollbacks.adoc[Set up rollbacks in CircleCI]
-*** xref:deploy:rollback-a-project-using-the-rollback-pipeline.adoc[Rollback a project using the rollback pipeline]
-*** xref:deploy:rollback-a-project-by-workflow-rerun.adoc[Rollback a project by workflow rerun]
 ** How-to guides
 *** xref:deploy:deploy-to-amazon-sagemaker.adoc[Deploy to Amazon SageMaker]
 *** xref:deploy:deploy-android-applications.adoc[Deploy Android applications]
diff --git a/docs/guides/modules/ROOT/partials/shared-sections/features-of-circleci.adoc b/docs/guides/modules/ROOT/partials/shared-sections/features-of-circleci.adoc
index 8fdea2bfeb..d5b4ee444b 100644
--- a/docs/guides/modules/ROOT/partials/shared-sections/features-of-circleci.adoc
+++ b/docs/guides/modules/ROOT/partials/shared-sections/features-of-circleci.adoc
@@ -25,4 +25,4 @@ For more information about Docker Layer Caching, refer to the xref:guides:optimi
 
 Visualise and control your deployments with CircleCI deploys. Deployments to Kubernetes and SageMaker are supported.
 
-Start with the xref:guides:deploy:deploys-overview.adoc[Deploys overview] for more information.
+Start with the xref:guides:deploy:deployment-overview.adoc[Deploys overview] for more information.
diff --git a/docs/guides/modules/about-circleci/pages/introduction-to-the-circleci-web-app.adoc b/docs/guides/modules/about-circleci/pages/introduction-to-the-circleci-web-app.adoc
index e09ffb98b9..67fd9a24d2 100644
--- a/docs/guides/modules/about-circleci/pages/introduction-to-the-circleci-web-app.adoc
+++ b/docs/guides/modules/about-circleci/pages/introduction-to-the-circleci-web-app.adoc
@@ -66,7 +66,7 @@ From your organization home page you have access to org-level options. You can c
 
 **Projects**: Allows you to see all projects associated with your organization. Choose to follow or unfollow projects, as well as xref:getting-started:create-project.adoc[create/set up new projects].
 
-**Deploys**: Set up environment integrations to manage deployments for your projects. For full details of the deployments feature, see the xref:deploy:deploys-overview.adoc[Deploys overview] page.
+**Deploys**: Set up environment integrations to manage deployments for your projects. For full details of the deployments feature, see the xref:deploy:deployment-overview.adoc[Deployment overview] page.
 
 **Insights**: Provides you with time-series data overviews of credit usage, success rates, pipeline duration, and more. For full details of the Insights feature, see the xref:insights:insights.adoc[Using Insights] page.
 
@@ -160,7 +160,7 @@ The following settings are available in the project settings page. If you do not
 * A list of configured xref:orchestrate:pipelines.adoc#pipelines-and-triggers[pipeline triggers]
 * Set up UI for scheduled pipelines if available for your integration. To set up a xref:orchestrate:scheduled-pipelines.adoc[scheduled pipeline] you will define a timetable, parameter, and attribution to automatically run a pipeline when the criteria is met.
 
-**Deploys**: A UI for managing and viewing deployments. Setup and manage environment integrations, setup components. For full information on the deploys feature, start with the xref:deploy:deploys-overview.adoc[Deploys overview] page.
+**Deploys**: A UI for managing and viewing deployments. Setup and manage environment integrations, setup components. For full information on the deploys feature, start with the xref:deploy:deployment-overview.adoc[Deployment overview] page.
 
 **Advanced**: Toggle options on and off for:
 
diff --git a/docs/guides/modules/about-circleci/pages/open-source.adoc b/docs/guides/modules/about-circleci/pages/open-source.adoc
index 3696748283..4783053e46 100644
--- a/docs/guides/modules/about-circleci/pages/open-source.adoc
+++ b/docs/guides/modules/about-circleci/pages/open-source.adoc
@@ -10,7 +10,7 @@ This page provides the details of 3rd-party open source components used in Circl
 Release agent::
 +
 --
-The following 3rd-party open source components are used in the CircleCI release agent. The release agent is used to integrate CircleCI with Kubernetes clusters for release management. For more information, see the xref:deploy:deploys-overview.adoc[Deploys docs].
+The following 3rd-party open source components are used in the CircleCI release agent. The release agent is used to integrate CircleCI with Kubernetes clusters for release management. For more information, see the xref:deploy:deployment-overview.adoc[Deploys docs].
 
 [cols=2*, options="header", format=csv]
 |===
diff --git a/docs/guides/modules/deploy/pages/configure-deploy-markers.adoc b/docs/guides/modules/deploy/pages/configure-deploy-markers.adoc
index 3ad4c4dc0b..49ac283290 100644
--- a/docs/guides/modules/deploy/pages/configure-deploy-markers.adoc
+++ b/docs/guides/modules/deploy/pages/configure-deploy-markers.adoc
@@ -9,22 +9,29 @@ This tutorial shows how to add a deploy marker step to your workflow config. Dep
 
 Deploy markers provide a lightweight way to log your deployments without requiring a you to install the CircleCI release agent. If you install deploy markers, as described in this guide, you will also be able to use the xref:set-up-rollbacks.adoc[CircleCI rollback feature].
 
-For a full guide to CircleCI's deploys features and functionality, refer to the xref:set-up-circleci-deploys.adoc[Set up CircleCI deploys] guide.
+For a full guide to CircleCI's deploys features and functionality, refer to the xref:deployment-overview.adoc[Deployment and deploy management] guide.
+
+You can configure deploy markers as follows:
+
+* To display updated statuses depending of the outcome of your deployments. Steps for this are provided in the <<deploy-markers-with-status-updates>> section.
+* Or, you can choose to configure deploy markers to log deployments without status updates. Steps for this are provided in the <<deploy-logs-without-status-updates>> section.
 
 == Prerequisites
 
 * A CircleCI account connected to your code. You can link:https://circleci.com/signup/[sign up for free].
 * A CircleCI project with a workflow configured to deploy your code.
 
-== 1. Update the configuration
+== Deploy markers with status updates
 
 To create a deployment marker, you will update your CircleCI configuration file.
+
 You will add commands to plan a deploy and then update its status based on the outcome of your deployment script.
 
+NOTE: The `circleci run release` commands are only available in CircleCI builds and are not part of the CircleCI local CLI. You do not need to install the CircleCI local CLI in your CircleCI pipeline to use these commands.
+
 === 1.1. Plan a deploy
 
 Add a `circleci run release plan` command to your deployment job. This tells CircleCI to plan a new deploy and show it in the link:https://app.circleci.com/deploys[Deploys UI] with `pending` status.
-The `target-version` parameter should match the name of the version being deployed.
 
 [,yml]
 ----
@@ -32,47 +39,42 @@ jobs:
   deploy-my-service:
     executor: some-executor
     steps:
-      - run: circleci run release plan --target-version=<some-version-name>
+      - run: circleci run release plan <deploy-name> --environment-name=<some-environment-name> --component-name=<some-component-name> --target-version=<some-version-name> --namespace=<some-namespace>
 ----
 
-If you do not have an environment set up in your organization a new one will be created with the name `default`. This will be set as the target for this deploy. See <<manage-environments>> for more information.
+In this example, note the following flags and options:
+
+* The `<deploy-name>` argument is used to identify the deployment. `deploy-name` is an arbitrary positional argument that will be used to identify the deployment and should be unique within the workflow. If not specified, the deployment name will be set to `default`. If you are deploying multiple components or to multiple environments from a single workflow, you need to provide the command with a deployment name.
+* The `--environment-name` flag sets the target environment. If the specified environment does not exist, it will be created. If you do not specify an environment, CircleCI will create one named `default`.
+* The `--component-name` flag sets the name that will be displayed in the Deploys UI. If you do not already have a component in your project a new one will be created with the name of the project. This will be set as the component that is being deployed.
+* The `--target-version` flag should match the version being deployed. Some examples are provided <<examples-for-target-version,in the next section>>.
+* The `--namespace` flag is optional and can be provided to use a value other than `default`.
+
+Configuring `circleci run release plan` identifies the deployment you are planning so that you can reference it to update its status later on.
 
-If you do not already have a component in your project a new one will be created with the name of the project. This will be set as the component that is being deployed.
+==== Examples for target-version
 
-If you already have multiple environments and components you must specify their names manually, as follows:
+This section provides some options for setting the `target-version` parameter.
 
+* One option is to use CircleCI's built-in environment variables. For example you could define the target version as follows:
++
 [,yml]
 ----
-jobs:
-  deploy-my-service:
-    executor: some-executor
-    steps:
-      - run: circleci run release plan --environment-name=<some-environment-name> --component-name=<some-component-name> --target-version=<some-version-name> --namespace=<some-namespace>
+--target-version="1.0.${CIRCLE_BUILD_NUM}-${CIRCLE_SHA1:0:7}"
 ----
++
+This configuration would yield a value with the following format `1.0.28853-ffdbeb1`.
 
-In this example, note the following:
-
-** The `environment-name` parameter sets the target environment. If the specified environment does not exist, it will be created.
-** The `component-name` parameter sets the name that will be displayed in the Deploys UI.
-** The `namespace` parameter is optional and can be provided to use a value other than `default`.
-
-If you are deploying multiple components or to multiple environments from a single workflow, you need to provide the command with a deployment name.
-This identifies the deployment your are planning so that you can later on reference it to update its status.
-This can be done as shown below:
-
+* Another option is to use pipeline values. For example you could define the target version as follows:
++
 [,yml]
 ----
-jobs:
-  deploy-my-service:
-    executor: some-executor
-    steps:
-      - run: circleci run release plan <deploy-name> --environment-name=<some-environment-name> --component-name<=>some-component-name> --target-version=<some-version-name>
+--target-version=<< pipeline.number >>
 ----
++
+This configuration would yield a value with the following format `12345`.
 
-In the example the positional argument `deploy-name` is the arbitrary value that will be used to identify the deployment and should be unique within the workflow.
-If not specified, the deployment name will be set to `default`.
-
-=== 1.2. Update the deploy status
+=== 1.2. Update the deploy status to running
 
 After deploying your application, you can update the status of the deployment to `RUNNING` by running the `circleci run release update` command in a new step.
 
@@ -88,8 +90,7 @@ jobs:
       - run: circleci run release update --status=running
 ----
 
-If you are deploying multiple components or to multiple environments from a single workflow, you need to provide the command with a deployment name.
-This value should match the value you provided when you planned the deploy.
+If you are deploying multiple components or to multiple environments from a single workflow, you need to provide the command with a deployment name. The deploy name value should match the value you provided when you planned the deploy.
 
 [,yml]
 ----
@@ -103,8 +104,10 @@ jobs:
       - run: circleci run release update <deploy-name> --status=running
 ----
 
-Now you can use the `when` attribute to add `on_success` and `on_failure` steps at the end of your deployment job, to handle the final status update of the deploy.
+=== 1.3. Update the deploy status to success or failure
+You can use the `when` attribute to add `on_success` and `on_failure` steps at the end of your deployment job, to handle the final status update of the deploy.
 
+.Config file example showing deploy status update to success or failure
 [,yml]
 ----
 jobs:
@@ -132,10 +135,11 @@ jobs:
           when: on_fail
 ----
 
-This will update the status of the deploy to `SUCCESS` or `FAILED` depending on the outcome of your job.
-In this example, the `failure_reason.env` file can be created by a previous step in the job. This can be done, for example, in a step in which we are validating the status of the deployment.
-You can do that as shown below:
+In this example, the status of the deploy is updated to `SUCCESS` or `FAILED` depending on the outcome of your job.
+
+The `failure_reason.env` file can be created by a previous step in the job. This can be done, for example, in a step in which we are validating the status of the deployment. One way to do this is as follows:
 
+.Create a file to store the failure reason
 [,yml]
 ----
 echo "FAILURE_REASON='Deployment was not found'" > failure_reason.env
@@ -143,10 +147,11 @@ echo "FAILURE_REASON='Deployment was not found'" > failure_reason.env
 
 CAUTION: Trying to update the status of the deploy after updating it to a terminal status such as `SUCCESS`, `FAILED` or `CANCELED` is not supported and will result in an error.
 
-=== 1.3 Update the deploy status to canceled
+=== 1.4 Update the deploy status to canceled
 
 If you want to update your deployment to `canceled` when the deploy job is canceled, you can do so by adding the following job to your configuration.
 
+.Job configuration for updating the deploy status to canceled
 [,yml]
 ----
 jobs:
@@ -166,6 +171,7 @@ jobs:
 
 Then you can add it to your workflow as shown below.
 
+.Workflow configuration for updating the deploy status to canceled. The cancel-deploy job only runs when the deploy job is canceled
 [,yml]
 ----
 workflows:
@@ -178,9 +184,9 @@ workflows:
               - canceled
 ----
 
-This will make it sot that the job will be run only when the `deploy` job is canceled, thus updating the deployment to the `canceled` status.
+In this example, the `cancel-deploy` job will be run only when the `deploy` job is canceled, thus updating the deployment to the `canceled` status.
 
-=== 1.4. Full config example
+=== 1.5. Full config example
 
 For reference, here is a full example of a CircleCI config that makes use of the deployment tracking feature.
 
@@ -239,7 +245,7 @@ workflows:
               - canceled
 ----
 
-== 2. Deploy logs
+== Deploy logs without status updates
 
 Sometimes you might not want your deployment marker to have any specific status, but still want it to be logged in the deploys UI.
 In those cases you can use the `release log` command in place of `release plan` as shown in the example below.
@@ -271,25 +277,27 @@ jobs:
       - run: circleci run release log --environment-name=<some-environment-name> --component-name=<some-component-name> --target-version=<some-version-name>
 ----
 
-** The `environment-name` specifies the target environment. If the environment does not exist, it will be created.
-** The `component-name` parameter sets the name that will be displayed in the CircleCI UI.
-** The `target-version` parameter should match the name of the version being deployed.
+** The `--environment-name` flag specifies the target environment. If the environment does not exist, it will be created.
+** The `--component-name` flag sets the name that will be displayed in the CircleCI UI.
+** The `--target-version` flag should match the name of the version being deployed. Some examples are provided <<examples-for-target-version,above>>.
 ** (Optional) You can provide the following parameter if required:
-*** The `namespace` parameter can be provided to use a value other than `default`.
+*** The `--namespace` flag can be provided to use a value other than `default`.
+
+== Manage environments
+
+In this guide we created an environment integration by supplying a name with the `--environment-name` flag. This was an optional step. If you did not specify an environment CircleCI will have created one for you with the name `default`.
 
-[#manage-environments]
-== 3. Manage environments
+You can also create an environment integration manually in the CircleCI web app.
 
-Configuring deploy markers will automatically create an environment integration in the link:https://app.circleci.com/deploys[CircleCI deploys UI] with the name you specified or with the `default` name if you didn't specify any.
-You can then use the link:https://app.circleci.com/deploys/github/circleci#environments[CircleCI UI] to manage your environments, by creating, deleting or updating them.
-To manually create an environment integration, follow these steps:
+=== Create an environment integration
 
-. In the CircleCI web app, select **Deploys** in the sidebar.
-. If this is your first environment setup, select btn:[Create your first Environment Integration]. If you already have environments set up, choose the **Environments** tab and select btn:[Create Environment Integration].
+. In the link:https://app.circleci.com[CircleCI web app], select your org from the org cards on your user homepage.
+. Select **Deploys** in the sidebar.
+. Select the **Environments** tab.
+. Select btn:[Create Environment Integration].
 . Enter a name for your environment, and a description if you would like.
-. Use the dropdown menu to choose your environment integration type, then select btn:[Next: Release Agent Setup].
-If you plan to only use deploy markers, as opposed to the Kubernetes agent, feel free to choose the `custom` type.
-**You do not need to continue with installing a release agent at this point**, but you will need to reference this environment integration name as part of your config when adding the `log release` step below.
+. Use the dropdown menu to choose your environment integration type. Choose the "Custom" option to follow along with this guide,. If you are deploying to your Kubernetes cluster you can or if you want to use the CircleCI release agent, then choose "Kubernetes Cluster" and head over to the xref:set-up-circleci-deploys.adoc[Release agent setup] page.
+. Select btn:[Save and Continue].
 
 == Next steps
 
@@ -297,5 +305,4 @@ By following the steps in this guide, you have added a deploy marker to your Cir
 You can now track the status of your deployments across your configured environments in the CircleCI deploys UI and in the project home page.
 You can now:
 
-* xref:set-up-the-release-agent.adoc[Set up a release agent on your Kubernetes cluster].
-* xref:configure-deploy-markers.adoc[Learn about deploy markers]
+* xref:set-up-rollbacks.adoc[Set up rollbacks].
diff --git a/docs/guides/modules/deploy/pages/deploy-to-amazon-sagemaker.adoc b/docs/guides/modules/deploy/pages/deploy-to-amazon-sagemaker.adoc
index faf0fd85da..da8f725da4 100644
--- a/docs/guides/modules/deploy/pages/deploy-to-amazon-sagemaker.adoc
+++ b/docs/guides/modules/deploy/pages/deploy-to-amazon-sagemaker.adoc
@@ -9,7 +9,7 @@ This how-to guide walks you through the steps to set up and use the Amazon SageM
 
 For further information about the orb and the CircleCI deploys feature see the following:
 
-* xref:deploys-overview.adoc[Deploys overview]
+* xref:deployment-overview.adoc[Deployment overview]
 * link:https://circleci.com/developer/orbs/orb/circleci/aws-sagemaker[Amazon SageMaker orb]
 * link:https://circleci.com/blog/amazon-sagemaker-deployment-orchestration/[**Blog post**: Using Amazon SageMaker orb to orchestrate model deployment across environments]
 
@@ -180,7 +180,7 @@ image::guides:ROOT:deploy/role-arn.png[Screenshot showing location of Role ARN]
 
 The CircleCI Amazon SageMaker orb requires some environment variables to function. You can store these environment variables at the project level, or you can store them using a xref:security:contexts.adoc[context]. The following steps show how to add the environment variables at the project level. You need to add two environment variables, as follows:
 
-* `CCI_RELEASE_INTEGRATION_TOKEN`: The orb connects your deployment to SageMaker with xref:deploys-overview.adoc[CircleCI deploys]. This gives you visibility into the Endpoint Configuration Updates, and what is currently active.
+* `CCI_RELEASE_INTEGRATION_TOKEN`: The orb connects your deployment to SageMaker with xref:deployment-overview.adoc[CircleCI deploys]. This gives you visibility into the Endpoint Configuration Updates, and what is currently active.
 * `SAGEMAKER_EXECUTION_ROLE_ARN`: This is the AWS IAM Role you configured with the necessary SageMaker permissions, and the OIDC Trust relationship.
 
 {empty} +
diff --git a/docs/guides/modules/deploy/pages/deployment-overview.adoc b/docs/guides/modules/deploy/pages/deployment-overview.adoc
index 291a185571..fafb8e1551 100644
--- a/docs/guides/modules/deploy/pages/deployment-overview.adoc
+++ b/docs/guides/modules/deploy/pages/deployment-overview.adoc
@@ -1,15 +1,14 @@
-= Deployment overview
+= Deployment and deploy management overview
+:page-aliases: deploys-overview.adoc
 :page-platform: Cloud, Server v4+
-:page-description: Learn the basics of CircleCI deployment.
+:page-description: Learn the basics of deployment and deploys management with CircleCI.
 :experimental:
 
-[#introduction]
-== Introduction
+With CircleCI you can deploy to any target and manage your deployments in the CircleCI web app. Track deployments using deploy markers and rollback deployments to a previous version.
 
-Once a software application has been developed and tested, it needs to be deployed and made available for its intended audience.
-With CircleCI, you can deploy to virtually any target.
+== Introduction
 
-You can also configure CircleCI to integrate with other services for:
+Once a software application has been developed and tested, it needs to be deployed and made available for its intended audience. With CircleCI, you can deploy to virtually any target and configure CircleCI to integrate with other services for:
 
 * QA and testing
 * Feature management
@@ -17,9 +16,8 @@ You can also configure CircleCI to integrate with other services for:
 
 Customize your configuration to match your requirements, whether you need a fully automated process or one that requires manual approval.
 
-NOTE: **Deploy to Kubernetes?** Refer to our xref:deploys-overview.adoc[Deploys overview] page to start managing your deployments in the CircleCI web app.
+Set up deploy markers to track deployments in the CircleCI web app and rollback to previous versions as required.
 
-[#the-basics-of-deployment]
 == The basics of deployment
 
 Here are the core concepts you need to get a deployment set up:
@@ -40,8 +38,7 @@ This job will create a manual approval button visible in the CircleCI web app wo
 
 If you need to restrict connections, consider enabling xref:security:ip-ranges.adoc[IP ranges] for your deployment job.
 
-[#using-orbs-to-simplify-deployment]
-== Using orbs to simplify deployment
+=== Using orbs to simplify deployment
 
 xref:orbs:use:orb-intro.adoc[Orbs] are packages of reusable configuration.
 For simpler deployment pipelines, you can use orbs to achieve the results you need with minimal configuration.
@@ -72,8 +69,7 @@ Under the hood, this orb creates, bundles, and deploys your application using yo
 
 Check out the full range of available orbs in the link:https://circleci.com/developer/orbs[orbs registry]. If the orb you need has not been created yet, consider xref:orbs:author:orb-author.adoc[authoring one]!
 
-[#using-images-to-simplify-deployment]
-== Using images to simplify deployment
+=== Using images to simplify deployment
 
 CircleCI provides maintained Docker images (convenience images) that contain the tools required for common deployment scenarios.
 Convenience images provide fast spin-up times, reliability, and stability.
@@ -84,28 +80,335 @@ Visit the link:https://circleci.com/developer/images?imageType=docker[CircleCI D
 - link:https://circleci.com/developer/images/image/cimg/azure[`cimg/azure`]
 - link:https://circleci.com/developer/images/image/cimg/gcp[`cimg/gcp`]
 
-[#next-steps]
-== Handling common deployment scenarios
-
-Use the following how-to guides to manage common deployment use cases:
-
-* For examples of deploying to Kubernetes, see the guides in the link:https://github.com/CircleCI-Public/cd-config-examples/blob/main/docs/cci_deploy/deployment_helm.md[Continuous deployment config examples] repo.
-* xref:deploy-to-amazon-sagemaker.adoc[Deploy to Amazon SageMaker]
-* xref:deploy-android-applications.adoc[Deploy Android applications]
-* xref:deploy-to-artifactory.adoc[Deploy to Artifactory]
-* xref:deploy-to-aws.adoc[Deploy to AWS]
-* xref:deploy-service-update-to-aws-ecs.adoc[Deploy to AWS ECS]
-* xref:ecs-ecr.adoc[Deploy to AWS ECR/ECS]
-* xref:deploy-to-azure-container-registry.adoc[Deploy to Azure Container Registry]
-* xref:deploy-to-capistrano.adoc[Deploy to Capistrano]
-* xref:deploy-to-cloud-foundry.adoc[Deploy to Cloud Foundry]
-* xref:deploy-to-firebase.adoc[Deploy to Firebase]
-* xref:deploy-to-google-cloud-platform.adoc[Deploy to Google Cloud Platform]
-* xref:deploy-to-heroku.adoc[Deploy to Heroku]
-* xref:deploy-ios-applications.adoc[Deploy iOS applications]
-* xref:deploy-to-npm-registry.adoc[Deploy to npm registry]
-* xref:deploy-over-ssh.adoc[Deploy over SSH]
-* xref:integration:authorize-google-cloud-sdk.adoc[Authorize Google Cloud SDK]
-* xref:publish-packages-to-packagecloud.adoc[Publish packages to Packagecloud]
+=== Handling common deployment scenarios
+
+Use the how-to guides in this section (select how-to guides from the left-hand navigation) to manage common deployment use cases.
 
 Go to the link:https://circleci.com/developer/orbs[orbs registry] to simplify your configuration by using an orb for your deployment target.
+
+== Deploys management
+
+CircleCI deploys gives you visibility into your deployments within the CircleCI web app.
+When setting up deploys you will add CLI commands to your config to enable logging and tracking of deploys and deployment status in the CircleCI UI. Use rollbacks to rollback to a previous version of a component.
+
+If you are deploying to Kubernetes you can choose to use the CircleCI release agent, which you install in your cluster to enable you to manage your deployments through CircleCI. If you choose the release agent approach, you will have access to the following deploy management tools from CircleCI:
+
+* Restore version
+* Scale component
+* Restart component
+
+The release agent supports link:https://argoproj.github.io/argo-rollouts/[Argo Rollouts] for progressive delivery. Currently the link:https://argo-rollouts.readthedocs.io/en/stable/concepts/#canary[canary deployment strategy] is supported, but in a future release link:https://argo-rollouts.readthedocs.io/en/stable/concepts/#blue-green[blue-green] will also be supported. Some further controls are available for projects that use Argo Rollouts:
+
+* Retry Rollout
+* Promote Rollout
+* Cancel Rollout
+
+=== Quickstart
+
+To get started with CircleCI deploys right away, refer to the following guides:
+
+* xref:configure-deploy-markers.adoc[Tutorial 1: Configure CircleCI deploy markers]
+* xref:set-up-rollbacks.adoc[Tutorial 2: Set up rollbacks]
+
+If you would like to install the release agent in your cluster, refer to the following guides:
+
+* xref:set-up-circleci-deploys.adoc[Set up CircleCI deploys environments]
+* xref:set-up-the-release-agent.adoc[Set up the release agent]
+* xref:configure-your-kubernetes-components.adoc[Configure your Kubernetes components]
+* xref:manage-deploys.adoc[How-to: Manage deploys]
+
+=== Release agent overview
+
+CircleCI integrates with your Kubernetes cluster to give you visibility and control over your release process through the CircleCI web app. We currently support Kubernetes Deployments and Argo Rollouts.
+
+image::guides:ROOT:releases/releases-architecture.png[Diagram showing the architecture of CircleCI deploys]
+
+Configure environment integrations to install the CircleCI release agent into your Kubernetes clusters. Configure the release agent to only monitor the namespaces you require.
+
+Developers can monitor deployments in the CircleCI web app, and run commands to manage those deployments from the UI. Commands are monitored by CircleCI and relayed to the release agent, which then runs the commands for you.
+
+=== Concepts
+
+The sections below explain some key software delivery concepts. Understanding these concepts will help you take full advantage of CircleCI deploys.
+
+
+==== Component
+
+A _component_ in CircleCI is a collection of code and configuration that is deployed and released as a single unit. In Kubernetes terms, this would be a Deployment or Rollout object along with the related objects such as Pods, ReplicaSets, etc. that share a common `circleci.com/component-name` label.
+
+==== Delivery
+
+_Delivery_ is the act of packaging code changes and making them available for Deployment. Continuous delivery is the prerequisite step for continuous deployment. With some variations on the technologies being used, the delivery process creates executables from code and then makes them available to be deployed to an environment at a subsequent time.
+
+==== Deployment
+
+_Deployment_ is the act of putting a new component version into an environment, regardless of whether users and other services interact with the new version or a previous one. Depending on the deployment type, a release may happen either:
+
+* As a later task, such as switching over traffic shaping rules for a blue/green deployment.
+* As a direct consequence of the deployment, such as a standard Kubernetes rolling update.
+
+==== Command
+
+A _command_ is a user-initiated action CircleCI performs on the user's behalf to manipulate a specific component. Actions are run asynchronously via our release agent and the results are reported back to the CircleCI web app. You can see the results in the deployments dashboard, similarly to how step output works for CI jobs.
+
+Some commands are available for all components. These are:
+
+* Restore version
+* Scale component
+* Restart component
+
+A subset of commands are available for _progressive_ deployments (when using Argo Rollouts). These are:
+
+* Retry deployment
+* Promote deployment
+* Cancel deployment
+
+==== Release
+
+A _release_ is the act of updating a component to a new version in a specific environment, causing it to become available to an audience of users and other services.
+
+A release can happen when an existing component is updated or when the first version for a new component is deployed.
+
+In the deploys dashboard, deployments are tagged as **Progressive** if they refer to an Argo Rollout.
+
+A deployment starts when the component version is updated, and ends when the new version has reached 100% availability, and all associated validations have been completed. In the case of a progressive deployment, this happens when the Rollout completes. In the case of a Kubernetes Deployment, this happens when the Deployment replicas are all available and ready.
+
+[#the-deploys-UI]
+== The deploys UI
+
+The CircleCI deploys UI is a powerful tool for visualising, monitoring and managing your deployments. The pages included in the deploys UI are described below.
+
+[#dashboard]
+=== The dashboard
+
+image::guides:ROOT:releases/dashboard.png[Screenshot showing the deploys dashboard in the CircleCI web app]
+
+Select **Deploys** in the CircleCI web app sidebar to enter the deploys dashboard. The dashboard shows the following:
+
+* **Timeline**: A timeline of deploys across your organization's components and environments. You can use the filter dropdown menus at the top of the page to select a component and/or environment. You will see live status updates, deployment trigger source, deployment version version, deployment type (for example, _progressive_, when you are using an Argo Rollout). From here you can access the following:
+** The deployment details page for a specific deployment by clicking on the status badge or version number.
+** The component or environment details pages by clicking on the respective names.
+** The project dashboard for the CircleCI project associated with a deployment.
+** The job details page for the job that started the deployment.
+** The commit details page in your VCS for the commit that started the deployment.
+
+* **Environments**: List of environment integrations set up for your organization. From here you can:
+** Set up a new environment integration by selecting btn:[Create Environment Integration].
+** Access settings for each environment image:guides:ROOT:icons/settings.svg[settings icon, role="no-border"].
+** Access the environment details view by selecting an environment name.
+
+* **Components**: A list of components and their associated projects. From here you can:
+** Set up a new component by selecting btn:[Create Component]. From here you can select and environment that has a successful environment integration set up, and from there you can add a new component.
+** Get straight to the component's project building on CircleCI by selecting the project name.
+** Access setting for each component image:guides:ROOT:icons/settings.svg[settings icon, role="no-border"].
+
+=== Filter and group components and environments with labels
+
+Add labels to your components and environments to provide teams with a way to filter and group content in the deploys UI. Once a label is added, you can use this to filter your view to focus on the content relevant to your team.
+
+Labels are composed of two values separated by a colon, for example, `team:my-team-name`. To specify multiple labels for a component or environment, you can separate them with a comma. For example, `team:my-team-name, role:web`. You can add up to 20 labels to a component or environment.
+
+==== Use labels to filter components and environments
+
+Once you have added labels to your components and environments, you can use them to filter your view in the deploys UI. In the timeline, environments, or components view, select a filter to reduce the content in the tab to only your selection. You can also use the label filter dropdown menu at the top of the page.
+
+==== Add or edit labels
+
+To add or edit labels follow the steps below.
+
+.Add and Edit environment and component labels
+image::guides:ROOT:releases/edit-labels.png[Screenshot showing the location of the add/edit labels button]
+
+===== Component labels
+
+To add or edit labels for a component, follow these steps:
+
+. Select *Deploys* in the CircleCI web app sidebar.
+. You are now in the timeline view. Select the **Components** tab.
+. Select the cog icon image:guides:ROOT:icons/settings.svg[settings icon, role="no-border"] for your component. You can use the filter at the top of the page to help find the component you want.
+. You are now on the component settings page. Select the edit button image:guides:ROOT:icons/edit-solid.svg[edit icon, role="no-border"] in the labels panel.
+. Enter or edit your label(s) and select btn:[Done].
+
+===== Environment labels
+
+To add or edit labels for an environment, follow these steps:
+
+. Select *Deploys* in the CircleCI web app sidebar.
+. You are now in the timeline view. Select the **Environments** tab.
+. Select the cog icon image:guides:ROOT:icons/settings.svg[settings icon, role="no-border"] for your environment.
+. You are now on the environment settings page. Select the edit button image:guides:ROOT:icons/edit-solid.svg[edit icon, role="no-border"] in the labels panel.
+. Enter or edit your label(s) and select btn:[Done].
+
+=== View all deployments for an environment
+
+To view all deployments for an environment, follow these steps:
+
+. Select *Deploys* in the CircleCI web app sidebar.
+. You are now in the timeline view. Select the **Environments** tab.
+. Select your environment by name.
+. You are now on the environment details page. Select the **Deployments** tab to view a list of all deployments for your chosen environment.
+
+=== View all commands run for an environment
+
+To view all commands run for an environment, follow these steps:
+
+. Select *Deploys* in the CircleCI web app sidebar.
+. You are now in the timeline view. Select the **Environments** tab.
+. Select your environment by name.
+. You are now on the environment details page. Select the **Commands** tab to view a list of all commands that have been run for your chosen environment.
+
+=== View all deployments for a component
+
+To view all deployments for a component, follow these steps:
+
+. Select *Deploys* in the CircleCI web app sidebar.
+. You are now in the timeline view. Select the **Components** tab.
+. Select your component by name. You can use the filter at the top of the page to help.
+. You are now on the component details page. Select the **Deployments** tab to view a list of all deployments for your chosen component.
+
+=== View all commands run for a component
+
+To view all commands run for a component, follow these steps:
+
+. Select *Deploys* in the CircleCI web app sidebar.
+. You are now in the timeline view. Select the **Components** tab.
+. Select your component by name. You can use the filter at the top of the page to help.
+. You are now on the component details page. Select the **Commands** tab to view a list of all commands run for your chosen component.
+
+== Requirements
+
+The following section describes the requirements for using the release agent.
+
+=== Tooling
+
+We test the versions listed here. Older versions may work but are not guaranteed.
+
+include::ROOT:partial$deploy/supported-versions.adoc[]
+
+=== Labels and annotations
+
+The following table shows a complete list of labels and annotations either required or available for configuring your environment integration.
+
+[cols=4*, options="header"]
+|===
+|
+|Label/annotation
+|Value
+|Required?
+
+|`Metadata.Labels`
+|`circleci.com/component-name`
+|A name for your application
+|Yes
+
+|`Metadata.Labels`
+|`circleci.com/version`
+|Current version
+|Yes
+
+|`Spec.Template.Metadata.Labels`
+|`circleci.com/component-name`
+|See above
+| Yes
+
+|`Spec.Template.Metadata.Labels`
+|`circleci.com/version`
+|See above
+| Yes
+
+|`Metadata.Annotations`
+|`circleci.com/project-id`
+|Project ID for the CircleCI project associated with the job that deploys your component
+|Yes
+
+|`Metadata.Annotations`
+|`circleci.com/operation-timeout`
+|A link:https://pkg.go.dev/time#ParseDuration[Go duration string], for example, 5m, 10m15s
+|No. Only needed to set a custom timeout duration. This option is only available if you are using Helm to configure your Kubernetes resources.
+
+|`Metadata.Annotations`
+|`circleci.com/restore-version-enabled`
+|`false`
+|No. Only set if you want to disable the restore version feature for your component.
+
+|`Metadata.Annotations`
+|`circleci.com/scale-component-enabled`
+|`false`
+|No. Only set if you want to disable the scale component feature for your component.
+
+|`Metadata.Annotations`
+|`circleci.com/restart-component-enabled`
+|`false`
+|No. Only set if you want to disable the restart component feature for your component.
+
+|`Metadata.Annotations`
+|`circleci.com/retry-release-enabled`
+|`false`
+|No. Only set if you want to disable the retry deployment feature for your component.
+
+|`Metadata.Annotations`
+|`circleci.com/promote-release-enabled`
+|`false`
+|No. Only set if you want to disable the promote deployment feature for your component.
+
+|`Metadata.Annotations`
+|`circleci.com/cancel-release-enabled`
+|`false`
+|No. Only set if you want to disable the cancel deployment feature for your component.
+|===
+
+== Deploy markers
+
+Deploy markers provide a lightweight way to log your deployments. Deploy markers generate a log of all deployments in one place, for a clear overview of what has changed, without the need to search through your CI/CD pipelines. Deploy markers log all new deployments in one place and link back to the CI/CD pipelines that caused them.
+
+See the xref:configure-deploy-markers.adoc[Configure deploy markers] page for full setup details.
+
+[#release-status]
+== Deploy status
+
+A deployment can be in one of the following states:
+
+[cols="1,2", options="header"]
+|===
+|Status
+|Notes
+
+|RUNNING
+|The deployment is currently in progress.
+
+|FAILED
+|Resources have reached an unhealthy status (pods for the new version of a Kubernetes component).
+
+|SUCCESS
+|The Deployment or Rollout has all desired resources available (all pods specified by a Kubernetes Deployment or Argo Rollout).
+
+|CANCELLED
+|The deployment has been cancelled, either using the `cancel deployment` option, or by being superseded by another deployment.
+
+|EXPIRED
+|Deployment commands failed to be picked up by the release agent within the required time window.
+
+|LOGGED
+|Deployment has been logged using a deploy marker and is available in the CircleCI deploys UI.
+|===
+
+[#known-limitations]
+== Known limitations
+
+* Restarting the release agent while a deployment is ongoing causes the release agent to lose track of the deployment status and fail to update the CircleCI services accordingly.
+* **In the CircleCI deploys UI it is currently possible for you to attempt to restore a version that does not exist**. All deployments are presented in the UI, including those outside of the scope of any version history limits you might have set. We do not currently filter out deployments for which there is no longer any data.
++
+Depending on your setup, you will have options for configuring revision history limits: `revisionHistoryLimit` for Kubernetes and Argo Rollouts, and `$HELM_MAX_HISTORY` for Helm.
++
+If you have these limits set, you can't restore a version outside the limit. For example, if your limit is set to the last 10 deployments, you can not restore the 11th deployment back.
++
+We are working on updates to:
++
+** Indicate out-of-scope deployments.
+** Prevent you from attempting to restore unavailable deployments
+** Provide a manual way for you to mark deployments as unavailable
+
+[#troubleshooting]
+== Troubleshooting
+
+include::ROOT:partial$troubleshoot/releases-troubleshoot.adoc[]
diff --git a/docs/guides/modules/deploy/pages/set-up-rollbacks.adoc b/docs/guides/modules/deploy/pages/set-up-rollbacks.adoc
index f461504276..4498e14952 100644
--- a/docs/guides/modules/deploy/pages/set-up-rollbacks.adoc
+++ b/docs/guides/modules/deploy/pages/set-up-rollbacks.adoc
@@ -5,20 +5,46 @@
 
 Rollbacks allow you to quickly revert your application to a previous stable version when issues are detected in production. This guide covers how to configure your CircleCI pipeline to support manual rollback capabilities.
 
+== Introduction
+
+CircleCI rollbacks support two methods: Rollback by running a custom rollback pipeline or Rollback by workflow re-run. Each method has appropriate use cases, advantages and disadvantages, as follows:
+
+[options="header", cols="1,1,1,1"]
+|===
+|
+|Advantages
+|Disadvantages
+|Applications
+
+|*Rollback by running a custom rollback pipeline*
+a| * Fast - Only execute deployment
+* Full control over rollback process
+a| * Requires pipeline setup
+a| * Complex systems
+* Time-critical requirements
+* Multi-component app deployments
+
+|*Rollback by workflow re-run*
+a| * No pipeline setup required
+a| * Limited control over rollback process
+* Full workflow is rerun
+* Slower execution
+a| * Simple systems
+* Need immediate rollback
+|===
+
 == Prerequisites
 
 * A CircleCI account connected to your code. You can link:https://circleci.com/signup/[sign up for free].
 * A CircleCI project with a workflow configured to deploy your code.
-* Read through the xref:deploys-overview.adoc[CircleCI deploys overview] guide.
+* Deploy markers *must* be configured in your project. Follow the xref:configure-deploy-markers.adoc[Configure Deploy Markers] guide to set this up.
+* Familiarity with CircleCI deploys concepts. Find full details in the xref:deployment-overview.adoc[CircleCI deploys overview] guide.
 
 == Set up rollbacks
 
-=== 1. Manually configure deploy markers
-If not already set up, you must configure deploy markers in your CircleCI workflows. Deploy markers track when deployments occur and are essential for rollback functionality. Follow the xref:configure-deploy-markers.adoc[Configure Deploy Markers] guide to set this up. Autodetected deploy markers are *not* supported for use with rollbacks.
-
-The rest of this guide covers how to set up rollbacks using a custom rollback pipeline. At this point, after deploy markers are configured, you can use the xref:rollback-a-project-by-workflow-rerun.adoc[Rollback by workflow rerun] method.
+The following steps guide you through setting up a custom rollback pipeline. Using a custom rollback pipeline is the recommended rollback method.
 
-=== 2. Navigate to project overview
+=== 1. Navigate to project overview
 
 . In the CircleCI dashboard, navigate to *Organization Home* from the sidebar.
 . Select the *Overview* link for your project.
@@ -28,6 +54,8 @@ You will see a red Rollback button with a dropdown option on the project overvie
 .Rollback options on project overview page
 image::guides:ROOT:deploy/project-overview-rollback.png[Rollback button on project overview page]
 
+The following steps guide you through setting up a custom rollback pipeline. If you want details on how to *Rollback by workflow re-run*, see the <<rollback-by-workflow-re-run, Rollback by workflow re-run>> section at the end of this guide.
+
 === 2. Start the rollback setup
 
 . Select the btn:[Rollback] dropdown.
@@ -42,9 +70,9 @@ image::guides:ROOT:deploy/set-up-a-rollback-pipeline.png[Set up a rollback pipel
 === 3. Configure the rollback pipeline
 
 . From the "What repo are you deploying?" dropdown, select the repository you want to create rollbacks for.
-. Select *Create pipeline definition* to proceed.
+. Select btn:[Create pipeline definition] to proceed.
 
-CircleCI creates a pipeline definition called rollback-pipeline and use the selected repository to store your rollback configuration.
+CircleCI creates a pipeline definition called `rollback-pipeline` and uses the selected repository to store your rollback configuration.
 
 === 4. Review the generated configuration
 After creating the pipeline definition, the modal will display a pre-generated configuration file for performing rollbacks.
@@ -57,15 +85,15 @@ This config is a template rollback pipeline that includes the following:
 * *Parameters section*: Placeholder parameters that you can customize for your specific deployment needs
 * *Jobs section*: A basic rollback job structure with common rollback configuration setups included (but commented out)
 
-After committing, you can modify the configuration according to your needs by setting your own parameters and rollback logic. You can uncomment the included common rollback setups or write your own custom rollback implementation.
-
 === 5. Create pull request
-After committing the configuration template, the final step is to create a pull request:
+After committing the configuration template, you can create a pull request from the CircleCI UI:
 
 . Select btn:[Create PR] to generate a pull request with your rollback configuration.
 +
 image::guides:ROOT:deploy/rollback-create-pr.png[Create PR for rollback pipeline]
-. Navigate to the pull request in your repository and modify the rollback configuration according to your specific deployment needs.
+. Navigate to the pull request in your repository and modify the rollback configuration according to your specific deployment needs, for example, you can:
+** Set your own parameters and rollback logic.
+** Uncomment the included common rollback setups or write your own custom rollback implementation.
 . Once you have customized the configuration, merge the pull request to complete the rollback setup.
 
 CAUTION: Until the pull request is merged, the rollback setup will not be complete and rollback functionality will not be available.
@@ -97,4 +125,416 @@ circleci run release plan \
 You can also update the status of the rollback deployment as mentioned in the xref:configure-deploy-markers.adoc[Configure Deploy Markers] guide to reflect the state of the rollback accurately in the CircleCI UI.
 
 === 6. Access rollback functionality
-Once the pull request is merged, the rollback setup is complete. You can now use the rollback functionality in the CircleCI UI. For a full guide, see the xref:rollback-a-project-using-the-rollback-pipeline.adoc[Rollback a project using the rollback pipeline] guide.
+Once the pull request is merged, the rollback setup is complete. You can now use the rollback functionality in the CircleCI UI.
+
+== Perform a rollback
+
+To perform a rollback using the rollback pipeline you can select the btn:[Rollback] button on the project overview page or from the deploys UI. The following steps show how to perform a rollback from the project overview page:
+
+. In the link:https://app.circleci.com[CircleCI web app], select your org from the org cards on your user homepage.
+. Select **Projects** from the sidebar and locate your project from the list. You can use the search to help.
+. Select the *Overview* link for your project.
+. Select btn:[Rollback].
+. Select btn:[Rollback by running rollback pipeline]. This opens the rollback execution modal.
++
+image::guides:ROOT:deploy/rollback-execution-modal.png[Rollback execution modal]
++
+The modal displays several configuration options with parameters auto-filled based on your rollback configuration. The following sections explain each required property:
++
+*Component Name*:: The name of the component you wish to rollback. If your project deploys multiple components, this helps you choose a specific component you want to rollback.
+*Environment Name*:: The environment in which you wish to perform the rollback.
+*Current Version*:: Once you choose the component name and environment name, this will display all possible current versions. More often than not there should be just one current version available. You could have two in case a new progressive release is ongoing. Choose the version you believe is the current version of your component. To help you out, the relevant commit information is also displayed alongside the version.
+*Target Version*:: Choose the version you wish to rollback to. To help you out, the relevant commit information is also displayed alongside the version.
+*Namespace*:: Optional. In case you use Kubernetes and do your deployments to a specific namespace, mention your namespace here, otherwise leave it empty.
++
+The Parameters section shows the auto-filled parameters from your configuration file, which you can modify as needed for the specific rollback operation.
+
+. *Execute*. Select btn:[Rollback] to trigger the rollback pipeline
+
+The rollback pipeline will now execute and perform the rollback operation according to your configuration.
+
+== Change Rollback Pipeline
+
+If you have configured a new pipeline and want to trigger this pipeline when performing rollbacks, you can change which pipeline is used for rollback operations.
+
+To select a different pipeline for rollbacks, follow these steps:
+
+. Navigate to your project's Overview page.
+. Go to Settings.
+. Select the Deploys tab.
+. In the Rollback Pipeline section, choose the pipeline you want to be selected as the rollback pipeline from the dropdown.
+
+This process allows you to switch between different rollback pipeline configurations as needed for your project.
+
+== Example rollback pipeline configuration
+
+In this section you can find a full example of a rollback pipeline config. This example uses Helm to perform a rollback on AWS EKS and kubectl to validate its status.
+
+****
+*This template assumes the following:*
+
+. Your deployment is annotated with a "version" label.
+. The name of your Helm chart is the same as the name of the component. If this is not the case, you can instead add a label to the deployment with the component name and retrieve it that way
+****
+
+.Example rollback pipeline configuration
+[source,yaml]
+----
+version: 2.1
+orbs:
+  aws-cli: circleci/aws-cli@5.4.0
+  helm: circleci/helm@3.2.0
+commands:
+  # The following command is needed only for the specific logic in this example. Feel free to remove it if you don't need it.
+  install_yq:
+    steps:
+      - run:
+          name: install yq
+          command: |
+            wget https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64 -O /tmp/yq
+            wget https://github.com/mikefarah/yq/releases/latest/download/checksums
+            sha_file=$(sha256sum /tmp/yq | awk '{ print $1 }')
+            sha=$(awk '$1=="yq_linux_amd64"{print $19}' checksums)
+            if [ "$sha_file" != "$sha" ]; then
+                    echo "Checksum failed" >&2
+                    exit 1
+            fi
+            echo "The checksums match."
+            chmod +x /tmp/yq
+  verify_current_version:
+    description: "Verifies that the currently deployed version matches the expected value"
+    parameters:
+      resource_name:
+        type: string
+        description: "Name of the resource to roll back"
+      namespace:
+        type: string
+        default: "default"
+        description: "Kubernetes namespace (optional)"
+      current_version:
+        type: string
+        description: "Current version"
+    steps:
+      - run:
+          name: Verify current version
+          command: |
+            RELEASE_NAME="<< parameters.resource_name >>"
+            if [ "<< parameters.current_version >>" == "" ]; then
+              echo "Current version not specified."
+              exit 0
+            fi
+            if [ -z "$RELEASE_NAME" ]; then
+              echo "Missing release name"
+              exit 1
+            fi
+            helm get manifest "<< parameters.resource_name >>" --namespace "<< parameters.namespace >>" > manifest.yaml
+            VERSION_LABEL=$(yq e '
+              select(.kind == "Deployment") |
+              .spec.template.metadata.labels.version
+            ' manifest.yaml)
+            if [ -z "$VERSION_LABEL" ] || [ "$VERSION_LABEL" == "null" ]; then
+              echo "Could not extract version label from manifest"
+              exit 1
+            fi
+            if [ "$VERSION_LABEL" == "<< parameters.current_version >>" ]; then
+              echo "Version matches input version << parameters.current_version >>"
+            else
+              echo "Version mismatch: expected << parameters.current_version >> but found $VERSION_LABEL"
+              exit 1
+            fi
+  retrieve_target_revision:
+    description: "Retrieve previous version"
+    parameters:
+      resource_name:
+        type: string
+        description: "Name of the resource to roll back"
+      namespace:
+        type: string
+        default: "default"
+        description: "Kubernetes namespace (optional)"
+      target_version:
+        type: string
+        description: "Target version"
+    steps:
+      - run:
+          name: Identify previous revision
+          command: |
+            TARGET_VERSION="<< parameters.target_version >>"
+            RELEASE_NAME="<< parameters.resource_name >>"
+            NAMESPACE="<< parameters.namespace >>"
+            if [ -z "$TARGET_VERSION" ]; then
+              echo "TARGET_VERSION is required"
+              exit 1
+            fi
+            # Get full release history
+            REVISIONS=$(helm history "$RELEASE_NAME" --namespace "$NAMESPACE" --output json | jq '.[].revision')
+            if [ -z "$REVISIONS" ]; then
+              echo "Could not fetch Helm history for release '$RELEASE_NAME'"
+              exit 1
+            fi
+            # Search each revision for a Deployment with the matching version label
+            TARGET_REVISION=""
+            for REV in $REVISIONS; do
+              helm get manifest "$RELEASE_NAME" --namespace "$NAMESPACE" --revision "$REV" > manifest.yaml || continue
+              VERSION_LABEL=$(yq e '
+                select(.kind == "Deployment") |
+                .spec.template.metadata.labels.version
+              ' manifest.yaml)
+              if [ "$VERSION_LABEL" == "$TARGET_VERSION" ]; then
+                TARGET_REVISION=$REV
+                break
+              fi
+            done
+            if [ -n "$TARGET_REVISION" ]; then
+              echo "export CONTAINER_VERSION=${TARGET_VERSION}" >> $BASH_ENV
+              echo "export TARGET_REVISION=${TARGET_REVISION}" >> $BASH_ENV
+              source $BASH_ENV
+            else
+              echo "No revision found with version label: $TARGET_VERSION"
+              exit 1
+            fi
+  perform_rollback:
+    description: "perform rollback"
+    parameters:
+      resource_name:
+        type: string
+        description: "Name of the resource to roll back"
+      namespace:
+        type: string
+        default: "default"
+        description: "Kubernetes namespace (optional)"
+    steps:
+      - run:
+          name: Perform rollback
+          command: |
+            helm rollback << parameters.resource_name >> ${TARGET_REVISION}
+  # This command validates the deployment after rolling back. The provided example uses kubectl to check the ready replicas and number of restarts
+  # of pods associated with the deployment and causes the job to fail if the deployment is not ready or has too many restarts by
+  # the end of the validation duration.
+  # Mind the fact that the example assumes you have an app label with value equal to the component name, in order to retrieve the pods.
+  # If that is not the case you will have to adapt the logic in the script.
+  validate_deployment:
+    description: "Validates the deployment after rolling back"
+    parameters:
+      resource_name:
+        type: string
+        description: "Name of the resource that has been rolled back"
+      namespace:
+        type: string
+        default: "default"
+        description: "Kubernetes namespace (optional)"
+      target_version:
+        type: string
+        description: "Target version"
+      max_restarts:
+        type: integer
+        default: 5
+        description: "Maximum number of allowed restarts"
+      duration:
+        type: integer
+        default: 600
+        description: "Duration of the validation in seconds"
+    steps:
+      - run:
+          name: Validate deployment
+          command: |
+            CHECK_DURATION=$((SECONDS+<< parameters.duration >>))  # 10 minutes duration
+            REPLICAS_OK=false
+
+            LABEL_SELECTOR="app=<< parameters.resource_name >>,version=<< parameters.target_version >>"
+            DEPLOYMENT_FOUND=false
+            echo "Starting validation of version: << parameters.target_version >>"
+            while [ $SECONDS -lt $CHECK_DURATION ]; do
+              DEPLOYMENT=$(kubectl get deployment << parameters.resource_name >>  -n << parameters.namespace >> --ignore-not-found -o json)
+
+              if [ -n "$DEPLOYMENT" ]; then
+                  DEPLOYMENT_FOUND=true
+                  DESIRED=$(echo "$DEPLOYMENT" | jq -r '.spec.replicas // 0')
+                  READY=$(echo "$DEPLOYMENT" | jq -r '.status.readyReplicas // 0')
+
+                  # Handle empty values
+                  DESIRED=${DESIRED:-0}
+                  READY=${READY:-0}
+
+                  echo "Current replicas $READY/$DESIRED"
+                  if [ "$DESIRED" -eq "$READY" ]; then
+                    REPLICAS_OK=true
+                  else
+                    REPLICAS_OK=false
+                  fi
+              else
+                  DEPLOYMENT_FOUND=false
+                  echo "Deployment not found"
+                  continue
+              fi
+              RESTARTS=$(kubectl get pods -l $LABEL_SELECTOR -n << parameters.namespace >> \
+                -o jsonpath='{.items[*].status.containerStatuses[*].restartCount}' 2>/dev/null | awk '{sum=0; for(i=1; i<=NF; i++) sum+=$i; print sum+0}')
+              # Handle potential errors
+              if [[ -z "$RESTARTS" || ! "$RESTARTS" =~ ^[0-9]+$ ]]; then
+                RESTARTS=0
+              fi
+              echo "Number of restarts $RESTARTS"
+              if [ $RESTARTS -gt << parameters.max_restarts >> ]; then
+                echo "FAILURE_REASON='Exceeded maximum number of restarts'" > failure_reason.env
+                exit 1
+              fi
+              sleep 10  # Check every 10 seconds
+            done
+            if [ $DEPLOYMENT_FOUND = false ]; then
+                echo "FAILURE_REASON='Deployment was not found'" > failure_reason.env
+                exit 1
+            fi
+            if [ $REPLICAS_OK = false ]; then
+                echo "FAILURE_REASON='Desired replicas doesn't match ready replica'" > failure_reason.env
+                exit 1
+            fi
+jobs:
+  rollback-component:
+    docker:
+      - image: cimg/aws:2023.03
+    environment:
+      COMPONENT_NAME: << pipeline.deploy.component_name >>
+      NAMESPACE: << pipeline.deploy.namespace >>
+      ENVIRONMENT_NAME: << pipeline.deploy.environment_name >>
+      TARGET_VERSION: << pipeline.deploy.target_version >>
+    steps:
+      - checkout
+      - attach_workspace:
+          at: .
+      ### Uncomment this section if you are using AWS EKS, otherwise add the steps to authenticate with your platform
+      - aws-cli/setup:
+          role_arn: $AWS_OIDC_ROLE
+          region: $AWS_REGION
+          role_session_name: "example"
+          session_duration: "1800"
+      - run: aws sts get-caller-identity
+      - run: aws configure list
+      - run:
+          name: Update kubeconfig for EKS
+          command: |
+            aws eks update-kubeconfig --name "$EKS_CLUSTER_NAME"
+            aws sts get-caller-identity  # Verify credentials are still valid
+      - helm/install_helm_client
+      - install_yq
+      # This command is used to validate that the current version on your cluster matches the value that was specified when
+      # the pipeline was triggered. If that is not the case it is possible that the deployment has been updated in the meantime
+      # this check is optional and can be removed if you don't need it.
+      # Refer to the commands section above for details about the implementation of this command.
+      - verify_current_version:
+          resource_name: "<< pipeline.deploy.component_name >>"
+          namespace: "<< pipeline.deploy.namespace >>"
+          current_version: "<< pipeline.deploy.current_version >>"
+      # This command is used to retrieve the target revision that will be used to perform the rollback.
+      # Depending on your implementation you may not need this, in which case feel free to remove it.
+      # Refer to the commands section above for details about the implementation of this command.
+      - retrieve_target_revision:
+          resource_name: "<< pipeline.deploy.component_name >>"
+          namespace: "<< pipeline.deploy.namespace >>"
+          target_version: "<< pipeline.deploy.target_version >>"
+      # This step will create a new deploy with PENDING status that will show up in the deploys tab in the UI
+      - run:
+          name: Plan release of deploy release smoke test
+          command: |
+            circleci run release plan  \
+              --environment-name=${ENVIRONMENT_NAME} \
+              --namespace=${NAMESPACE} \
+              --component-name=${COMPONENT_NAME} \
+              --target-version=${TARGET_VERSION} \
+              --rollback
+      # This command will perform the actual rollback, using the revision retrieved by retrieve_target_revision
+      - perform_rollback:
+          resource_name: "<< pipeline.deploy.component_name >>"
+          namespace: "<< pipeline.deploy.namespace >>"
+      # This step will update the PENDING deployment marker to RUNNING.
+      # If you are not going to perform any validation you can just remove this.
+      - run:
+          name: Update planned release to RUNNING
+          command: |
+            circleci run release update \
+              --status=RUNNING
+      # This step performs validation on the deployment status after the rollback and sets the failure reason if the validation fails.
+      # if you don't want to perform any validation you can just remove this.
+      - validate_deployment:
+          resource_name: "<< pipeline.deploy.component_name >>"
+          target_version: "<< pipeline.deploy.target_version >>"
+          namespace: "<< pipeline.deploy.namespace >>"
+      # These last two steps update the PENDING deployment marker to SUCCESS or FAILED, based on the outcome of the job.
+      - run:
+          name: Update planned release to SUCCESS
+          command: |
+            # if the rollback failed, we don't want to update the status to SUCCESS. This is unnecessary if there is no logic around
+            # validating the deployment status.
+            if [ -f failure_reason.env ]; then
+              exit 0
+            fi
+            circleci run release update \
+              --status=SUCCESS
+          when: on_success
+      - run:
+          name: Update planned release to FAILED
+          command: |
+            if [ -f failure_reason.env ]; then
+              source failure_reason.env
+            fi
+            FAILURE_REASON="${FAILURE_REASON:-}"
+            circleci run release update \
+             --status=FAILED \
+             --failure-reason="$FAILURE_REASON"
+          when: on_fail
+  # This job handles the cancellation of the rollback deploy marker if the rollback job is canceled
+  cancel-rollback:
+    docker:
+      - image: cimg/aws:2023.03
+    steps:
+      - run:
+          name: Update planned release to CANCELED
+          command: |
+            circleci run release update \
+             --status=CANCELED
+workflows:
+  rollback:
+    jobs:
+      - rollback-component:
+          context:
+            # provide any required context
+      - cancel-rollback:
+          context:
+            # provide any required context
+          requires:
+            - rollback-component:
+              - canceled
+          filters:
+            branches:
+              only: main
+----
+
+
+== Rollback by workflow re-run
+
+Workflow rerun rollbacks do not need any additional configuration beyond setting up deploy markers. Advantages and disadvantages of using this method are as follows:
+
+* *Advantage*: No setup required. This rollback method works immediately after configuring deploy markers.
+* *Disadvantage*: The entire workflow will be re-run, which may not always be desirable depending on your workflow complexity and duration.
+
+The Rollback by workflow re-run method is only recommended for simple deployments. For complete control over the rollback process and to avoid re-running entire workflows, consider using the custom rollback pipeline approach described above.
+
+To perform a rollback using workflow rerun:
+
+. In the link:https://app.circleci.com[CircleCI web app], select your org from the org cards on your user homepage.
+. Select **Projects** from the sidebar and locate your project from the list. You can use the search to help.
+. Select the *Overview* link for your project.
+. Select btn:[Rollback].
+. Select btn:[Rollback by workflow re-run].
+
+.Rollback options on project overview page
+image::guides:ROOT:deploy/project-overview-rollback.png[Rollback button on project overview page]
+
+This will open the workflow re-run modal with the following options:
+
+* *Choose a version*. Select the version you want to roll back to from the list of available versions.
+* *Confirm rollback*. Select btn:[Next], confirm rollback to proceed.
+
+The workflow that originally deployed the selected version will be re-run, effectively performing a rollback to that version.
+
+
+
diff --git a/docs/reference/modules/ROOT/pages/configuration-reference.adoc b/docs/reference/modules/ROOT/pages/configuration-reference.adoc
index e5b70facce..693e71daa3 100644
--- a/docs/reference/modules/ROOT/pages/configuration-reference.adoc
+++ b/docs/reference/modules/ROOT/pages/configuration-reference.adoc
@@ -416,7 +416,7 @@ jobs:
       ... // other config
 ----
 
-Jobs with the `release` type are used to xref:guides:deploy:configure-your-kubernetes-components.adoc#link-release[connect your pipeline configuration] to a deployment in the CircleCI deploys UI. For full details, see the xref:guides:deploy:deploys-overview.adoc#[Deploys overview] page.
+Jobs with the `release` type are used to xref:guides:deploy:configure-your-kubernetes-components.adoc#link-release[connect your pipeline configuration] to a deployment in the CircleCI deploys UI. For full details, see the xref:guides:deploy:deployment-overview.adoc#[Deploys overview] page.
 
 **Example** of a job with a `release` type: