Unity Cloud Self-Hosted On-premises 2.0.0

This release requires shdctl 1.0.0 or later: install it before you pull the release. Before you upgrade, read the migration guide: it lists the manual steps this release needs, and which deployments each applies to.

Platform service and Keycloak pods restart once during the upgrade.

Check ArgoCD deployments before you upgrade: If you deploy with ArgoCD, check your GitOps repository before you upgrade, or ArgoCD can delete every application and its workloads. For the check and the command, refer to ArgoCD deployments: remove the finalizer of a self-tracking application.

Manifest settings that shdctl 1.0.0 refuses: shdctl 1.0.0 refuses two settings that a manifest written for an earlier release can hold: `_arrayMerge` under `configuration.overrides` , and `configuration.kubernetes.docker.namespace` when you pull from Unity's registry directly. If your manifest holds either, change it before you upgrade: refer to Remove settings that shdctl 1.0.0 refuses from your manifest.

Release package renamed from onprem to shd: The release package files are renamed from "onprem" to "shd". `shdctl release pull` needs no change and keeps working for every version, new or old.

Release package renamed from onprem to shd: If you mirror the release artifact yourself, or script around the package, refer to Update your own mirror and scripts for the shd package name.

Kubernetes 1.34 or later required: Kubernetes 1.33 is past its upstream end of life. `shdctl cluster check` now reports a failure on 1.33. Upgrade your cluster before you deploy this release.

Air-gapped mirrors copy only the images your deployment needs: `shdctl artifact sync images` now copies only the images your deployment needs. With Istio, Prometheus, log collection, or database monitoring turned off, or with `configuration.objectStore.provider: s3` , which stops deploying the in-cluster object store, it no longer copies those images into your registry. It tells you what it left out whenever it skips anything.

Renamed ingress resources: Several `IngressRoute` resources that the release installs are renamed, and so are most of the per-route `Middleware` resources alongside them. The shared middlewares that every route chains, `cors` , `forward-auth` , `strip-backend-prefix` , `remove-authorization-header` , and `security-headers` , keep their names.

Renamed ingress resources: No action is needed beyond the usual redeployment, unless something outside the release refers to one of these resources by name: refer to Update references to renamed ingress resources.

Optimize and Convert pipeline inputs: The Optimize and Convert pipeline now always creates a new asset: its option to add the output to an existing asset (the `CreateNewAsset` input) is removed. `Output Formats` and `Asset Version` are now required, and the output formats no longer default to `glb` and `pxz` , so anything that calls the pipeline must change: refer to Update callers of the Optimize and Convert pipeline.

If you turn one of those features on, run `shdctl artifact sync images` again before you deploy. The images it needs were never mirrored, and an air-gapped cluster can't fetch them at deployment time.

To check a registry against your manifest at any time, run the new `shdctl artifact sync verify` . It lists the missing images and exits with a non-zero code, so a deployment pipeline can stop on it. Run `shdctl artifact sync preflight` first: it confirms your registry credentials, and a verify run that can't read the registry reports every image as missing.

To mirror the full image set as before, run `shdctl artifact sync images --all` . Use it for a registry that deployments with different features enabled share.

Bring your own object storage: Object storage can now be a bucket that you own instead of the in-cluster store. Set `configuration.objectStore.provider: s3` in your manifest, and transformation step logs, MongoDB backups, and Unity Studio publications are written to your own S3-compatible endpoint. The in-cluster store is then no longer deployed.

Bring your own object storage: If you omit `objectStore` , or leave `provider: garage` , the behavior stays exactly as before, so no existing manifest needs to change.

Bring your own object storage: For the endpoint grammar, the warnings that shdctl emits for a partial configuration, and the behavior of each bucket, refer to Bringing your own object storage.

Bring your own object storage: To switch an existing deployment without losing its MongoDB backups or Studio publications, refer to Switching an existing deployment to your own buckets.

Unity Studio is now deployed, as two new services: `studio-file-server` and `studio-publisher-service` . On the in-cluster object store, the deployment creates a `studio-assets` bucket for you, so there's no storage to set up. With `configuration.objectStore.provider: s3` , you must also name `buckets.studioAssets` , extend your access key to it, configure CORS on it, and reach your store over `https` , as described in Bring your own object storage. Studio publications are user data, and no backup that this release configures covers them.

