HAMi Enterprise Air-Gap Deployment Guide

This document is intended for SRE / platform engineers and describes how to deploy HAMi Enterprise in a Kubernetes cluster using the v0.0.5 All-in-One air-gap package and Zarf v0.86.0, complete license activation, enable GPU nodes, and verify with sample workloads.

This delivery package uses Zarf to perform image import, Helm chart installation, and subsequent upgrades in environments without external network access or with restricted networks, reducing the manual effort of syncing images and maintaining installation order.

Zarf is an application packaging and deployment tool for Kubernetes air-gap / semi-air-gap environments; it can bundle images, Helm charts, scripts, and deployment actions into a portable package.

Installation itself does not require a license. Complete the software deployment first, then apply for and import the license.

Without activation, vGPU partitioning and scheduling are unavailable, and functional verification will fail.

Air-Gap Package Contents

The outer delivery package is named as follows:

hami-enterprise-v<VERSION>-airgap-<ARCH>.tar.gz
hami-enterprise-v<VERSION>-airgap-<ARCH>.tar.gz.sha256
hami-enterprise-slim-v<VERSION>-airgap-<ARCH>.tar.gz
hami-enterprise-slim-v<VERSION>-airgap-<ARCH>.tar.gz.sha256

The full hami-enterprise-v0.0.5-airgap-amd64.tar.gz contains the files below. Slim retains NVIDIA GPU Operator but excludes NVIDIA driver images and sample workloads. When using Slim, the GPU nodes must already have a compatible NVIDIA driver.

File	Purpose
zarf-linux-amd64	Linux amd64 Zarf v0.86.0 CLI
zarf-init-amd64-v0.86.0.tar.zst	Zarf init air-gap package
hami-enterprise-v0.0.5-airgap-amd64.tar.zst	HAMi Enterprise main deployment package
zarf-package-hami-example-gpu-burn-amd64-v0.0.2.tar.zst	GPU Burn sample; full package only
zarf-package-hami-example-vllm-qwen-amd64-v0.0.4.tar.zst	vLLM + Qwen sample; full package only
collect-hami-license-info.sh	License request information collection script
collect-cluster-info.sh	Kubernetes and GPU inventory collector
COLLECT-CLUSTER-INFO.md	Collector prerequisites and commands
package-values.yaml	Component values template; every component starts as an empty object
PACKAGE-VALUES.md	Package values format and migration guide
hami/README.md	HAMi Chart values examples and configuration reference

Prerequisite Checks

• Use Kubernetes 1.27 or later with an available default StorageClass. The administration host needs kubectl and the bundled Zarf v0.86.0; check existing releases with zarf tools helm list -A.

For NVIDIA nodes, prepare a compatible driver and runtime configuration. The full package can deploy the optional GPU Operator with driver images. Slim also retains GPU Operator, but its NVIDIA driver images are omitted; install a compatible driver on the nodes before choosing Slim.

• Prepare the vendor driver, firmware and runtime on Ascend nodes. The bundle provides optional ascend-device-plugin and npu-exporter components; they do not install node prerequisites.

If using GPU Operator alongside HAMi, disable the GPU Operator device plugin (gpu-operator.devicePlugin.enabled=false) and CDI (gpu-operator.cdi.enabled=false). The delivered package already uses these settings. HAMi Enterprise uses scheduler.useDownward, which is incompatible with CDI. Assess running GPU workloads before changing an existing Operator installation.

kubectl cluster-info
kubectl version
kubectl get nodes -o wide
kubectl get storageclass

Extract, Verify, and Install Zarf

# Download the delivery package and checksum file
curl -L -O <URL>
curl -L -O <SHA256_URL>

# Verify integrity
shasum -a 256 -c hami-enterprise-v0.0.5-airgap-amd64.tar.gz.sha256

# Extract the outer tar.gz
tar -xzf hami-enterprise-v0.0.5-airgap-amd64.tar.gz

# Enter the extracted directory
cd hami-enterprise-v0.0.5-airgap-amd64

The package includes the Linux Zarf v0.86.0 CLI and its matching init package. The example below uses amd64; for arm64, use zarf-linux-arm64 and the arm64 init package. Install the bundled CLI after entering the extracted directory:

chmod +x ./zarf-linux-amd64
sudo install -m 0755 ./zarf-linux-amd64 /usr/local/bin/zarf
zarf version

