Skip to content

Overview

What is Mantle 2.0

Mantle 2.0 brings deployment knowledge, system configuration, and application setup into a single operational platform. It helps teams assemble and apply the configuration required to field mission systems across network infrastructure, compute, virtualization, operating systems, and supported hardware. Instead of relying on multiple specialists to manually perform each step, Mantle organizes those tasks into repeatable workflows that trained operators can execute consistently.

Mantle can work with configurations and deployment requirements drawn from environments such as Cisco and Palo Alto, application stacks such as Compass, TAK, Android, and custom software, and infrastructure spanning VMware, Linux, and supported hardware platforms from vendors including PacStar, KLAS, Samsung, Dell, and HPE. By centralizing that deployment logic in one place, Mantle improves repeatability, reduces manual effort, and helps operators bring systems online faster.

Capability highlights

  • Network configuration workflows: Mantle supports repeatable workflows for applying approved network and security configurations across supported environments, helping teams maintain consistency across kits and deployments.
  • Application deployment and setup: Applications such as Compass, TAK, Android packages, and custom software can be prepared and deployed with their required supporting elements, helping systems arrive configured for operational use.
  • Automated system provisioning: Mantle streamlines virtualization, operating system, and device provisioning through guided workflows that can be launched from the UI or API.
  • Hardware-aware deployment: Mantle uses defined hardware profiles for supported platforms such as PacStar, KLAS, Dell, HPE, and others so deployment workflows can align to the correct interfaces, device roles, and platform-specific requirements.

Why it matters

  • Lower the skill floor: Complex Cisco or VMware procedures show up as guided forms and playbooks, so operators can execute high-end workflows without live SME coverage.
  • Keep experts focused on future capability: Once design intent is captured, engineering teams can spend more time developing the next release while Mantle repeats the validated steps.
  • Bridge edge and home-station teams: A single bundle runs in labs, demos, or DDIL kits, limiting the need for reach-back support when connectivity is constrained.
  • Accelerate mission timelines: Automation delivers networks, applications, infrastructure, and hardware in one push, shrinking the window between requirement and operational use.

How it helps the end user

  • Faster turn-up: Crews power on, select the approved bundle, and Mantle configures the kit without waiting for multiple SMEs to remote in.
  • Consistent outcomes: Infrastructure-as-code keeps every kit aligned with the same capability baseline—no more variation between lab, demo, and edge deployments.
  • Lower cognitive load: Mantle translates engineering intent into guided workflows, so teams focus on mission tasks instead of deciphering integration steps.
  • Resilient operations: Once cached on the node, bundles can be redeployed or recovered entirely offline, enabling DDIL users to maintain capability without expert intervention.

Terminology

Remaining references to "Mantle Enterprise" inside the UI or screenshots map directly to Mantle 2.0 capabilities.

Upgrade Path from Mantle Enterprise

  1. In-place upgrades: Some existing appliances can be upgraded to Mantle 2.0 without redeploying infrastructure or reissuing licenses. Non-Beta Legacy Mantle Enterprise versions cannot be upgraded.
  2. License continuity: Current Enterprise licenses unlock the matching Mantle 2.0 feature sets (Builds, Flow, Mobile, Taclan, etc.).
  3. Asset reuse: VM templates, kickstarts, CSR configs, APKs, and DAGs uploaded in Enterprise remain available after the upgrade.
  4. Backwards-compatible APIs: REST integrations continue to function; new endpoints simply add Mantle 2.0 metadata.

Terminology

  • Mantle Node: An appliance or VM that executes builds, automation, and synchronization tasks for a specific program or group.
  • Asset: Any uploadable artifact (OVAs, kickstarts, playbooks, CSR templates, APKs, PDFs)-that Mantle tracks and versions.
  • Provision: A queued workflow (VMware, Linux, mobile, physical network, or Mantle Flow) assigned to one or more nodes.
  • Build Interface: The optional PXE/serial network used for datacenter or physical network automation.
  • Edge / Lab / Demo Modes: Pre-defined operating postures used throughout the docs to describe tactical deployments, integration labs, or portable demo kits.