Unity Studio: Action required: before you deploy, allow your cluster's own outbound addresses through your ingress allowlist, or Studio fails while everything else stays healthy. Refer to Ingress.

Unity Studio: Studio trusts a privately issued ingress certificate: if your ingress presents a certificate from a private CA, the `configuration.networking.trustedCaSecretName` you already set covers Studio too. With `configuration.authentication.x509.enabled: true` , however, Studio publishing doesn't work in this release. That setting turns on mutual TLS (mTLS), which requires every client that reaches your deployment to present a certificate of its own, and the Studio publisher has none to present. Nothing in the manifest exempts it, so leave x509 client authentication off if you need Studio publishing.

Optional ingress routes for the ArgoCD, Argo Workflows, and PMM user interfaces: You can now expose the ArgoCD, Argo Workflows, and PMM user interfaces at `argocd.` , `argoworkflows.` , and `pmm.` . All three routes are disabled by default: leave them disabled unless you put authentication in front of them. The Argo Workflows server runs unauthenticated, and its permissions allow submitting workflows and reading namespace secrets, so exposing it grants those capabilities to anyone who can reach your load balancer. Omitting the DNS record doesn't protect the route, because the client supplies the hostname.

Optional ingress routes for the ArgoCD, Argo Workflows, and PMM user interfaces: To enable the routes, first restrict access to trusted sources. `configuration.networking.allowedIngressCIDRs` does that only with the `LoadBalancer` service type; with `NodePort` or `ClusterIP` , restrict access on your own load balancer or firewall. Then set:

Optional ingress routes for the ArgoCD, Argo Workflows, and PMM user interfaces: You must also create DNS records for the hostnames you enable, pointing at your load balancer.

Image pull secret generated for you: `shdctl secret generate` now renders the secret named by `configuration.kubernetes.imagePullSecret` from the container registry credentials you already supply, and `shdctl secret deploy` applies it with the rest. You no longer need the separate `kubectl create secret docker-registry` step.

Image pull secret generated for you: Action required if something else in your cluster creates that secret: refer to Keep an image pull secret that something else creates.

Image pull secret generated for you: The block form, with `name` and `generate` , is the new form of `imagePullSecret` . A plain secret name still works and needs no change now: it means `generate: true` , and shdctl logs a notice that points at the block form until a future release retires the string.

Database monitoring tokens created automatically: When database monitoring is enabled ( `configuration.monitoring.database.enabled: true` ), the PMM server tokens that let the MongoDB and PostgreSQL clusters report to PMM are now created automatically during deployment. `shdctl secret generate` no longer asks you for either token, and you no longer need to create them in the PMM user interface. Each database gets its own PMM service account, so revoking one database's access in PMM leaves the other reporting.

Database monitoring tokens created automatically: During the upgrade to this release, an existing token that you supplied is replaced by a newly created one, and MongoDB and PostgreSQL each restart once to pick up theirs. After that, running `shdctl secret generate` again and reapplying secrets no longer disturbs either token, because neither is part of the generated secrets anymore.

Database monitoring tokens created automatically: If a token ever needs replacing, for example because it was revoked in PMM, set `FORCE_ROTATE` to `"true"` for the `pmm-integration-job` chart through the manifest's per-chart override, and redeploy. `FORCE_ROTATE` covers every monitored database, so both MongoDB and PostgreSQL get new tokens and restart once. Remove the override after that deployment: left in place, the next upgrade issues new tokens and restarts both databases again.

Database monitoring tokens created automatically: If PMM doesn't become reachable, the `pmm-integration-job` job fails without affecting the databases or the rest of the release, but it doesn't retry on its own. Once PMM is healthy, delete the failed job before you redeploy ( `kubectl delete job -n -l app=pmm-integration-job` ); otherwise, the redeployment doesn't recreate it. A database whose token couldn't be created is left unmonitored, and the others are still integrated.

Database monitoring tokens created automatically: Once PostgreSQL reports to PMM, PMM lists a second service next to the database instance, named `-patroni-external` , and shows its status as `Unspecified` or `Failed` even though it works. The metrics it collects are present and queryable; no action is needed.

Size the PostgreSQL backup volume: The new `configuration.infrastructure.components.postgresql.backupStorage` manifest field sizes the volume that PostgreSQL's backups sit on, separately from `storage` , which sizes the database's own data. If you leave it out, the sizing profile decides it as before: 100Gi on `small` , 800Gi on `medium` , and 1600Gi on `large` . It has no effect when `configuration.objectStore.buckets.postgresBackups` sends those backups to a bucket instead.

