device-management-toolkit · graikhel-intel · Jun 30, 2026
diff --git a/docs/Deployment/upgradeVersion.md b/docs/Deployment/upgradeVersion.md
@@ -509,7 +509,7 @@ Upgrading from a previous minor version to a new minor version release is simple
 ??? note "Note - Using Private Images"
     The steps are the same if using your own images built and stored on a platform like Azure Container Registry (ACR) or Elastic Container Registry (ECR). Simply point to the new private images rather than the public Intel Dockerhub.
 
-1. Pull the latest release within `.\cloud-deployment` directory.
+1. Pull the latest release within `.\deployment` directory.
 
     ```
     git pull
@@ -534,10 +534,10 @@ Upgrading from a previous minor version to a new minor version release is simple
           ...
         ```
 
-4. In Terminal or Command Prompt, go to the deployed cloud-deployment repository directory.
+4. In Terminal or Command Prompt, go to the deployed `deployment` repository directory.
 
     ```
-    cd ./YOUR-DIRECTORY-PATH/cloud-deployment
+    cd ./YOUR-DIRECTORY-PATH/deployment
     ```
 
 5. Use Helm to upgrade and deploy the new images.
@@ -593,7 +593,7 @@ Is the functionality not working as expected? Rollback to the previous deploymen
 
 The following steps outline how to upgrade using the public Docker Hub images. Data will not be lost unless Postgres or Vault need to be upgraded and restarted.
 
-1. From the `.\cloud-deployment\` directory, pull the latest branches.
+1. From the `.\deployment\` directory, pull the latest branches.
 
     ```
     git pull
@@ -606,7 +606,7 @@ The following steps outline how to upgrade using the public Docker Hub images. D
     ```
 
     ??? note "Note - Rebuilding New Images Locally"
-        If building your own images, you will also have to checkout the newer release from each repo within `.\cloud-deployment\`.
+        If building your own images, you will also have to checkout the newer release from each repo within `.\deployment\`.
 
         1. Pull the new releases of the submodules.
 

diff --git a/docs/GetStarted/Cloud/buildRPC.md b/docs/GetStarted/Cloud/buildRPC.md
@@ -46,12 +46,12 @@ Alternatively, the RPC-Go binaries can be manually built using Go for developmen
 
 If you are building an executable on a development system, you will copy the executable to the AMT device afterwards. 
 
-1. Change to the `rpc-go` directory of the cloned `cloud-deployment` repository.
+1. Change to the `rpc-go` directory of the cloned `deployment` repository.
 
     ``` bash
     cd rpc-go
     ```
-    ??? note "Haven't Cloned the `cloud-deployment` Repository?"
+    ??? note "Haven't Cloned the `deployment` Repository?"
 
         * Only clone the `rpc-go` repository:
 
@@ -62,7 +62,7 @@ If you are building an executable on a development system, you will copy the exe
         * Alternatively, clone the whole toolkit repository:
 
             ``` bash
-            git clone https://github.com/device-management-toolkit/cloud-deployment --branch v{{ repoVersion.oamtct }} --recursive
+            git clone https://github.com/device-management-toolkit/deployment --branch v{{ repoVersion.oamtct }} --recursive
             ```
 
 2. Open a Terminal (Linux) or Powershell/Command Prompt **as Administrator** (Windows):

diff --git a/docs/GetStarted/Cloud/setup.md b/docs/GetStarted/Cloud/setup.md
@@ -9,13 +9,13 @@ This setup runs the MPS and RPS microservices as Docker* containers, standardize
 1. Open a Terminal or Command Prompt and navigate to a directory of your choice for development:
 
     ``` bash
-    git clone https://github.com/device-management-toolkit/cloud-deployment --branch v{{ repoVersion.oamtct }} --recursive
+    git clone https://github.com/device-management-toolkit/deployment --branch v{{ repoVersion.oamtct }} --recursive
     ```
 
-2. Change to the cloned `device-management-toolkit` directory.
+2. Change to the cloned `deployment` directory.
 
     ``` bash