Zarf includes the Helm tool. For subsequent troubleshooting of Helm release, values, and chart status, use zarf tools helm to avoid relying on a separately installed Helm in the target environment:

zarf tools helm version
zarf tools helm list -A

Initialize Zarf

Run zarf init only if the target cluster has not been initialized. Use the labeled policy to limit image rewriting to explicitly labeled namespaces or workloads. For an existing Zarf installation, inspect its Registry, StorageClass, and Agent mutation policy first; deploying the main package does not change that policy.

Use the Zarf built-in registry:

zarf init zarf-init-amd64-v0.86.0.tar.zst \
  --agent-mutation-policy=labeled \
  --confirm

Use an external registry:

zarf init zarf-init-amd64-v0.86.0.tar.zst \
  --agent-mutation-policy=labeled \
  --registry-url=harbor.example.com/zarf-amd64 \
  --registry-push-username=<username> \
  --registry-push-password=<password> \
  --confirm

💡 Mixed-architecture clusters must use separate registry prefixes. AMD64 and ARM64 clusters may share the same Harbor instance, but they must not share the same Zarf registry project or repository prefix. Images in a Zarf air-gap package are packaged for the target architecture. Deploying AMD64 and ARM64 packages sequentially to the same image path does not merge identical tags into a multi-platform manifest. A later push may replace the earlier tag and cause Pods on the other architecture to pull an incompatible image after a restart or rescheduling.

During cluster initialization, use an architecture-specific --registry-url for each architecture. For example, use registry.example.com/zarf-amd64 for AMD64 and registry.example.com/zarf-arm64 for ARM64. Create the corresponding Harbor projects or repository prefixes in advance, and ensure that the account used by Zarf has push and pull permissions.

External registry parameter descriptions:

Parameter	Description
--registry-url	External image registry address
--registry-push-username	Username used to push images
--registry-push-password	Password used to push images

After initialization, zarf package deploy imports the images bundled in the package and uses an admission webhook to rewrite image references for managed workloads to the Zarf registry. With the labeled policy, only resources labeled zarf.dev/agent: mutate, or resources in a namespace with that label, are processed; a label on the resource takes precedence over the namespace label. Before deployment, confirm that the namespaces for the selected components have this label. For offline workloads created separately, confirm that the namespace is labeled first. Label changes do not affect existing Pods; recreate the Pods to trigger rewriting.

Use --insecure-skip-tls-verify for the relevant command only when the TLS certificate of the target registry genuinely cannot be verified and the man-in-the-middle risk has been assessed. In production, fix the certificate chain or configure a trusted CA for the Zarf Agent instead of treating skipped TLS verification as a default.

Deploy HAMi Enterprise

All workload components are optional and disabled by default. Select the required components with --components and keep the order shown below. Passing values alone does not select a component.

The component list is as follows:

Component Name	Description	Required	Use
tools	Installs jq and nerdctl on the host	No	As needed
hami	HAMi Enterprise Helm chart	No	HAMi core
ascend-device-plugin	Ascend Device Plugin; uses the HAMi device ConfigMap	No	Ascend nodes
npu-exporter	Ascend NPU metrics exporter; see the shared configuration and monitoring instructions below.	No	When NPU metrics are needed
prometheus-crds	Prometheus Operator CRDs, installed with Server-Side Apply	No	Before prometheus
prometheus	kube-prometheus-stack Helm chart	No	As needed
gpu-operator	NVIDIA GPU Operator; its device plugin is disabled in bundled values	No	Optional for NVIDIA nodes in both full and Slim packages; Slim requires an existing compatible driver

Zarf v0.86.0 accepts --values=package-values.yaml. Starting with main package v0.0.5, each top-level key must match the target component name. For example, use hami.scheduler or prometheus.prometheusOperator. Values merge in this order: Chart defaults → bundled Chart values → the matching component object in package values. To override a small number of fields, use a component-prefixed path such as --set-values hami.scheduler.replicas=1. If no overrides are needed, omit --values.

Prepare Custom Values

Start with the outer archive’s package-values.yaml template and read PACKAGE-VALUES.md. Each top-level key below sends only its own object to the matching Chart. Tools and CRD components have no Chart values mapping.