Size the PostgreSQL backup volume: Raising the value resizes the volume in place, which needs `allowVolumeExpansion: true` on the StorageClass. Lowering it doesn't: a persistent volume can't shrink, so a smaller value is refused and the volume stays as it is. To reclaim space, delete the backup volume and let the operator recreate it, which discards the backup history.

GPU transformations run without GPU nodes: A new `automation-manager` value, `env.vpcGpuAvailable` , defaults to `false` . Set it to `true` only on clusters with GPU nodes. When it's `false` , GPU transformation actions are rewritten to run on the `argocpu` pool with a software rasterizer, instead of staying `Pending` until the workflow times out. The 3D Data Streaming image ships the Mesa lavapipe driver they render with.

Pod annotations, and clusters behind an HTTP proxy: The new `configuration.kubernetes.podAnnotations` manifest field adds annotations to every platform pod. A chart's `configuration.overrides` can change or remove one, with `null` , for that chart alone.

Pod annotations, and clusters behind an HTTP proxy: On AKS with an HTTP proxy ( `httpProxyConfig` ), set `kubernetes.azure.com/no-http-proxy-vars: "true"` , so that no platform pod receives the proxy variables that AKS injects, and services keep reaching each other inside the cluster. Nodes still pull images through the proxy, but the pods get no internet access. The automation-manager job still needs the proxy, to pull the release manifest from your registry: pass it through that chart's overrides, unless your cluster reaches the registry without the proxy.

Pod annotations, and clusters behind an HTTP proxy: For what the proxy must allow, refer to Clusters behind an HTTP proxy.

Before you deploy, create every bucket you name, and one access key pair that can read, write, and delete objects in all of them. Backup retention and pgBackRest both delete what they expire. On this provider, `shdctl secret generate` prompts for that key pair instead of generating one. A key scoped to only some of the buckets generates cleanly, and then fails much later, at backup or transformation time.

`buckets.studioAssets` needs a CORS rule and an `https` endpoint. Allow the origin `https://` , the methods `GET` , `PUT` , and `HEAD` , and all request headers ( `*` ), and expose `ETag` . shdctl checks neither, and both fail only in the browser while the server reports success, so publish an asset and check it rather than trusting a green deployment. If your store is reachable only over `http` , Studio publishing doesn't work in this release.

`buckets.postgresBackups` is optional. Naming it moves PostgreSQL's backups off their persistent volume, and stops provisioning that volume. It requires an `https` endpoint: `shdctl release generate` refuses the combination rather than leaving the bucket unused. If you leave it out, PostgreSQL keeps backing up to its volume, whatever the other buckets are.

On MinIO, Ceph RGW, or StorageGRID, confirm that a transformation's step logs are readable after you switch. `forcePathStyle: true` doesn't yet reach the step-log clients, so working MongoDB backups aren't evidence that step logs work. If they don't, contact Unity. This doesn't apply to AWS S3.

Switching an existing deployment doesn't move PostgreSQL's backup history. A fresh backup chain starts in the bucket. Take a manual backup first if you need the old chain, and keep the backup volume until you're satisfied with the new one.

An endpoint that presents a privately issued certificate isn't supported in this release. It must present a publicly trusted certificate, or be reached over `http` , which neither `postgresBackups` nor `studioAssets` supports.

vpctl is renamed shdctl. The command-line tool is now `shdctl` , and its installer is `install-shdctl.sh` . The installer leaves a `vpctl` symlink, so your existing scripts keep running throughout shdctl 1.x, and print a notice each time. Update your scripts to `shdctl` , and to the `SHDCTL_USERNAME` and `SHDCTL_PASSWORD` environment variables, before shdctl 2.0.0, which drops the old names. Credentials already stored in `~/.vpctl/config.json` are still read; to move them, run `shdctl configure ` .

Secrets files that vpctl persisted don't hold the storage key. If you keep your secret values in a file that vpctl wrote with `--persist` , rebuild it from the cluster before you generate the secrets, or deploying rotates the key the cluster runs with: refer to Rebuild a secrets file that vpctl persisted.

