Prerequisites
Before you deploy Self-Hosted Deployment on premises
์ฝ๋ ์๊ฐ 3๋ถ์ต๊ทผ ์
๋ฐ์ดํธ: 8์ผ ์
Access to the container registry
Ensure that you have credentials for the Unity private container registry . Unity provides these credentials. You need this information to download the vpctl CLI tool, pull release packages, and sync container images and ORAS artifacts to your private registry.
uccmpprivatecloud.azurecr.ioTooling
Ensure that you have this tooling:
-
Access to a terminal, and basic knowledge of the command line
-
One of these tools if you use Microsoft Windows:
- Windows Subsystem for Linux (WSL)
- Git for Windows
-
ORAS CLI, to download the vpctl tool and the pull release packages from the registry
-
Helm (version 3.0 or later), to install the Helm charts
-
kubectl, to interact with your Kubernetes cluster
-
Docker, to sync the container images to your private registry
-
ArgoCD (recommended), for continuous delivery via GitOps
-
vpctl is the Unity CLI tool that manages the entire deployment lifecycle. To install it, refer to Install vpctl.
์ฐธ๊ณ
We recommend ArgoCD as the deployment method. ArgoCD handles CRD installation ordering and detects configuration drift automatically, which makes ongoing operations more reliable. Helm is also fully supported if you prefer direct deployments without a GitOps workflow.
Install the vpctl tool
The vpctl install steps, requirements, and registry credential setup are documented separately. For more information, refer to Install vpctl.
Kubernetes
The deployment requires a Kubernetes cluster that you manage.
Use Kubernetes version 1.33 or later. Newer versions might also work, but we haven't tested them extensively.
Your cluster must include at least 3 schedulable nodes in the general workloads pool. Several stateful components run as 3-replica clusters by default and place each replica on a different node by using on . These components include MongoDB (Percona Server for MongoDB), RabbitMQ, and Garage object storage. PostgreSQL also runs 3 replicas by default. If your cluster has only two nodes, some pods remain in the state because the scheduler can't satisfy the anti-affinity requirement.
podAntiAffinitykubernetes.io/hostnamePendingStorage classes
The cluster must provide two storage classes:
- A default storage class for general-purpose persistent volumes (block storage). For example, a local-path provisioner, a SAN-backed CSI driver, or any block storage provisioner.
- A ReadWriteMany (RWX) storage class for shared volumes that multiple pods can mount simultaneously. For example, an NFS provisioner, a distributed filesystem, or any CSI driver that supports the access mode.
ReadWriteMany
You configure these storage class names in the manifest file during deployment.
Namespaces
Services come preconfigured for use within a single Kubernetes namespace. You configure the target namespace in the manifest file.
Node pools
The platform separates general application workloads from asset transformation jobs. Configure your cluster with three node pools (or equivalent node groups):
Node pool | Node label | Taint | Recommended node size | Purpose |
|---|---|---|---|---|
| General workloads | None required | None | 8โ32 vCPUs; compute, general-purpose, or memory-optimized instances | Application services, databases, messaging |
| Transformations | | None | 8โ32 vCPUs; compute, general-purpose, or memory-optimized instances | Transformation workflow pods |
| Transformations (large) | | | 32โ64 vCPUs; general-purpose or memory-optimized instances | Escalation pool for memory-intensive transformations; only pods that explicitly tolerate the taint are scheduled here |
The exact mechanism to create node pools depends on your Kubernetes distribution (for example, static node labels, a node autoscaler, or a cluster API provider).
Network policies
During deployment to an existing cluster, you may need to control the flow of network traffic by using network policies. You can deploy most Kubernetes resources in a single namespace, which you can use to scope network isolation from other services that run in your cluster.
Container registry
By default, the platform pulls container images directly from the Unity source registry (). This is the simplest setup and doesn't require a separate registry.
uccmpprivatecloud.azurecr.ioIf your environment is air-gapped or if you need full control over artifact distribution, you can mirror artifacts to your own private container registry. Any OCI-compliant registry is supported, for example Harbor, JFrog Artifactory, or a cloud-managed registry such as Amazon ECR or Azure Container Registry. Use these commands to mirror artifacts from the Unity source registry to your private registry:
- : this command syncs the Docker container images.
vpctl artifact sync images - ; this command syncs the ORAS artifacts, for example, the Pixyz workflow templates.
vpctl artifact sync oras - : this command syncs the OCI Helm charts. This command is required only if your manifest opts in to the
vpctl artifact sync chartspreview. This command mirrors only the charts that have been published to the Unity OCI Helm registry so far.deployment.helmChartMode: remote
System requirements
Ensure that you have these elements:
-
A valid hostname that can be updated to point to the IP of the load balancer
-
A valid Plastic license to run the UVCS server
-
A valid Unity Asset Transformer SDK license to run transformations on assetsA valid Unity Asset Transformer license is required for all users who perform asset transformations. The platform uses static licenses, so a floating license server is not required.