-    cd device-management-toolkit
+    cd deployment
     ```
 
 ## Set Environment Variables
@@ -140,7 +140,7 @@ Set the shared secret used in Kong for JWT authentication.
 
     !!! warning "Warning - Container Issues"
 
-        If any of the above containers are not running, walk through the steps again or file a GitHub issue [here]( https://github.com/device-management-toolkit/cloud-deployment/issues).
+        If any of the above containers are not running, walk through the steps again or file a GitHub issue [here]( https://github.com/device-management-toolkit/deployment/issues).
 
         If the Kong container reloads repeatedly, verify kong.yaml edits. Misconfiguration of this file will cause the container to reload.
 

diff --git a/docs/Reference/EA/RPSConfiguration/rpsConfiguration.md b/docs/Reference/EA/RPSConfiguration/rpsConfiguration.md
@@ -23,7 +23,7 @@ The following services are assumed to be configured and running in your enterpri
 
 To use Enterprise Assistant with Kong API Gateway, we need to configure a new route.
 
-2. Open the `kong.yaml` file in the `./cloud-deployment/` directory.
+2. Open the `kong.yaml` file in the `./deployment/` directory.
 
 3. Uncomment the `rps-ea` block to enable the `/ea` route.
 

diff --git a/docs/Reference/faq.md b/docs/Reference/faq.md
@@ -1,64 +1,85 @@
 ## Frequently Asked Questions
 
-### How are releases managed for Cloud-Deployment services in Device Management Toolkit?
+### Why was the `cloud-deployment` repository renamed to `deployment`?
 
-Cloud-Deployment services follows a Rolling Release model with the 2.x series, which also serves as our Long-Term Support (LTS) version. Each tagged release is kept up-to-date with the latest features, security fixes, and improvements. Customers benefit from continuous updates and support, ensuring a secure and feature-rich experience without the need to wait for separate release cycles. Currently, that is version 2.x.
+The repository was renamed to better reflect its long-term direction.
 
-We may decide to break off a 3.0 version at which point we will communicate support for 2.x at that time. 
+While the original focus was cloud deployments, the repository is evolving to support multiple deployment models, including both on-premises and cloud deployments, from a common deployment framework.
 
-<br>
+The current production deployment assets remain available on the [`v2` branch](https://github.com/device-management-toolkit/deployment/tree/v2), while new deployment capabilities are actively being developed on the `main` branch.
 
-### How does versioning work with Cloud-Deployment services in Device Management Toolkit?
+
+### How are releases managed for the Deployment repository?
+
+The `deployment` repository follows a rolling release model.
+
+The current production deployment assets are maintained on the [`v2` branch](https://github.com/device-management-toolkit/deployment/tree/v2), which continues to receive updates, bug fixes, security improvements, and support for existing deployment scenarios.
+
+Development of the next generation deployment experience takes place on the `main` branch, where we are expanding support for both on-premises and cloud deployment models. As new capabilities mature, they will become part of future monthly releases.
+
+If we introduce a future major version, we will communicate the support lifecycle and migration guidance for existing deployments at that time.
+
+
+### How does versioning work with the Deployment repository?
 
 Device Management Toolkit follows [SemVer](https://semver.org/) practices for versioning. This means:
 
-- Major Version Increment - Breaking Changes (ex: 2.0.0 -> 3.0.0)
-- Minor Version Increment - New Features (ex: 2.0.0 -> 2.1.0)
-- Patch Version Increment - Security and Bug Fixes (ex: 2.0.0 -> 2.0.1)
+-   **Major Version Increment** - Breaking Changes (ex: 2.0.0 → 3.0.0)
+-   **Minor Version Increment** - New Features (ex: 2.0.0 → 2.1.0)
+-   **Patch Version Increment** - Security and Bug Fixes (ex: 2.0.0 → 2.0.1)
 
 All microservices with the same minor version should be compatible.
 
-The separate repos for microservices and libraries are versioned individually. These versions are separate from the `cloud-deployment` repo version.  The `cloud-deployment` repo is where we have the monthly release. This repo might carry a higher version than some of the individual repos but is tagged as `{Month} {Year}`. All sub-repos referenced within `cloud-deployment` for a specific release are guaranteed to be compatible.
+Individual microservices and libraries continue to be versioned independently.
+
+The `deployment` repository itself is released monthly and tagged using the `{Month} {Year}` format. Each monthly release references a validated set of compatible component versions, ensuring all services work together as a supported deployment.
 
-<br>
 
-### What versions of Intel&reg; AMT are supported?
+### What versions of Intel® AMT are supported?
 
-Device Management Toolkit aligns to the Intel Network and Edge (NEX) Group support roadmap for Intel vPro&reg; Platform and Intel&reg; AMT devices. This is currently calculated as `Latest AMT Version - 7`.
+Device Management Toolkit aligns with the Intel Edge Computing Group support roadmap for Intel vPro® Platform and Intel® AMT devices. This is currently calculated as **Latest AMT Version - 7**.
 
-<br>
 
-### How do I migrate to a new release of Cloud-Deployment?
+### How do I migrate to a new Deployment release?
 
-Resources and information for migrating releases for either a Kubernetes deployment or local Docker deployment can be found in the [Upgrade Toolkit Version documentation](../Deployment/upgradeVersion.md).
+Migration resources for both Kubernetes and local Docker deployments can be found in the [Upgrade Toolkit Version documentation](../Deployment/upgradeVersion.md).
 
-<br>
+The current production deployment assets are available on the [`v2` branch](https://github.com/device-management-toolkit/deployment/tree/v2). Future deployment capabilities will continue to be introduced through the `main` branch as they become available.
 
-### Will there be any changes to Cloud-Deployment services following the release of Console v1.0?
 
-No changes are currently planned. We will continue supporting our Cloud-Deployment services.
+### What is the difference between the `v2` and `main` branches in the Deployment repository?
 
-<br>
+The [`v2` branch](https://github.com/device-management-toolkit/deployment/tree/v2) contains the current supported deployment assets and continues to receive updates, bug fixes, security improvements, and ongoing support.
 
-### What is the long-term vision for MPS and RPS services following the release of Console v1.0?
+The `main` branch is where new deployment capabilities are actively being developed, including support for both on-premises and cloud deployment scenarios. As these capabilities mature, they will become part of future monthly releases.
 
-- Our long-term vision is for Console to support both Enterprise and Cloud deployments, reducing the number of services we need to maintain.
-- As part of this vision, Console will take on the functions of both MPS and RPS. It will handle AMT connections and expose REST APIs to enable AMT features, similar to MPS. It will also manage profile creation, similar to RPS.
-- Furthermore, RPC-Go will be utilized for the configuration and activation of AMT, improving efficiency and reducing the need for a full provisioning service on the backend.
-- Consolidating these services into Console reduces our codebase and simplifies maintenance now with a smaller team.
+Existing deployments should continue using the `v2` branch unless you are evaluating new functionality under active development.
+
+
+### What is the long-term vision for MPS and RPS services?
+
+Our long-term vision is to simplify deployment by reducing the number of backend services required to manage Intel® AMT devices.
+
+Over time, Console will continue to absorb functionality currently provided by standalone services where it makes architectural and operational sense, while maintaining compatibility with existing deployment models during the transition.
+
+RPC-Go will continue evolving as the primary endpoint orchestration tool for Intel® AMT configuration, activation, and management, further simplifying deployment architectures and reducing the need for dedicated backend provisioning services.
 
-<br>
 
 ### What is a Pre-Release Feature?
 
-Sometimes, newer features may be available as **pre-release**. These are features that are still in-development and subject to change. The team opts to make these available for early feedback. These may have limited functionality or potentially even bugs. When the feature is mature and fully validated, it will move from a **pre-release** state to a full release.
+Sometimes, newer features may be available as **pre-release**. These are features that are still under development and subject to change. We make these available early to gather customer feedback and validate new functionality.
+
+Pre-release features may have limited functionality or known issues. Once they have matured and completed validation, they will transition to fully supported features.
 
-<br>
 
 ### How do I find more information about the MPS and RPS configuration files and security details?
 
-Details and descriptions of configuration options can be found in [MPS Configuration](./MPS/configuration.md) and [RPS Configuration](./RPS/configuration.md).
+Configuration documentation can be found here:
+
+-   [MPS Configuration](./MPS/configuration.md)
+-   [RPS Configuration](./RPS/configuration.md)
 
-Security information can be found in [MPS Security Information](./MPS/securityMPS.md) and [RPS Security Information](./RPS/securityRPS.md).
+Security documentation can be found here:
 
-<br>
+-   [MPS Security Information](./MPS/securityMPS.md)
+-   [RPS Security Information](./RPS/securityRPS.md)
diff --git a/docs/Reference/productionVault.md b/docs/Reference/productionVault.md
@@ -27,7 +27,7 @@ Learn how to run MPS and RPS using Vault in production server mode. The current
         entrypoint: vault server -config=/vault/config/vault.json
     ```
 