Pipeline automation upgraded to v0.0.77. Snapshot the automation database before you upgrade, and set `DISPLAY` in your own action images if they relied on the platform for it: refer to Automation 0.0.77: snapshot its database first and Set DISPLAY in your own action images.

Monitoring stack installed like every other component. `helm history` , `helm rollback` , and `helm uninstall` now work for it, and its setup jobs run in the correct order on every upgrade. A deployment without ArgoCD now waits for the monitoring stack before it installs the rest of the release, and allows 10 minutes for each component; `shdctl release deploy --timeout` raises that. If you deploy without ArgoCD and already run the monitoring stack, hand it over to Helm once during the upgrade: refer to Helm deployments: hand the monitoring stack over to Helm. Deployments that use ArgoCD need no action.

Failed thumbnail renders retry on a larger node. A failed thumbnail render now retries on the `argocpu-large` pool, requesting 8 CPUs and 48 GB of memory. Make sure that pool can provide a node with that much allocatable capacity, or the retry stays `Pending` until the workflow times out.

Shared workflow volume for 3D Data Streaming. The `automation` service now provisions a shared workflow persistent volume claim ( `sync-share-3dds` , `ReadWriteMany` ) on the storage class named by `configuration.kubernetes.storage.readWriteManyStorageClass` . No action is required if that class already provisions volumes dynamically.

Node drains and cluster upgrades no longer stall on PodDisruptionBudgets. Every service, Keycloak included, now allows one pod at a time to be evicted. Services that run a single replica ( `minReplicas: 1` ) can now be briefly interrupted while their pod moves to another node: set `minReplicas: 2` for any service that must stay up through node maintenance.

Observability stack upgraded. Loki 3.7, Grafana 13.1, Prometheus 3.13, and Alloy v1.18. Each restarts once, so log queries, dashboards, and metric queries are briefly unavailable. Stored logs, stored metrics, and saved dashboards are preserved.

The `platform` manifest field is ignored. You can delete the `platform:` line from your `manifest.yaml` : the generated charts are identical with or without it. Removing it is optional in this release; a future release will reject the field.

Baseline examples are reference code only. The AWS and Azure baseline examples ( `aws-baseline-example/` and `azure-baseline-example/` ) are reference code. Their changes are no longer listed in these release notes, and they may break a stack built from an earlier copy, so review the differences before you reapply one.

Transformations no longer stall on a tainted `argocpu` pool. The four transformation steps that retry on a larger node, Pixyz file import, spatializer, scene analyzer, and Pixyz publisher, no longer stay `Pending` if you taint your `argocpu` pool with `argo-workflows=cpu:NoSchedule` . Pools tainted only with `aks-node-pool` , as the bundled baseline examples are, were never affected.

Upgrades no longer stop at the notification setup. You no longer need to delete the completed `novu-manager` job by hand on every upgrade, and new and changed notification templates now reach Novu.

Built-in workflow templates upload once per release. They're no longer uploaded again every few minutes. If the workflow engine doesn't answer yet when the upload runs, the upload retries for about 2.5 hours before the job is reported as failed; deleting that job runs the upload again.

Transformations start during node maintenance. Starting a transformation no longer fails with `Unexpected error calling Workflow Engine` while nodes are drained: the workflow engine now keeps at least one instance serving.

Fewer restarts under load. Platform services are no longer restarted for briefly failing a health check under heavy load.

Keycloak recovers on its own. A Keycloak pod that loses its place in the cluster now restarts itself after 13 minutes of continuous unreadiness, instead of staying `Running` but never `Ready` until someone deletes it. If Keycloak still ends up short a replica, delete both pods together ( `kubectl delete pod keycloak-0 keycloak-1 -n ` ) and let them come back in order. `kubectl rollout restart` does nothing while a pod is unready, and deleting only the pod that still looks healthy leaves you with no working Keycloak.

Notifications work on single-stack IPv6 clusters. This includes the Dashboard's notification feed and preferences, and notifications for comments and annotations.

Rollouts no longer fail requests. Rolling out or scaling down a platform service no longer fails requests, except on single-stack IPv6: a stopping pod keeps serving for 10 seconds while traffic moves to other replicas, so rollouts and node drains take slightly longer.

The shdctl installer creates its directory. `install-shdctl.sh` now creates a missing installation directory with `sudo` when you can't create it yourself, for example `/opt/bin` as a non-root user.