Package values key	Chart	Available in
hami	HAMi Enterprise	Enterprise
ascend-device-plugin	Ascend Device Plugin	Enterprise
npu-exporter	NPU Exporter	Enterprise
prometheus	kube-prometheus-stack	Enterprise
gpu-operator	NVIDIA GPU Operator	Full and Slim Enterprise packages

The hami/ examples use native Chart values. Do not pass them directly as package values. In v0.0.5, old root-level keys such as scheduler, nodeSelector, and global are not forwarded to any Chart. Move them under the matching component key. If a previous file served several Charts, split its fields between those components. Common HAMi fields are listed below with their package values paths:

Parameter	Description	Default
hami.dra.enabled	Whether to enable and deploy DRA	false
hami.scheduler.leaderElect	Whether to enable leader election for hami-scheduler across multiple nodes. Strongly recommended to disable for single-node clusters.	true
hami.scheduler.replicas	Adjust the number of hami-scheduler instances	1
hami.scheduler.kubeScheduler.image.registry	Image registry for the kube-scheduler image used by hami-scheduler	registry.cn-hangzhou.aliyuncs.com
hami.scheduler.kubeScheduler.image.repository	Image repository name for the kube-scheduler image used by hami-scheduler	google_containers/kube-scheduler
hami.scheduler.kubeScheduler.image.tag	Version of the kube-scheduler image used by hami-scheduler; should match the target cluster	""

Minimal package-values.yaml example. For a single-node cluster, set hami.scheduler.leaderElect to false:

hami:
  dra:
    enabled: false
  scheduler:
    leaderElect: false

For non-NVIDIA devices, enable the corresponding vendor under hami.devices. For Ascend, set both switches:

hami:
  devices:
    ascend:
      enabled: true
      hamiVnpuCore: true

The kube-scheduler image selected by HAMi must be included in the delivered package and imported into the registry chosen at zarf init. Zarf-managed workloads in hami-system have their image references rewritten by the Agent. Setting a different registry in values does not add a missing image to the package. If the target Kubernetes version requires another image, contact technical support for a matching package.

Before deployment, you can inspect the values and rendered manifests for the selected components with the same values file used for deployment. The example below selects HAMi core only.

PACKAGE=./hami-enterprise-v0.0.5-airgap-amd64.tar.zst
COMPONENTS=hami
VALUES_FILE=./package-values.yaml

zarf package inspect values-files "${PACKAGE}" \
  --components="${COMPONENTS}" --values="${VALUES_FILE}"
zarf package inspect manifests "${PACKAGE}" \
  --components="${COMPONENTS}" --values="${VALUES_FILE}" \
  > rendered.yaml

Execute Deployment

Minimal installation, deploying only the HAMi Enterprise core components:

zarf package deploy hami-enterprise-v0.0.5-airgap-amd64.tar.zst \
  --components=hami \
  --values=package-values.yaml \
  --confirm

Optional: NVIDIA GPU Operator

NVIDIA GPU Operator is optional, just like the Ascend components below. If the nodes already have a compatible driver, NVIDIA Container Toolkit and runtime configuration, you may skip it. See the HAMi NVIDIA GPU node prerequisites for the more detailed GPU Operator values. Do not enable CDI: this HAMi Enterprise package uses scheduler.useDownward. The bundled GPU Operator has CDI and its own device plugin disabled. Slim can deploy GPU Operator, but the GPU nodes must already have compatible drivers.

zarf package deploy hami-enterprise-v0.0.5-airgap-amd64.tar.zst \
  --components=gpu-operator \
  --values=package-values.yaml \
  --confirm

Optional: Ascend Components

ascend-device-plugin and npu-exporter are optional in both full and Slim packages. The plugin runs in hami-system and uses the existing hami-scheduler-device ConfigMap. The Exporter runs in npu-exporter. Avoid duplicate installations. Ascend-only clusters do not need GPU Operator; mixed clusters may select each hardware component as needed.

Prepare the Nodes

NPU Exporter supports ordinary Ascend compute nodes using containerd. Install the driver, firmware, and runtime on each target node first. Atlas 200I SoC A1 core boards require separate upstream manifests and startup scripts and are outside this component’s scope.

The default selector reuses the plugin’s ascend: "on" node label. No separate Exporter label is needed. The default containerd directory is /run/containerd. Override the Exporter settings only if the actual node labels or runtime path differ.

