Tactical Edge Compute Node Manager

Principal workflows

• Enroll: Each edge node and cluster is registered with its platform, hardware, approved configuration baseline and the links it normally uses, so the program has one inventory of what is fielded.
• Package: A software release or patch is assembled into a signed update bundle that contains only what changed, split into pieces that can be sent and resumed over a constrained link.
• Deliver: Bundles move to nodes when links allow, resume where they stopped after a dropped connection, and are verified on the node before anything is applied. Installation waits for the mission owner's approval and the node's maintenance window.
• Verify: When a node reports back, its software versions and configuration are compared with what was approved. Drift, failed updates and nodes that have not reported are flagged for the fleet team.

Who uses it

• Program offices that field mission software on vehicles, ships and aircraft
• Platform and DevSecOps engineers who build and maintain edge Kubernetes clusters
• Unit and platform maintainers who install and recover edge hardware
• Information system security officers and authorizing officials' staff
• Inspectors and auditors who need evidence of configuration and patch status

Reporting

• Fleet inventory and last contact by platform and unit
• Release status: delivered, staged, installed or failed, by node
• Nodes out of baseline and the drift found
• Exposure to a named component or vulnerability across the fleet
• Pending installation approvals by mission owner
• Patch and baseline evidence for authorization and inspections

Features

• Fleet inventory: One record of every fielded node and cluster: platform, unit, hardware, software versions, baseline and last contact.
• Bandwidth-aware updates: Bundles carry only the layers and files that changed, are split into small pieces, and resume after interruption instead of starting again.
• Signed bundles verified on the node: Images and bundles are signed at release, and the node checks signatures and integrity before staging anything.
• Store-and-forward operation: Nodes keep working while disconnected, queue their status reports, and pick up waiting updates at the next contact window.
• Physical transfer option: Where no network link is allowed or available, bundles are exported for transfer through your approved removable-media process and verified on arrival.
• Mission-aware approvals: Installation waits for the mission owner's approval and the platform's maintenance window, so updates do not interrupt operations.
• Staged rollout and rollback: Updates go to a small group of nodes first, health checks run after each stage, and a failed update rolls back to the previous version.
• Configuration baselines: Approved cluster configurations, including STIG settings, are kept as versioned baselines and checked on every node report.
• Drift detection: Changes made on a node outside an approved update are flagged with what changed, so they can be approved into the baseline or reversed.
• SBOM per release: Each bundle carries a software bill of materials, so the program can find which nodes run an affected component when a vulnerability is announced.
• Exposure search: Search the fleet for a component, image or version and see which nodes run it, when they last reported and whether a fix is waiting.
• Authorization evidence: Patch status, baseline compliance and update history exported for your RMF package and inspections.

Integrations

• Software factory and CI/CD pipelines: Released container images and configuration from your DevSecOps pipelines are pulled into bundles.
• Container registries: Approved images are taken from your registry, including registries on disconnected networks.
• Vulnerability scanners: Scan results from the tools your program already uses are attached to each bundle and image.
• SBOM Watchtower: Software admitted through Moraph's Software Bill of Materials (SBOM) Watchtower can be packaged with its SBOM and admission decision.
• Single sign-on: Staff sign in through your identity provider, including with smart cards where your provider supports them.
• Security monitoring: Node events, drift and failed verifications are sent to your security information and event management system.
• Work API: Inventory, release and update status available to your program's reporting and maintenance systems through the Moraph Work API.

Deployment

• Moraph cloud, US region: The management service hosted and operated by Moraph in the United States region, for unclassified fleets.
• Client-hosted: The management service installed in your own environment, including disconnected and classified networks, where it is operated under your authority and your authorization process.
• At the edge: A small agent runs on each node alongside your Kubernetes distribution and keeps working while disconnected.

Security and privacy

• Single sign-on: Staff sign in through your identity provider, so your authentication and multi-factor policies apply.
• Role-based access: What each person can see and do follows their role; building a bundle is separate from approving its installation.
• Signed and verified software: Nodes accept only bundles signed with your program's keys, and reject anything that fails verification.
• Encryption and keys: Client data is encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.
• Complete audit trail: Every release, approval, delivery, installation and baseline change is logged with the person and time, and cannot be edited.
• US-only hosting and support: Hosted in the United States region only; support tickets for defense clients are handled only by US citizens with active clearances, and work on classified networks happens under your authority.

Limitations

• It does not create bandwidth. Delivery depends on the links and contact windows available, and large releases may still take several contacts or a physical transfer.
• It manages the software and configuration on edge clusters; it does not manage radios, networks or the tactical links themselves.
• It does not decide when an update is safe to install during a mission. Installation is approved by the mission owner.
• Nodes that never report back cannot be verified. The inventory shows when each node last reported, rather than assuming it is current.
• It does not test mission software. Functional and safety testing remain with your program before a release is built.
• It does not grant an authority to operate. It produces evidence that supports your authorization process.
• Moraph does not claim accreditation for any classified environment; use on classified networks is under your authority.
• Supported Kubernetes distributions and node hardware are confirmed during scoping; unusual hardware may need additional engineering.

Next steps

Book a demonstration or a technical briefing at www.moraph.com/solutions/tactical-edge-compute-node-manager. Purchasing routes and company information: www.moraph.com/how-to-buy.