v2.12.8 - Rancher Manager Release Maintenance (#2242 ) (#2253 )

* Update the deprecated features table * Update the CSP adapter compatibility matrix * Update the Rancher:webhook version mapping table * Update the versions table
Merge pull request #2252 from rancher/v2.11.12
2026-09-29 06:29:34 +00:00 · 2026-03-25 20:11:25 -07:00 · 2026-03-25 20:10:45 -07:00 · 2026-03-24 13:28:46 -07:00 · 2026-03-23 23:29:18 +05:30 · 2026-03-23 22:43:55 +05:30
7948 changed files with 409179 additions and 336784 deletions
@@ -6,10 +6,13 @@ title: '<VERSION> - Rancher Manager Release Maintenance Task Checklist'

 This issue is to track tasks that need to be done every release regardless of whether the release has new feature content or not.

+- [ ] Create a new branch for the release. Release-specific updates should use this branch as its base
 - [ ] Update the [versions table](https://ranchermanager.docs.rancher.com/versions)
 - [ ] Update the [Rancher:webhook version mapping table](https://ranchermanager.docs.rancher.com/reference-guides/rancher-webhook)
 - [ ] Update the [CNI popularity table](https://ranchermanager.docs.rancher.com/faq/container-network-interface-providers#cni-community-popularity)
- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix):
- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features):
+- [ ] Update the [CSP adapter compatibility matrix](https://ranchermanager.docs.rancher.com/integrations-in-rancher/cloud-marketplace/aws-cloud-marketplace/install-adapter#rancher-vs-adapter-compatibility-matrix)
+- [ ] Update the [deprecated features table](https://ranchermanager.docs.rancher.com/faq/deprecated-features)
+- [ ] Update the swagger-<VERSION>.json file
+- [ ] Create a PR merging the release branch back into the main branch
 - [ ] Create a new [release](https://github.com/rancher/rancher-docs/releases)
 - [ ] Update Algolia search index
@@ -0,0 +1 @@
+f288d286db3b7c65e02cb6635d0c048f0f7a88fa
@@ -1,31 +0,0 @@
-name: Create issue to track porting between Community and Product docs
-
-on:
-  pull_request_target:
-    types:
-      - closed
-    branches: 
-      - main
-    paths-ignore:
-      - '**/README.md'
-
-permissions:
-  issues: write
-  pull-requests: read
-
-jobs:
-  create_issue:
-    if: github.event.pull_request.merged == true && contains( github.event.pull_request.labels.*.name, 'port/community-product')
-    runs-on: ubuntu-latest
-    steps:
-    - name: Create issue
-      env:
-        GH_TOKEN: ${{ github.token }}
-        REPO_TYPE: ${{ contains( github.repository, 'product-docs') && 'Product' || 'Community' }}
-        PR_TITLE: ${{ github.event.pull_request.title }}
-      run: |
-        gh issue create \
-          --repo ${{ github.repository }} \
-          --title "Port $REPO_TYPE docs PR #${{ github.event.pull_request.number }}: $PR_TITLE" \
-          --body "Reference: https://github.com/${{ github.repository }}/pull/${{ github.event.pull_request.number }}" \
-          --label port/community-product
@@ -25,7 +25,7 @@ jobs:
        run: yarn install --frozen-lockfile
      - name: Build website
        env:
-          NODE_OPTIONS: "--max_old_space_size=7168"
+          NODE_OPTIONS: "--max_old_space_size=10240"
        run: yarn build --no-minify

      - name: Upload Build Artifact
@@ -27,5 +27,5 @@ jobs:
        run: yarn run remark --quiet --use remark-lint-no-dead-urls ./docs
      - name: Test build website
        env:
-          NODE_OPTIONS: "--max_old_space_size=7168"
+          NODE_OPTIONS: "--max_old_space_size=10240"
        run: yarn build --no-minify
@@ -1 +1 @@
-* @btat @LucasSaintarbor @sunilarjun
+* @btat @LucasSaintarbor @pmkovar @sunilarjun
@@ -15,7 +15,7 @@ To get started, [fork](https://github.com/rancher/rancher-docs/fork) and clone t

 Our repository doesn't allow you to make changes directly to the `main` branch. Create a working branch and make pull requests from your fork to [rancher/rancher-docs](https://github.com/rancher/rancher-docs).

-For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of August 2024, the most recently released version of Rancher is 2.9.
+For most updates, you'll need to edit a file in the `/docs` directory, which represents the ["Latest"](https://ranchermanager.docs.rancher.com/) version of our published documentation. The "Latest" version is a mirror of the most recently released version of Rancher. As of July 2025, the most recently released version of Rancher is 2.12.

 Whenever an update is made to `/docs`, you should apply the same change to the corresponding file in `/versioned_docs/version-2.9`. If a change only affects older versions, you don't need to mirror it to the `/docs` directory.

@@ -93,7 +93,7 @@ Subsequent executions will check for updated dependencies, if there are none, it

 License
 =======
-Copyright (c) 2014-2025 [SUSE, LLC.](https://www.suse.com/)
+Copyright (c) 2014-2026 [SUSE, LLC.](https://www.suse.com/)

 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
@@ -52,7 +52,7 @@ As an [administrator](../../../how-to-guides/advanced-user-guides/authentication
 > | 10252 | Controlplane | Kube controller manager |
 > | 2379 | Etcd | Etcd server |

-> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](/versioned_docs/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)
+> Monitoring V1 requires a Kubernetes verison less than or equal to v1.20.x. To install monitoring on Kubernetes v1.21+, you will need to [migrate to Monitoring V2.](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.5/how-to-guides/advanced-user-guides/monitoring-alerting-guides/migrate-to-rancher-v2.5%2B-monitoring.md)

 1. From the **Global** view, navigate to the cluster that you want to configure cluster monitoring.

@@ -41,7 +41,7 @@ Prometheus RemoteRead and RemoteWrite can be configured as custom answers in the

 For more information on remote endpoints and storage, refer to the [Prometheus documentation.](https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage)

-The Prometheus operator documentation contains the full [RemoteReadSpec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotereadspec) and [RemoteWriteSpec.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#remotewritespec)
+The Prometheus operator documentation contains the full [RemoteReadSpec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#remotereadspec) and [RemoteWriteSpec.](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#remotewritespec)

 An example configuration would be:

@@ -155,15 +155,32 @@ You may terminate the SSL/TLS on a L7 load balancer external to the Rancher clus

 Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.

-#### Configuring Ingress for External TLS when Using NGINX v0.25
+### Configuring Ingress for External TLS when Using NGINX v0.22

-In NGINX v0.25, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/main/Changelog.md#0220) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.25, you must edit the `cluster.yml` to enable the `use-forwarded-headers` option for ingress:
+In NGINX v0.22, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/06efac9f0b6f8f84b553f58ccecf79dc42c75cc6/Changelog.md) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.22, you must enable the `use-forwarded-headers` option for ingress:

+For RKE installations, edit the `cluster.yml` to add the following settings.
 ```yaml
 ingress:
  provider: nginx
  options:
-    use-forwarded-headers: "true"
+    use-forwarded-headers: 'true'
+```
+
+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
 ```

 #### Required Headers
@@ -121,7 +121,7 @@ To test the overlay network, you can launch the following `DaemonSet` definition
          - image: alpine
            imagePullPolicy: Always
            name: alpine
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log
    ```

@@ -41,7 +41,7 @@ Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](..

 The upgrade instructions assume you are using Helm 3.

-For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](helm2.md)provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.

 ### For air gap installs: Populate private registry

@@ -16,12 +16,13 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
 - [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
 - At least 4GB of free RAM.

-### Note
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
+:::note 

-  `vagrant plugin install vagrant-vboxmanage`
+Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands: 
+- `vagrant plugin install vagrant-vboxmanage` 
+- `vagrant plugin install vagrant-vbguest` 

-  `vagrant plugin install vagrant-vbguest`
+:::

 ## Getting Started

@@ -111,7 +111,7 @@ If you are experiencing issues while testing the connection to the Keycloak serv
 When you click on **Authenticate with Keycloak**, your are not redirected to your IdP.

  * Verify your Keycloak client configuration.
-  * Make sure `Force Post Binding` set to `OFF`.
+  * Make sure `Force Post Binding` is set to `OFF`.


 ### Forbidden message displayed after IdP login
@@ -10,7 +10,7 @@ After installation, the [system administrator](manage-role-based-access-control-

 ## First Log In

-After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
+After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**. You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.

 >**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care.

@@ -38,7 +38,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl

 ### About the kube-api-auth Authentication Webhook

-The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint,](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
+The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.

 During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.

@@ -100,7 +100,7 @@ If you want to check resolving of domain names on all of the hosts, execute the
          - image: busybox:1.28
            imagePullPolicy: Always
            name: alpine
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log
    ```

@@ -43,7 +43,7 @@ To test the overlay network, you can launch the following `DaemonSet` definition
          - image: rancherlabs/swiss-army-knife
            imagePullPolicy: Always
            name: overlaytest
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log

    ```
@@ -74,7 +74,7 @@ To see the Prometheus Targets, install `rancher-monitoring`. Then go to the **Cl

 ### Viewing the PrometheusRules

-When you define a Rule (which is declared within a RuleGroup in a PrometheusRule resource), the [spec of the Rule itself](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#rule) contains labels that are used by Alertmanager to figure out which Route should receive a certain Alert.
+When you define a Rule (which is declared within a RuleGroup in a PrometheusRule resource), the [spec of the Rule itself](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#rule) contains labels that are used by Alertmanager to figure out which Route should receive a certain Alert.

 To see the PrometheusRules, install `rancher-monitoring`. Then go to the **Cluster Explorer.** In the top left corner, click **Cluster Explorer > Monitoring.** Then click **Prometheus Rules.**

@@ -85,7 +85,7 @@ A PrometheusRule allows you to define one or more RuleGroups. Each RuleGroup con
 - Labels that should be attached to the alert or record that identify it (e.g. cluster name or severity)
 - Annotations that encode any additional important pieces of information that need to be displayed on the notification for an alert (e.g. summary, description, message, runbook URL, etc.). This field is not required for recording rules.

-Upon evaluating a [rule](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api.md#rule), Prometheus runs the provided PromQL query, adds the provided labels, and runs the appropriate action for the rule. If the rule triggers an alert, Prometheus also adds the provided annotations. For example, an Alerting Rule that adds `team: front-end` as a label to the provided PromQL query will append that label to the fired alert, which will allow Alertmanager to forward the alert to the correct Receiver.
+Upon evaluating a [rule](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#rule), Prometheus runs the provided PromQL query, adds the provided labels, and runs the appropriate action for the rule. If the rule triggers an alert, Prometheus also adds the provided annotations. For example, an Alerting Rule that adds `team: front-end` as a label to the provided PromQL query will append that label to the fired alert, which will allow Alertmanager to forward the alert to the correct Receiver.

 ### Alerting and Recording Rules

@@ -183,7 +183,7 @@ Refer to [Scraping Metrics with PushProx](#scraping-metrics-with-pushprox) for m

 ### Defining what Metrics are Scraped

-ServiceMonitors and PodMonitors define targets that are intended for Prometheus to scrape. The [Prometheus custom resource](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md#prometheus) tells Prometheus which ServiceMonitors or PodMonitors it should use to find out where to scrape metrics from.
+ServiceMonitors and PodMonitors define targets that are intended for Prometheus to scrape. The [Prometheus custom resource](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/getting-started/design.md#prometheus) tells Prometheus which ServiceMonitors or PodMonitors it should use to find out where to scrape metrics from.

 The Prometheus Operator observes the ServiceMonitors and PodMonitors. When it observes that they are created or updated, it calls the Prometheus API to update the scrape configuration in the Prometheus custom resource and keep it in sync with the scrape configuration in the ServiceMonitors or PodMonitors. This scrape configuration tells Prometheus which endpoints to scrape metrics from and how it will label the metrics from those endpoints.

@@ -16,12 +16,13 @@ The following steps quickly deploy a Rancher Server with a single node cluster a
 - [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
 - At least 4GB of free RAM.

-### Note
- Vagrant will require plugins to create VirtualBox VMs. Install them with the following commands:
+:::note 

-  `vagrant plugin install vagrant-vboxmanage`
+Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands: 
+- `vagrant plugin install vagrant-vboxmanage` 
+- `vagrant plugin install vagrant-vbguest` 

-  `vagrant plugin install vagrant-vbguest`
+:::

 ## Getting Started

@@ -164,7 +164,7 @@ If you are experiencing issues while testing the connection to the Keycloak serv
 When you click on **Authenticate with Keycloak**, you are not redirected to your IdP.

  * Verify your Keycloak client configuration.
-  * Make sure `Force Post Binding` set to `OFF`.
+  * Make sure `Force Post Binding` is set to `OFF`.


 ### Forbidden message displayed after IdP login
@@ -10,7 +10,7 @@ After installation, the [system administrator](manage-role-based-access-control-

 ## First Log In

-After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**.You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.
+After you log into Rancher for the first time, Rancher will prompt you for a **Rancher Server URL**. You should set the URL to the main entry point to the Rancher Server. When a load balancer sits in front a Rancher Server cluster, the URL should resolve to the load balancer. The system will automatically try to infer the Rancher Server URL from the IP address or host name of the host running the Rancher Server. This is only correct if you are running a single node Rancher Server installation. In most cases, therefore, you need to set the Rancher Server URL to the correct value yourself.

 >**Important!** After you set the Rancher Server URL, we do not support updating it. Set the URL with extreme care.

@@ -36,7 +36,7 @@ These methods of communicating with downstream Kubernetes clusters are also expl

 ### About the kube-api-auth Authentication Webhook

-The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint,](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.
+The `kube-api-auth` microservice is deployed to provide the user authentication functionality for the [authorized cluster endpoint](../../../../reference-guides/rancher-manager-architecture/communicating-with-downstream-user-clusters.md#4-authorized-cluster-endpoint) which is only available for [RKE clusters.](../../../new-user-guides/kubernetes-clusters-in-rancher-setup/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md) When you access the user cluster using `kubectl`, the cluster's Kubernetes API server authenticates you by using the `kube-api-auth` service as a webhook.

 During cluster provisioning, the file `/etc/kubernetes/kube-api-authn-webhook.yaml` is deployed and `kube-apiserver` is configured with `--authentication-token-webhook-config-file=/etc/kubernetes/kube-api-authn-webhook.yaml`. This configures the `kube-apiserver` to query `http://127.0.0.1:6440/v1/authenticate` to determine authentication for bearer tokens.

@@ -28,7 +28,7 @@ To create rule groups in the Rancher UI,

 ## About the PrometheusRule Custom Resource

-When you define a Rule (which is declared within a RuleGroup in a PrometheusRule resource), the [spec of the Rule itself](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#rule) contains labels that are used by Alertmanager to figure out which Route should receive this Alert. For example, an Alert with the label `team: front-end` will be sent to all Routes that match on that label.
+When you define a Rule (which is declared within a RuleGroup in a PrometheusRule resource), the [spec of the Rule itself](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#rule) contains labels that are used by Alertmanager to figure out which Route should receive this Alert. For example, an Alert with the label `team: front-end` will be sent to all Routes that match on that label.

 Prometheus rule files are held in PrometheusRule custom resources. A PrometheusRule allows you to define one or more RuleGroups. Each RuleGroup consists of a set of Rule objects that can each represent either an alerting or a recording rule with the following fields:

@@ -37,7 +37,7 @@ Prometheus rule files are held in PrometheusRule custom resources. A PrometheusR
 - Labels that should be attached to the alert or record that identify it (e.g. cluster name or severity)
 - Annotations that encode any additional important pieces of information that need to be displayed on the notification for an alert (e.g. summary, description, message, runbook URL, etc.). This field is not required for recording rules.

-For more information on what fields can be specified, please look at the [Prometheus Operator spec.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#prometheusrulespec)
+For more information on what fields can be specified, please look at the [Prometheus Operator spec.](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#prometheusrulespec)

 Use the label selector field `ruleSelector` in the Prometheus object to define the rule files that you want to be mounted into Prometheus.

@@ -8,7 +8,7 @@ title: Monitoring V2 Configuration Guides

 This page captures some of the most important options for configuring Monitoring V2 in the Rancher UI.

-For information on configuring custom scrape targets and rules for Prometheus, please refer to the upstream documentation for the [Prometheus Operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus Operator [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/design.md) The Prometheus Operator documentation can help also you set up RBAC, Thanos, or custom configuration.
+For information on configuring custom scrape targets and rules for Prometheus, please refer to the upstream documentation for the [Prometheus Operator.](https://github.com/prometheus-operator/prometheus-operator) Some of the most important custom resources are explained in the Prometheus Operator [design documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/getting-started/design.md) The Prometheus Operator documentation can help also you set up RBAC, Thanos, or custom configuration.

 ## Setting Resource Limits and Requests

@@ -160,10 +160,11 @@ You may terminate the SSL/TLS on a L7 load balancer external to the Rancher clus

 Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.

-### Configuring Ingress for External TLS when Using NGINX v0.25
+### Configuring Ingress for External TLS when Using NGINX v0.22

-In NGINX v0.25, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/master/Changelog.md#0220) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.25, you must edit the `cluster.yml` to enable the `use-forwarded-headers` option for ingress:
+In NGINX v0.22, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/06efac9f0b6f8f84b553f58ccecf79dc42c75cc6/Changelog.md) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.22, you must enable the `use-forwarded-headers` option for ingress:

+For RKE installations, edit the `cluster.yml` to add the following settings.
 ```yaml
 ingress:
  provider: nginx
@@ -171,6 +172,22 @@ ingress:
    use-forwarded-headers: 'true'
 ```

+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
+```
+
 ### Required Headers

 - `Host`
@@ -8,7 +8,7 @@ title: Monitoring V2 Configuration Examples

 ## ServiceMonitor

-See the official prometheus-operator GitHub repo for an example [ServiceMonitor](https://github.com/prometheus-operator/prometheus-operator/blob/master/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml) YAML.
+See the official prometheus-operator GitHub repo for an example [ServiceMonitor](https://github.com/prometheus-operator/prometheus-operator/blob/main/example/prometheus-operator-crd/monitoring.coreos.com_servicemonitors.yaml) YAML.

 ## PodMonitor

@@ -20,9 +20,9 @@ This pseudo-CRD maps to a section of the Prometheus custom resource configuratio

 When a ServiceMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the ServiceMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the ServiceMonitor.

-Any Services in your cluster that match the labels located within the ServiceMonitor `selector` field will be monitored based on the `endpoints` specified on the ServiceMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#servicemonitor) provided by Prometheus Operator.
+Any Services in your cluster that match the labels located within the ServiceMonitor `selector` field will be monitored based on the `endpoints` specified on the ServiceMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#servicemonitor) provided by Prometheus Operator.

-For more information about how ServiceMonitors work, refer to the [Prometheus Operator documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/user-guides/running-exporters.md)
+For more information about how ServiceMonitors work, refer to the [Prometheus Operator documentation.](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/user-guides/running-exporters.md)

 ## PodMonitors

@@ -30,4 +30,4 @@ This pseudo-CRD maps to a section of the Prometheus custom resource configuratio

 When a PodMonitor is created, the Prometheus Operator updates the Prometheus scrape configuration to include the PodMonitor configuration. Then Prometheus begins scraping metrics from the endpoint defined in the PodMonitor.

-Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/api.md#podmonitorspec) provided by Prometheus Operator.
+Any Pods in your cluster that match the labels located within the PodMonitor `selector` field will be monitored based on the `podMetricsEndpoints` specified on the PodMonitor. For more information on what fields can be specified, please look at the [spec](https://github.com/prometheus-operator/prometheus-operator/blob/main/Documentation/api-reference/api.md#podmonitor) provided by Prometheus Operator.
@@ -100,7 +100,7 @@ If you want to check resolving of domain names on all of the hosts, execute the
          - image: busybox:1.28
            imagePullPolicy: Always
            name: alpine
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log
    ```

@@ -43,7 +43,7 @@ To test the overlay network, you can launch the following `DaemonSet` definition
          - image: rancherlabs/swiss-army-knife
            imagePullPolicy: Always
            name: overlaytest
-            command: ["sh", "-c", "tail -f /dev/null"]
+            command: ["sleep", "infinity"]
            terminationMessagePath: /dev/termination-log

    ```
@@ -0,0 +1,33 @@
+---
+title: Deprecated Features in Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/faq/deprecated-features"/>
+</head>
+
+## Where can I find out which features have been deprecated in Rancher?
+
+Rancher will publish deprecated features as part of the [release notes](https://github.com/rancher/rancher/releases) for Rancher found on GitHub. Please consult the following patch releases for deprecated features:
+
+| Patch Version | Release Date |
+|---------------|---------------|
+| [2.6.14](https://github.com/rancher/rancher/releases/tag/v2.6.14) | Feb 8, 2024 |
+| [2.6.13](https://github.com/rancher/rancher/releases/tag/v2.6.13) | May 31, 2023 |
+| [2.6.12](https://github.com/rancher/rancher/releases/tag/v2.6.12) | Apr 27, 2023 |
+| [2.6.11](https://github.com/rancher/rancher/releases/tag/v2.6.11) | Mar 8, 2023 |
+| [2.6.10](https://github.com/rancher/rancher/releases/tag/v2.6.10) | Jan 24, 2023 |
+| [2.6.9](https://github.com/rancher/rancher/releases/tag/v2.6.9) | Oct 18, 2022 |
+| [2.6.8](https://github.com/rancher/rancher/releases/tag/v2.6.8) | Aug 29, 2022 |
+| [2.6.7](https://github.com/rancher/rancher/releases/tag/v2.6.7) | Aug 18, 2022 |
+| [2.6.6](https://github.com/rancher/rancher/releases/tag/v2.6.6) | Jun 30, 2022 |
+| [2.6.5](https://github.com/rancher/rancher/releases/tag/v2.6.5) | May 12, 2022 |
+| [2.6.4](https://github.com/rancher/rancher/releases/tag/v2.6.4) | Mar 31, 2022 |
+| [2.6.3](https://github.com/rancher/rancher/releases/tag/v2.6.3) | Dec 21, 2021 |
+| [2.6.2](https://github.com/rancher/rancher/releases/tag/v2.6.2) | Oct 19, 2021 |
+| [2.6.1](https://github.com/rancher/rancher/releases/tag/v2.6.1) | Oct 11, 2021 |
+| [2.6.0](https://github.com/rancher/rancher/releases/tag/v2.6.0) | Aug 31, 2021 |
+
+## What can I expect when a feature is marked for deprecation?
+
+In the release where functionality is marked as "Deprecated", it will still be available and supported allowing upgrades to follow the usual procedure. Once upgraded, users/admins should start planning to move away from the deprecated functionality before upgrading to the release it marked as removed. The recommendation for new deployments is to not use the deprecated feature.
@@ -0,0 +1,197 @@
+---
+title: Upgrades
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades"/>
+</head>
+
+The following instructions will guide you through upgrading a Rancher server that was installed on a Kubernetes cluster with Helm. These steps also apply to air-gapped installs with Helm.
+
+For the instructions to upgrade Rancher installed with Docker, refer to [this page.](../other-installation-methods/rancher-on-a-single-node-with-docker/upgrade-docker-installed-rancher.md)
+
+To upgrade the components in your Kubernetes cluster, or the definition of the [Kubernetes services](https://rancher.com/docs/rke/latest/en/config-options/services/) or [add-ons](https://rancher.com/docs/rke/latest/en/config-options/add-ons/), refer to the [upgrade documentation for RKE](https://rancher.com/docs/rke/latest/en/upgrades/), the Rancher Kubernetes Engine.
+
+## Prerequisites
+
+### Access to kubeconfig
+
+Helm should be run from the same location as your kubeconfig file, or the same location where you run your kubectl commands from.
+
+If you installed Kubernetes with RKE, the config will have been created in the directory you ran `rke up` in.
+
+The kubeconfig can also be manually targeted for the intended cluster with the `--kubeconfig` tag (see: https://helm.sh/docs/helm/helm/)
+
+### Review Known Issues
+
+Review the list of known issues for each Rancher version, which can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
+
+Note that upgrades _to_ or _from_ any chart in the [rancher-alpha repository](../resources/choose-a-rancher-version.md#helm-chart-repositories) aren't supported.
+### Helm Version
+
+The upgrade instructions assume you are using Helm 3.
+
+For migration of installs started with Helm 2, refer to the official [Helm 2 to 3 migration docs.](https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/) The [Helm 2 upgrade page here](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/helm2.md) provides a copy of the older upgrade instructions that used Helm 2, and it is intended to be used if upgrading to Helm 3 is not feasible.
+
+### For air-gapped installs: Populate private registry
+
+For [air-gapped installs only,](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md) collect and populate images for the new Rancher server version. Follow the guide to [populate your private registry](../other-installation-methods/air-gapped-helm-cli-install/publish-images.md) with the images for the Rancher version that you want to upgrade to.
+
+### For upgrades with cert-manager older than 0.8.0
+
+[Let's Encrypt will be blocking cert-manager instances older than 0.8.0 starting November 1st 2019.](https://community.letsencrypt.org/t/blocking-old-cert-manager-versions/98753) Upgrade cert-manager to the latest version by following [these instructions.](../resources/upgrade-cert-manager.md)
+
+## Upgrade Outline
+
+Follow the steps to upgrade Rancher server:
+
+### 1. Back up Your Kubernetes Cluster that is Running Rancher Server
+
+Use the [backup application](../../../how-to-guides/new-user-guides/backup-restore-and-disaster-recovery/back-up-rancher.md) to back up Rancher.
+
+You'll use the backup as a restore point if something goes wrong during upgrade.
+
+### 2. Update the Helm chart repository
+
+1. Update your local Helm repo cache:
+
+    ```
+    helm repo update
+    ```
+
+1. Get the repository name that you used to install Rancher.
+
+    For information about the repos and their differences, see [Helm Chart Repositories](../resources/choose-a-rancher-version.md#helm-chart-repositories).
+
+    - Latest: Recommended for trying out the newest features
+        ```
+        helm repo add rancher-latest https://releases.rancher.com/server-charts/latest
+        ```
+    - Stable: Recommended for production environments
+        ```
+        helm repo add rancher-stable https://releases.rancher.com/server-charts/stable
+        ```
+    - Alpha: Experimental preview of upcoming releases.
+        ```
+        helm repo add rancher-alpha https://releases.rancher.com/server-charts/alpha
+        ```
+        Note: Upgrades are not supported to, from, or between Alphas.
+
+    ```
+    helm repo list
+
+    NAME          	       URL
+    stable        	       https://charts.helm.sh/stable
+    rancher-<CHART_REPO>	 https://releases.rancher.com/server-charts/<CHART_REPO>
+    ```
+
+    :::note
+
+    If you want to switch to a different Helm chart repository, please follow the [steps on how to switch repositories](../resources/choose-a-rancher-version.md#switching-to-a-different-helm-chart-repository). If you switch repositories, make sure to list the repositories again before continuing onto Step 3 to ensure you have the correct one added.
+
+    :::
+
+1. Fetch the latest chart to install Rancher from the Helm chart repository.
+
+    This command will pull down the latest charts and save it in the current directory as a `.tgz` file.
+
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher
+    ```
+    You can fetch the chart for the specific version you are upgrading to by adding in the `--version=` tag.  For example:
+
+    ```plain
+    helm fetch rancher-<CHART_REPO>/rancher --version=2.6.8
+    ```
+
+### 3. Upgrade Rancher
+
+This section describes how to upgrade normal (Internet-connected) or air-gapped installations of Rancher with Helm.
+
+:::note Air Gap Instructions:
+
+If you are installing Rancher in an air-gapped environment, skip the rest of this page and render the Helm template by following the instructions on [this page.](air-gapped-upgrades.md)
+
+:::
+
+
+Get the values, which were passed with `--set`, from the current Rancher Helm chart that is installed.
+
+```
+helm get values rancher -n cattle-system
+
+hostname: rancher.my.org
+```
+
+:::note
+
+There will be more values that are listed with this command. This is just an example of one of the values.
+
+:::
+
+:::tip 
+Your deployment name may vary; for example, if you're deploying Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
+Thus: 
+```
+helm get values rancher-stable -n cattle-system
+
+hostname: rancher.my.org
+```
+:::
+
+If you are upgrading cert-manager to the latest version from v1.5 or below, follow the [cert-manager upgrade docs](../resources/upgrade-cert-manager.md#option-c-upgrade-cert-manager-from-versions-15-and-below) to learn how to upgrade cert-manager without needing to perform an uninstall or reinstall of Rancher. Otherwise, follow the [steps to upgrade Rancher](#steps-to-upgrade-rancher) below.
+
+#### Steps to Upgrade Rancher
+
+Upgrade Rancher to the latest version with all your settings.
+
+Take all the values from the previous step and append them to the command using `--set key=value`:
+
+```
+helm upgrade rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+
+:::note
+
+The above is an example, there may be more values from the previous step that need to be appended.
+
+:::
+
+:::tip 
+If you deploy Rancher through the AWS Marketplace, the deployment name is 'rancher-stable'. 
+Thus: 
+```
+helm upgrade rancher-stable rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  --set hostname=rancher.my.org
+```
+:::
+
+Alternatively, it's possible to export the current values to a file and reference that file during upgrade. For example, to only change the Rancher version:
+
+```
+helm get values rancher -n cattle-system -o yaml > values.yaml
+
+helm upgrade rancher rancher-<CHART_REPO>/rancher \
+  --namespace cattle-system \
+  -f values.yaml \
+  --version=2.6.8
+```
+
+### 4. Verify the Upgrade
+
+Log into Rancher to confirm that the upgrade succeeded.
+
+:::tip
+
+Having network issues following upgrade?
+
+See [Restoring Cluster Networking](https://github.com/rancher/rancher-docs/tree/main/archived_docs/en/version-2.0-2.4/getting-started/installation-and-upgrade/install-upgrade-on-a-kubernetes-cluster/upgrades/namespace-migration.md).
+
+:::
+
+## Known Upgrade Issues
+
+A list of known issues for each Rancher version can be found in the release notes on [GitHub](https://github.com/rancher/rancher/releases) and on the [Rancher forums.](https://forums.rancher.com/c/announcements/12)
@@ -0,0 +1,318 @@
+---
+title: Rancher Helm Chart Options
+keywords: [rancher v2.0-v2.4 helm chart, rancher v2.0-v2.4 helm options, rancher v2.0-v2.4 helm chart options, helm chart rancher v2.0-v2.4 helm options rancher v2.0-v2.4 helm chart options rancher v2.0-v2.4]
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/installation-references/helm-chart-options"/>
+</head>
+
+This page is a configuration reference for the Rancher Helm chart.
+
+For help choosing a Helm chart version, refer to [this page.](../../../getting-started/installation-and-upgrade/resources/choose-a-rancher-version.md)
+
+For information on enabling experimental features, refer to [this page.](../../../how-to-guides/advanced-user-guides/enable-experimental-features/enable-experimental-features.md)
+
+## Common Options
+
+| Option                    | Default Value | Description                                                                        |
+| ------------------------- | ------------- | ---------------------------------------------------------------------------------- |
+| `bootstrapPassword`       | " "           | `string` - Set the [bootstrap password](#bootstrap-password) for the first admin user. After logging in, the admin should reset their password. A randomly generated bootstrap password is used if this value is not set.
+| `hostname`                | " "           | `string` - the Fully Qualified Domain Name for your Rancher Server                 |
+| `ingress.tls.source`      | "rancher"     | `string` - Where to get the cert for the ingress. - "rancher, letsEncrypt, secret" |
+| `letsEncrypt.email`       | " "           | `string` - Your email address                                                      |
+| `letsEncrypt.environment` | "production"  | `string` - Valid options: "staging, production"                                    |
+| `privateCA`               | false         | `bool` - Set to true if your cert is signed by a private CA                        |
+
+<br/>
+
+## Advanced Options
+
+| Option                         | Default Value                                         | Description                                                                                                                                       |
+| ------------------------------ | ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `additionalTrustedCAs`         | false                                                 | `bool` - See [Additional Trusted CAs](#additional-trusted-cas)                                                                                    |
+| `addLocal`                     | "true"                                                | `string` - Have Rancher detect and import the "local" Rancher server cluster.  _Note: This option is no longer available in v2.5.0. Consider using the `restrictedAdmin` option to prevent users from modifying the local cluster._ |
+| `antiAffinity`                 | "preferred"                                           | `string` - AntiAffinity rule for Rancher pods - "preferred, required"                                                                             |
+| `auditLog.destination`         | "sidecar"                                             | `string` - Stream to sidecar container console or hostPath volume - "sidecar, hostPath"                                                           |
+| `auditLog.hostPath`            | "/var/log/rancher/audit"                              | `string` - log file destination on host (only applies when `auditLog.destination` is set to `hostPath`)                                           |
+| `auditLog.level`               | 0                                                     | `int` - set the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md) level. 0 is off. [0-3]                                   |
+| `auditLog.maxAge`              | 1                                                     | `int` - maximum number of days to retain old audit log files (only applies when `auditLog.destination` is set to `hostPath`)                      |
+| `auditLog.maxBackup`           | 1                                                     | `int` - maximum number of audit log files to retain (only applies when `auditLog.destination` is set to `hostPath`)                               |
+| `auditLog.maxSize`             | 100                                                   | `int` - maximum size in megabytes of the audit log file before it gets rotated (only applies when `auditLog.destination` is set to `hostPath`)    |
+| `busyboxImage`                 | "busybox"                                             | `string` - Image location for busybox image used to collect audit logs                |
+| `certmanager.version`          | ""                                                    | `string` - set cert-manager compatibility                                                                                                         |
+| `debug`                        | false                                                 | `bool` - set debug flag on rancher server                                                                                                         |
+| `extraEnv`                     | []                                                    | `list` - set additional environment variables for Rancher                                                          |
+| `imagePullSecrets`             | []                                                    | `list` - list of names of Secret resource containing private registry credentials                                                                 |
+| `ingress.configurationSnippet` | ""                                                    | `string` - additional Nginx configuration. Can be used for proxy configuration.   |
+| `ingress.extraAnnotations`     | {}                                                    | `map` - additional annotations to customize the ingress                                                                                           |
+|  `ingress.enabled` |  true   |    When set to false, Helm will not install a Rancher ingress. Set the option to false to deploy your own ingress.   |
+| `letsEncrypt.ingress.class`    | ""                                                    | `string` - optional ingress class for the cert-manager acmesolver ingress that responds to the Let's Encrypt ACME challenges. Options: traefik, nginx.       |                      |
+| `noProxy`                      | "127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,cattle-system.svc" | `string` - comma separated list of hostnames or ip address not to use the proxy                              |                                     |
+| `proxy`                        | ""                                                    | `string` - HTTP[S] proxy server for Rancher                                                                                                       |
+| `rancherImage`                 | "rancher/rancher"                                     | `string` - rancher image source                                                                                                                   |
+| `rancherImagePullPolicy`       | "IfNotPresent"                                        | `string` - Override imagePullPolicy for rancher server images - "Always", "Never", "IfNotPresent"                                                 |
+| `rancherImageTag`              | same as chart version                                 | `string` - rancher/rancher image tag                                                                                                              |
+| `replicas`                     | 3                                                     | `int` - Number of Rancher server replicas. Setting to -1 will dynamically choose 1, 2, or 3 based on the number of available nodes in the cluster.                                                                                                        |
+| `resources`                    | {}                                                    | `map` - rancher pod resource requests & limits                                                                                                    |
+| `restrictedAdmin` | `false` | `bool` - When this option is set to true, the initial Rancher user has restricted access to the local Kubernetes cluster to prevent privilege escalation. For more information, see the section about the [restricted-admin role.](../../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md#restricted-admin) |
+| `systemDefaultRegistry`        | ""                                                    | `string` - private registry to be used for all system container images, e.g., http://registry.example.com/                   |
+| `tls`                          | "ingress"                                             | `string` - See [External TLS Termination](#external-tls-termination) for details. - "ingress, external"                                           |
+| `useBundledSystemChart`        | `false`                                               | `bool` - select to use the system-charts packaged with Rancher server. This option is used for air gapped installations.  |
+
+
+
+### Bootstrap Password
+
+You can [set a specific bootstrap password](../resources/bootstrap-password.md) during Rancher installation. If you don't set a specific bootstrap password, Rancher randomly generates a password for the first admin account.
+
+When you log in for the first time, use the bootstrap password you set to log in. If you did not set a bootstrap password, the Rancher UI shows commands that can be used to [retrieve the bootstrap password](../resources/bootstrap-password.md#retrieving-the-bootstrap-password). Run those commands and log in to the account. After you log in for the first time, you are asked to reset the admin password.
+
+### API Audit Log
+
+Enabling the [API Audit Log](../../../how-to-guides/advanced-user-guides/enable-api-audit-log.md).
+
+You can collect this log as you would any container log. Enable [logging](../../../integrations-in-rancher/logging/logging.md) for the `System` Project on the Rancher server cluster.
+
+```plain
+--set auditLog.level=1
+```
+
+By default enabling Audit Logging will create a sidecar container in the Rancher pod. This container (`rancher-audit-log`) will stream the log to `stdout`. You can collect this log as you would any container log. When using the sidecar as the audit log destination, the `hostPath`, `maxAge`, `maxBackups`, and `maxSize` options do not apply. It's advised to use your OS or Docker daemon's log rotation features to control disk space use. Enable [logging](../../../integrations-in-rancher/logging/logging.md) for the Rancher server cluster or System Project.
+
+Set the `auditLog.destination` to `hostPath` to forward logs to volume shared with the host system instead of streaming to a sidecar container. When setting the destination to `hostPath` you may want to adjust the other auditLog parameters for log rotation.
+
+### Setting Extra Environment Variables
+
+You can set extra environment variables for Rancher server using `extraEnv`. This list is passed to the Rancher deployment in its YAML format. It is embedded under `env` for the Rancher container. Refer to the Kubernetes documentation for setting container environment variables, `extraEnv` can use any of the keys referenced in [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
+
+Consider an example that uses the `name` and `value` keys:
+
+```plain
+--set 'extraEnv[0].name=CATTLE_TLS_MIN_VERSION'
+--set 'extraEnv[0].value=1.0'
+```
+
+If passing sensitive data as the value for an environment variable, such as proxy authentication credentials, it is strongly recommended that a secret reference is used. This will prevent sensitive data from being exposed in Helm or the Rancher deployment.
+
+Consider an example that uses the `name`, `valueFrom.secretKeyRef.name`, and `valueFrom.secretKeyRef.key` keys. See example in [HTTP Proxy](#http-proxy)
+
+### TLS Settings
+
+When you install Rancher inside of a Kubernetes cluster, TLS is offloaded at the cluster's ingress controller. The possible TLS settings depend on the used ingress controller.
+
+See [TLS settings](tls-settings.md) for more information and options.
+
+### Import `local` Cluster
+
+By default Rancher server will detect and import the `local` cluster it's running on. User with access to the `local` cluster will essentially have "root" access to all the clusters managed by Rancher server.
+
+:::caution
+
+If you turn addLocal off, most Rancher v2.5 features won't work, including the EKS provisioner.
+
+:::
+
+If this is a concern in your environment you can set this option to "false" on your initial install.
+
+This option is only effective on the initial Rancher install. See [Issue 16522](https://github.com/rancher/rancher/issues/16522) for more information.
+
+```plain
+--set addLocal="false"
+```
+
+### Customizing your Ingress
+
+To customize or use a different ingress with Rancher server you can set your own Ingress annotations.
+
+Example on setting a custom certificate issuer:
+
+```plain
+--set ingress.extraAnnotations.'cert-manager\.io/cluster-issuer'=issuer-name
+```
+
+Example on setting a static proxy header with `ingress.configurationSnippet`. This value is parsed like a template so variables can be used.
+
+```plain
+--set ingress.configurationSnippet='more_set_input_headers X-Forwarded-Host {{ .Values.hostname }};'
+```
+
+### HTTP Proxy
+
+Rancher requires internet access for some functionality (Helm charts). Use `proxy` to set your proxy server or use `extraEnv` to set the `HTTPS_PROXY` environment variable to point to your proxy server.
+
+Add your IP exceptions to the `noProxy` chart value as a comma separated list. Make sure you add the following values:
+- Pod cluster IP range (default: `10.42.0.0/16`).
+- Service cluster IP range (default: `10.43.0.0/16`).
+- Internal cluster domains (default: `.svc,.cluster.local`).
+- Any worker cluster `controlplane` nodes.
+Rancher supports CIDR notation ranges in this list.
+
+When not including sensitive data, the `proxy` or `extraEnv` chart options can be used. When using `extraEnv` the `noProxy` Helm option is ignored. Therefore, the `NO_PROXY` environment variable must also be set with `extraEnv`.
+
+The following is an example of setting proxy using the `proxy` chart option:
+
+```plain
+--set proxy="http://<proxy_url:proxy_port>/"
+```
+
+Example of setting proxy using the `extraEnv` chart option:
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].value="http://<proxy_url>:<proxy_port>/"
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+When including sensitive data, such as proxy authentication credentials, use the `extraEnv` option with `valueFrom.secretRef` to prevent sensitive data from being exposed in Helm or the Rancher deployment.
+
+The following is an example of using `extraEnv` to configure proxy. This example secret would contain the value `"http://<username>:<password>@<proxy_url>:<proxy_port>/"` in the secret's`"https-proxy-url"` key:
+```plain
+--set extraEnv[1].name=HTTPS_PROXY
+--set extraEnv[1].valueFrom.secretKeyRef.name=secret-name
+--set extraEnv[1].valueFrom.secretKeyRef.key=https-proxy-url
+--set extraEnv[2].name=NO_PROXY
+--set extraEnv[2].value="127.0.0.0/8\,10.0.0.0/8\,172.16.0.0/12\,192.168.0.0/16\,.svc\,.cluster.local"
+```
+
+To learn more about how to configure environment variables, refer to [Define Environment Variables for a Container](https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/#define-an-environment-variable-for-a-container).
+
+### Additional Trusted CAs
+
+If you have private registries, catalogs or a proxy that intercepts certificates, you may need to add more trusted CAs to Rancher.
+
+```plain
+--set additionalTrustedCAs=true
+```
+
+Once the Rancher deployment is created, copy your CA certs in pem format into a file named `ca-additional.pem` and use `kubectl` to create the `tls-ca-additional` secret in the `cattle-system` namespace.
+
+```plain
+kubectl -n cattle-system create secret generic tls-ca-additional --from-file=ca-additional.pem=./ca-additional.pem
+```
+
+### Private Registry and Air Gap Installs
+
+For details on installing Rancher with a private registry, see the [air gap installation docs.](../other-installation-methods/air-gapped-helm-cli-install/air-gapped-helm-cli-install.md)
+
+## External TLS Termination
+
+We recommend configuring your load balancer as a Layer 4 balancer, forwarding plain 80/tcp and 443/tcp to the Rancher Management cluster nodes. The Ingress Controller on the cluster will redirect http traffic on port 80 to https on port 443.
+
+You may terminate the SSL/TLS on a L7 load balancer external to the Rancher cluster (ingress). Use the `--set tls=external` option and point your load balancer at port http 80 on all of the Rancher cluster nodes. This will expose the Rancher interface on http port 80. Be aware that clients that are allowed to connect directly to the Rancher cluster will not be encrypted. If you choose to do this we recommend that you restrict direct access at the network level to just your load balancer.
+
+:::note
+
+If you are using a Private CA signed certificate, add `--set privateCA=true` and see [Adding TLS Secrets - Using a Private CA Signed Certificate](../../../getting-started/installation-and-upgrade/resources/add-tls-secrets.md) to add the CA cert for Rancher.
+
+:::
+
+Your load balancer must support long lived websocket connections and will need to insert proxy headers so Rancher can route links correctly.
+
+### Configuring Ingress for External TLS when Using NGINX v0.22
+
+In NGINX v0.22, the behavior of NGINX has [changed](https://github.com/kubernetes/ingress-nginx/blob/06efac9f0b6f8f84b553f58ccecf79dc42c75cc6/Changelog.md) regarding forwarding headers and external TLS termination. Therefore, in the scenario that you are using external TLS termination configuration with NGINX v0.22, you must enable the `use-forwarded-headers` option for ingress:
+
+For RKE installations, edit the `cluster.yml` to add the following settings.
+```yaml
+ingress:
+  provider: nginx
+  options:
+    use-forwarded-headers: 'true'
+```
+
+For RKE2 installations, you can create a custom `rke2-ingress-nginx-config.yaml` file at `/var/lib/rancher/rke2/server/manifests/rke2-ingress-nginx-config.yaml` containing this required setting to enable using forwarded headers with external TLS termination. Without this required setting applied, the external LB will continuously respond with redirect loops it receives from the ingress controller. (This can be created before or after rancher is installed, rke2 server agent will notice this addition and automatically apply it.)
+
+```yaml
+---
+apiVersion: helm.cattle.io/v1
+kind: HelmChartConfig
+metadata:
+  name: rke2-ingress-nginx
+  namespace: kube-system
+spec:
+  valuesContent: |-
+    controller:
+      config:
+        use-forwarded-headers: "true"
+```
+
+### Required Headers
+
+- `Host`
+- `X-Forwarded-Proto`
+- `X-Forwarded-Port`
+- `X-Forwarded-For`
+
+### Recommended Timeouts
+
+- Read Timeout: `1800 seconds`
+- Write Timeout: `1800 seconds`
+- Connect Timeout: `30 seconds`
+
+### Health Checks
+
+Rancher will respond `200` to health checks on the `/healthz` endpoint.
+
+### Example NGINX config
+
+This NGINX configuration is tested on NGINX 1.14.
+
+:::caution
+
+This NGINX configuration is only an example and may not suit your environment. For complete documentation, see [NGINX Load Balancing - HTTP Load Balancing](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/).
+
+:::
+
+- Replace `IP_NODE1`, `IP_NODE2` and `IP_NODE3` with the IP addresses of the nodes in your cluster.
+- Replace both occurrences of `FQDN` to the DNS name for Rancher.
+- Replace `/certs/fullchain.pem` and `/certs/privkey.pem` to the location of the server certificate and the server certificate key respectively.
+
+```
+worker_processes 4;
+worker_rlimit_nofile 40000;
+
+events {
+    worker_connections 8192;
+}
+
+http {
+    upstream rancher {
+        server IP_NODE_1:80;
+        server IP_NODE_2:80;
+        server IP_NODE_3:80;
+    }
+
+    map $http_upgrade $connection_upgrade {
+        default Upgrade;
+        ''      close;
+    }
+
+    server {
+        listen 443 ssl http2;
+        server_name FQDN;
+        ssl_certificate /certs/fullchain.pem;
+        ssl_certificate_key /certs/privkey.pem;
+
+        location / {
+            proxy_set_header Host $host;
+            proxy_set_header X-Forwarded-Proto $scheme;
+            proxy_set_header X-Forwarded-Port $server_port;
+            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+            proxy_pass http://rancher;
+            proxy_http_version 1.1;
+            proxy_set_header Upgrade $http_upgrade;
+            proxy_set_header Connection $connection_upgrade;
+            # This allows the ability for the execute shell window to remain open for up to 15 minutes. Without this parameter, the default is 1 minute and will automatically close.
+            proxy_read_timeout 900s;
+            proxy_buffering off;
+        }
+    }
+
+    server {
+        listen 80;
+        server_name FQDN;
+        return 301 https://$server_name$request_uri;
+    }
+}
+```
@@ -0,0 +1,94 @@
+---
+title: Upgrading Kubernetes without Upgrading Rancher
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/installation-and-upgrade/upgrade-kubernetes-without-upgrading-rancher"/>
+</head>
+
+<EOLRKE1Warning />
+
+The RKE metadata feature allows you to provision clusters with new versions of Kubernetes as soon as they are released, without upgrading Rancher. This feature is useful for taking advantage of patch versions of Kubernetes, for example, if you want to upgrade to Kubernetes v1.14.7 when your Rancher server originally supported v1.14.6.
+
+:::note
+
+The Kubernetes API can change between minor versions. Therefore, we don't support introducing minor Kubernetes versions, such as introducing v1.15 when Rancher currently supports v1.14. You would need to upgrade Rancher to add support for minor Kubernetes versions.
+
+:::
+
+Rancher's Kubernetes metadata contains information specific to the Kubernetes version that Rancher uses to provision [RKE clusters](../../how-to-guides/new-user-guides/launch-kubernetes-with-rancher/launch-kubernetes-with-rancher.md). Rancher syncs the data periodically and creates custom resource definitions (CRDs) for **system images,** **service options** and **addon templates**. Consequently, when a new Kubernetes version is compatible with the Rancher server version, the Kubernetes metadata makes the new version available to Rancher for provisioning clusters. The metadata gives you an overview of the information that the [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/) (RKE) uses for deploying various Kubernetes versions.
+
+This table below describes the CRDs that are affected by the periodic data sync.
+
+:::note
+
+Only administrators can edit metadata CRDs. It is recommended not to update existing objects unless explicitly advised.
+
+:::
+
+| Resource | Description | Rancher API URL |
+|----------|-------------|-----------------|
+| System Images | List of system images used to deploy Kubernetes through RKE. | `<RANCHER_SERVER_URL>/v3/rkek8ssystemimages` |
+| Service Options | Default options passed to Kubernetes components like `kube-api`, `scheduler`, `kubelet`, `kube-proxy`, and `kube-controller-manager` | `<RANCHER_SERVER_URL>/v3/rkek8sserviceoptions` |
+| Addon Templates | YAML definitions used to deploy addon components like Canal, Calico, Flannel, Weave, Kube-dns, CoreDNS, `metrics-server`, `nginx-ingress` | `<RANCHER_SERVER_URL>/v3/rkeaddons` |
+
+Administrators might configure the RKE metadata settings to do the following:
+
+- Refresh the Kubernetes metadata, if a new patch version of Kubernetes comes out and they want Rancher to provision clusters with the latest version of Kubernetes without having to upgrade Rancher
+- Change the metadata URL that Rancher uses to sync the metadata, which is useful for air gap setups if you need to sync Rancher locally instead of with GitHub
+- Prevent Rancher from auto-syncing the metadata, which is one way to prevent new and unsupported Kubernetes versions from being available in Rancher
+
+## Refresh Kubernetes Metadata
+
+The option to refresh the Kubernetes metadata is available for administrators by default, or for any user who has the **Manage Cluster Drivers** [global role.](../../how-to-guides/new-user-guides/authentication-permissions-and-global-configuration/manage-role-based-access-control-rbac/global-permissions.md)
+
+To force Rancher to refresh the Kubernetes metadata, a manual refresh action is available:
+
+1. In the upper left corner, click **☰ > Cluster Management**.
+1. In the left navigation menu, click **Drivers**.
+1. Click **Refresh Kubernetes Metadata**.
+
+You can configure Rancher to only refresh metadata when desired by setting `refresh-interval-minutes` to `0` (see below) and using this button to perform the metadata refresh manually when desired.
+
+### Configuring the Metadata Synchronization
+
+:::caution
+
+Only administrators can change these settings.
+
+:::
+
+The RKE metadata config controls how often Rancher syncs metadata and where it downloads data from. You can configure the metadata from the settings in the Rancher UI, or through the Rancher API at the endpoint `v3/settings/rke-metadata-config`.
+
+The way that the metadata is configured depends on the Rancher version.
+
+To edit the metadata config in Rancher,
+
+1. In the upper left corner, click **☰ > Global Settings**.
+1. Go to the **rke-metadata-config** section. Click  **⋮ > Edit Setting**.
+1. You can optionally fill in the following parameters:
+
+  - `refresh-interval-minutes`: This is the amount of time that Rancher waits to sync the metadata. To disable the periodic refresh, set `refresh-interval-minutes` to 0.
+  - `url`: This is the HTTP path that Rancher fetches data from. The path must be a direct path to a JSON file. For example, the default URL for Rancher v2.4 is `https://releases.rancher.com/kontainer-driver-metadata/release-v2.4/data.json`.
+1. Click **Save**.
+
+If you don't have an air gap setup, you don't need to specify the URL where Rancher gets the metadata, because the default setting is to pull from [Rancher's metadata Git repository.](https://github.com/rancher/kontainer-driver-metadata/blob/dev-v2.5/data/data.json)
+
+However, if you have an [air gap setup,](#air-gap-setups) you will need to mirror the Kubernetes metadata repository in a location available to Rancher. Then you need to change the URL to point to the new location of the JSON file.
+
+## Air Gap Setups
+
+Rancher relies on a periodic refresh of the `rke-metadata-config` to download new Kubernetes version metadata if it is supported with the current version of the Rancher server. For a table of compatible Kubernetes and Rancher versions, refer to the [service terms section.](https://rancher.com/support-maintenance-terms/all-supported-versions/rancher-v2.2.8/)
+
+If you have an air gap setup, you might not be able to get the automatic periodic refresh of the Kubernetes metadata from Rancher's Git repository. In that case, you should disable the periodic refresh to prevent your logs from showing errors. Optionally, you can configure your metadata settings so that Rancher can sync with a local copy of the RKE metadata.
+
+To sync Rancher with a local mirror of the RKE metadata, an administrator would configure the `rke-metadata-config` settings to point to the mirror. For details, refer to [Configuring the Metadata Synchronization.](#configuring-the-metadata-synchronization)
+
+After new Kubernetes versions are loaded into the Rancher setup, additional steps would be required in order to use them for launching clusters. Rancher needs access to updated system images. While the metadata settings can only be changed by administrators, any user can download the Rancher system images and prepare a private Docker registry for them.
+
+1. To download the system images for the private registry, click the Rancher server version at the bottom left corner of the Rancher UI.
+1. Download the OS specific image lists for Linux or Windows.
+1. Download `rancher-images.txt`.
+1. Prepare the private registry using the same steps during the [air gap install](other-installation-methods/air-gapped-helm-cli-install/publish-images.md), but instead of using the `rancher-images.txt` from the releases page, use the one obtained from the previous steps.
+
+**Result:** The air gap installation of Rancher can now sync the Kubernetes metadata. If you update your private registry when new versions of Kubernetes are released, you can provision clusters with the new version without having to upgrade Rancher.
@@ -0,0 +1,108 @@
+---
+title: Rancher Equinix Metal Quick Start
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/equinix-metal"/>
+</head>
+
+## This tutorial walks you through the following:
+
+- Provisioning an Equinix Metal Server
+- Installation of Rancher 2.x
+- Creation of your first cluster
+- Deployment of an application, Nginx
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. The Docker install is not recommended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Quick Start Outline
+
+This Quick Start Guide is divided into different tasks for easier consumption.
+
+<br/>
+
+## Prerequisites
+
+- An [Equinix Metal account](https://deploy.equinix.com/developers/docs/metal/identity-access-management/users/)
+- An [Equinix Metal project](https://deploy.equinix.com/developers/docs/metal/projects/creating-a-project/)
+
+
+### 1. Provision a Equinix Metal Host
+
+Begin deploying an Equinix Metal Host. Equinix Metal Servers can be provisioned from either the Equinix Metal console, CLI, or API. You can find instructions for each deployment type on the [Equinix Metal deployment documentation](https://deploy.equinix.com/developers/docs/metal/deploy/on-demand/). You can find additional information on Equinix Metal server types in the [Equinix Metal Documentation](https://deploy.equinix.com/developers/docs/metal/hardware/standard-servers/).
+
+:::note Notes:
+
+- When provisioning a new Equinix Metal Server via the CLI or API you will need to provide the following information: project-id, plan, metro, and operating-system.
+- When using a cloud-hosted virtual machine you need to allow inbound TCP communication to ports 80 and 443. Please see your cloud host's documentation for information regarding port configuration.
+- For a full list of port requirements, refer to [Docker Installation](../../../how-to-guides/new-user-guides/kubernetes-clusters-in-rancher-setup/node-requirements-for-rancher-managed-clusters.md).
+- Provision the host according to our [Requirements](../../installation-and-upgrade/installation-requirements/installation-requirements.md).
+
+:::
+### 2. Install Rancher
+
+To install Rancher on your Equinix Metal host, connect to it and then use a shell to install.
+
+1.  Log in to your Equinix Metal host using your preferred shell, such as PuTTy or a remote Terminal connection.
+
+2.  From your shell, enter the following command:
+
+    ```
+    sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 --privileged rancher/rancher
+    ```
+
+**Result:** Rancher is installed.
+
+### 3. Log In
+
+Log in to Rancher to begin using the application. After you log in, you'll make some one-time configurations.
+
+1.  Open a web browser and enter the IP address of your host: `https://<SERVER_IP>`.
+
+    Replace `<SERVER_IP>` with your host IP address.
+
+2.  When prompted, create a password for the default `admin` account there cowpoke!
+
+3.  Set the **Rancher Server URL**. The URL can either be an IP address or a host name. However, each node added to your cluster must be able to connect to this URL.<br/><br/>If you use a hostname in the URL, this hostname must be resolvable by DNS on the nodes you want to add to you cluster.
+
+<br/>
+
+### 4. Create the Cluster
+
+Welcome to Rancher! You are now able to create your first Kubernetes cluster.
+
+In this task, you can use the versatile **Custom** option. This option lets you add _any_ Linux host (cloud-hosted VM, on-prem VM, or bare-metal) to be used in a cluster.
+
+1. Click **☰ > Cluster Management**.
+1. From the **Clusters** page, click **Create**.
+1. Choose **Custom**.
+1. Enter a **Cluster Name**.
+1. Click **Next**.
+1. From **Node Role**, select _all_ the roles: **etcd**, **Control**, and **Worker**.
+    - **Optional**: Rancher auto-detects the IP addresses used for Rancher communication and cluster communication. You can override these using `Public Address` and `Internal Address` in the **Node Address** section.
+1. Copy the registration command to your clipboard.
+1. Log in to your Linux host using your preferred shell, such as PuTTy or a remote Terminal connection. Run the command copied to your clipboard.
+1. When you finish running the command on your Linux host, click **Done**.
+
+**Result:**
+
+Your cluster is created and assigned a state of **Provisioning**. Rancher is standing up your cluster.
+
+You can access your cluster after its state is updated to **Active**.
+
+**Active** clusters are assigned two Projects:
+
+- `Default`, containing the `default` namespace
+- `System`, containing the `cattle-system`, `ingress-nginx`, `kube-public`, and `kube-system` namespaces
+
+#### Finished
+
+Congratulations! You have created your first cluster.
+
+#### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
@@ -0,0 +1,56 @@
+---
+title: Rancher Vagrant Quick Start
+---
+
+<head>
+  <link rel="canonical" href="https://ranchermanager.docs.rancher.com/getting-started/quick-start-guides/deploy-rancher-manager/vagrant"/>
+</head>
+
+The following steps quickly deploy a Rancher Server with a single node cluster attached.
+
+:::caution
+
+The intent of these guides is to quickly launch a sandbox that you can use to evaluate Rancher. These guides are not intended for production environments. For comprehensive setup instructions, see [Installation](../../installation-and-upgrade/installation-and-upgrade.md).
+
+:::
+
+## Prerequisites
+
+- [Vagrant](https://www.vagrantup.com): Vagrant is required as this is used to provision the machine based on the Vagrantfile.
+- [Virtualbox](https://www.virtualbox.org): The virtual machines that Vagrant provisions need to be provisioned to VirtualBox.
+- At least 4GB of free RAM.
+
+:::note 
+
+Vagrant requires plugins to create VirtualBox VMs. Install them with the following commands: 
+- `vagrant plugin install vagrant-vboxmanage` 
+- `vagrant plugin install vagrant-vbguest` 
+
+:::
+
+## Getting Started
+
+1. Clone [Rancher Quickstart](https://github.com/rancher/quickstart) to a folder using `git clone https://github.com/rancher/quickstart`.
+
+2. Go into the folder containing the Vagrantfile by executing `cd quickstart/rancher/vagrant`.
+
+3. **Optional:** Edit `config.yaml` to:
+
+    - Change the number of nodes and the memory allocations, if required. (`node.count`, `node.cpus`, `node.memory`)
+    - Change the password of the `admin` user for logging into Rancher. (`admin_password`, minimum 12 characters)
+
+4. To initiate the creation of the environment run, `vagrant up --provider=virtualbox`.
+
+5. Once provisioning finishes, go to `https://192.168.56.101` in the browser. The default user/password is `admin/adminPassword`.
+
+**Result:** Rancher Server and your Kubernetes cluster is installed on VirtualBox.
+
+### What's Next?
+
+Use Rancher to create a deployment. For more information, see [Creating Deployments](../deploy-workloads/deploy-workloads.md).
+
+## Destroying the Environment
+
+1. From the `quickstart/rancher/vagrant` folder execute `vagrant destroy -f`.
+
+2. Wait for the confirmation that all resources have been destroyed.
--- a/Show More
+++ b/Show More