The installer creates the Exporter log directory and sets ownership to root:root and mode 0750. No manual directory setup on each node is needed. Installation uses the standard Zarf and Helm readiness checks. Verify metric collection and monitoring integration as described under “Verify the Deployment” below.

Configure and Deploy

The default node labels and containerd path need no extra configuration. Keep HAMi settings aligned with the target NPU model and partitioning mode. For a non-default containerd path, configure npu-exporter.hostPaths.containerd with the path used by the target nodes.

To add these components to a cluster where HAMi is already installed, select them as below. For a first installation, add them to the component combination for your edition. Also select prometheus-crds,prometheus when using the bundled monitoring stack. Use the main package for the selected version and architecture.

zarf package deploy <main-package.tar.zst> \
  --components=ascend-device-plugin,npu-exporter \
  --values=package-values.yaml --confirm

Omit --values if no overrides are needed. Select only npu-exporter if the plugin is already installed. Image changes require rebuilding the package with the new image; an offline deployment cannot pull an image that was not packaged.

Connect Monitoring

The Exporter does not create a ServiceMonitor by default. Enable the Exporter’s optional ServiceMonitor. When using the bundled stack, install prometheus-crds,prometheus. After deployment, confirm the targets and metrics in Prometheus. Avoid two monitors scraping the same Exporter.

npu-exporter:
  serviceMonitor:
    enabled: true

Verify the Deployment

kubectl -n hami-system get daemonsets
kubectl -n npu-exporter get daemonset npu-exporter
kubectl -n npu-exporter rollout status daemonset/npu-exporter --timeout=180s
kubectl -n npu-exporter get pods -o wide
kubectl -n npu-exporter get endpointslice -l kubernetes.io/service-name=npu-exporter

Check the Exporter DaemonSet’s DESIRED and READY counts: both should equal the expected number of Ascend nodes and be greater than zero. Query up{job="npu-exporter",namespace="npu-exporter"} and npu_chip_info_utilization in Prometheus to confirm scraping and metrics for each node. Zero utilization is valid for idle devices. Also verify device-plugin registration and run a workload requesting the expected Ascend resources to confirm allocation and device access.

Exporter Pods being Ready does not prove that metrics are being collected. Prometheus configuration updates and the first scrape take some time after a ServiceMonitor is created. If metrics are missing, check the driver and DCMI. For scrape failures, check target discovery, configuration reload, ServiceMonitor labels, duplicate scraping, and network policies.

Maintenance and Non-default Environments

For Exporter troubleshooting, check that the node has a usable containerd.sock at the configured containerd directory. The component mounts the directory, rather than an individual socket file.

The NetworkPolicy allows TCP 8082 from Pods labeled app.kubernetes.io/name: prometheus across namespaces and denies outbound traffic by default; enforcement depends on the CNI. For other monitoring labels, override npu-exporter.networkPolicy.prometheusPodSelector. Configure standalone ServiceMonitor selector labels through npu-exporter.serviceMonitor.labels.

The Exporter runs as root in a privileged container and accesses host driver libraries, DCMI libraries, and the runtime socket. A read-only socket mount does not restrict runtime API calls. Keep DCMI libraries and their parent directories owned by root and not writable by group or others. Before upgrading the driver, stop workloads and then stop NPU Exporter.

Default host path	Purpose	Mount access
/usr/local/Ascend/driver	Driver libraries	Read-only
/usr/local/dcmi	DCMI libraries	Read-only
/sys	Device information	Read-only
/run/containerd	Containerd and CRI socket access	Read-only directory mount
/etc/localtime	Node timezone	Read-only
/var/log/mindx-dl/npu-exporter	Exporter logs	Writable

test -d /usr/local/Ascend/driver
test -d /usr/local/dcmi
test -S /run/containerd/containerd.sock

Removing the component does not remove host logs. The container root filesystem is read-only, /tmp uses emptyDir, and the ServiceAccount token is not mounted. These settings do not remove the privileged container’s host access.

If a component remains stuck for a long time, the installation has encountered an issue. You can use zarf tools helm to diagnose the component; if the failure is caused by incorrect values during Helm rendering or installation, fix package-values.yaml and rerun the same zarf package deploy ... command.

After an interrupted deployment, resolve the issue and resume with the same zarf package deploy ... --components=... --values=... command. Zarf will skip re-importing images when the digest has not changed; it will perform a Helm upgrade when Helm charts or values have changed.

