Tactical Edge Compute Node Manager

The Tactical Edge Compute Node Manager keeps track of the Kubernetes clusters running on deployed hardware and delivers signed mission software updates and security patches to them over limited, intermittent links. Updates are packaged to move in small resumable pieces, verified on the node before they are applied, and rolled out only when the mission owner approves. Every node's configuration, software versions and update history are recorded, so the program can show what is running where.

The problem it solves

Mission software at the edge runs on hardware that is often out of contact, connected over links with little bandwidth, and maintained by small teams far from the program office. Updates are carried by hand or pushed in large images that fail partway, nodes drift from their approved configuration, and nobody can say with confidence which version is running on which platform. When a vulnerability is announced, the program cannot quickly show which nodes are exposed or prove that a patch was applied.

Who it’s for

• 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

1. EnrollEach 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.
2. PackageA 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.
3. DeliverBundles 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.
4. VerifyWhen 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.

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.

Fleet operator

Monitors the fleet, schedules deliveries and works exceptions such as drift and failed updates

Release manager

Builds, signs and releases update bundles for mission software and patches

Mission owner

Approves when updates are installed on the platforms they are responsible for

Field technician

Installs and recovers nodes on site and carries out physical transfers

Information system security officer

Reviews bundles and baselines, approves baseline changes and keeps the authorization evidence current

Auditor or inspector (read-only)

Views inventory, update history and evidence without being able to change anything

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.

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.

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.

Fleet discovery

We work with your program to list fielded platforms, nodes, clusters and their links, and load them into the inventory. We need hardware and configuration records and a contact from each platform team.

Baseline definition

Approved cluster configurations, including applicable STIG settings, are captured as versioned baselines and reviewed with your security officer.

Signing and key setup

Signing keys and trust anchors are set up under your program's key management, so nodes accept only software your program has signed.

Link and transfer profiles

Delivery settings are agreed for each type of link, along with the approved physical transfer process for nodes that cannot be reached by network.

Pilot platforms

The agent is installed on a small set of platforms and a test release is delivered end to end before the wider fleet is enrolled.

Training and handover

Fleet operators, release managers, mission owners and field technicians are trained on their own workflows, with runbooks for recovery and physical transfer.

• 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.

• Enroll a few lab nodes that match your fielded hardware and compare the inventory with your own records
• Deliver a release over a simulated low-bandwidth link and interrupt it to confirm it resumes
• Tamper with a bundle and confirm the node rejects it
• Change a setting on a node by hand and check that the drift is reported
• Walk a mission owner through an installation approval and a deferral
• Export patch and baseline evidence and review it with your security officer