Platform Pillars

Asset Synchronization

Upload artifacts once and let Mantle 2.0 replicate them to every authorized node with source-of-truth tracking.

Centralized Provisioning

Define builds centrally, allow nodes to pull approved jobs, and maintain a single history of what ran, when, and on which hardware.

Observability & Compliance

Aggregate logs, run states, and flow telemetry so accreditation teams and mission partners can audit activity from a single dashboard.

Disconnected Operations

Operate fully offline in Edge/Lab/Demo kits, then reconcile jobs and assets when the appliance reconnects to higher networks.

Benefits at a Glance

  • Faster fielding: Repeatable builds cut hours or days off deployment timelines.
  • Scale without surprises: Version-controlled assets plus automation guardrails reduce drift across large fleets.
  • Improved mission assurance: Consistent logging and Mantle Flow summaries simplify after-action analysis.
  • Governance ready: Role-based approvals and immutable history align with cybersecurity and RMF expectations.

Primary Deployment Scenarios

  • Edge Sites: Fully ruggedized nodes that provision physical networks, servers, and mobile devices in contested environments.
  • Integration Labs: Central engineering centers where teams test upgrades, simulate builds, and certify automation before release.
  • Demo & Training Kits: Portable laptops or NUCs that showcase Mantle workflows for leadership briefings or operator training.

Key Resources

Quickstart PDF Guides

Need an offline-ready version of the build steps? Download the latest quickstart references directly from the docs site:

Network Ports and Protocols

Overview

Mantle 2.0 relies on two logical networks:

  • Management Plane: Web UI, API, SSH console, Mantle Flow traffic, and observability feeds.
  • Build / PXE Plane: Automated OS builds, DHCP/TFTP/HTTP delivery, and serial hub workflows.

Plan firewall openings, VLANs, and MTU requirements before powering on the appliance so the Getting Started workflow can complete without rework.

Quick Reference Tables

Inbound to the Management Plane

Purpose Port Protocol Notes
Web UI / API (Nginx - React/FastAPI) 443 TCP Primary entry point for operators and REST clients. Port 80 redirects to HTTPS.
HTTP redirect 80 TCP Optional redirect only. Disable if the environment blocks plain HTTP.
SSH (optional) 22 TCP For console access or troubleshooting. Restrict to jump hosts if not needed.
Cockpit (optional) 9090 TCP OS management portal; expose only when remote OS access is required.

Build / PXE Plane (optional interface)

Purpose Port Protocol Notes
DHCP server 67/UDP (server), 68/UDP (client) DHCP Needed when Mantle issues PXE bootstrap leases.
TFTP 69/UDP TFTP Legacy BIOS PXE payload delivery.
HTTP asset repo 80/TCP HTTP Serves kickstarts, kernels/initrds, and automation artifacts.
HTTPS asset repo 443/TCP HTTPS Optional secure delivery for PXE payloads.

Outbound from Mantle

Destination Port Protocol Reason
DNS resolvers 53 TCP/UDP Hostname resolution for licenses, repos, and webhook targets.
NTP servers 123 UDP Keeps TLS certificates, syslog, and job logs aligned.
External license/asset repos 443 TCP Download updated licenses, OVAs, or APKs when Internet access is allowed.
Git/Artifact mirrors (optional) 22/443 TCP When Mantle pulls kickstart templates or playbooks directly from SCM.

Internal Container/Service Ports (no external exposure)

Service Port Notes
FastAPI backend 8000 Serves API requests behind Nginx.
React frontend 3000 UI assets served via Nginx.
MongoDB 27017 Database for objects, builds, and logs; bound to the Docker network only.
Celery / Worker queue 5672/6379 RabbitMQ or Redis depending on deployment.

