Config Manager Temporal Deployment Process

Temporal is deployed as part of the Config Manager Helm release. Use the standard deployment guide for connected environments and the airgapped deployment guide for disconnected environments.

Deployment Inputs

The installer controls Temporal deployment through nv-config-manager-install.yaml and generated Helm values:

• services.temporal: enables the Temporal API, workers, and related deployment resources.
• cluster.hostname: drives public workflow API and Temporal Web hostnames.
• secrets: provides database, auth, and integration secrets.
• rbac: configures workflow read and execute roles.
• infrastructure: configures TLS, gateway, storage, and optional observability.

Temporal Images

The managed Temporal deployment uses three independently scoped distroless images:

For a user-managed remote Temporal service, configure the external Temporal connection instead. The chart does not run the server, UI, database schema, namespace, or search-attribute bootstrap workloads in that mode.

Verify Temporal

After deployment, verify the workflow API and Temporal Web routes:

$
kubectl get pods -n <namespace> | grep temporal
$
kubectl get httproutes -n <namespace> | grep -E 'workflow|temporal'

Open the workflow API at https://workflow.<hostname>/docs and Temporal Web at https://temporal.<hostname> if Temporal Web is enabled for the environment.

Operations

For normal operator actions, use the Config Manager UI. Use Temporal Web for detailed workflow event history, retries, payload inspection, and child workflow troubleshooting. See Which Interface Should I Use?.

Worker Reliability

PodDisruptionBudgets

Two PDBs protect Temporal worker pods from simultaneous eviction during voluntary node disruptions (cluster upgrades, autoscaler scale-downs, scheduled maintenance):

With maxUnavailable: 1 and 3 replicas, the Kubernetes eviction API will allow at most one replica to be unavailable at any time. A node drain will block on the second eviction attempt until the first rescheduled pod is Ready.

To inspect the current disruption budget:

$
kubectl get pdb -n <namespace>
$
# NAME                                              MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS
$
# <release>-temporal-worker-pdb                     N/A             1                 1
$
# <release>-temporal-nv-config-manager-worker-pdb   N/A             1                 1

ALLOWED DISRUPTIONS should be replicas - maxUnavailable. If it shows 0, all replicas are already disrupted or not Ready — investigate before draining further nodes.

Pod Anti-Affinity

Both worker Deployments use preferredDuringSchedulingIgnoredDuringExecution pod anti-affinity with topology key kubernetes.io/hostname. The scheduler will prefer placing replicas on separate nodes. In clusters with fewer nodes than replicas the constraint degrades gracefully — pods still schedule, but may co-locate.

To verify replicas are spread across nodes:

$
# Temporal server worker
$
kubectl get pods -n <namespace> \
>
  -l app.kubernetes.io/component=temporal-worker \
>
  -o wide
$
# NODE column should show distinct hostnames across all 3 replicas
$
$
# nv-config-manager workflow executor
$
kubectl get pods -n <namespace> \
>
  -l app.kubernetes.io/component=nv-config-manager-worker \
>
  -o wide
$
# NODE column should show distinct hostnames across all 3 replicas