If the target resources are already managed by another Helm release and you have confirmed that they should be transferred to the current Zarf package, review the resource scope and then use --take-ownership. Use --force-conflicts only for Server-Side Apply field ownership conflicts. It overwrites fields managed by other field managers, so use it only after confirming that this deployment may take over those fields; do not use it as a general retry option.

Enable GPU Nodes

The HAMi NVIDIA device plugin starts on nodes labeled gpu=on. Apply this label to NVIDIA nodes that HAMi should manage. Ascend components use their own nodeSelector; gpu=on is not their selection rule.

kubectl label nodes <node-name> gpu=on

Nodes and Monitoring

Monitoring is optional. If the cluster already has compatible Prometheus or VictoriaMetrics monitoring, connect it using the selectors below. To install the bundled kube-prometheus-stack, select both monitoring components:

zarf package deploy hami-enterprise-v0.0.5-airgap-amd64.tar.zst \
  --components=prometheus-crds,prometheus \
  --values=package-values.yaml \
  --confirm

kubectl describe node <node-name>
kubectl api-resources --api-group=monitoring.coreos.com

For Prometheus, match ServiceMonitor.metadata.labels to Prometheus.spec.serviceMonitorSelector and check the namespace selector. For VictoriaMetrics Operator, VMAgent.spec.serviceScrapeSelector selects VMServiceScrape.metadata.labels; also check serviceScrapeNamespaceSelector and any ServiceMonitor conversion.

The v0.0.5 air-gap bundle sets hami.legacyMetrics=false. Check that the relevant scrape targets report up=1, then query these current NVIDIA metrics and confirm that they return data:

• DCGM_FI_DEV_GPU_UTIL

• hami_host_gpu_utilization_ratio

• hami_gpu_core_allocated_ratio

Obtain License Request Information

Collect the license request information once the HAMi core is ready. You do not need to wait for optional GPU Operator, Ascend, or monitoring components. The administration host needs kubectl and jq. Use either method below.

Download and Run the Script

curl -fsSLO https://public.hami.run/collect-hami-license-info.sh
bash collect-hami-license-info.sh

Run a Local Copy

bash collect-hami-license-info.sh

The script outputs JSON in the following format:

{
  "esn": "96565d61-986a-4918-aafb-448ff6e3746b",
  "deviceInstances": [
    {
      "uuid": "GPU-ceee905d-48ac-93de-a81b-17c00e1e5e02",
      "deviceType": "NVIDIA A10"
    }
  ]
}

Send the JSON output to Dynamia.ai sales or technical support to obtain the license.

Post-Activation Verification

kubectl -n hami-system get pods
kubectl describe node <gpu-node>
kubectl get events --field-selector involvedObject.name=hami-license -n hami-system
kubectl get nodes -o custom-columns='NODE:.metadata.name,LICENSE:.metadata.annotations.hami\.io/nvidia-license'

A LicenseValid event indicates that license validation succeeded. Confirm that the selected component Pods are Running or Completed and that accelerator resources are registered on the managed nodes.

Sample Workload Verification

The full amd64 outer package includes two independent Zarf sample packages. Deploy them after the core components are ready; no manual kubectl apply is needed for these two samples. Slim does not include samples. Their versions are independent of the main package: GPU Burn remains v0.0.2 and vLLM Qwen remains v0.0.4.

GPU Burn Verification

zarf package deploy zarf-package-hami-example-gpu-burn-amd64-v0.0.2.tar.zst --confirm

After deployment, check the Deployment / Pod status:

kubectl -n hami-example get deploy turbo-gpu-burn
kubectl -n hami-example get pods -l app=turbo-gpu-burn
kubectl -n hami-example logs -l app=turbo-gpu-burn --tail=50

This sample creates hami-example/turbo-gpu-burn Deployment; clean it up as needed after verification:

kubectl -n hami-example delete deploy turbo-gpu-burn

vLLM + Qwen Verification

zarf package deploy zarf-package-hami-example-vllm-qwen-amd64-v0.0.4.tar.zst --confirm

After deployment, check the inference service status:

kubectl -n hami-example get deploy vllm-qwen3
kubectl -n hami-example get pods -l app=vllm-qwen3
kubectl -n hami-example get svc vllm-qwen3-webui

