Skip to main content

​
Introduction

A deployment request is how you move an AI model from Edge Inference Services onto a target Kubernetes cluster or cluster group. Each request routes through a GitOps-based approval pipeline before the model is deployed. You can initiate a request from the model detail page or from the Marketplace AI Apps catalog. For the approval side of the workflow — reviewing, approving, and validating deployed models — see Approve and Validate Models.

​
How It Works

When you submit a deployment request, the system:
  1. Creates a GitOps pull request (PR) in the configured repository with the deployment specification.
  2. Routes the PR through a review step where an approver can accept or reject it.
  3. On approval, deploys the model to the target cluster or cluster group using a Helm chart.
A deployment request has one of the following statuses: Pending, Approved, Rejected, Closed, Pending Update, or Pending Delete.

​
Submit a Deployment Request

  1. Go to Inference > Deploy > Models and open the model detail page.
  2. Select Deploy from the actions menu.
  3. The deployment creation wizard opens. Complete the following steps in order.
  4. In the Identity step, complete the following fields:
    • Name: An identifier for this deployment request, up to 255 characters. The name must be unique for the selected target within the organization. Spaces are automatically converted to hyphens. Seeds the Title and Description fields if you leave them blank.
    • Title: A display name for the deployment request.
    • Description: An optional description.
  5. Complete the model or solution step:
    • When deploying a model, complete the Model step:
      • Model: The model is pre-filled when launched from a model detail page. Select a different model or version if needed.
      • Model Version: The version of the selected model to deploy.
      • Business App Image: The container image for the inference server. Defaults to zededa/edgeai-demo-app:latest.
    • When deploying an agentic solution, complete the Configuration Values step: optionally override the solution’s default Helm chart values. Only the values you change are submitted. This step is optional.
  6. In the Target step, complete the following fields:
    • Target Type: Select Single Cluster to deploy to one cluster, or Cluster Group to deploy to all clusters in a group.
    • Target: Select the cluster or cluster group. Only online targets appear in the list. Selecting a single cluster sets the architecture automatically.
    • Architecture: The CPU architecture of the target hardware. Set automatically when targeting a single cluster. For cluster groups, select AMD64 or ARM64 (Jetson) manually.
  7. In the Review step, confirm the deployment settings and select Create Deployment.
The deployment request is created and routed through the approval pipeline. You can track its progress in the deployment request list.

​
View Deployment Requests

After submitting, the deployment request list opens automatically. You can return to it at any time from the link in your post-submission confirmation. The list shows all requests in the current project scope. A summary bar at the top displays the total count and a count for each status.

​
Status reference

​
Track a Deployment Request

Select a deployment request name to open its detail page. The detail page shows the current status of the request at the top. The detail page also shows:
  • The pull request number, URL, and branch in the GitOps repository.
  • The submitter, approver or rejector, and associated timestamps.
  • The model name, version, target cluster, and architecture.
  • An Update History log that records each change made after initial submission, showing which fields changed and their before and after values.

​
Update a Deployment Request

If a deployment request needs to be changed after submission:
  1. Open the deployment request detail page.
  2. Select Edit.
  3. Update the relevant fields.
  4. Select Submit.
If you change the model, image, chart, or configuration values, the request status changes to Pending Update and another user must approve the change. If the change is rejected, the request returns to its previous status. Changes to the name, title, or description apply immediately without review. Changes to the target or architecture also apply to the deployment without review. You cannot change the project of an existing request, and you cannot edit a request that is Pending Delete.

​
In This Section