Important: Do not expose internal container ports outside the host. Restrict access to 80/443/22 (and any approved optional services) at the hypervisor or firewall layer.

Planning Guidelines

  1. Segment the networks early. Assign separate port groups or VLANs before importing the OVA. Place "Management" on a trusted admin network and isolate "Build/PXE" so rogue devices cannot request DHCP leases or PXE payloads.
  2. Document default gateway expectations. The management plane needs routes to DNS, NTP, and downstream automation targets. The PXE plane usually remains unrouted; confirm whether it should stay air-gapped.
  3. Sequence firewall openings. Approve 443 (and optional 22) first so operators can complete the Getting Started workflow. Only enable DHCP/TFTP/HTTP once you are ready to run builds.
  4. Decide on DHCP ownership. If Mantle hosts the PXE scope, allow broadcasts on UDP/67 and ensure no other DHCP servers exist on that VLAN. If another DHCP server is used, forward helper-address traffic only to Mantle's TFTP/HTTP ports.
  5. Control outbound dependencies. Stage licenses and artifacts internally for air-gapped sites. When Internet egress is allowed, limit Mantle to known destinations (Git mirrors, artifact repositories, TAC portals).
  6. Mantle Flow allowances. Mantle Flow runs Ansible playbooks and DAG tasks that may connect to remote devices over SSH/HTTPS/WinRM. Build allow-lists from the Mantle management IP range to all automation targets and monitor those flows.
  7. Serial/console infrastructure. When using terminal servers or USB hubs, document TCP ports (often 2001-2032) and restrict those hosts to the Build/PXE network only.
  8. Logging and monitoring. Enable logging on 80/443/22 inbound rules and DHCP/TFTP/HTTP rules to PXE networks. Forward Mantle OS logs to your SIEM for centralized auditing.
  9. Change-control alignment. Capture firewall objects, VLAN IDs, and MTU requirements in change records so future Mantle upgrades follow the same blueprint.

Troubleshooting Tips

  • Verify listeners. sudo ss -tulpn confirms Nginx (80/443), SSH (22), DHCP (67/UDP), and TFTP/HTTP processes are bound to the correct interfaces.
  • Check interface mapping. nmcli connection show reveals which VLAN or port group each NIC uses; many PXE issues stem from swapped adapters.
  • Capture PXE traffic. sudo tcpdump -i <build-nic> port 67 or port 69 verifies DHCP offers and TFTP requests leave the appliance.
  • Audit firewalls. Review upstream firewall logs for denied entries referencing Mantle's management IP on 443/22 or the build IP on DHCP/TFTP/HTTP.
  • USB / serial hub checks. lsusb and dmesg | grep ttyUSB confirm the OS sees connected hubs before launching physical network builds.
  • Mantle Flow runs. If DAGs stall, open Automation & Playbooks -> Track Flow, download the configuration object, and confirm firewall rules permit the target device IPs.

Next Steps

With port policies in place, proceed with:

  1. Install Guide verify network adapters and VM settings align with the firewall design.
  2. VMware & Linux Builds configure datacenter builds that depend on PXE services.
  3. Physical Network Builds confirm Mantle reaches terminal servers or USB hubs.
  4. Mantle Flow ensure downstream devices accept SSH/HTTPS connections from the Mantle management network before running automation.

Architecture Diagram(s)

Mantle 2.0's architecture facilitates seamless communication and provisioning across distributed nodes, ensuring high efficiency and scalability. Key components include:

  • MANTLE Nodes: Each node independently pulls tasks from the provisioning queue to ensure efficient execution.
  • Centralized Dashboard: Provides a unified view of all assets and configurations, facilitating efficient troubleshooting and monitoring.
  • Offline Capabilities: Nodes can operate autonomously and synchronize upon reconnection.

(Refer to the diagram on Page 2 of the whitepaper for a detailed visualization of the architecture.)