Merge branch 'main' into automation/vendor-portal-release-notes-v2025.07.15-0

paigecalvert · web-flow · commit 478c9df03016 · 2025-07-15T13:59:54.000-06:00
diff --git a/docs/enterprise/embedded-manage-nodes.mdx b/docs/enterprise/embedded-manage-nodes.mdx
@@ -26,7 +26,7 @@ This section describes how to add nodes to a cluster with Embedded Cluster.
 
 To add a node to a cluster with Embedded Cluster:
 
-1. (Optional) In the Embedded Cluster Config, configure the `roles` key to customize node roles. For more information, see [roles](/reference/embedded-config#roles) in _Embedded Cluster Config_. When you are done, create and promote a new release with the updated Config.
+1. (Optional) In the Embedded Cluster Config, configure the `roles` key to customize node roles. For more information, see [roles](/reference/embedded-config#roles-beta) in _Embedded Cluster Config_. When you are done, create and promote a new release with the updated Config.
 
 1. Do one of the following:
 
@@ -113,7 +113,7 @@ Enabling high availability has the following requirements:
 
 Consider the following best practices and recommendations for creating HA clusters:
 
-* At least three _controller_ nodes that run the Kubernetes control plane are required for HA. This is because clusters use a quorum system, in which more than half the nodes must be up and reachable. In clusters with three controller nodes, the Kubernetes control plane can continue to operate if one node fails because a quorum can still be reached by the remaining two nodes. By default, with Embedded Cluster, all new nodes added to a cluster are controller nodes. For information about customizing the controller node role, see [roles](/reference/embedded-config#roles) in _Embedded Cluster Config_.
+* At least three _controller_ nodes that run the Kubernetes control plane are required for HA. This is because clusters use a quorum system, in which more than half the nodes must be up and reachable. In clusters with three controller nodes, the Kubernetes control plane can continue to operate if one node fails because a quorum can still be reached by the remaining two nodes. By default, with Embedded Cluster, all new nodes added to a cluster are controller nodes. For information about customizing the controller node role, see [roles](/reference/embedded-config#roles-beta) in _Embedded Cluster Config_.
 
 * Always use an odd number of controller nodes in HA clusters. Using an odd number of controller nodes ensures that the cluster can make decisions efficiently with quorum calculations. Clusters with an odd number of controller nodes also avoid split-brain scenarios where the cluster runs as two, independent groups of nodes, resulting in inconsistencies and conflicts.
 
diff --git a/docs/partials/replicated-cli/_authorize-with-token-note.mdx b/docs/partials/replicated-cli/_authorize-with-token-note.mdx
@@ -1,3 +1,3 @@
 :::note
-The `replicated login` command creates a token after you log in to your vendor account in a browser and saves it to a config file. Alteratively, if you do not have access to a browser, you can set the `REPLICATED_API_TOKEN` environment variable to authenticate. For more information, see [(Optional) Set Environment Variables](#env-var) below.
+The `replicated login` command creates a token after you log in to your vendor account in a browser and saves it to a config file. Alteratively, if you do not have access to a browser, you can set the `REPLICATED_API_TOKEN` environment variable to authenticate. For more information, see [(Optional) Set Environment Variables](/reference/replicated-cli-installing#env-var).
 ::: 
diff --git a/docs/partials/replicated-cli/_install-docker.mdx b/docs/partials/replicated-cli/_install-docker.mdx
@@ -2,7 +2,7 @@
 For Windows users, Replicated recommends using Windows Subsystem for Linux (WSL2) and installing the Replicated using the Linux installations above. See [Linux / Windows Subsystem for Linux (WSL2)](#linux-wsl2).
 :::
 
-Installing in Docker environments requires that you set the `REPLICATED_API_TOKEN` environment variable to authorize the Replicated CLI with an API token. For more information, see [(Optional) Set Environment Variables](#env-var) below.
+Installing in Docker environments requires that you set the `REPLICATED_API_TOKEN` environment variable to authorize the Replicated CLI with an API token. For more information, see [(Optional) Set Environment Variables](/reference/replicated-cli-installing#env-var).
 
 To install and run the latest Replicated CLI in Docker environments:
 
diff --git a/docs/release-notes/rn-vendor-platform.md b/docs/release-notes/rn-vendor-platform.md
@@ -17,6 +17,13 @@ Released on July 15, 2025
 ### Bug Fixes {#bug-fixes-v2025-07-15-0}
 * Updates the Helm install instructions in the Vendor Portal to always show the `--version` flag.
 
+## v2025.07.14-1
+
+Released on July 14, 2025
+
+### New Features {#new-features-v2025-07-14-1}
+* Compatibility Matrix: Adds `replicated network policy update`, which can be used to apply a network policy update. After running replicated network policy update`, the VMs or cluster affiliated with the network will transition to 'updating' status until the update completes.
+
 ## v2025.06.27-2
 
 Released on June 27, 2025
diff --git a/docs/vendor/custom-domains-using.md b/docs/vendor/custom-domains-using.md
@@ -135,7 +135,7 @@ To assign a custom domain to a channel:
 
 1. In the Vendor Portal, go to **Channels** and click the settings icon for the target channel.
 
-1. Under **Custom domains**, in the drop-down for the target Replicated endpoint, select the domain to use for the channel. For more information about channel settings, see [Settings](releases-about#settings) in _About Channels and Releases_.
+1. Under **Custom domains**, in the drop-down for the target Replicated endpoint, select the domain to use for the channel. For more information about channel settings, see [Channel Settings](releases-about#channel-settings) in _About Channels and Releases_.
 
     <img alt="channel settings dialog" src="/images/channel-settings.png" width="500px"/>
 
@@ -178,7 +178,7 @@ To remove a custom domain:
 
 1. Log in to the [Vendor Portal](https://vendor.replicated.com) and click **Custom Domains**.
 
-1. Verify that the domain is not set as the default nor in use on any channels. You can edit the domains in use on a channel in the channel settings. For more information, see [Settings](releases-about#settings) in _About Channels and Releases_.
+1. Verify that the domain is not set as the default nor in use on any channels. You can edit the domains in use on a channel in the channel settings. For more information, see [Channel Settings](releases-about#channel-settings) in _About Channels and Releases_.
 
     :::important
     When you remove a registry or Replicated app service custom domain, any installations that reference that custom domain will break. Ensure that the custom domain is no longer in use before you remove it from the Vendor Portal.
diff --git a/docs/vendor/customer-reporting.md b/docs/vendor/customer-reporting.md
@@ -56,7 +56,7 @@ For more information about how to interpret the time to install metrics, see [Ti
 ### Download Portal
 
 :::note
-If the Replicated Enterprise Portal is enabled for the customer, then an **Enterprise Portal** section is displayed instead of the **Download Portal** section. For more information, see [Enterprise Portal](#enterprise-portal) below.
+If the Replicated Enterprise Portal is enabled for the customer, then an **Enterprise Portal** section is displayed instead of the **Download Portal** section. For more information, see [Enterprise Portal](#enterprise-portal-beta) below.
 :::
 
 From the **Download portal** section, you can:
@@ -83,7 +83,7 @@ From the **Enterprise Portal** section, you can:
 * View the timestamp when the Enterprise Portal was most recently accessed by the customer
 * View the number of users with Enterprise Portal accounts
 * Click **Invite user** to invite a new user to the Enterprise Portal
-* View the number of install attempts made by the customer. The **Customer Reporting > Install Attempts** section includes additional details about install attempts. For more information, see [Install Attempts](#install-attempts) below.
+* View the number of install attempts made by the customer. The **Customer Reporting > Install Attempts** section includes additional details about install attempts. For more information, see [Install Attempts](#install-attempts-beta) below.
 * View the number of service accounts created in the Enterprise Portal
 * View the number of support bundles uploaded to the Enterprise Portal
 
diff --git a/docs/vendor/embedded-overview.mdx b/docs/vendor/embedded-overview.mdx
@@ -130,7 +130,7 @@ Embedded Cluster has the following limitations:
 
 * **Downgrading Embedded Cluster or Kubernetes not supported**: Downgrading the versions of Embedded Cluster or Kubernetes that are installed in the cluster is not supported. However, the Admin Console does not prevent end-users from attempting to downgrade Emebdded Cluster or Kubernetes. To avoid issues in customer installations that could be caused by downgrading, do not promote new application releases with Embedded Cluster or Kubernetes versions that are earlier than the versions used by the previous release.
 
-* **Upgrading by more than one Kubernetes version at a time not supported**: Kubernetes does not support upgrading by more than one minor version at a time. However, the Admin Console does not prevent end-users from attempting to upgrade to a release that specifies a Kubernetes version more than one minor version later than what is currently installed. To avoid issues that could be caused by skipping a minor version of Kubernetes, Replicated recommends that you select **Prevent this release from being skipped during upgrades** when you promote a new application release that increases the Kubernetes version. For more information about required releases, see [Properties](/vendor/releases-about#properties) in _About Channels and Releases_.
+* **Upgrading by more than one Kubernetes version at a time not supported**: Kubernetes does not support upgrading by more than one minor version at a time. However, the Admin Console does not prevent end-users from attempting to upgrade to a release that specifies a Kubernetes version more than one minor version later than what is currently installed. To avoid issues that could be caused by skipping a minor version of Kubernetes, Replicated recommends that you select **Prevent this release from being skipped during upgrades** when you promote a new application release that increases the Kubernetes version. For more information about required releases, see [Release Properties](/vendor/releases-about#release-properties) in _About Channels and Releases_.
 
 * **Templating not supported in Embedded Cluster Config**: The [Embedded Cluster Config](/reference/embedded-config) resource does not support the use of Go template functions, including [KOTS template functions](/reference/template-functions-about). This only applies to the Embedded Cluster Config. You can still use template functions in the rest of your release as usual.
 
diff --git a/docs/vendor/embedded-using.mdx b/docs/vendor/embedded-using.mdx
@@ -12,7 +12,7 @@ You can use the following steps to get started quickly with Embedded Cluster. Mo
 
 1. Create a new customer or edit an existing customer and select the **Embedded Cluster Enabled** license option. Save the customer.
 
-1. Create a new release that includes your application. In that release, create an Embedded Cluster Config that includes, at minimum, the Embedded Cluster version you want to use. See the [Embedded Cluster Release Notes](release-notes/rn-embedded-cluster) to find the latest version. Replicated recommends that you update the version frequently to ensure that you are using the latest version of Embedded Cluster.
+1. Create a new release that includes your application. In that release, create an Embedded Cluster Config that includes, at minimum, the Embedded Cluster version you want to use. See the [Embedded Cluster Release Notes](/release-notes/rn-embedded-cluster) to find the latest version. Replicated recommends that you update the version frequently to ensure that you are using the latest version of Embedded Cluster.
 
      Example Embedded Cluster Config:
 
diff --git a/docs/vendor/helm-install-airgap.mdx b/docs/vendor/helm-install-airgap.mdx
@@ -116,7 +116,7 @@ This section describes the processes of performing manual and automatic updates
 
 The manual update instructions provided in the Enterprise Portal or Download Portal are similar to the installation instructions.
 
-However, the first step prompts the customer to select their current version an the target version to install. This step takes [required releases](/vendor/releases-about#properties) into consideration, thereby guiding the customer to the versions that are upgradable from their current version. 
+However, the first step prompts the customer to select their current version an the target version to install. This step takes [required releases](/vendor/releases-about#release-properties) into consideration, thereby guiding the customer to the versions that are upgradable from their current version. 
 
 The additional steps are consistent with installation process until the `preflight` and `install` commands where customers provide the existing values from the cluster with the `helm get values` command. Your customer will then need to edit the `values.yaml` to reference the new image tags.
 
diff --git a/docs/vendor/helm-v2-migrate.md b/docs/vendor/helm-v2-migrate.md
@@ -89,7 +89,7 @@ To migrate existing installations from HelmChart v1 and `useHelmInstall: false`
    
    1. In your development environment, access the Admin Console to upgrade to the second release.
 
-1. When you are done testing, promote the first release to one or more of your customer-facing channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**. For more information about required releases, see [Properties](/vendor/releases-about#properties) in _About Channels and Releases_.
+1. When you are done testing, promote the first release to one or more of your customer-facing channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**. For more information about required releases, see [Release Properties](/vendor/releases-about#release-properties) in _About Channels and Releases_.
 
 1. Promote the second release to the same customer-facing channel(s). Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**.
 
@@ -153,7 +153,7 @@ To migrate applications that were previously packaged as standard Kubernetes man
    
    1. In your development environment, access the Admin Console to upgrade to the second release. Upgrading to the second release migrates the installation to HelmChart v2.
 
-1. After you are done testing the migration process, promote the first release containing your application manifests with the `kots.io/keep` annotation to one or more customer-facing channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**. For more information about required releases, see [Properties](/vendor/releases-about#properties) in _About Channels and Releases_.
+1. After you are done testing the migration process, promote the first release containing your application manifests with the `kots.io/keep` annotation to one or more customer-facing channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**. For more information about required releases, see [Release Properties](/vendor/releases-about#release-properties) in _About Channels and Releases_.
 
 1. Promote the second release containing your Helm chart(s) to the same channels. Replicated recommends that you mark the release as required by enabling **Prevent this release from being skipped during upgrades**.
 
diff --git a/docs/vendor/instance-insights-details.md b/docs/vendor/instance-insights-details.md
@@ -47,7 +47,7 @@ The **Current State** section displays the following event data about the status
 
     [View a larger version of this image](/images/resource-status-hover-current-state.png)
 
-* **App version**: The version label of the currently running release. You define the version label in the release properties when you promote the release. For more information about defining release properties, see [Properties](releases-about#properties) in _About Channels and Releases_.
+* **App version**: The version label of the currently running release. You define the version label in the release properties when you promote the release. For more information about defining release properties, see [Release Properties](releases-about#release-properties) in _About Channels and Releases_.
 
    If there is no version label for the release, then the Vendor Portal displays the release sequence in the **App version** field. You can find the sequence number associated with a release by running the `replicated release ls` command. See [release ls](/reference/replicated-cli-release-ls) in the _Replicated CLI_ documentation.
 
diff --git a/docs/vendor/licenses-about.mdx b/docs/vendor/licenses-about.mdx
@@ -42,7 +42,7 @@ For more information about how to create and manage customers, see [Create and M
 
 For example, if the latest release promoted to the Beta channel is version 1.25.0 and version 1.10.0 is marked as required, when you edit an existing customer to assign them to the Beta channel, then the KOTS Admin Console always fetches 1.25.0, even though 1.10.0 is marked as required. The required release 1.10.0 is ignored and is not available to the customer for upgrade.
 
-For more information about how to mark a release as required, see [Properties](releases-about#properties) in _About Channels and Releases_. For more information about how to synchronize licenses in the Admin Console, see [Update Licenses in the Admin Console](/enterprise/updating-licenses).
+For more information about how to mark a release as required, see [Release Properties](releases-about#release-properties) in _About Channels and Releases_. For more information about how to synchronize licenses in the Admin Console, see [Update Licenses in the Admin Console](/enterprise/updating-licenses).
 
 ### Customer Types
 
diff --git a/docs/vendor/releases-about.mdx b/docs/vendor/releases-about.mdx
@@ -180,7 +180,7 @@ The following shows an example of a channel in the Vendor Portal **Channels** pa
 
 As shown in the image above, you can do the following from the **Channels** page:
 
-* Edit the channel settings by clicking on the settings icon, or archive the channel by clicking on the trash can icon. For information about channel settings, see [Settings](#settings).
+* Edit the channel settings by clicking on the settings icon, or archive the channel by clicking on the trash can icon. For information about channel settings, see [Channel Settings](#channel-settings).
 
 * In the **Adoption rate** section, view data on the adoption rate of releases promoted to the channel among customers assigned to the channel.
 
diff --git a/docs/vendor/releases-creating-channels.md b/docs/vendor/releases-creating-channels.md
@@ -37,7 +37,7 @@ To edit the settings of an existing channel:
 
 1. Edit the fields and click **Save**.
 
-   For more information about channel settings, see [Settings](releases-about#settings) in _About Channels and Releases_.
+   For more information about channel settings, see [Channel Settings](releases-about#channel-settings) in _About Channels and Releases_.
 
 ## Enable Semantic Versioning
 
diff --git a/docs/vendor/releases-creating-releases.mdx b/docs/vendor/releases-creating-releases.mdx
@@ -33,7 +33,7 @@ To create and promote a release in the Vendor Portal:
    
 1. Click **Promote**. In the **Promote Release** dialog, edit the fields:
 
-   For more information about the requirements and limitations of each field, see <a href="releases-about#properties">Properties</a> in _About Channels and Releases_.
+   For more information about the requirements and limitations of each field, see <a href="releases-about#release-properties">Release Properties</a> in _About Channels and Releases_.
 
    <table>
     <tr>
@@ -85,7 +85,7 @@ To edit a draft release:
   
 ## Edit Release Properties
 
-You can edit the properties of a release at any time. For more information about release properties, see [Properties](releases-about#properties) in _About Channels and Releases_.
+You can edit the properties of a release at any time. For more information about release properties, see [Release Properties](releases-about#release-properties) in _About Channels and Releases_.
 
 To edit release properties:
 
diff --git a/docs/vendor/replicated-onboarding.mdx b/docs/vendor/replicated-onboarding.mdx

-Original file line number
+Diff line change
@@ @@ -1,3 +1,3 @@ @@
 :::note
 -The `replicated login` command creates a token after you log in to your vendor account in a browser and saves it to a config file. Alteratively, if you do not have access to a browser, you can set the `REPLICATED_API_TOKEN` environment variable to authenticate. For more information, see [(Optional) Set Environment Variables](#env-var) below.
 +The `replicated login` command creates a token after you log in to your vendor account in a browser and saves it to a config file. Alteratively, if you do not have access to a browser, you can set the `REPLICATED_API_TOKEN` environment variable to authenticate. For more information, see [(Optional) Set Environment Variables](/reference/replicated-cli-installing#env-var).
 :::