The textual user interface (TUI) wizard is organized by deployment concern. Work through the sections from top to bottom for a first-time install, or jump directly to the section you need when editing an existing nv-config-manager-install.yaml.
Sidebar status indicators show which section is selected, complete, or needs attention. Hover over a section for status details.
Set the deployment identity, site list, and resource size profile. These values drive service hostnames, namespace selection, Helm release naming, and generated resource overlays.
Each size profile selects a matching Helm values overlay, such as values-local-small.yaml, that tunes CPU, memory, and replica counts across services.
Sites represent data centers managed by this Config Manager deployment. Each site name must match the slug of the corresponding Nautobot Location. Sites scope per-site network secrets such as device login credentials and BGP passwords.
Choose which Config Manager services this deployment should run.
To use an existing Nautobot instance, configure it on the External Services screen.
Connect Config Manager to existing Nautobot, Redis, Slack, or PostgreSQL services. Leave a service disabled to use the default in-cluster deployment.
Choose where application secrets are stored, and configure Git repository tokens for Nautobot Git sync.
Vault paths map secret groups such as Nautobot, Redis, PostgreSQL, network credentials, OIDC, Redfish, BMC, Slack, AIR, Jira, and CNPG backup settings to the paths used in your Vault layout.
Git tokens create git-token-<name> Kubernetes secrets or ESO-backed Vault references for Nautobot Git sync.
If you are using local Kubernetes secrets, you can optionally supply manual values for each secret, or leave them blank to auto-generate a random secret.
Configure network protocol and workflow secrets written to config-secrets.ini. Common entries are pre-seeded on first run, including hash_salt, bgp_password, root_password, and api_user_key.
The Scan Plugin Templates button inspects Jinja2 templates from Content plugin paths to discover additional required secrets. Add template plugin locations on the Template Plugins screen.
Configure custom Nautobot jobs, bootstrap jobs, and post-deploy job execution. Use this section to stage a Design Builder topology loader, include the standard bootstrap jobs, or run other Nautobot jobs after Helm deployment.
Custom jobs and bootstrap jobs require local Nautobot (services.nautobot: true). If Nautobot is remote, validation shows a warning.
For a concrete Design Builder example, see Design Builder Data Loading.
Configure Jinja2 template plugin directories used by the Render service. The node browser lets you pin plugin PVCs to a Kubernetes node on multi-node clusters that do not have shared RWX storage.
If a PVC is ReadWriteOnce, it can only mount on the node where it was first bound. Pin the pod to that node on multi-node clusters without shared NFS or RWX storage.
Configure where ZTP OS images are stored and which images should be uploaded during deployment.
For S3 bucket storage, configure the bucket name and path prefix. The installer computes SHA256 checksums, creates the expected {platform}/{version}/{filename} directory structure, and uploads the images to the S3 bucket.
For file storage, configure the PVC name, size, storage class, access mode, and images to upload at deploy time. Each OS image entry includes platform, version, and local file path. During deployment, the installer computes SHA256 checksums, creates the expected {platform}/{version}/{filename} directory structure, and writes manifest.json to the PVC root. Images can also be uploaded later through the ZTP /v1/files API.
If a PVC is ReadWriteOnce, it can only mount on the node where it was first bound. Pin the pod to that node on multi-node clusters without shared NFS or RWX storage.
Configure Temporal workflow RBAC defaults and per-workflow overrides.
The workflow list is generated from the Helm RBAC values file.
Configure image source and registry settings.
When Pull from registry is selected, the installer can fetch available tags from the Docker V2 API.
Per-image overrides can set a custom repository or tag for individual components. For local builds, images are tagged with a short content hash derived from the Docker image ID. Helm only restarts pods when image content changes.
Configure OIDC Single Sign-On for Config Manager services.
The configuration samples use Keycloak as the example OIDC provider, but the installer accepts any OIDC provider that supplies the required issuer, client, secret, JWKS, audience, and scope settings.
Configure SPIFFE identity for service-to-service authentication.
Configure gateway behavior, TLS, database backups, monitoring resources, and load balancers.
Load balancer providers include None, MetalLB, Cilium, and AWS NLB. MetalLB and Cilium use static IPs and optional DNS names for ZTP and DHCP. AWS NLB can be configured separately for Gateway, ZTP, and DHCP.
For local or lab deployments using self-signed TLS, the browser and any API clients must trust the generated certificate authority or explicitly accept the warning for each service hostname.
Generate and inspect the complete Helm values YAML before deploying. Use this screen to review exactly what the installer will pass to Helm.
Run deployment orchestration with live monitoring.
Once you have set up your configuration, click the Start Deployment button to begin the deployment process. The deploy screen shows a step list, live pod status, deployment logs, individual pod/container log streams, and integration test output.
If anything goes wrong, correct the error and click the Retry Deployment button to try again.