alauda · davidwtf · Aug 6, 2026
diff --git a/docs/en/administer/secure_profile/install_secure_dependencies.mdx b/docs/en/administer/secure_profile/install_secure_dependencies.mdx
@@ -8,20 +8,10 @@ The [secure profile](./enable_secure_profile.mdx) requires **cert-manager**, **S
 
 ## Common installation pattern
 
-Each component is delivered as a platform package — an OLM operator or a Cluster Plugin. The steps are the same for all of them:
+Each component is delivered as a platform package — an OLM operator or a Cluster Plugin. For the common package download, `violet` setup, and upload procedure, see [Upload Packages](../../installation/package-upload.mdx). The pattern is the same for all of them:
 
-1. **Download** the component package from the <Term name="company" /> Customer Portal — `https://cloud.alauda.cn` (China) or `https://cloud.alauda.io` (international).
-2. **Upload** it to the platform with `violet`:
-
-   ```bash
-   violet push \
-     --platform-address=<platform-access-address> \
-     --platform-username=<platform-admin> \
-     --platform-password=<platform-admin-password> \
-     <package>.tgz
-   ```
-
-   `violet` relocates the package's images into the platform registry, so the components install on **air-gapped** clusters.
+1. **Download** the component package from the <Term name="company" /> Customer Portal.
+2. **Upload** it to the platform following [Upload Packages](../../installation/package-upload.mdx). `violet` relocates the package's images into the platform registry, so the components install on **air-gapped** clusters.
 3. **Install** from the web console — **Administrator → Marketplace / OperatorHub**, selecting the target cluster — or with `kubectl` (a `Subscription` for OLM operators, a `ModuleInfo` for Cluster Plugins).
 
 The sections below cover the per-component configuration.
@@ -30,7 +20,7 @@ The sections below cover the per-component configuration.
 
 SPIRE issues the workload SVIDs that AuthBridge uses for mTLS. It is delivered as a **Cluster Plugin**.
 
-Upload the SPIRE package with `violet` and install it on the **workload cluster** (Marketplace → install on cluster, or create a `ModuleInfo` from the global cluster). Configure the install:
+Upload the SPIRE package following [Upload Packages](../../installation/package-upload.mdx) and install it on the **workload cluster** (Marketplace → install on cluster, or create a `ModuleInfo` from the global cluster). Configure the install:
 
 | Setting | Notes |
 |---------|-------|
@@ -59,7 +49,7 @@ Keycloak issues the OAuth2/JWT tokens that AuthBridge validates. It is delivered
 
 ### 1. Install the operator
 
-Upload the Keycloak operator package with `violet`, then install it from **OperatorHub**. Platform operators require the **`Manual`** upgrade approval — approve the generated `InstallPlan` to complete the install.
+Upload the Keycloak operator package following [Upload Packages](../../installation/package-upload.mdx), then install it from **OperatorHub**. Platform operators require the **`Manual`** upgrade approval — approve the generated `InstallPlan` to complete the install.
 
 ### 2. Deploy a Keycloak instance
 
@@ -117,7 +107,7 @@ The value you set as `keycloak.publicUrl` becomes the JWT issuer (`iss`) claim t
 
 The secure profile uses Istio **ambient** mesh (ztunnel) for namespace-level mTLS, delivered as **<Term name="company" /> Service Mesh v2** (the `servicemesh-operator2` / Sail operator).
 
