diff --git a/docs/vendor/helm-native-about.mdx b/docs/vendor/helm-native-about.mdx
index 8a5502663d..171bf60dbb 100644
--- a/docs/vendor/helm-native-about.mdx
+++ b/docs/vendor/helm-native-about.mdx
@@ -109,7 +109,51 @@ When installing an application that includes one or more Helm charts, KOTS alway
 
 For information about how to set the deployment order for Helm charts with KOTS, see [Orchestrate Resource Deployment](/vendor/orchestrating-resource-deployment).
 
-## Deprecated HelmChart kots.io/v1beta1 Installation Methods
+## Comparison to HelmChart v1
+
+### HelmChart v1 and v2 Differences
+
+To support the use of local registries with version `kots.io/v1beta2` of the HelmChart custom resource, provide the necessary values in the builder field to render the Helm chart with all of the necessary images so that KOTS knows where to pull the images from to push them into the local registry.
+
+For more information about how to configure the `builder` key, see [Packaging Air Gap Bundles for Helm Charts](/vendor/helm-packaging-airgap-bundles) and [`builder`](/reference/custom-resource-helmchart-v2#builder) in _HelmChart v2_.
+
+The `kots.io/v1beta2` HelmChart custom resource has the following differences from `kots.io/v1beta1`:
+
+<table>
+  <tr>
+    <th>HelmChart v1beta2</th>
+    <th>HelmChart v1beta1</th>
+    <th>Description</th>
+  </tr>
+  <tr>
+    <td><code>apiVersion: kots.io/v1beta2</code></td>
+    <td><code>apiVersion: kots.io/v1beta1</code></td>
+    <td><code>apiVersion</code> is updated to <code>kots.io/v1beta2</code></td>
+  </tr>
+  <tr>
+    <td><code>releaseName</code></td>
+    <td><code>chart.releaseName</code></td>
+    <td><code>releaseName</code> is a top level field under <code>spec</code></td>
+  </tr>
+  <tr>
+    <td>N/A</td>
+    <td><code>helmVersion</code></td>
+    <td><code>helmVersion</code> field is removed</td>
+  </tr>
+  <tr>
+    <td>N/A</td>
+    <td><code>useHelmInstall</code></td>
+    <td><code>useHelmInstall</code> field is removed</td>
+  </tr>
+</table>
+
+### About Migrating Existing KOTS Installations to HelmChart v2
+
+Existing KOTS installations can be migrated to use the KOTS HelmChart v2 method, without having to reinstall the application.
+
+There are different steps for migrating to HelmChart v2 depending on the application deployment method used previously. For more information, see [Migrating Existing Installations to HelmChart v2](helm-v2-migrate).
+
+### Additional Information About HelmChart v1
 
 This section describes the deprecated Helm chart installation methods that use the HelmChart custom resource `apiVersion: kots.io/v1beta1`.
 
@@ -117,7 +161,7 @@ This section describes the deprecated Helm chart installation methods that use t
 <Deprecated/>
 :::
 
-### useHelmInstall: true {#v1beta1}
+#### useHelmInstall: true {#v1beta1}
 
 :::note
 This method was previously referred to as _Native Helm_.
@@ -208,7 +252,7 @@ To deploy Helm charts with version `kots.io/v1beta1` of the HelmChart custom res
 
    Finally, KOTS runs `helm upgrade -i <release-name> <chart> --timeout 3600s -n <namespace>`. The Helm binary processes hooks and weights, applies manifests to the Kubernetes cluster, and saves a release secret similar to `sh.helm.release.v1.chart-name.v1`. Helm uses this secret to track upgrades and rollbacks of applications.
 
-### useHelmInstall: false {#v1beta1-false}
+#### useHelmInstall: false {#v1beta1-false}
 
 :::note
 This method was previously referred to as _Replicated Helm_.
@@ -218,7 +262,7 @@ When you use version `kots.io/v1beta1` of HelmChart custom resource with `useHel
 
 The resulting deployment is comprised of standard Kubernetes manifests. Therefore, cluster operators can view the exact differences between what is currently deployed and what an update will deploy.
 
-### Limitations {#replicated-helm-limitations}
+### HelmChart v1 Limitations {#replicated-helm-limitations}
 
 This section lists the limitations for version `kots.io/v1beta1` of the HelmChart custom resource.
 #### kots.io/v1beta1 (useHelmInstall: true) Limitations
diff --git a/docs/vendor/helm-native-v2-using.md b/docs/vendor/helm-native-v2-using.md
deleted file mode 100644
index 11f2dfd1ab..0000000000
--- a/docs/vendor/helm-native-v2-using.md
+++ /dev/null
@@ -1,371 +0,0 @@
-import KotsHelmCrDescription from "../partials/helm/_kots-helm-cr-description.mdx"
-
-# Configure the HelmChart Custom Resource v2
-
-This topic describes how to configure the Replicated HelmChart custom resource version `kots.io/v1beta2` to support Helm chart installations with Replicated KOTS.
-
-## Workflow
-
-To support Helm chart installations with the KOTS `kots.io/v1beta2` HelmChart custom resource, do the following:
-1. Rewrite image names to use the Replicated proxy registry. See [Rewrite Image Names](#rewrite-image-names).
-1. Inject a KOTS-generated image pull secret that grants proxy access to private images. See [Inject Image Pull Secrets](#inject-image-pull-secrets).
-1. Add a pull secret for any Docker Hub images that could be rate limited. See [Add Pull Secret for Rate-Limited Docker Hub Images](#docker-secret).
-1. Configure the `builder` key to allow your users to push images to their own local registries. See [Support Local Image Registries](#local-registries).
-1. (KOTS Existing Cluster and kURL Installations Only) Add backup labels to your resources to support backup and restore with the KOTS snapshots feature. See [Add Backup Labels for Snapshots](#add-backup-labels-for-snapshots).
-   :::note
-   Snapshots is not supported for installations with Replicated Embedded Cluster. For more information about configuring disaster recovery for Embedded Cluster, see [Disaster Recovery for Embedded Cluster](/vendor/embedded-disaster-recovery).
-   :::
-
-## Task 1: Rewrite Image Names {#rewrite-image-names}
-
-Configure the KOTS HelmChart custom resource `values` key so that KOTS rewrites the names for both private and public images in your Helm values during deployment. This allows images to be accessed at one of the following locations, depending on where they were pushed:
-* The [Replicated proxy registry](private-images-about) (`proxy.replicated.com` or your custom domain)
-* A public image registry
-* Your customer's local registry
-* The built-in registry used in Replicated Embedded Cluster or Replicated kURL installations in air-gapped environments
-
-You will use the following KOTS template functions to conditionally rewrite image names depending on where the given image should be accessed: 
-* [HasLocalRegistry](/reference/template-functions-config-context#haslocalregistry): Returns true if the installation environment is configured to use a local image registry. HasLocalRegistry is always true in air gap installations. HasLocalRegistry is also true in online installations if the user configured a local private registry.
-* [LocalRegistryHost](/reference/template-functions-config-context#localregistryhost): Returns the host of the local registry that the user configured. Alternatively, for air gap installations with Embedded Cluster or kURL, LocalRegistryHost returns the host of the built-in registry.
-* [LocalRegistryNamespace](/reference/template-functions-config-context#localregistrynamespace): Returns the namespace of the local registry that the user configured. Alternatively, for air gap installations with Embedded Cluster or kURL, LocalRegistryNamespace returns the namespace of the built-in registry.
-
-    <details>
-    <summary>What is the registry namespace?</summary>
-    
-    The registry namespace is the path between the registry and the image name. For example, `images.yourcompany.com/namespace/image:tag`.
-    </details>
-
-### Task 1a: Rewrite Private Image Names
-
-For any private images used by your application, configure the HelmChart custom resource so that image names are rewritten to either the Replicated proxy registry (for online installations) or to the local registry in the user's installation environment (for air gap installations or online installations where the user configured a local registry).
-
-To rewrite image names to the location of the image in the proxy registry, use the format `<proxy-domain>/proxy/<app-slug>/<image>`, where:
-* `<proxy-domain>` is `proxy.replicated.com` or your custom domain. For more information about configuring a custom domain for the proxy registry, see [Use Custom Domains](/vendor/custom-domains-using).
-* `<app-slug>` is the unique application slug in the Vendor Portal
-* `<image>` is the path to the image in your registry
-
-For example, if the private image is `quay.io/my-org/nginx:v1.0.1` and `images.yourcompany.com` is the custom proxy registry domain, then the image name should be rewritten to `images.yourcompany.com/proxy/my-app-slug/quay.io/my-org/nginx:v1.0.1`.
-
-For more information, see the example below. 
-
-#### Example
-
-The following HelmChart custom resource uses the KOTS [HasLocalRegistry](/reference/template-functions-config-context#haslocalregistry), [LocalRegistryHost](/reference/template-functions-config-context#localregistryhost), and [LocalRegistryNamespace](/reference/template-functions-config-context#localregistrynamespace) template functions to conditionally rewrite an image registry and repository depending on if a local registry is used:
-
-```yaml
-# kots.io/v1beta2 HelmChart custom resource
-
-apiVersion: kots.io/v1beta2
-kind: HelmChart
-metadata:
-  name: samplechart
-spec:
-  ...
-  values:
-    image:
-    # If a registry is configured by the user or by Embedded Cluster/kURL, use that registry's hostname
-    # Else use proxy.replicated.com or your custom proxy registry domain
-      registry: '{{repl HasLocalRegistry | ternary LocalRegistryHost "images.yourcompany.com" }}'
-      # If a registry is configured by the user or by Embedded Cluster/kURL, use that registry namespace
-      # Else use the image's namespace at the proxy registry domain
-      repository: '{{repl HasLocalRegistry | ternary LocalRegistryNamespace "proxy/my-app/quay.io/my-org" }}/nginx'
-      tag: v1.0.1
-```
-
-The `spec.values.image.registry` and `spec.values.image.repository` fields in the HelmChart custom resource above correspond to `image.registry` and `image.repository` fields in the Helm chart `values.yaml` file, as shown below:
-
-```yaml
-# Helm chart values.yaml file
-
-image:
-  registry: quay.io
-  repository: my-org/nginx
-  tag: v1.0.1
-```
-
-During installation, KOTS renders the template functions and sets the `image.registry` and `image.repository` fields in the Helm chart `values.yaml` file based on the value of the corresponding fields in the HelmChart custom resource.
-
-Any templates in the Helm chart that access the `image.registry` and `image.repository` fields are updated to use the appropriate value, as shown in the example below:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: nginx
-spec:
-  containers:
-  - name: 
-    image: {{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
-```
-
-### Task 1b: Rewrite Public Image Names
-
-For any public images used by your application, configure the HelmChart custom resource so that image names are rewritten to either the location of the image in the public registry (for online installations) or the local registry (for air gap installations or online installations where the user configured a local registry.
-
-For more information, see the example below.
-
-#### Example
-
-The following HelmChart custom resource uses the KOTS [HasLocalRegistry](/reference/template-functions-config-context#haslocalregistry), [LocalRegistryHost](/reference/template-functions-config-context#localregistryhost), and [LocalRegistryNamespace](/reference/template-functions-config-context#localregistrynamespace) template functions to conditionally rewrite an image registry and repository depending on if a local registry is used:
-
-```yaml
-# kots.io/v1beta2 HelmChart custom resource
-
-apiVersion: kots.io/v1beta2
-kind: HelmChart
-metadata:
-  name: samplechart
-spec:
-  ...
-  values:
-    image: 
-      # If a local registry is used, use that registry's hostname
-      # Else, use the public registry host (ghcr.io) 
-      registry: '{{repl HasLocalRegistry | ternary LocalRegistryHost "ghcr.io" }}' 
-      # If a local registry is used, use the registry namespace provided
-      # Else, use the path to the image in the public registry 
-      repository: '{{repl HasLocalRegistry | ternary LocalRegistryNamespace "cloudnative-pg" }}/cloudnative-pg'
-      tag: catalog-1.24.0
-```
-
-The `spec.values.image.registry` and `spec.values.image.repository` fields in the HelmChart custom resource correspond to `image.registry` and `image.repository` fields in the Helm chart `values.yaml` file, as shown in the example below:
-
-```yaml
-# Helm chart values.yaml file
-
-image:
-  registry: ghcr.io
-  repository: cloudnative-pg/cloudnative-pg
-  tag: catalog-1.24.0
-```
-
-During installation, KOTS renders the template functions and sets the `image.registry` and `image.repository` fields in your Helm chart `values.yaml` file based on the value of the corresponding fields in the HelmChart custom resource. Any templates in the Helm chart that access the `image.registry` and `image.repository` fields are updated to use the appropriate value, as shown in the example below:
-
-```yaml
-apiVersion: v1
-kind: Pod
-spec:
-  containers:
-  - name: 
-    image: {{ .Values.image.registry }}/{{ .Values.image.repository }}:{{ .Values.image.tag }}
-```
-
-## Task 2: Inject Image Pull Secrets {#inject-image-pull-secrets}
-
-Kubernetes requires a Secret of type `kubernetes.io/dockerconfigjson` to authenticate with a registry and pull a private image. When you reference a private image in a Pod definition, you also provide the name of the Secret in a `imagePullSecrets` key in the Pod definition. For more information, see [Specifying imagePullSecrets on a Pod](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) in the Kubernetes documentation.
-
-During installation, KOTS creates a `kubernetes.io/dockerconfigjson` type Secret that is based on the customer license. This pull secret grants access to the private image through the Replicated proxy registry or in the Replicated registry. Additionally, if the user configured a local image registry, then the pull secret contains the credentials for the local registry. You must provide the name of this KOTS-generated pull secret in any Pod definitions that reference the private image.
-
-You can inject the name of this pull secret into a field in the HelmChart custom resource using the Replicated ImagePullSecretName template function. During installation, KOTS sets the value of the corresponding field in your Helm chart `values.yaml` file with the rendered value of the ImagePullSecretName template function. 
-
-#### Example
-
-The following example shows a `spec.values.image.pullSecrets` array in the HelmChart custom resource that uses the ImagePullSecretName template function to inject the name of the KOTS-generated pull secret:
-
-```yaml
-# kots.io/v1beta2 HelmChart custom resource
-
-apiVersion: kots.io/v1beta2
-kind: HelmChart
-metadata:
-  name: samplechart
-spec:
-  values:
-    image: 
-      # Note: Use proxy.replicated.com or your custom domain
-      registry: '{{repl HasLocalRegistry | ternary LocalRegistryHost "proxy.replicated.com" }}'
-      repository: '{{repl HasLocalRegistry | ternary LocalRegistryNamespace "proxy/my-app/ecr.us-east-1.amazonaws.com/my-org" }}/api'
-      pullSecrets:
-      - name: '{{repl ImagePullSecretName }}'
-```
-
-The `spec.values.image.pullSecrets` array in the HelmChart custom resource corresponds to a `image.pullSecrets` array in the Helm chart `values.yaml` file, as shown in the example below:
-
-```yaml
-# Helm chart values.yaml file
-
-image:
-  registry: ecr.us-east-1.amazonaws.com
-  repository: my-org/api/nginx
-  pullSecrets:
-  - name: my-org-secret
-```
-
-During installation, KOTS renders the ImagePullSecretName template function and adds the rendered pull secret name to the `image.pullSecrets` array in the Helm chart `values.yaml` file.
-
-Any templates in the Helm chart that access the `image.pullSecrets` field are updated to use the name of the KOTS-generated pull secret, as shown in the example below:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: nginx
-spec:
-  containers:
-  - name: nginx
-    image: {{ .Values.image.registry }}/{{ .Values.image.repository }}
-  {{- with .Values.image.pullSecrets }}
-  imagePullSecrets:
-  {{- toYaml . | nindent 2 }}
-  {{- end }}
-```
-
-## Task 3: Add Pull Secret for Rate-Limited Docker Hub Images {#docker-secret}
-
-Docker Hub enforces rate limits for Anonymous and Free users. To avoid errors caused by reaching the rate limit, your users can run the `kots docker ensure-secret` command, which creates an `<app-slug>-kotsadm-dockerhub` secret for pulling Docker Hub images and applies the secret to Kubernetes manifests that have images. For more information, see [Avoiding Docker Hub Rate Limits](/enterprise/image-registry-rate-limits).
-
-If you are deploying a Helm chart with Docker Hub images that could be rate limited, to support the use of the `kots docker ensure-secret` command, any Pod definitions in your Helm chart templates that reference the rate-limited image must be updated to access the `<app-slug>-kotsadm-dockerhub` pull secret, where `<app-slug>` is your application slug. For more information, see [Get the Application Slug](/vendor/vendor-portal-manage-app#slug).
-
-You can do this by adding the `<app-slug>-kotsadm-dockerhub` pull secret to a field in the `values` key of the HelmChart custom resource, along with a matching field in your Helm chart `values.yaml` file. During installation, KOTS sets the value of the matching field in the `values.yaml` file with the `<app-slug>-kotsadm-dockerhub` pull secret, and any Helm chart templates that access the value are updated.
-
-For more information about Docker Hub rate limiting, see [Understanding Docker Hub rate limiting](https://www.docker.com/increase-rate-limits) on the Docker website.
-
-#### Example
-
-The following Helm chart `values.yaml` file includes `image.registry`, `image.repository`, and `image.pullSecrets` for a rate-limited Docker Hub image:
-
-```yaml
-# Helm chart values.yaml file
-
-image:
-  registry: docker.io
-  repository: my-org/example-docker-hub-image
-  pullSecrets: []
-```
-
-The following HelmChart custom resource includes `spec.values.image.registry`, `spec.values.image.repository`, and `spec.values.image.pullSecrets`, which correspond to those in the Helm chart `values.yaml` file above.
-
-The `spec.values.image.pullSecrets` array lists the `<app-slug>-kotsadm-dockerhub` pull secret, where the slug for the application is `example-app-slug`:
-
-```yaml
-# kots.io/v1beta2 HelmChart custom resource
-
-apiVersion: kots.io/v1beta2
-kind: HelmChart
-metadata:
-  name: samplechart
-spec:
-  values:
-    image:
-      registry: docker.io
-      repository: my-org/example-docker-hub-image
-      pullSecrets:
-      - name: example-app-slug-kotsadm-dockerhub
-```
-
-During installation, KOTS adds the `example-app-slug-kotsadm-dockerhub` secret to the `image.pullSecrets` array in the Helm chart `values.yaml` file. Any templates in the Helm chart that access `image.pullSecrets` are updated to use `example-app-slug-kotsadm-dockerhub`:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: example
-spec:
-  containers:
-  - name: example
-    image: {{ .Values.image.registry }}/{{ .Values.image.repository }}
-  {{- with .Values.image.pullSecrets }}
-  imagePullSecrets:
-  {{- toYaml . | nindent 2 }}
-  {{- end }}
-```
-
-## Task 4: Support the Use of Local Image Registries {#local-registries}
-
-Local image registries are required for KOTS installations in air-gapped environments with no outbound internet connection. Also, users in online environments can optionally use a local registry. For more information about how users configure a local image registry with KOTS, see [Configuring Local Image Registries](/enterprise/image-registry-settings).
-
-To support the use of local registries, configure the `builder` key. For more information about how to configure the `builder` key, see [`builder`](/reference/custom-resource-helmchart-v2#builder) in _HelmChart v2_.
-
-## Task 5: Add Backup Labels for Snapshots (KOTS Existing Cluster and kURL Installations Only) {#add-backup-labels-for-snapshots}
-
-:::note
-The Replicated [snapshots](snapshots-overview) feature for backup and restsore is supported only for existing cluster installations with KOTS. Snapshots are not support for installations with Embedded Cluster. For more information about disaster recovery for installations with Embedded Cluster, see [Disaster Recovery for Embedded Cluster](/vendor/embedded-disaster-recovery.mdx).
-:::
-
-The snapshots feature requires the following labels on all resources in your Helm chart that you want to be included in the backup:
-* `kots.io/backup: velero`
-* `kots.io/app-slug: APP_SLUG`, where `APP_SLUG` is the slug of your Replicated application.
-
-For more information about snapshots, see [Understanding Backup and Restore](snapshots-overview).
-
-To support backup and restore with snapshots, add the `kots.io/backup: velero` and `kots.io/app-slug: APP_SLUG` labels to fields under the HelmChart custom resource `optionalValues` key. Add a `when` statement that evaluates to true only when the customer license has the `isSnapshotSupported` entitlement.
-
-The fields that you create under the `optionalValues` key must map to fields in your Helm chart `values.yaml` file. For more information about working with the `optionalValues` key, see [optionalValues](/reference/custom-resource-helmchart-v2#optionalvalues) in _HelmChart v2_.
-
-#### Example
-
-The following example shows how to add backup labels for snapshots in the `optionalValues` key of the HelmChart custom resource:
-
-```yaml
-# kots.io/v1beta2 HelmChart custom resource
-
-apiVersion: kots.io/v1beta2
-kind: HelmChart
-metadata:
-  name: samplechart
-spec:
-  ...
-  optionalValues:
-  # add backup labels only if the license supports snapshots
-  - when: "repl{{ LicenseFieldValue `isSnapshotSupported` }}"
-    recursiveMerge: true
-    values:
-      mariadb:
-        commonLabels:
-          kots.io/backup: velero
-          kots.io/app-slug: repl{{ LicenseFieldValue "appSlug" }}
-        podLabels:
-          kots.io/backup: velero
-          kots.io/app-slug: repl{{ LicenseFieldValue "appSlug" }}
-```
-
-## Additional Information
-
-### About the HelmChart Custom Resource
-
-
-<KotsHelmCrDescription/>
-
-For more information about the HelmChart custom resource, including the unique requirements and limitations for the keys described in this topic, see [HelmChart v2](/reference/custom-resource-helmchart-v2).
-
-### HelmChart v1 and v2 Differences
-
-To support the use of local registries with version `kots.io/v1beta2` of the HelmChart custom resource, provide the necessary values in the builder field to render the Helm chart with all of the necessary images so that KOTS knows where to pull the images from to push them into the local registry.
-
-For more information about how to configure the `builder` key, see [Package Air Gap Bundles for Helm Charts](/vendor/helm-packaging-airgap-bundles) and [`builder`](/reference/custom-resource-helmchart-v2#builder) in _HelmChart v2_.
-
-The `kots.io/v1beta2` HelmChart custom resource has the following differences from `kots.io/v1beta1`:
-
-<table>
-  <tr>
-    <th>HelmChart v1beta2</th>
-    <th>HelmChart v1beta1</th>
-    <th>Description</th>
-  </tr>
-  <tr>
-    <td><code>apiVersion: kots.io/v1beta2</code></td>
-    <td><code>apiVersion: kots.io/v1beta1</code></td>
-    <td><code>apiVersion</code> is updated to <code>kots.io/v1beta2</code></td>
-  </tr>
-  <tr>
-    <td><code>releaseName</code></td>
-    <td><code>chart.releaseName</code></td>
-    <td><code>releaseName</code> is a top level field under <code>spec</code></td>
-  </tr>
-  <tr>
-    <td>N/A</td>
-    <td><code>helmVersion</code></td>
-    <td><code>helmVersion</code> field is removed</td>
-  </tr>
-  <tr>
-    <td>N/A</td>
-    <td><code>useHelmInstall</code></td>
-    <td><code>useHelmInstall</code> field is removed</td>
-  </tr>
-</table>
-
-### Migrate Existing KOTS Installations to HelmChart v2
-
-Existing KOTS installations can be migrated to use the KOTS HelmChart v2 method, without having to reinstall the application.
-
-There are different steps for migrating to HelmChart v2 depending on the application deployment method used previously. For more information, see [Migrating Existing Installations to HelmChart v2](helm-v2-migrate).
diff --git a/docs/vendor/helm-native-v2-using.mdx b/docs/vendor/helm-native-v2-using.mdx
new file mode 100644
index 0000000000..608f0f6dd4
--- /dev/null
+++ b/docs/vendor/helm-native-v2-using.mdx
@@ -0,0 +1,100 @@
+import KotsHelmCrDescription from "../partials/helm/_kots-helm-cr-description.mdx"
+
+# Rewrite Images to Local Registries with HelmChart
+
+This topic describes how to configure the Replicated KOTS HelmChart custom resource so that KOTS rewrites the images used by your application to the location of the image in the user's local image registry. The main use case for local image registries is air gap installations with Replicated KOTS in existing clusters.
+
+## Overview
+
+The HelmChart custom resource `optionalValues` key can be used to set values in the Helm chart `values.yaml` file when a given conditional statement evaluates to true. For more information, see [optionalValues](/reference/custom-resource-helmchart-v2#optionalvalues) in _HelmChart v2_.
+
+If you have customers that will push images to their own local image registry (such as customers performing air gap installations with KOTS in existing clusters), you can configure the HelmChart `optionalValues` key so that KOTS rewrites the images for your application to the location of the image in user's local image registry during deployment.
+
+## Prerequisite
+
+Before configuring the HelmChart custom resource to conditionally rewrite images to the user's local registry, you first need to configure the HelmChart `builder` key to support the use of local registries. For more information, see [Package Air Gap Bundles for Helm Charts](/vendor/helm-packaging-airgap-bundles).
+
+## Rewrite Application Images
+
+To configure the HelmChart `optionalValues` key so that KOTS conditionally rewrites images to the user's local registry:
+
+1. In the HelmChart custom resource `optionalValues` key, use the following KOTS template functions:
+   * [HasLocalRegistry](/reference/template-functions-config-context#haslocalregistry)
+   * [LocalRegistryHost](/reference/template-functions-config-context#localregistryhost)
+   * [LocalRegistryNamespace](/reference/template-functions-config-context#localregistrynamespace)
+      <details>
+      <summary>What is the registry namespace?</summary>
+      <p>The registry namespace is the path between the registry and the image name. For example, `images.yourcompany.com/namespace/image:tag`.</p>
+      </details>
+
+   **Example:**
+
+    ```yaml
+    # KOTS HelmChart custom resource
+
+     apiVersion: kots.io/v1beta2
+     kind: HelmChart
+     metadata:
+       name: samplechart
+     spec:
+       optionalValues:
+         # Define the conditional statement in the when field
+         - when: 'repl{{ HasLocalRegistry }}'
+           values:
+             postgres:
+               image:
+                 registry: '{{repl LocalRegistryHost }}'
+                 repository: '{{repl LocalRegistryNamespace }}'/cloudnative-pg/cloudnative-pg
+    ```  
+1.      
+
+## Rewrite the Replicated SDK Image
+
+To configure the HelmChart `optionalValues` key so that KOTS conditionally rewrites the SDK image to the user's local registry:
+
+1. In the KOTS HelmChart custom resource, under the `optionalValues` key, rewrite the image for the Replicated SDK so that it can be accessed from the user's local registry, if a local registry was configured:
+
+    ```yaml
+       # KOTS HelmChart custom resource
+
+    apiVersion: kots.io/v1beta2
+    kind: HelmChart
+    metadata:
+      name: samplechart
+    spec:
+      optionalValues:
+        # Rewrite Replicated SDK image to local registry
+        - when: 'repl{{ HasLocalRegistry }}'
+          values:
+            replicated:
+              image:
+                registry: '{{repl LocalRegistryHost }}'
+                repository: '{{repl LocalRegistryNamespace }}/replicated-sdk'
+    ```
+
+## Add a Pull Secret for Rate-Limited Docker Hub Images {#docker-secret}
+
+Docker Hub enforces rate limits for Anonymous and Free users. For more information about Docker Hub rate limiting, see [Understanding Docker Hub rate limiting](https://www.docker.com/increase-rate-limits) on the Docker website.
+
+To avoid errors caused by reaching the rate limit, your users can run the `kots docker ensure-secret` command, which creates an `APP_SLUG-kotsadm-dockerhub` secret for pulling Docker Hub images and applies the secret to Kubernetes manifests that have images. For more information, see [Avoiding Docker Hub Rate Limits](/enterprise/image-registry-rate-limits). 
+
+To support the use of the `kots docker ensure-secret` command, add the `APP_SLUG-kotsadm-dockerhub` pull secret (where `APP_SLUG` is your application slug) to any Docker images that could be rate-limited.
+
+**Example:**
+
+```yaml
+# kots.io/v1beta2 HelmChart custom resource
+
+apiVersion: kots.io/v1beta2
+kind: HelmChart
+metadata:
+  name: samplechart
+spec:
+  values:
+    image:
+      registry: docker.io
+      repository: org-name/example-docker-hub-image
+      # Add the dockerhub secret
+      pullSecrets:
+      - name: gitea-kotsadm-dockerhub
+```    
\ No newline at end of file
diff --git a/docs/vendor/helm-packaging-airgap-bundles.mdx b/docs/vendor/helm-packaging-airgap-bundles.mdx
index 9a0b57cfd7..8d20e26af2 100644
--- a/docs/vendor/helm-packaging-airgap-bundles.mdx
+++ b/docs/vendor/helm-packaging-airgap-bundles.mdx
@@ -5,7 +5,7 @@ import AirGapBundle from "../partials/airgap/_airgap-bundle.mdx"
 
 # Package Air Gap Bundles for Helm Charts
 
-This topic describes how to package and build air gap bundles for releases that contain one or more Helm charts. This topic applies to applications deployed with Replicated KOTS.
+This topic describes how to package and build air gap bundles for releases that contain one or more Helm charts. This topic applies to applications deployed with a Replicated installer (Embedded Cluster, KOTS, or kURL).
 
 ## Overview
 
diff --git a/docs/vendor/helm-v2-migrate.md b/docs/vendor/helm-v2-migrate.mdx
similarity index 94%
rename from docs/vendor/helm-v2-migrate.md
rename to docs/vendor/helm-v2-migrate.mdx
index a606be9f2e..b370f23d8a 100644
--- a/docs/vendor/helm-v2-migrate.md
+++ b/docs/vendor/helm-v2-migrate.mdx
@@ -18,11 +18,15 @@ To migrate existing installations from HelmChart v1 with `useHelmInstall: true`
 
 1. In a development environment, install an application release using the KOTS HelmChart v1 with `useHelmInstall: true` method. You will use this installation to test the migration to HelmChart v2.
 
-1. Create a new release containing your application files.
+1. Update your Helm values file or files to rewrite image names to use the proxy registry.
 
-1. For each Helm chart in the release, find the corresponding HelmChart custom resource and update `apiVersion` to `kots.io/v1beta2`. Then update it to rewrite images, inject image pull secrets, and add backup labels. See [Configure the HelmChart Custom Resource v2](helm-native-v2-using).
+1. For each of your application's Helm charts, update the corresponding HelmChart custom resource:
+    1. Update `apiVersion` to `kots.io/v1beta2`
+    1. Update the `values` key to inject the KOTS image pull secret to provide authentication to the proxy registry
+    1. Update the `optionalValues` key to rewrite images to support local registries
+    1. Add backup labels to support the snapshots feature for KOTS existing cluster and kURL installations
 
-1. Promote the release to an internal-only channel that your team uses for testing.
+1. Create and promote a new release with your changes to an internal-only channel that your team uses for testing.
 
 1. In your development environment, log in to the Admin Console and confirm that you can upgrade to the new HelmChart v2 release.
 
diff --git a/docs/vendor/helmchart-v2-snapshots.mdx b/docs/vendor/helmchart-v2-snapshots.mdx
new file mode 100644
index 0000000000..0d44fd7707
--- /dev/null
+++ b/docs/vendor/helmchart-v2-snapshots.mdx
@@ -0,0 +1,48 @@
+# Add Backup Labels for Snapshots with HelmChart v2
+
+This topic describes how to configure the Replicated KOTS HelmChart v2 custom resource to add labels to resources in your Helm chart that you want to be included in backups taken with the Replicated snapshots feature. The information in this topic applies to Replicated KOTS installations in existing clusters and Replicated kURL installations.
+
+:::note
+The Replicated snapshots feature for backup and restore is supported only for KOTS existing cluster and kURL installations. Snapshots are not supported for installations with Replicated Embedded Cluster. For more information about disaster recovery for installations with Embedded Cluster, see [Disaster Recovery for Embedded Cluster](/vendor/embedded-disaster-recovery.mdx).
+:::
+
+## Overview
+
+The snapshots feature requires the following labels on all resources in your Helm chart that you want to be included in the backup:
+* `kots.io/backup: velero`
+* `kots.io/app-slug: APP_SLUG`, where `APP_SLUG` is the slug of your Replicated application.
+
+For more information about snapshots, see [Understanding Backup and Restore](snapshots-overview).
+
+## Add Backup Labels for Snapshots
+
+To support backup and restore with snapshots:
+
+1. In the HelmChart v2 custom resource for your Helm chart, under the `optionalValues` key, add a `when` statement that evaluates to true only when the customer license has the `isSnapshotSupported` entitlement. This ensures that the labels are only added to resources when the customer license supports snapshots. Then, add `values` that assign the following labels to the resources you want backed up:
+    * `kots.io/backup: velero`
+    * `kots.io/app-slug: APP_SLUG`, where `APP_SLUG` is the unique slug of your application. You can use the KOTS [LicenseFieldValue](/reference/template-functions-license-context#licensefieldvalue) function to get the application slug from the license.
+
+    ```yaml
+    # kots.io/v1beta2 HelmChart custom resource
+
+    apiVersion: kots.io/v1beta2
+    kind: HelmChart
+    metadata:
+      name: samplechart
+    spec:
+      optionalValues:
+      # add backup labels only if the license supports snapshots
+      - when: "repl{{ LicenseFieldValue `isSnapshotSupported` }}"
+        recursiveMerge: true
+        values:
+          mariadb:
+            commonLabels:
+              kots.io/backup: velero
+              # use the LicenseFieldValue function to get the app slug from the license
+              kots.io/app-slug: repl{{ LicenseFieldValue "appSlug" }}
+            podLabels:
+              kots.io/backup: velero
+              kots.io/app-slug: repl{{ LicenseFieldValue "appSlug" }}
+    ```
+
+1. Save and promote the release to the channel that you use for testing. Install in a development environment using KOTS or kURL to test your changes.    
\ No newline at end of file
diff --git a/docs/vendor/private-images-about.md b/docs/vendor/private-images-about.md
index 8d0e2dec83..e72286d7d4 100644
--- a/docs/vendor/private-images-about.md
+++ b/docs/vendor/private-images-about.md
@@ -14,12 +14,12 @@ The following diagram demonstrates how the proxy registry pulls images from your
 
 [View a larger version of this image](/images/private-registry-diagram-large.png)
 
-## About Enabling the Proxy Registry
+## About Using the Proxy Registry
 
 The proxy registry requires read-only credentials to your private registry to access your application images. See [Connect to an External Registry](/vendor/packaging-private-images).
 
 After connecting your registry, the steps the enable the proxy registry vary depending on your application deployment method. For more information, see:
-* [Using the Proxy Registry with KOTS Installations](/vendor/private-images-kots)
+* [Using the Proxy Registry with Replicated Installers](/vendor/private-images-kots)
 * [Using the Proxy Registry with Helm Installations](/vendor/helm-image-registry)
 
 ## About Allowing Pull-Through Access of Public Images
diff --git a/docs/vendor/private-images-kots.mdx b/docs/vendor/private-images-kots.mdx
index 9527486115..727dba05be 100644
--- a/docs/vendor/private-images-kots.mdx
+++ b/docs/vendor/private-images-kots.mdx
@@ -2,25 +2,112 @@ import Deprecated from "../partials/helm/_replicated-deprecated.mdx"
 import StepCreds from "../partials/proxy-service/_step-creds.mdx"
 import StepCustomDomain from "../partials/proxy-service/_step-custom-domain.mdx"
 
-# Use the Proxy Registry with KOTS Installations
+# Use the Proxy Registry with Replicated Installers
 
-This topic describes how to use the Replicated proxy registry with applications deployed with Replicated KOTS.
+This topic describes how to use the Replicated proxy registry with applications deployed with Replicated installers (KOTS, kURL, and Embedded Cluster).
 
 ## Overview
 
-Replicated KOTS automatically creates the required image pull secret for accessing the Replicated proxy registry during application deployment. When possible, KOTS also automatically rewrites image names in the application manifests to the location of the image at `proxy.replicated.com` or your custom domain.  
+For applications installed with a Replicated installer, Replicated KOTS automatically creates the required image pull secret for accessing the Replicated proxy registry during application deployment. When possible, KOTS also automatically rewrites image names in the application manifests to the location of the image at `proxy.replicated.com` or your custom domain.
 
-### Image Pull Secret
+There are different steps to configure your application to use the proxy registry depending on the installation method and how your application is packaged.
 
-During application deployment, KOTS automatically creates an `imagePullSecret` with `type: kubernetes.io/dockerconfigjson` that is based on the customer license. This secret is used to authenticate with the proxy registry and grant proxy access to private images.
+## Use the Proxy Registry
 
-For information about how Kubernetes uses the `kubernetes.io/dockerconfigjson` Secret type to authenticate to a private image registry, see [Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) in the Kubernetes documentation.
+This section describes how to configure your application to use the proxy registry.
 
-### Image Location Patching (Standard Manifests and HelmChart v1)
+### Helm Charts Deployed with HelmChart v2
 
-For applications packaged with standard Kubernetes manifests (or Helm charts deployed with the [HelmChart v1](/reference/custom-resource-helmchart) custom resource), KOTS automatically patches image names to the location of the image at at `proxy.replicated.com` or your custom domain during deployment. If KOTS receives a 401 response when attempting to load image manifests using the image reference from the PodSpec, it assumes that this is a private image that must be proxied through the proxy registry.
+To use the proxy registry for Helm charts deployed with HelmChart v2:
 
-KOTS uses Kustomize to patch the `midstream/kustomization.yaml` file to change the image name during deployment to reference the proxy registry. For example, a PodSpec for a Deployment references a private image hosted at `quay.io/my-org/api:v1.0.1`:
+1. <StepCreds/>
+
+1. <StepCustomDomain/>
+
+1. In your Helm chart values file, set your image repository URL to the location of the image on the proxy registry. If you added a custom domain, use your custom domain. Otherwise, use `proxy.replicated.com`.
+
+      The proxy registry URL has the following format: `DOMAIN/proxy/APP_SLUG/EXTERNAL_REGISTRY_IMAGE_URL`
+      
+      Where:
+      * `DOMAIN` is either `proxy.replicated.com` or your custom domain.
+      * `APP_SLUG` is the unique slug of your application.
+      * `EXTERNAL_REGISTRY_IMAGE_URL` is the path to the private image on your external registry.
+      
+      **Example:**
+
+      ```yaml
+      # values.yaml
+      api:
+        image:
+          # proxy.registry.com or your custom domain
+          registry: ghcr.io
+          repository: proxy/app/ghcr.io/cloudnative-pg/cloudnative-pg
+          tag: catalog-1.24.0
+      ```
+
+1. Ensure that any references to the image in your Helm chart access the field from your values file.  
+
+   **Example**:
+
+    ```yaml
+    apiVersion: v1
+    kind: Pod
+    spec:
+      containers:
+        - name: api 
+            # Access the registry, repository, and tag fields from the values file
+            image: {{ .Values.images.api.registry }}/{{ .Values.images.api.repository }}:{{ .Values.images.api.tag }}
+    ```
+
+1. In the KOTS HelmChart custom resource, under the `values` key, use the KOTS [ImagePullSecretName](/reference/template-functions-config-context#imagepullsecretname) template function to set the image pull secret for any private images to the KOTS-generated image pull secret.
+    <details>
+    <summary>What is the image pull secret?</summary>
+    <p>During application deployment, KOTS automatically creates an `imagePullSecret` with `type: kubernetes.io/dockerconfigjson` that is based on the customer license. This secret is used to authenticate with the proxy registry and grant proxy access to private images.</p>
+    <p>For information about how Kubernetes uses the `kubernetes.io/dockerconfigjson` Secret type to authenticate to a private image registry, see [Pull an Image from a Private Registry](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) in the Kubernetes documentation.</p>
+    </details>
+
+    **Example:**
+
+    ```yaml
+    # KOTS HelmChart custom resource
+
+    apiVersion: kots.io/v1beta2
+    kind: HelmChart
+    metadata:
+      name: samplechart
+    spec:
+      values:
+        postgres:
+          image:
+            # Inject the pull secret with ImagePullSecretName
+            imagePullSecrets:
+              - name: '{{repl ImagePullSecretName }}'
+    ```
+
+1. If you are deploying Pods to namespaces other than the application namespace, add the namespace to the `additionalNamespaces` attribute of the KOTS Application custom resource. This ensures that KOTS can provision the `imagePullSecret` in the namespace to allow the Pod to pull the image. For instructions, see [Define Additional Namespaces](operator-defining-additional-namespaces).
+
+
+### Helm Charts Deployed with HelmChart v1 or Standard Manifests
+
+:::note
+<Deprecated/>
+:::
+
+To use the proxy registry with applications deployed with HelmChart v1 or packed with standard manifests:
+
+1. <StepCreds/>
+
+1. <StepCustomDomain/>
+
+1. If you are deploying Pods to namespaces other than the application namespace, add the namespace to the `additionalNamespaces` attribute of the KOTS Application custom resource. This ensures that KOTS can provision the `imagePullSecret` in the namespace to allow the Pod to pull the image. For instructions, see [Define Additional Namespaces](operator-defining-additional-namespaces).
+
+For standard manifest-based applications or Helm charts deployed with the [HelmChart v1](/reference/custom-resource-helmchart), KOTS automatically rewrites image names and injects image pull secrets during deployment for these application types. No additional configuration is required.
+
+<details>
+<summary>How does KOTS rewrite image names and inject image pull secrets?</summary>
+
+<p>For applications packaged with the [HelmChart v1](/reference/custom-resource-helmchart) custom resource or with standard Kubernetes manifests, KOTS automatically patches image names to the location of the image at `proxy.replicated.com` or your custom domain during deployment. If KOTS receives a 401 response when attempting to load image manifests using the image reference from the PodSpec, it assumes that this is a private image that must be proxied through the proxy registry.</p>
+<p>KOTS uses Kustomize to patch the `midstream/kustomization.yaml` file to change the image name during deployment to reference the proxy registry. For example, a PodSpec for a Deployment references a private image hosted at `quay.io/my-org/api:v1.0.1`:</p>
 
 ```yaml
 apiVersion: apps/v1
@@ -35,9 +122,9 @@ spec:
           image: quay.io/my-org/api:v1.0.1
 ```
 
-When this application is deployed, KOTS detects that it cannot access
+<p>When this application is deployed, KOTS detects that it cannot access
 the image at quay.io. So, it creates a patch in the `midstream/kustomization.yaml`
-file that changes the image name in all manifest files for the application. This causes the container runtime in the cluster to use the proxy registry to pull the images, using the license information provided to KOTS for authentication.
+file that changes the image name in all manifest files for the application. This causes the container runtime in the cluster to use the proxy registry to pull the images, using the license information provided to KOTS for authentication.</p>
 
 ```yaml
 apiVersion: kustomize.config.k8s.io/v1beta1
@@ -47,29 +134,16 @@ images:
 - name: quay.io/my-org/api:v1.0.1
   newName: proxy.replicated.com/proxy/my-kots-app/quay.io/my-org/api
 ```
+</details>
 
-## Enable the Proxy Registry
-
-This section describes how to enable the proxy registry for applications deployed with KOTS, including how to ensure that image names are rewritten and that the required image pull secret is provided.
+### Kubernetes Operators
 
-To enable the proxy registry:
+To use the proxy registry with applications packaged with Kubernetes Operators:
 
 1. <StepCreds/>
 
 1. <StepCustomDomain/>
 
-1. Rewrite images names to the location of the image at `proxy.replicated.com` or your custom domain. Also, ensure that the correct image pull secret is provided for all private images. The steps required to configure image names and add the image pull secret vary depending on your application type:
-
-    * **HelmChart v2**: For Helm charts deployed with the[ HelmChart v2](/reference/custom-resource-helmchart-v2) custom resource, configure the HelmChart v2 custom resource to dynamically update image names in your Helm chart and to inject the image pull secret that is automatically created by KOTS. For instructions, see [Configure the HelmChart Custom Resource v2](/vendor/helm-native-v2-using).
-
-    * **Standard Manifests or HelmChart v1**: For standard manifest-based applications or Helm charts deployed with the [HelmChart v1](/reference/custom-resource-helmchart) custom resource, no additional configuration is required. KOTS automatically rewrites image names and injects image pull secrets during deployment for these application types.
-
-        :::note
-        <Deprecated/>
-        :::
-
-    * **Kubernetes Operators**: For applications packaged with Kubernetes Operators, KOTS cannot modify pods that are created at runtime by the Operator. To support the use of private images in all environments, the Operator code should use KOTS functionality to determine the image name and image pull secrets for all pods when they are created. For instructions, see [Reference Images](/vendor/operator-referencing-images) in the _Packaging Kubernetes Operators_ section.
-
 1. If you are deploying Pods to namespaces other than the application namespace, add the namespace to the `additionalNamespaces` attribute of the KOTS Application custom resource. This ensures that KOTS can provision the `imagePullSecret` in the namespace to allow the Pod to pull the image. For instructions, see [Define Additional Namespaces](operator-defining-additional-namespaces).
 
-1. (Optional) Add a custom domain for the proxy registry instead of `proxy.replicated.com`. See [Use Custom Domains](custom-domains-using).
\ No newline at end of file
+1. For applications packaged with Kubernetes Operators, KOTS cannot modify pods that are created at runtime by the Operator. To support the use of private images in all environments, the Operator code should use KOTS functionality to determine the image name and image pull secrets for all pods when they are created. For instructions, see [Reference Images](/vendor/operator-referencing-images) in the _Packaging Kubernetes Operators_ section.
\ No newline at end of file