-3. Create a folder named `vault` located in `./cloud-deployment` directory and create a new file named `vault.json` in that folder with the contents below:
+3. Create a folder named `vault` located in `./deployment` directory and create a new file named `vault.json` in that folder with the contents below:
 
     ```json
     {
@@ -49,7 +49,7 @@ Learn how to run MPS and RPS using Vault in production server mode. The current
     }
     ```
 
-4. Run `docker compose` to start the containers from the ./cloud-deployment directory.
+4. Run `docker compose` to start the containers from the ./deployment directory.
 
     ```bash
     docker compose up -d --build

diff --git a/docs/Tutorials/Scaling/Kubernetes/deployingk8s-aks.md b/docs/Tutorials/Scaling/Kubernetes/deployingk8s-aks.md
@@ -15,10 +15,10 @@ Azure Kubernetes Service (AKS) offers serverless Kubernetes, an integrated conti
 
 ## Get the Toolkit
 
-1. Clone the cloud-deployment repository.
+1. Clone the `deployment` repository.
 
     ```
-    git clone https://github.com/device-management-toolkit/cloud-deployment.git --branch v{{ repoVersion.oamtct }}
+    git clone https://github.com/device-management-toolkit/deployment.git --branch v{{ repoVersion.oamtct }}
     ```
 
 ## Create SSH Key
@@ -46,7 +46,7 @@ This key is required by Azure to create VMs that use SSH keys for authentication
     az group create --name <your-resource-group-name> --location <region>
     ```
 
