Use the Config Manager installer for standard, internet-connected deployments. The installer guides you through cluster settings, services, secrets, external integrations, images, and deployment options; saves a repeatable nv-config-manager-install.yaml file; generates Helm values and Kubernetes secrets; and can run the deployment lifecycle from the same terminal interface.
Use this page to:
nv-config-manager-install.yaml configurationFor disconnected environments, use the airgapped deployment guide. To preview Config Manager functionality locally without a real lab, use Local Development Quick Start instead of this production deployment path.
Before you start, install the following tools and confirm you have access to the target cluster and supporting services.
The installer size profile controls Kubernetes resource requests and replica counts. The host or cluster still needs enough capacity for the selected profile.
On Linux hosts running Kind or dense local clusters, raise the default inotify limits before deploying:
For Kind deployments that build and load images locally, use the standard cluster name so the installer loads images into the expected cluster:
On macOS, Terminal.app has limited support for text selection and copy/paste in Textual TUI applications. For the best experience, use iTerm2 or Ghostty.
Local and lab deployments commonly use self-signed TLS. Your browser and API clients must trust the generated certificate authority or explicitly accept the warning for each service hostname before the UIs and APIs behave normally.
Clone the Config Manager platform repository and change into it.
From the Config Manager platform repository, run the installer from the installer directory.
The wizard writes nv-config-manager-install.yaml with owner-only permissions (0600). Treat the file as sensitive because it can contain secrets.
For one-time use from the platform repository, run the CLI with uv.
To make nv-config-manager-installer available as a standalone shell command from the installer package, run:
Run nv-config-manager-installer init to launch the interactive TUI wizard.
The wizard walks through every configuration section, saves the configuration to disk, and can deploy directly from the TUI when you are ready.
Run nv-config-manager-installer validate to validate a configuration file without deploying.
Validation checks include:
cluster.hostnamesso.issuer_url when SSO is enabledUsing ArgoCD? Generate a values file to use instead of managing the full deployment lifecycle with the TUI. Run nv-config-manager-installer generate-values to generate deployment artifacts without running a deployment.
The command writes a values-generated.yaml file to the output directory, combining the installer config and selected size profile.
Run nv-config-manager-installer deploy to run a headless, non-interactive deployment from an existing configuration file.
Use this command for repeatable deploys after you have created and reviewed nv-config-manager-install.yaml.
For a fresh Kind deployment that builds local images, the local-image flags and the three operator install flags are required unless those operators are already installed and images are already available to the cluster. If the Kind cluster name is not nv-config-manager, pass the actual name with --kind-cluster.
Prerequisite operator versions are read from deploy/operator-versions.env. When cluster.airgapped is true, or the chart directory sits inside an airgapped bundle with sibling charts/ and manifests/ directories, the installer uses the local bundled artifacts.
Detailed installer screen fields are documented in TUI Wizard Reference.
Common nv-config-manager-install.yaml examples are documented in Configuration Samples.
When you deploy from the TUI or with nv-config-manager-installer deploy, the installer runs the following steps. Steps are skipped when they do not apply to the selected configuration.
The deployer detects existing deployments and content checksums. On re-runs, it only restarts services when associated PVC content, generated INI content, or other relevant inputs have changed.
The installer can scan Jinja2 template plugins to discover required config secrets before deployment. Start the scan from the Network Secrets screen after selecting your template plugin paths.
Discovered secrets are merged with the existing network secrets list. The installer also pre-seeds common secrets.
For common failure modes and recovery steps, see Troubleshooting.
After deployment, verify that all pods are running and that Gateway or LoadBalancer resources are ready. You can also get the Nautobot admin password to log in to the Nautobot UI.
The commands below use the default nv-config-manager namespace; replace it if your nv-config-manager-install.yaml uses a different namespace.
If DNS is not configured for the selected hostname, add host entries for the gateway address before opening the UIs:
If you enabled self-signed TLS, your browser or API client must trust the generated certificate authority or accept the browser warning for each service hostname in non-production environments.
After pods are running and hostnames resolve, open the Nautobot UI in your browser at https://nautobot.<hostname> and log in with the admin credentials. Local development profiles, such as the SuperPOD sample, may set the password to admin; otherwise use the generated secret lookup above.
Deploying Config Manager with the installer, including any post-deploy Nautobot jobs, is the only step required for day-0 bring-up.
Devices enter Config Manager through Nautobot. You can create them manually, through the Nautobot API, or with a post-deploy job such as a Nautobot Design Builder topology loader. The local SuperPOD profile uses the bundled mock topology Design Builder job in development/mock_topology as an example. See Design Builder Data Loading for the job structure and the context-only customization path.
ZTP is initiated by the device, not by Config Manager. As soon as Config Manager has sufficient Nautobot data, it serves DHCP on the configured network. When a device is cabled and powered on, it gets an IP address and boot file from DHCP, then retrieves its configuration and firmware from the ZTP service. Devices that successfully complete ZTP show a status of Provisioned in Nautobot.
Validation or runtime errors from post-deploy jobs appear in the installer deploy output. Fix the job code, Design Builder design files, or context data and re-run the deployment with the same content.run_after_deploy configuration.
Open the Config Store UI from the Config Manager interface, such as https://config-manager.example.com/configs, and confirm that intended configs are present for every device that should be rendered. If renders are missing, check the render service logs.
Search log output for RenderException, Error processing event, or Python tracebacks to identify the failing device and cause.
To verify that devices have DHCP reservations, call the DHCP config endpoint, usually https://dhcp.<your-hostname>/config?ip_version=4, and search for the device by hostname, IP address, or device UUID.
To verify that DHCP has sufficient data from Nautobot, check the logs of the config-refresh-v4 container in the DHCP refresh pods.
You do not need to redeploy from scratch when you change data, add images, update templates, or upgrade versions. Treat nv-config-manager-install.yaml as the source of truth: re-open it with nv-config-manager-installer init nv-config-manager-install.yaml, adjust the configuration, and deploy again. The deployer applies updates through Helm and only restarts services when relevant inputs have changed.
To change topology, devices, or other data managed by a post-deploy job, edit that job’s context data or design files and re-run the deployment with the same post-deploy job configuration. You can also make changes in the Nautobot UI. For subsequent deployments, remove the job configuration if you do not want the job to overwrite UI changes.
With file-backed OS image storage, add or update image entries in the OS Images section and re-run deployment. The installer updates the PVC layout and manifest, including checksums. If the PVC is backed by NFS, you can also copy images into the expected path and update the manifest manually.
Some environments support the ZTP upload endpoint, which can upload images without re-running deployment. See Upload Images to the ZTP Server for the full procedure across all three approaches.
Set the intended firmware version on the device or in a Config Context that applies to the device, such as by platform. You do not need a new Config Context for every image version.
For a new OS version, add a version-specific entry point in the templates repository, such as a 5.15.0 directory under the platform and role path. Templates are versioned so syntax changes can be tested per OS version.
To completely remove the Config Manager platform deployment: