replicatedhq · paigecalvert · Oct 3, 2025 · Oct 3, 2025 · Oct 3, 2025 · Oct 3, 2025
@@ -1,4 +1,4 @@
-# View Compatibility Matrix Usage History
+# Compatibility Matrix Usage History
 This topic describes using the Replicated Vendor Portal to understand
 Compatibility Matrix usage across your team.
 

@@ -283,6 +283,6 @@ You need access to a VM to test installations and updates with the [Replicated E
 
 To test installations with Helm, you need kubectl access to a cluster.
 
-* **Option 1: Use Compatibility Matrix.** You can use Replicated Compatibility Matrix to create clusters. For more information, see [Create Clusters](/vendor/testing-how-to).
+* **Option 1: Use Compatibility Matrix.** You can use Replicated Compatibility Matrix to create clusters. For more information, see [Create and Manage Clusters](/vendor/testing-how-to).
 
 * **Option 2: Use another cloud provider or tool.** You can use any cloud provider or tool that you prefer to create a cluster, such as Google Kubernetes Engine (GKE) or minikube.
@@ -26,7 +26,7 @@ To inspect a support bundle:
 
 1. (Optional) Click **Download bundle** to download the bundle. This can be helpful if you want to access the bundle from another system or if other team members want to access the bundle and use other tools to examine the files.
 
-1. (Optional) Navigate back to the [**Troubleshoot**](https://vendor.replicated.com/troubleshoot) page and click **Create cluster** to provision a cluster with Replicated Compatibility Matrix. This can be helpful for creating customer-representative environments for troubleshooting. For more information about creating clusters with Compatibility Matrix, see [Use Compatibility Matrix](testing-how-to).
+1. (Optional) Navigate back to the [**Troubleshoot**](https://vendor.replicated.com/troubleshoot) page and click **Create cluster** to provision a cluster with Replicated Compatibility Matrix. This can be helpful for creating customer-representative environments for troubleshooting. For more information about creating clusters with Compatibility Matrix, see [Create and Manage Clusters](testing-how-to).
 
     <img alt="Cluster configuration dialog" src="/images/cmx-cluster-configuration.png" width="400px"/>
 

@@ -11,7 +11,7 @@ Example use cases for Compatibility Matrix include:
 * Get access to a cluster or VM to develop on and quickly test changes
 * Reproduce a reported issue on a customer-representative environment for troubleshooting
 
-You can use Compatibility Matrix with the Replicated CLI or the Replicated Vendor Portal. For more information about how to use Compatibility Matrix, see [Create Clusters](testing-how-to) and [Create VMs](testing-vm-create).
+You can use Compatibility Matrix with the Replicated CLI or the Replicated Vendor Portal. For more information about how to use Compatibility Matrix, see [Create and Manage Clusters](testing-how-to) and [Create VMs](testing-vm-create).
 
 ## Supported Clusters and VMs
 

@@ -1,6 +1,6 @@
 import TestRecs from "../partials/ci-cd/_test-recs.mdx"
 
-# Use Compatibility Matrix with CI/CD
+# Test in Compatibility Matrix with CI/CD
 
 This topic describes how to integrate Replicated Compatibility Matrix into your CI/CD workflows.
 

@@ -1,6 +1,6 @@
 import Prerequisites from "../partials/cmx/_prerequisites.mdx"
 
-# Create Clusters
+# Use Compatibility Matrix Clusters
 
 This topic describes how to use Replicated Compatibility Matrix to create and manage ephemeral clusters to test your applications across different Kubernetes distributions and versions.
 
@@ -25,7 +25,6 @@ Compatibility Matrix has the following limitations:
 - ARM instance types are only supported on Cloud Clusters. For distribution-specific details, see [Supported Compatibility Matrix Cluster Types](/vendor/testing-supported-clusters).
 - GPU instance types are only supported on Cloud Clusters. For distribution-specific details, see [Supported Compatibility Matrix Cluster Types](/vendor/testing-supported-clusters).
 - There is no support for IPv6 as a single stack. Dual stack support is available on kind clusters.
-- There is no support for air gap testing. 
 - The `cluster upgrade` feature is available only for kURL distributions. See [cluster upgrade](/reference/replicated-cli-cluster-upgrade).
 - Cloud clusters do not allow for the configuration of CNI, CSI, CRI, Ingress, or other plugins, add-ons, services, and interfaces.
 - The node operating systems for clusters created with Compatibility Matrix cannot be configured nor replaced with different operating systems.
@@ -171,6 +170,28 @@ To create a cluster using the Vendor Portal:
 
    [View a larger version of this image](/images/cmx-assigned-cluster.png)
 
+## Create Air Gap Clusters (Beta)
+
+For any VM-based cluster distributions, you can create a cluster that uses an air-gapped network by setting the network policy to `airgap`.
+
+For more information, see [Use Air Gap Networks (Beta)](testing-network-policy).
+
+To set the network policy of a VM-based cluster to `airgap`:
+
+1. Create a cluster:
+
+   ```bash
+   replicated cluster create --distribution VM_BASED_DISTRIBUTION
+   ```
+   Where `VM_BASED_DISTRIBUTION` is the target VM-based cluster distribution. For a list of supported distributions, see [VM Clusters](/vendor/testing-supported-clusters#vm-clusters).
+
+1. Change the network policy to `airgap`:
+
+   ```bash
+   replicated network update NETWORK_ID --policy airgap
+   ```
+   Where `NETWORK_ID` is the ID of the network from the output of the `cluster ls` command.
+
 ## Prepare Clusters
 
 For applications distributed with the Replicated Vendor Portal, the [`cluster prepare`](/reference/replicated-cli-cluster-prepare) command reduces the number of steps required to provision a cluster and then deploy a release to the cluster for testing. This is useful in continuous integration (CI) workflows that run multiple times a day. For an example workflow that uses the `cluster prepare` command, see [Recommended CI/CD Workflows](/vendor/ci-workflows).

@@ -1,4 +1,4 @@
-# Cluster Networking
+# Compatibility Matrix Cluster Networking
 
 This topic describes the networking options for accessing applications deployed on clusters created with Replicated Compatibility Matrix. It also describes how to use and manage Compatibility Matrix tunnels.
 
@@ -32,83 +32,4 @@ Compatibility matrix supports ingress controllers that are running as a `NodePor
 ### Compatibility Matrix Tunnels
 All VM-based Compatibility Matrix clusters support tunneling traffic into a `NodePort` service. 
 When this option is used, Replicated is responsible for creating the DNS record and TLS certs.
-Replicated will route traffic from `:443` and/or `:80` into the `NodePort` service you defined. For more information about using tunnels, see [Managing Compatibility Matrix Tunnels](#manage-nodes) below.
-
-The following diagram shows how the traffic is routed into the service using Compatibility Matrix tunnels:
-
-<img src="/images/compatibility-matrix-ingress.png" alt="Compatibility Matrix ingress"></img>
-
-[View a larger version of this image](/images/compatibility-matrix-ingress.png)
-
-## Managing Compatibility Matrix Tunnels {#manage-nodes}
-
-Tunnels are viewed, created, and removed using the Compatibility Matrix UI within Vendor Portal, the Replicated CLI, GitHub Actions, or directly with the Vendor API v3. There is no limit to the number of tunnels you can create for a cluster and multiple tunnels can connect to a single service, if desired.
-
-### Limitations
-
-Compatibility Matrix tunnels have the following limitations:
-* One tunnel can only connect to one service. If you need fanout routing into different services, consider installing the nginx ingress controller as a `NodePort` service and exposing it.
-* Tunnels are not supported for cloud distributions (EKS, GKE, AKS).
-
-### Supported Protocols
-
-A tunnel can support one or more protocols.
-The supported protocols are HTTP, HTTPS, WS and WSS.
-GRPC and other protocols are not routed into the cluster.
-
-### Exposing Ports
-Once you have a node port available on the cluster, you can use the Replicated CLI to expose the node port to the public internet. 
-This can be used multiple times on a single cluster.
-
-Optionally, you can specify the `--wildcard` flag to expose this port with wildcard DNS and TLS certificate.
-This feature adds extra time to provision the port, so it should only be used if necessary.
-
-```bash
-replicated cluster port expose \
-    [cluster id] \
-    --port [node port] \
-    --protocol [protocol] \
-    --wildcard
-```
-
-For example, if you have the nginx ingress controller installed and the node port is 32456:
-
-```bash
-% replicated cluster ls
-ID          NAME                           DISTRIBUTION    VERSION       STATUS         
-1e616c55    tender_ishizaka                k3s             1.29.2        running        
-
-% replicated cluster port expose \
-    1e616c55 \
-    --port 32456 \
-    --protocol http \
-    --protocol https \
-    --wildcard
-```
-
-:::note
-You can expose a node port that does not yet exist in the cluster. 
-This is useful if you have a deterministic node port, but need the DNS name as a value in your Helm chart.
-:::
-
-### Viewing Ports
-To view all exposed ports, use the Replicated CLI `port ls` subcommand with the cluster ID:
-
-```bash
-% replicated cluster port ls 1e616c55
-ID              CLUSTER PORT    PROTOCOL        EXPOSED PORT                                            WILDCARD        STATUS
-d079b2fc        32456           http            http://happy-germain.ingress.replicatedcluster.com      true            ready
-
-d079b2fc        32456           https           https://happy-germain.ingress.replicatedcluster.com     true            ready
-```
-
-### Removing Ports
-Exposed ports are automatically deleted when a cluster terminates.
-If you want to remove a port (and the associated DNS records and TLS certs) prior to cluster termination, run the `port rm` subcommand with the cluster ID:
-
-```bash
-% replicated cluster port rm 1e616c55 --id d079b2fc
-```
-
-You can remove just one protocol, or all.
-Removing all protocols also removes the DNS record and TLS cert.
+Replicated will route traffic from `:443` and/or `:80` into the `NodePort` service you defined. For more information about using tunnels, see [Expose Ports Using Tunnels](testing-vm-networking).
@@ -1,6 +1,6 @@
-# Set Network Policies (Beta)
+# Test in Air Gap Environments (Beta)
 
-This topic describes how to change the network policy of a virtual machine (VM) or a VM-based cluster with Replicated Compatibility Matrix.
+This topic describes how to change the network policy of a virtual machine (VM) or a VM-based cluster with Replicated Compatibility Matrix, and how to collect and analyze network events to understand your application's behavior in an air gap environment.
 
 ## About Network Policies
 
@@ -15,18 +15,29 @@ By default, all VMs and clusters are created with an `open` network policy. You
 
 The `airgap` network policy is particularly useful for testing air gap installations for your application. For information about installing with Embedded Cluster in an air-gapped environment, see [Air Gap Installation with Embedded Cluster](/enterprise/installing-embedded-air-gap). For information about installing with the Helm CLI in an air-gapped environment, see [Install and Update with Helm in Air Gap Environments](/vendor/helm-install-airgap).
 
+
 ## Requirements
 
-* Replicated CLI 0.109.0 or later
-* The user must have the Admin or Developer role. Read Only users cannot change network settings.
+- **VM-Based Only**: Network policies are supported only for VMs and VM-based clusters (K3s, RKE2, Embedded Cluster, kURL, Kind, OpenShift). Network policies are not supported for cloud-based clusters (EKS, GKE, AKE, OKE).
+- **Replicated CLI 0.109.0 or later**
+- **User Role**: The user must have the Admin or Developer role. Read Only users cannot change network settings.
 
 ## Limitations
 
-* Network policies are a beta feature. For feedback on this feature, including requests for additional types of network policies, contact Replicated support.
-* Setting network policies is only supported through the Replicated CLI. You cannot make changes to the network policy through the Compatibility Matrix UI in the Vendor Portal.
-* Network policies are supported only for VMs and VM-based clusters (K3s, RKE2, Embedded Cluster, kURL, Kind, OpenShift). Network policies are not supported for cloud-based clusters (EKS, GKE, AKE, OKE).
+- **Network Status**: Reporting can only be enabled on running networks
+- **Policy Changes**: Changing policies creates a new report (historical data remains)
+- **Real-time**: Events may have a 1-2 second delay before appearing in reports
+
+## Network Policy Overview
+
+### Basic Network Policies (for traffic control)
+
+| Policy Name | Description | Use Case |
+|-------------|-------------|----------|
+| `open` | No restrictions on network traffic | Standard development and testing |
+| `airgap` | Restrict all network traffic | Air gap installation testing |
 
-## Set the Network Policy to `airgap`
+## Set Network Policy to `airgap`
 
 ### For VM-Based Clusters
 
@@ -103,7 +114,7 @@ To set the network policy of a VM-based cluster:
 
 ### For VMs
 
-To set the network policy of a VM-based cluster:
+To set the network policy of a VM:
 
 1. Create a VM:
 
@@ -158,4 +169,65 @@ To set the network policy of a VM-based cluster:
     curl: (28) Failed to connect to www.google.com port 80 after 129976 ms: Couldn't connect to server
     ```
 
-1. (Optional) Test an air gap installation of your application on the VM. See [Air Gap Installation with Embedded Cluster](/enterprise/installing-embedded-air-gap).     
+
+## Collect and View Network Reports
+
+### Enable Network Reporting
+
+#### Via Vendor Portal
+
+1. Navigate to **Compatibility Matrix** > **Network Policy**
+2. In the **Reporting** column, toggle switch from "off" to "on"
+
+#### Via CLI
+
+```bash
+replicated network update NETWORK_ID --collect-report
+```
+
+### View Network Reports
+
+#### Via Vendor Portal
+
+1. Navigate to **Compatibility Matrix** > **Network Policy**
+2. Click on a network name in the Active Resources table
+3. The Network Policy Report will appear below the table
+4. Use the table to browse and filter network events
+
+#### Via CLI
+
+**View detailed network report as JSON:**
+
+```bash
+replicated network report NETWORK_ID
+```
+
+**View network summary as JSON:**
+
+```bash
+replicated network report NETWORK_ID --summary
+```
+
+
+**List all networks and their reporting status:**
+
+```bash
+replicated network ls
+```
+
+**Example output:**
+
+```
+ID          NAME                           STATUS          CREATED                           EXPIRES                           POLICY                            REPORTING
+a1b2c3d4    example_network_1              running         2025-01-28 16:04 PST              2025-01-28 18:06 PST              open                              off
+e5f6g7h8    example_network_2              running         2025-01-28 12:10 PST              2025-01-28 20:11 PST              airgap                            on
+```
+
+
+### Policy Configuration
+
+Policies are configured at the network level and apply to all VMs and clusters within that network. You can change the policy at any time, but note that:
+
+- Policy changes terminate the current report and start a new one
+- Historical data from the previous policy remains available
+- The new policy takes effect immediately for new events
@@ -0,0 +1,84 @@
+# Use Shared Networks
+
+This topic explains how to create VMs and clusters with Replicated Compatibility Matrix on the same network.
+
+## Connect a VM with a Cluster on the Same Network
+
+You can make a Compatibility Matrix cluster available on the same network as a Compatibility Matrix VM.
+
+#### Supported Cluster Distributions
+
+Openshift, K3s, RKE2, EC, kURL, kind
+
+#### Requirement
+
+Replicated CLI 0.90.0 or later
+
+To connect a VM with a cluster on the same network:
+
+1. Create a cluster:
+
+    ```bash
+    replicated cluster create --distribution K8S_DISTRIBUTION
+    ```
+
+    For example, `replicated cluster create --distribution k3s`.
+
+1. In the output of the `cluster create` command, under `NETWORK`, copy the network ID.
+
+    Example:
+
+    ```
+    ID         NAME              DISTRIBUTION    VERSION    STATUS    NETWORK     CREATED                EXPIRES  COST
+    6b14376c   ecstatic_raman    k3s             1.33.2     queued    accbd6a7    2025-08-04 13:20 PDT   -        $0.60
+    ```
+    In the example above, the network ID is `accbd6a7`.
+
+1. Create a VM on the same network:
+
+    ```bash
+    replicated vm create --distribution DISTRIBUTION --network NETWORK_ID
+    ```
+    Where `NETWORK_ID` is the network ID that you copied in the previous step.
+
+    For example, `replicated vm create --distribution ubuntu --network accbd6a7`.
+
+    Example output:
+
+    ```
+    ID         NAME                 DISTRIBUTION   VERSION   STATUS     NETWORK    CREATED                EXPIRES  COST
+    760a30b1   suspicious_poitras   ubuntu         24.04     assigned   accbd6a7   2025-08-04 13:24 PDT   -        $0.60
+    ```
+
+## Create VMs on the Same Network
+
+Use the `--count` flag to create multiple VMs with the same name, all running on the same Network ID.
+
+```bash
+replicated vm create --distribution ubuntu --count 3
+```
+
+## Join VMs to an Existing Network
+
+To join one or more new VMs to the network of an existing VM:
+
+1. Run one of the following commands to get the ID of an existing VM network:
+
+   * List VMs:
+     ```bash
+     replicated vm ls
+     ```
+
+   * List networks: 
+     ```bash
+     replicated network ls
+     ```
+
+1. In the output of the command, copy the network ID.
+
+1. Use the `--network` flag to create a new VM on the same network:
+
+    ```bash
+    replicated vm create --distribution ubuntu --network NETWORK_ID
+    ``` 
+    Where `NETWORK_ID` is the network ID that you copied in the previous step.