-Install the **Alauda Service Mesh v2** operator from the Marketplace (download → `violet` → install), version **2.1.1 or later** (ambient support). Ambient on ACP also requires the **Multus** CNI plugin and `kube-ovn` ≥ v4.1.5.
+Install the **Alauda Service Mesh v2** operator from the Marketplace (download → upload via [Upload Packages](../../installation/package-upload.mdx) → install), version **2.1.1 or later** (ambient support). Ambient on ACP also requires the **Multus** CNI plugin and `kube-ovn` ≥ v4.1.5.
 
 Then enable ambient by creating the `IstioCNI`, `Istio`, and `ZTunnel` resources with `profile: ambient`. Create the `istio-cni`, `istio-system`, and `ztunnel` namespaces first, each labeled `istio-discovery=enabled`. The full, authoritative procedure (prerequisites, namespace labels, verification) is in the **Alauda Service Mesh v2** documentation — *Installing Istio ambient mode* ([`alauda/servicemesh2-docs`](https://github.com/alauda/servicemesh2-docs/blob/master/docs/en/installing/ambient-mode/installing-ambient-mode.mdx)). In summary:
 

diff --git a/docs/en/ai_applications/components/dify/install.mdx b/docs/en/ai_applications/components/dify/install.mdx
@@ -12,7 +12,7 @@ For what Dify is and the components it deploys, see [Introduction](./intro).
 
 | You need | Why |
 |---|---|
-| The Dify operator package (`.tgz`) | Pushed via `violet` so the operator appears in OperatorHub |
+| The Dify operator package | Downloaded and uploaded with the common package procedure so the operator appears in OperatorHub (see [Upload Packages](../../../installation/package-upload.mdx)) |
 | External **PostgreSQL 12+** | Dify's main database (only PostgreSQL is supported) |
 | External **Redis 6+** (standalone or Sentinel) | Cache + Celery broker; Cluster mode is **not** supported |
 | External **pgvector** *(optional)* | Vector store for RAG; disable if not using RAG |
@@ -22,15 +22,7 @@ For what Dify is and the components it deploys, see [Introduction](./intro).
 
 ## Step 1 — Publish the Operator Package
 
-Download the Dify operator package (e.g. `dify-operator.alpha.ALL.v<version>.tgz`) from Customer Support / Portal, then push it to the platform repository so it appears in **Marketplace / OperatorHub**:
-
-```bash
-violet push \
-  --platform-address=<platform-access-address> \
-  --platform-username=<platform-admin> \
-  --platform-password=<platform-admin-password> \
-  dify-operator.alpha.ALL.v<version>.tgz
-```
+Download the Dify operator package from Customer Support / Portal, then upload the package following [Upload Packages](../../../installation/package-upload.mdx) so it appears in **Marketplace / OperatorHub**.
 
 ## Step 2 — Install the Dify Operator
 

diff --git a/docs/en/ai_applications/components/kagenti/install.mdx b/docs/en/ai_applications/components/kagenti/install.mdx
@@ -2,7 +2,7 @@
 weight: 20
 ---
 
-# Installation
+# Install Kagenti
 
 Kagenti Operator is delivered as an **OLM Operator** and installed from the platform **OperatorHub**.
 
@@ -13,23 +13,15 @@ Kagenti Operator is delivered as an **OLM Operator** and installed from the plat
 - Operator Lifecycle Manager (OLM) available on the target cluster (provided by ACP).
 - **cert-manager** installed on the target cluster. The operator's admission webhooks get their serving certificate from cert-manager.
 
-## Upload Operator \{#upload-operator}
+## Upload the Operator Package
 
-Download the `Kagenti Operator` bundle from the <Term name="company" /> Customer Portal / Marketplace, then publish it to the platform repository with the `violet` command-line tool:
-
-```bash
-violet push \
-  --platform-address=<platform-access-address> \
-  --platform-username=<platform-admin> \
-  --platform-password=<platform-admin-password> \
-  kagenti-operator.ALL.xxxx.tgz
-```
+Download the `Kagenti Operator` bundle from the <Term name="company" /> Customer Portal / Marketplace, then upload the package following [Upload Packages](../../../installation/package-upload.mdx).
 
 :::info
 The operator bundle records its runtime images in the CSV `relatedImages`, so a `violet` release relocates them into the platform registry. This makes the operator installable on **air-gapped** clusters without reaching `docker.io` or `ghcr.io`.
 :::
 
-## Install Operator
+## Install the Operator
 
 In the **Administrator** view:
 

diff --git a/docs/en/ai_applications/components/llama_stack/install.mdx b/docs/en/ai_applications/components/llama_stack/install.mdx
@@ -4,27 +4,42 @@ weight: 20
 
 # Install Llama Stack
 
-This document describes how to install and deploy Llama Stack Server on Kubernetes using the Llama Stack Operator.
+In Alauda AI 2.8.x, **Alauda Build of Llama Stack** is installed and managed by Alauda AI. The `llamaStack` component in the cluster-scoped `default` `AmlCluster` defaults to `Unmanaged`; set it to `Managed`, and you do not need to install the Operator from OperatorHub manually. After the component is reconciled, deploy Llama Stack Server with a `LlamaStackDistribution` custom resource as described below.
 
-## Upload Operator
+## Upload the Operator Package
 
-Download the Llama Stack Operator installation file (e.g., `llama-stack-operator.alpha.ALL.xxxx.tgz`).
+Download the Llama Stack Operator package, then upload the package following [Upload Packages](../../../installation/package-upload.mdx).
 
-Use the violet command to publish to the platform repository:
+## Enable Llama Stack
 
-```bash
-violet push --platform-address=platform-access-address --platform-username=platform-admin --platform-password=platform-admin-password llama-stack-operator.alpha.ALL.xxxx.tgz
+In **Administrator** view:
+
+1. Open **Marketplace** > **OperatorHub**.
+2. Select the target cluster and open **Alauda AI**.
+3. Open the **All Instances** tab and edit the `default` `AmlCluster` instance.
+4. Set `spec.components.llamaStack.managementState` to `Managed`.
+5. Save the `AmlCluster` instance and wait for the Llama Stack Operator to become ready.
+
+You can apply the component setting in the `AmlCluster` YAML:
+
+```yaml
+spec:
+  components:
+    llamaStack:
+      managementState: Managed
 ```
 
-## Install Operator
+## Verify the Installation
 
-1. Go to the `Administrator` view in the Alauda Container Platform.
+Check the `AmlCluster` status and the Llama Stack Operator:
 
-2. In the left navigation, select `Marketplace` / `Operator Hub`.
+```bash
+kubectl get amlcluster default
 
-3. In the right panel, find `Alauda build of Llama Stack` and click `Install`.
+kubectl get pods -n llama-stack-k8s-operator-system
+```
 
-4. Keep all parameters as default and complete the installation.
+The `AmlCluster` should report `Phase=Ready`, and the Llama Stack Operator controller pod should be in `Running` state. The `LlamaStackDistribution` CRD is registered once the operator is ready.
 
 ## Deploy Llama Stack Server
 

diff --git a/docs/en/ai_applications/components/mcp_lifecycle_operator/install.mdx b/docs/en/ai_applications/components/mcp_lifecycle_operator/install.mdx
@@ -2,27 +2,19 @@
 weight: 20
 ---
 
-# Installation
+# Install MCP Lifecycle Operator
 
 Alauda Build of MCP Lifecycle Operator is delivered as an **OLM Operator** and installed from the platform **OperatorHub**.
 
-## Upload Operator
+## Upload the Operator Package
 
-Download the Alauda Build of MCP Lifecycle Operator package from the <Term name="company" /> Customer Portal / Marketplace, then publish it to the platform repository with the `violet` command-line tool:
-
-```bash
-violet push \
-  --platform-address=<platform-access-address> \
-  --platform-username=<platform-admin> \
-  --platform-password=<platform-admin-password> \
-  mcp-lifecycle-operator.ALL.xxxx.tgz
-```
+Download the Alauda Build of MCP Lifecycle Operator package from the <Term name="company" /> Customer Portal / Marketplace, then upload the package following [Upload Packages](../../../installation/package-upload.mdx).
 
 :::info
 The operator package includes the OLM bundle and the related runtime images required by the operator. For air-gapped clusters, make sure the MCP server images used by your `MCPServer` resources are also mirrored to a registry that the cluster can pull from.
 :::
 
-## Install Operator
+## Install the Operator
 
 In the **Administrator** view:
 
@@ -55,7 +47,7 @@ You should see the `mcp-lifecycle-operator-controller-manager` pod in `Running`
 
 ## Upgrade Operator
 
-1. Upload the new Alauda Build of MCP Lifecycle Operator package with `violet push`.
+1. Upload the new Alauda Build of MCP Lifecycle Operator package following [Upload Packages](../../../installation/package-upload.mdx).
 2. Go to **Administrator** -> **Marketplace** -> **OperatorHub**.
 3. Find **Alauda Build of MCP Lifecycle Operator** and apply the new version according to the configured upgrade strategy.
 4. Verify the CSV, controller pod, and existing `MCPServer` resources after the upgrade.
diff --git a/docs/en/deploy/components/envoy_ai_gateway/install.mdx b/docs/en/deploy/components/envoy_ai_gateway/install.mdx
diff --git a/docs/en/deploy/components/envoy_ai_gateway/intro.mdx b/docs/en/deploy/components/envoy_ai_gateway/intro.mdx
@@ -20,7 +20,7 @@ Main components and capabilities include:
 
 Envoy AI Gateway is a required dependency of **Alauda Build of KServe** for exposing inference services.
 
-For installation on the platform, see [Install Envoy AI Gateway](./install).
+Envoy AI Gateway is installed and managed by Alauda AI through the `envoyAIGateway` component in the `default` `AmlCluster`. For the Alauda AI installation and component configuration, see [Install Alauda AI](../../../installation/ai-cluster.mdx).
 
 ## Guides
 

diff --git a/docs/en/deploy/components/index.mdx b/docs/en/deploy/components/index.mdx
@@ -1,5 +1,5 @@
 ---
-weight: 60
+weight: 70
 i18n:
   title:
     en: Components

diff --git a/docs/en/deploy/components/infernex_bridge/install.mdx b/docs/en/deploy/components/infernex_bridge/install.mdx
@@ -19,7 +19,7 @@ Before installing **Alauda Build of InferNex Bridge**, ensure the target cluster
 | KServe                          | Operator        | Required when using the KServe `LLMInferenceService` entry point. The declared upstream compatibility range is KServe v0.17.0-v0.19.0. Alauda Build of KServe v0.16.1 has also been validated. |
 | Envoy Gateway and Gateway API   | Operator / CRDs | Required when exposing inference services through Gateway API resources.                                                                                                                       |
 | Gateway API Inference Extension | CRDs            | Required for `InferencePool` based intelligent routing.                                                                                                                                        |
-| Alauda Build of LeaderWorkerSet | Cluster Plugin  | Install it before InferNex Bridge. The controller watches `LeaderWorkerSet` resources and uses them for multi-node inference workloads.                                                        |
+| Alauda Build of LeaderWorkerSet | Operator (managed by AmlCluster) | Required for InferNex Bridge. The controller watches `LeaderWorkerSet` resources and uses them for multi-node inference workloads. It is normally enabled through the `lws` component in the `default` `AmlCluster`; see [Install Alauda AI](../../../installation/ai-cluster.mdx). |
 | Inference runtime prerequisites | Runtime         | Prepare NPU nodes, model storage, runtime templates, runtime images, and network access required by the selected inference engine.                                                             |
 
 :::info
@@ -42,7 +42,7 @@ The following CRDs are not installed by this OLM bundle. Install them separately
 
 | CRD                                         | Source Project                                             | When Required                                                     | How to Install                                                                                                                                   |
 | ------------------------------------------- | ---------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `leaderworkersets.leaderworkerset.x-k8s.io` | [Alauda Build of LeaderWorkerSet](../lws/index.mdx)        | InferNex Bridge controller and multi-node inference workloads     | Follow the [LeaderWorkerSet installation guide](../lws/install.mdx) before installing InferNex Bridge.                                           |
+| `leaderworkersets.leaderworkerset.x-k8s.io` | [Alauda Build of LeaderWorkerSet](../lws/index.mdx)        | InferNex Bridge controller and multi-node inference workloads     | Ensure LeaderWorkerSet is installed and running. It is normally managed through the `lws` component in the `default` `AmlCluster`; see [Install Alauda AI](../../../installation/ai-cluster.mdx). |
 | `rolebasedgroups.workloads.x-k8s.io`        | [RoleBasedGroup (RBG)](https://github.com/sgl-project/rbg) | ResourceScalingGroup targets that explicitly use `RoleBasedGroup` | Install from the upstream [RBG v0.7.0 release manifest](https://raw.githubusercontent.com/sgl-project/rbg/v0.7.0/deploy/kubectl/manifests.yaml). |
 
 The `rolebasedgroups.workloads.x-k8s.io` CRD is provided by the upstream [RoleBasedGroup (RBG) project](https://github.com/sgl-project/rbg). It is a conditional dependency and is not required for Deployment or LeaderWorkerSet targets. To install the upstream RBG v0.7.0 controller and CRDs, use the versioned release manifest:
@@ -242,18 +242,11 @@ kubectl get deployment,daemonset,service -n <inference-service-namespace> \
 
 Expected workloads include the EagleEye hardware diagnosis Deployment, hardware monitor DaemonSet, and network performance exporter DaemonSet. If EagleEye is not required, keep all three child switches set to `false`.
 
-## Upload Operator \{#upload-operator}
+## Upload the Operator Package
 
-Obtain the arm64 installation package from your Alauda product delivery channel:
-`infernex-bridge.alpha.arm64.v26.6.0.tgz`.
+Obtain the arm64 installation package from your Alauda product delivery channel, then upload the package following [Upload Packages](../../../installation/package-upload.mdx).
 
-Use the `violet` command to publish it to the platform repository:
-
-```bash
-violet push --platform-address=<platform-access-address> --platform-username=<platform-admin> --platform-password=<platform-admin-password> infernex-bridge.alpha.arm64.v26.6.0.tgz
-```
-
-## Install Operator
+## Install the Operator
 
 In **Administrator** view:
 
@@ -302,7 +295,7 @@ For community-maintained examples, see [InferNex Bridge v26.6.0 examples](https:
    kubectl get infernexservice,infernexserviceconfig -A -o yaml > infernex-bridge-backup.yaml
    ```
 
-2. Upload the new version of the **Alauda Build of InferNex Bridge** operator package using the `violet` tool.
+2. Upload the new version of the **Alauda Build of InferNex Bridge** operator package following [Upload Packages](../../../installation/package-upload.mdx).
 3. Go to the `Administrator` -> `Marketplace` -> `OperatorHub` page, find **Alauda Build of InferNex Bridge**, review the target version, and click **Confirm** to apply it.
 
 ### Verification
@@ -324,7 +317,7 @@ kubectl get crd \
 Use a previous package only when its CRDs are compatible with the custom
 resources already stored in the cluster. In OperatorHub, select the previous
 available version and confirm the manual upgrade action. If the previous version
-is not available, upload its installation package with `violet` first.
+is not available, upload its installation package first (see [Upload Packages](../../../installation/package-upload.mdx)).
 
 After rollback, verify the controller, CRDs, inference services, runtime image
 IDs, and one representative inference request. Do not delete the five bundled