Skip to content

Mantle 2.0 Physical Network Builds

Purpose

This quick start provides a streamlined, operator-focused procedure for deploying physical network device configurations in Mantle 2.0 using serial console automation. It assumes the target devices will be configured from approved Jinja2 templates and that the operator has access to the required build inputs.

Need a refresher?

Review the Mantle 2.0 Definitions for terms such as Build Interface, PXE Network, and Serial Device Profile before continuing.

What this workflow does

A Physical Network Build in Mantle 2.0:

  • Applies rendered device configuration over serial console connections
  • Uses build-form values as the source of truth for each device
  • Supports parallel execution across multiple target devices
  • Captures post-build output for validation and troubleshooting

A build should be considered complete only when all device tasks finish successfully.

Prerequisites

Before starting, confirm the following:

Required assets in Mantle 2.0

  • Approved Jinja2 network device templates are uploaded in Assets
  • Target devices are supported by Mantle serial device profiles (see Definitions)
  • Required serial ports are enabled and available (map them under Appliance Settings)

Required build inputs

  • Template selection for each target device
  • Device type or device name
  • Correct serial port mapping for each device
  • All required template variable values

Optional inputs

  • Kit ID, if your workflow uses kit-level tracking
  • Existing credentials, if a device has already been configured and must be baselined with the Write/Erase Network Utility first

Connectivity and readiness

  • Mantle has stable serial connectivity to each target device
  • Devices are powered on and reachable on the expected console ports
  • Devices are in a state that allows configuration mode access

Perform these checks before deployment:

  • Template readiness: confirm template syntax and required variables are complete
  • Port readiness: confirm each serial port maps to the correct physical device and is not duplicated
  • Device state: confirm the device can be accessed for factory reset or configuration; if not, run Write/Erase first

Operating model

Mantle treats the build form as the source of truth. For each device, the platform combines:

  • the selected template
  • the selected serial port
  • the device-specific variables entered at build time

This separation allows operators to reuse static assets while changing only the values unique to the current deployment.

Quick start procedure

1. Sign in to Mantle

  1. Open Mantle.
  2. Sign in with the username and password created during installation.
  3. Confirm the Dashboard loads successfully.
  4. Verify that a valid license has been uploaded before using build features.

Mantle login screen

Dashboard after login

To validate licensing:

  1. Click the Settings cog.
  2. Click the green + icon in the upper-right corner.
  3. Select the license file and upload it.
  4. Confirm the license is active and valid.

Open Settings

Add license

Choose and upload license file


2. Verify serial port connectivity

  1. Open the Settings cog.
  2. If already in Settings, select Appliance.
  3. Open Serial Ports.
  4. Verify the correct serial connection is present and ready for use.

Open Appliance settings

Open Serial Ports

Verify serial port availability


3. Factory baseline the device

Use the Write/Erase Network Utility to reset the device to a known-good starting state before applying the production template.

  1. From the Dashboard, click New Build.
  2. Select Network Utilities Build, then click Next.
  3. Click New, then Submit.
  4. Enter the required login credentials.
  5. Confirm the correct serial port and baud rate are selected.
  6. Click Next, then Deploy.
  7. Allow Mantle to complete the factory default process.

Start a new build

Select Network Utilities Build

Create utility build job

Deploy utility build

Factory baseline in progress


4. Add a Kit ID if required

If your workflow uses kit tracking, add the Kit ID after the utility build completes.

  1. Click Kit ID.
  2. Enter the required identifier.
  3. Click Add.
  4. Return to the Dashboard and confirm the Kit ID is associated with the completed build.

Open Kit ID dialog

Enter and add Kit ID


5. Upload the device template

After the device is baselined, upload the Jinja2 template that will be used for production deployment.

  1. In the left navigation, click Assets.
  2. Click the + button in the upper-right corner.
  3. Upload or drag and drop the Jinja2 template.
  4. Click Upload Assets.
  5. In the dropdowns, select Template and the correct template type.
  6. Click Upload All.
  7. Close the confirmation window.
  8. Open Templates and verify the asset appears correctly.

Open Assets

Add new asset

Upload template file

Upload all assets


6. Start the production network build

Once the device has been reset and the template is available, begin the production deployment.

  1. From the Dashboard, click New Build.
  2. Select Network Build, then click Next.
  3. Click New, then Submit.
  4. Select the correct serial port.
  5. Select the device name or type.
  6. Select the appropriate template.
  7. Enter all required variable values.
  8. Click Next, then Deploy.
  9. Monitor the deployment until the build completes.

7. Review and validate the result

When the build finishes:

  1. Confirm the deployment completed successfully without errors.
  2. Review the post-build scan and captured output.
  3. Validate the running configuration, system messages, and interface state.
  4. Investigate any partial success before considering the overall build complete.

Best practices

  • Baseline devices before applying production templates when device state is uncertain.
  • Keep template logic in assets and device-specific data in the build form.
  • Double-check port mappings before deployment to avoid configuring the wrong device.
  • Review post-build output every time, even when the job reports success.
  • Treat serial connectivity issues as blocking conditions, not warnings.