Once the Pod is ready, access Open WebUI at http://<node-ip>:30081/openwebui. Confirm that your firewall and cluster network policy allow port 30081.

# Get cluster node IP (any reachable node is fine)
kubectl get nodes -o wide

# Access via browser
# http://<node-ip>:30081/openwebui

Open WebUI is automatically connected to the vLLM sidecar in the same Pod; open the page to start interacting.

If the Pod remains Pending, first check whether the license is activated, whether GPU nodes are labeled with gpu=on, and whether the node GPU drivers are normal.

Troubleshooting

Use the following commands to inspect workloads and recent cluster events:

kubectl get pods -A | grep -E 'hami|gpu-operator|prometheus|vllm|gpu-burn'
kubectl get events -A --sort-by=.lastTimestamp | tail -50
zarf package list

Collect Kubernetes and GPU inventory with collect-cluster-info.sh; see COLLECT-CLUSTER-INFO.md. First install tools to provide jq. It does not install business components. Set PACKAGE to your Enterprise main package below; Slim uses hami-enterprise-slim-v0.0.5-airgap-amd64.tar.zst. For arm64, replace amd64 in both CLI and package names. Preserve the target kubeconfig when using sudo.

KUBECONFIG_PATH="${KUBECONFIG:-$HOME/.kube/config}"
COLLECTOR_PATH="$PWD/collect-cluster-info.sh"
ROOT_PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin"
PACKAGE=./hami-enterprise-v0.0.5-airgap-amd64.tar.zst

sudo env PATH="$ROOT_PATH" sh -c 'command -v kubectl >/dev/null'
sudo env KUBECONFIG="$KUBECONFIG_PATH" PATH="$ROOT_PATH" \
  ./zarf-linux-amd64 package deploy "$PACKAGE" \
  --components=tools --confirm
sudo env PATH="$ROOT_PATH" sh -c 'command -v jq >/dev/null'
sudo env KUBECONFIG="$KUBECONFIG_PATH" PATH="$ROOT_PATH" \
  "$COLLECTOR_PATH" > cluster-info.json
sudo /usr/local/bin/jq empty cluster-info.json

Common Issues

Symptom	Checks and Resolution
hami-device-plugin is not running	Confirm that the node has the gpu=on label, then check kubectl -n hami-system get pods.
hami-device-plugin repeatedly restarts	Check whether NVIDIA GPU Operator still enables its default device plugin. Set the Chart key devicePlugin.enabled=false; in v0.0.5 package values, use gpu-operator.devicePlugin.enabled=false.
Image pull fails	Inspect Pod events, the image reference and registry access. For air-gap deployment, confirm the image is included in the package, the Namespace has zarf.dev/agent: mutate, and the Pod image was rewritten to the Zarf registry. Recreate the Pod after changing mutation labels.
HAMi metrics are unavailable	Check whether the Prometheus or VictoriaMetrics selector matches the labels on the monitoring object.
A workload remains Pending	Check license activation, the gpu=on node label, available accelerator resources, and events from kubectl describe pod.

Limitations of Installing Components with Zarf

Control the Image Rewrite Scope Explicitly with Labels

We recommend initializing Zarf with zarf init --agent-mutation-policy=labeled. This policy rewrites only resources labeled zarf.dev/agent: mutate, or resources in a namespace with that label. An individual workload that must retain its original image reference can be labeled zarf.dev/agent: ignore, and a resource label takes precedence over the namespace label. This allows image rewriting to be controlled per resource, even within the same cluster or namespace, without having the Agent manage every application namespace by default. Only images included in the Zarf package can be rewritten and pulled in an offline environment. After changing labels, recreate existing Pods because they are not updated automatically.

Manage Each Set of Resources Through a Single Delivery Pipeline

Zarf manages the chart releases in a package through Helm. Managing the same Kubernetes resources in parallel through another native Helm workflow can still cause release ownership, field ownership, and upgrade ordering conflicts. Continue routine upgrades with a newer Zarf package. If existing resources must be transferred to Zarf, review the release and resource scope before using --take-ownership. Use --force-conflicts only for Server-Side Apply field conflicts that you have confirmed may be overwritten; it should not be used as a routine installation option.

Support

• Email: info@dynamia.ai

• Sales / technical support: 400-026-7800

• Customers with active commercial agreements should submit support requests through their dedicated support channel.