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?.

Workflow Schedulers

The <release>-temporal-scheduler Deployment runs the scheduler host. The host discovers every scheduler contributed by the built-in workflows package and installed workflow plugins, then runs only the schedulers selected in Helm values. Installing or upgrading a plugin never starts a scheduler on its own.

Each scheduler has a stable identity of the form <plugin-name>.<name>, such as builtin.backup for the built-in backup scheduler or acme.cleanup for a scheduler from a plugin named acme. Every dot-separated segment starts with a lowercase letter and contains only lowercase letters, digits, underscores, or hyphens. The first segment must be the contributing plugin’s name, so plugins cannot claim each other’s identities, and the builtin. prefix is reserved for built-in schedulers. A plugin that contributes schedulers also cannot have a name starting with backup-, which is reserved for the built-in backup scheduler’s schedule IDs; identities such as acme.backup are allowed. The workflows package README lists accepted and rejected examples for plugin authors. The workflow API, the workflow worker, the scheduler host, and the MCP server each build the full workflow registry at startup, so a plugin or scheduler that breaks these rules, or any other plugin discovery or validation error, stops all of them from starting, even if the scheduler is not enabled.

Schedulers are enabled per stable identity under temporal.scheduler.schedulers. The chart default enables the built-in backup scheduler for the nautobot-2x DCIM provider:

temporal:
  scheduler:
    enabled: true
    schedulers:
      builtin.backup:
        enabled: true
        requiresDcimProvider: nautobot-2x

Helm merges maps across values files, so an environment lists only the entries it changes. To run a plugin scheduler in addition to the built-in backup scheduler:

temporal:
  scheduler:
    schedulers:
      acme.cleanup:
        enabled: true

To restrict a plugin scheduler to one DCIM provider, set requiresDcimProvider on its entry. Helm selects the entry only when dcim.provider matches:

temporal:
  scheduler:
    schedulers:
      acme.cleanup:
        enabled: true
        requiresDcimProvider: nautobot-2x

To stop reconciling device backup schedules:

temporal:
  scheduler:
    schedulers:
      builtin.backup:
        enabled: false

Turning off builtin.backup, here or with temporal.scheduler.enabled: false, does not delete its existing backup-<device-id> schedules, which keep starting a backup for each device every 12 hours. Delete them in Temporal Web or with the Temporal CLI, for example temporal schedule delete --schedule-id backup-<device-id>.

Identities contain dots, so escape them when using --set:

helm upgrade <release> <chart> --reuse-values \
  --set 'temporal.scheduler.schedulers.builtin\.backup.enabled=false'

Selection rules:

• builtin.backup keeps a Temporal schedule backup-<device-id> for every backup-enabled device, runs each backup every 12 hours with up to one hour of jitter, and reconciles the device set every 10 minutes. Its default entry declares requiresDcimProvider: nautobot-2x, so by default Helm deploys it only on Nautobot. The scheduler host does not check the DCIM provider. If you set requiresDcimProvider: null on this entry, Helm deploys the backup scheduler and it runs against the configured DCIM provider, which must list backup-enabled devices. Listing backup-enabled devices is part of the required DCIM client interface.
• Each entry must be a map with a boolean enabled flag. The optional requiresDcimProvider must be a non-empty string; otherwise rendering fails. Set requiresDcimProvider: null to remove a requirement inherited from the chart defaults, which makes the entry run on any provider; it does not turn the scheduler off. Use enabled: false for that.
• Helm selects an entry when enabled is true and its requiresDcimProvider, if set, matches dcim.provider.
• The Deployment is rendered only when at least one scheduler is selected. Installs on a DCIM provider other than nautobot-2x that enable no plugin schedulers have no scheduler pod.
• On nautobot-2x, the pod waits for Nautobot before starting only when a builtin. scheduler is selected. The host gives DCIM access only to built-in schedulers, so a pod that runs only plugin schedulers starts while Nautobot is unavailable.
• If an existing release was installed from a chart that predates temporal.scheduler.schedulers, helm upgrade --reuse-values reuses values with no schedulers map, so rendering fails with temporal.scheduler.schedulers is missing before anything is applied; the running release is untouched. Upgrade without --reuse-values, or also pass --set 'temporal.scheduler.schedulers.builtin\.backup.enabled=true' --set 'temporal.scheduler.schedulers.builtin\.backup.requiresDcimProvider=nautobot-2x' to keep the chart default. Pass both: reused values have no default to merge, so without requiresDcimProvider the backup scheduler would also be deployed for other DCIM providers. To run no schedulers, set temporal.scheduler.enabled=false. The check fires only when the map is missing: if the same upgrade sets any other entry, such as --set 'temporal.scheduler.schedulers.acme\.cleanup.enabled=true', the map exists without builtin.backup, so rendering succeeds and backup reconciliation silently stops. Pass both builtin.backup settings in that case too.
• A selected identity that no installed plugin provides stops the scheduler host at startup with Unknown enabled workflow scheduler identities.
• The host constructs every selected scheduler before starting any. If a constructor raises, the host logs Failed to construct workflow scheduler <identity> from plugin <plugin> and exits nonzero before any scheduler runs. On SIGTERM or SIGINT, the host logs Received signal <signal>, stopping workflow schedulers, cancels every scheduler, and exits 0.
• Selected schedulers share one pod and fail together. If any scheduler raises an unhandled exception or returns, the host stops every other scheduler, including builtin.backup, and exits nonzero so that Kubernetes restarts the pod. The Workflow scheduler <identity> from plugin <plugin> failed or ... returned unexpectedly log message names the failing scheduler; set its entry to enabled: false to keep the others running.
• temporal.scheduler.enabled: false removes the Deployment entirely.
• The host reads NVCM_ENABLED_SCHEDULERS as a comma-separated list of identities, which Helm sets from the selected entries. An identity listed more than once stops the scheduler host at startup with NVCM_ENABLED_SCHEDULERS contains a scheduler identity more than once. When you run nv-config-manager-temporal-scheduler directly, outside Helm, and the variable is unset, the host runs builtin.backup against the configured DCIM provider. If it is set to an empty value, the host runs no schedulers, logs a warning, and waits for shutdown.

The host logs the workflow plugin manifest and the selected scheduler identities at startup:

kubectl logs -n <namespace> deploy/<release>-temporal-scheduler | grep -E 'Loaded workflow plugin|Workflow registry manifest|Enabled workflow schedulers'

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