-3. Provide the name of your new resource group from the last step and start a deployment at that resource group based on `aks.json` in the `./cloud-deployment` directory.
+3. Provide the name of your new resource group from the last step and start a deployment at that resource group based on `aks.json` in the `./deployment` directory.
 
     ``` bash
     az deployment group create --resource-group <your-resource-group-name> --template-file aks.json
@@ -86,7 +86,7 @@ Ensure your `kubectl` is connected to the Kubernetes cluster you wish to deploy/
 
 ## Create Kubernetes Secrets 
 
-1. Open the `secrets.yaml` file in the `cloud-deployment/kubernetes/charts/` directory.
+1. Open the `secrets.yaml` file in the `deployment/kubernetes/charts/` directory.
 
     ??? note "Note - Additional Information about Secrets Created"
 
@@ -131,7 +131,7 @@ Ensure your `kubectl` is connected to the Kubernetes cluster you wish to deploy/
 
 ### Edit values.yaml
 
-1. Open the `values.yaml` file in `./cloud-deployment/kubernetes/charts/`.
+1. Open the `values.yaml` file in `./deployment/kubernetes/charts/`.
 
 2. Update the `service.beta.kubernetes.io/azure-dns-label-name` key in the **kong** section with a desired subdomain name for the URL that you would like for your cluster (i.e. myopenamtk8s).
 
@@ -250,7 +250,7 @@ Ensure your `kubectl` is connected to the Kubernetes cluster you wish to deploy/
 
 Add the root token as a secret to the AKS cluster so that the services can access Vault.
 
-1. Open the `secrets.yaml` file again in the `cloud-deployment/kubernetes/charts/` directory.
+1. Open the `secrets.yaml` file again in the `deployment/kubernetes/charts/` directory.
 
 2. Replace `<VAULT-ROOT-TOKEN>` in the `vaultKey:` field (line 66) with the actual Vault root token.
 

diff --git a/docs/Tutorials/Scaling/Kubernetes/deployingk8s-eks.md b/docs/Tutorials/Scaling/Kubernetes/deployingk8s-eks.md
@@ -17,10 +17,10 @@ Amazon EKS offers serverless Kubernetes, an integrated continuous integration an
 
 ## Get the Toolkit
 
-1. Clone the cloud-deployment repository.
+1. Clone the `deployment` repository.
 
     ```
-    git clone https://github.com/device-management-toolkit/cloud-deployment.git --branch v{{ repoVersion.oamtct }}
+    git clone https://github.com/device-management-toolkit/deployment.git --branch v{{ repoVersion.oamtct }}
     ```
 
 ## Create a New EKS Cluster
@@ -128,7 +128,7 @@ The Amazon EBS CSI plugin requires IAM permissions to make calls to Amazon APIs
     ```
 
 ## Create Kubernetes Secrets 
-1. Open the `secrets.yaml` file in the `cloud-deployment/kubernetes/charts/` directory.
+1. Open the `secrets.yaml` file in the `deployment/kubernetes/charts/` directory.
 
     ??? note "Note - Additional Information about Secrets Created"
 
@@ -181,7 +181,7 @@ The Amazon EBS CSI plugin requires IAM permissions to make calls to Amazon APIs
 
 ### Edit values.yaml
 
-1. Open the `values.yaml` file in the `./cloud-deployment/kubernetes/charts/` directory.
+1. Open the `values.yaml` file in the `./deployment/kubernetes/charts/` directory.
 
 2. Remove the **annotations** section and `service.beta.kubernetes.io/azure-dns-label-name` key in the `kong:` section. These are Azure-specific implementations.
 
@@ -259,7 +259,7 @@ The Amazon EBS CSI plugin requires IAM permissions to make calls to Amazon APIs
 
 Add the root token as a secret to the AKS cluster so that the services can access Vault.
 
-1. Open the `secrets.yaml` file again in the `cloud-deployment/kubernetes/charts/` directory.
+1. Open the `secrets.yaml` file again in the `deployment/kubernetes/charts/` directory.
 
 2. Replace `<VAULT-ROOT-TOKEN>` in the `vaultKey:` field (line 66) with the actual Vault root token.