Defense & intelligence · Moraph software

Tactical Edge Compute Node Manager

Keep Kubernetes clusters on deployed vehicles, ships and aircraft patched, consistent and accounted for

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

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.

  • Large updates fail over low-bandwidth or intermittent links and must start again
  • Nodes drift from their approved configuration with no record of who changed what
  • Programs cannot quickly answer which software version is running on which platform
  • Patch evidence for authorization and inspections is assembled by hand

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

Requirements it supports

DoD Instruction 8500.01, CybersecurityDoD Instruction 8510.01, Risk Management Framework for DoD SystemsCNSSI 1253, Security Categorization and Control Selection for National Security SystemsDISA Kubernetes Security Technical Implementation Guide (STIG)NIST SP 800-190, Application Container Security GuideDoD Enterprise DevSecOps Reference Design: CNCF Kubernetes

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    The fleet inventory

    The fleet team starts from one list of fielded nodes, with the software they run, their baseline status and when each last reported.

    NodePlatformReleaseBaselineLast contactStatus
    EN-0142Example Vehicle 124.3.1Compliant2 hours agoCurrent
    EN-0157Example Vessel A4.2.0Compliant1 day agoUpdate staged
    EN-0163Example Aircraft 34.2.0Drift found3 days agoException
    EN-0171Example Vehicle 194.3.1Compliant5 hours agoCurrent
    EN-0188Example Vessel B4.1.2Unknown12 days agoNot reporting
    The fleet team starts from one list of fielded nodes, with the software they run, their baseline status and when each last reported.

  2. Step 2

    Building an update bundle

    A release is packaged with only what changed, signed, and checked by security before it is offered for delivery.

    Release 4.3.1 · Example mission application (fictional)

    Images changed
    3 of 11
    Bundle size
    212 MB (full image set 3.4 GB)
    Pieces
    54, each resumable
    Signed by
    Program release key
    SBOM
    Attached
    Scan result
    1 medium finding, accepted with note

    Included

    • Mission application image update
    • Base image security patches
    • Updated network policy
    A release is packaged with only what changed, signed, and checked by security before it is offered for delivery.

  3. Step 3

    Delivery over a constrained link

    Transfers resume where they stopped, and each node verifies the bundle before it is staged.

    NodeBundleLinkProgressVerifiedNext step
    EN-01574.3.1Satellite, intermittent54 of 54YesAwaiting approval
    EN-01634.3.1Line of sight31 of 54PendingResume at next contact
    EN-01754.3.1Shore network54 of 54YesInstalling
    EN-01884.3.1None available0 of 54NoPhysical transfer planned
    Transfers resume where they stopped, and each node verifies the bundle before it is staged.

  4. Step 4

    The mission owner's approval

    Installation waits for the person responsible for the platform, who sees what will change and when.

    Install 4.3.1 on Example Vessel A

    Node
    EN-0157
    Current release
    4.2.0
    Bundle
    Verified on node
    Maintenance window
    Next scheduled window
    Rollback
    Automatic to 4.2.0 on failed health check

    What changes

    • Mission application updated to 4.3.1
    • Base image security patches applied
    • Mission application restarted during the window
    Installation waits for the person responsible for the platform, who sees what will change and when.

  5. Step 5

    A drift exception

    When a node reports a change outside an approved update, the fleet team sees what changed and decides with security what to do.

    EN-0163 · Example Aircraft 3

    1. Node report received after 3 days without contactSystem
    2. Drift found: logging setting changed on the nodeSystem
    3. Assigned for investigationFleet operator
    4. Change confirmed as an on-site troubleshooting stepField technician
    5. Reverse to baseline at next windowSecurity officer
    When a node reports a change outside an approved update, the fleet team sees what changed and decides with security what to do.

  6. Step 6

    Searching for exposure

    When a vulnerability is announced, the program searches the fleet for the affected component and sees where a fix is waiting.

    ComponentVersionNodes running itFix in releaseFix deliveredNot reporting
    example-tls-library2.8.4144.3.192
    example-tls-library2.9.031Not affectedn/a0
    example-parser1.4.26Pending01
    When a vulnerability is announced, the program searches the fleet for the affected component and sees where a fix is waiting.

Workflows

The principal workflows

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

    • Node registered with its platform, unit and hardware details
    • Cluster configuration compared with the approved baseline
    • Installed software and container images recorded with their SBOMs
    • Link profile set: expected bandwidth, contact windows and fallback transfer method
    • Node shown in the fleet inventory with its compliance status

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

    • Release manager selects the images and configuration to include
    • Bundle built from the differences against what each target node already runs
    • Images and bundle signed, with the SBOM and scan results attached
    • Security review recorded before the bundle is released for delivery
    • Bundle offered for network delivery or exported for approved physical transfer

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

    • Transfer scheduled by priority and the node's link profile
    • Interrupted transfers resume from the last verified piece
    • Node verifies signatures and integrity before staging the update
    • Mission owner approves installation for the platform
    • Update applied in stages with health checks and automatic rollback on failure

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

    • Node status reports queued locally and sent when a link is available
    • Installed versions compared with the release record
    • Configuration drift detected against the approved baseline
    • Exceptions assigned to a fleet operator or field technician
    • Patch and configuration evidence updated for the authorization package

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

Fleet operator

Platform engineer, edge operations engineer, DevSecOps engineer

Keeps the fleet current: schedules deliveries, watches node status and works exceptions until they are resolved.

Sees

  • Every node in their assigned fleet with its release, baseline status and last contact
  • Delivery progress and verification results
  • Drift findings and failed updates
  • Pending installation approvals

Does

  • Schedules delivery of released bundles to nodes and groups of nodes
  • Sets delivery priority and staged rollout groups
  • Investigates drift, failed updates and nodes that stop reporting
  • Assigns on-site work to field technicians
  • Plans physical transfers for unreachable nodes
  • Maintains link profiles and node records

Cannot

  • Build or sign a bundle
  • Approve installation on a platform
  • Change an approved baseline without security officer approval
Approvals
Installations they schedule need the mission owner's approval, and baseline changes they propose need the security officer's approval.
Notified about
Failed deliveries or installations, drift found, nodes not reporting for longer than your procedures set, and approvals granted or deferred.

Release manager

Software release manager, configuration manager, build engineer

Turns approved mission software and patches into signed update bundles ready for delivery.

Sees

  • Images and configuration available from the software factory
  • Scan results and SBOMs for each image
  • Which releases each node runs
  • Bundle history and security review outcomes

Does

  • Selects the images and configuration for a release
  • Builds bundles against the versions nodes already run
  • Signs bundles with the program's release key
  • Sends bundles for security review
  • Exports bundles for physical transfer

Cannot

  • Release a bundle that has not passed security review
  • Approve installation on a platform
  • Change node baselines
Approvals
Each bundle is reviewed by the security officer before it can be delivered.
Notified about
Security review outcomes, bundles returned with comments, and new findings against components in released bundles.

Mission owner

Platform commander's representative, mission system owner, unit maintenance officer

Decides when software changes are installed on the platforms they are responsible for, so updates fit operations.

Sees

  • Pending updates for their platforms and what each will change
  • Maintenance windows and rollback plans
  • Release and baseline status of their nodes

Does

  • Approves or defers installation for a platform
  • Sets or changes maintenance windows
  • Requests an urgent update or a hold on updates
  • Records the reason for a deferral

Cannot

  • Build, sign or change a bundle
  • Change baselines or delivery settings
  • Approve installation on platforms outside their responsibility
Approvals
Their approval is the final step before installation; holds they place can be lifted only by them or a designated alternate.
Notified about
Updates waiting for their approval, failed installations and rollbacks on their platforms.

Field technician

Field service representative, platform maintainer, system technician

Installs, maintains and recovers edge hardware on site, and carries out physical transfers where there is no link.

Sees

  • Work assigned to them and the node records it concerns
  • Bundles prepared for physical transfer to their nodes
  • Recovery runbooks and the approved baseline

Does

  • Installs and enrolls new nodes
  • Carries out physical transfers and confirms verification on the node
  • Records on-site changes and troubleshooting steps
  • Recovers or replaces failed nodes

Cannot

  • Approve installation or change baselines
  • Build or sign bundles
  • See nodes outside their assignment
Approvals
Installations they carry out still need the mission owner's approval; on-site changes are reviewed as drift.
Notified about
New work assigned to them and physical transfers ready to collect.

Information system security officer

ISSO, ISSM, cybersecurity officer

Keeps software and configuration on the fleet within what the authorization allows, and maintains the evidence.

Sees

  • Every bundle with its SBOM, signatures and scan results
  • Baselines and every change to them
  • Drift findings, exposure searches and patch status across the fleet
  • The full audit trail

Does

  • Reviews and approves bundles for delivery
  • Approves or rejects baseline changes
  • Decides how drift is resolved
  • Runs exposure searches when vulnerabilities are announced
  • Exports evidence for the authorization package and inspections

Cannot

  • Approve a bundle they built themselves
  • Edit or delete entries in the audit trail
  • Approve installation on a platform in place of the mission owner
Approvals
Approves bundles and baseline changes; their own proposed baseline changes need a second designated approver.
Notified about
Bundles waiting for review, drift found, failed verifications on nodes, and new findings against fielded components.

Auditor or inspector (read-only)

Cybersecurity inspector, internal auditor, assessor (under temporary access)

Reviews configuration, patch status and update history without being able to change anything.

Sees

  • Inventory, baselines and update history within the scope granted
  • Evidence exports and reports
  • The audit trail

Does

  • Searches and reads records within their scope
  • Exports reports they have been given access to, with each export logged
  • Leaves review notes where the program enables them

Cannot

  • Change, approve or deliver anything
  • See records outside the scope and dates granted
  • Keep access after it expires
Approvals
Their access is approved by the security officer or an administrator, with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the person who approved it.

Administrator

Application administrator, program systems administrator

Manages users, roles and configuration of the management service, without approving releases or installations.

Sees

  • Users, roles, fleets and assignments
  • Service configuration and integration settings
  • The record of permission changes

Does

  • Adds and removes users, or maps them from single sign-on groups
  • Assigns roles, fleets and platforms
  • Maintains integration settings
  • Runs access review reports

Cannot

  • Build, approve or deliver bundles
  • Grant themselves another role without a second administrator or the security officer
  • Change signing keys or trust anchors
Approvals
Role changes that grant release or approval rights are approved by the security officer.
Notified about
Access reviews coming due and accounts not used for a period your policy sets.

Permissions at a glance

ActionFleet operatorRelease mgrMission ownerField techISSOAuditorAdmin
View fleet inventoryFullView onlyOwn work onlyOwn work onlyView onlyView onlyView only
Enroll or retire nodesFullNo accessNo accessOwn work onlyView onlyNo accessNo access
Build and sign bundlesNo accessFullNo accessNo accessView onlyNo accessNo access
Release a bundle for deliveryNo accessNo accessNo accessNo accessApprovesNo accessNo access
Schedule deliveriesFullNo accessNo accessNo accessView onlyNo accessNo access
Approve installationNo accessNo accessApprovesNo accessNo accessNo accessNo access
Carry out physical transfersFullNo accessNo accessOwn work onlyNo accessNo accessNo access
Change baselinesOwn work onlyNo accessNo accessNo accessApprovesNo accessNo access
Resolve drift exceptionsOwn work onlyNo accessNo accessOwn work onlyApprovesNo accessNo access
Export authorization evidenceNo accessNo accessNo accessNo accessFullView onlyNo access
View audit trailNo accessNo accessNo accessNo accessView onlyView onlyView only
Manage users and rolesNo accessNo accessNo accessNo accessApprovesNo accessFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Separation of duties is built in: the person who builds a bundle cannot release it, the person who releases it cannot approve installation on a platform, and nobody approves a baseline change they proposed.
  • Roles are configured with you during implementation. You can rename them, create custom roles, and limit them by program, fleet, unit or platform, so each team sees only the nodes it is responsible for.
  • Every permission change is recorded in the audit trail with who made it and when, and access review reports list each person's roles for periodic certification by the security officer.
  • Staff sign in through your identity provider, and roles can follow its groups. Inspectors and assessors get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

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

How it connects to your systems

Connects toHowWhat flows
Software factory and CI/CD pipelinesReleased container images and configuration from your DevSecOps pipelines are pulled into bundles.In: container images, Helm charts or manifests, build metadata.
Container registriesApproved images are taken from your registry, including registries on disconnected networks.In: image layers, digests and signatures.
Vulnerability scannersScan results from the tools your program already uses are attached to each bundle and image.In: scan findings by image and component.
SBOM WatchtowerSoftware admitted through Moraph's Software Bill of Materials (SBOM) Watchtower can be packaged with its SBOM and admission decision.In: SBOMs and admission decisions. Out: which nodes run each component.
Single sign-onStaff sign in through your identity provider, including with smart cards where your provider supports them.In: user identity and group membership for role assignment.
Security monitoringNode events, drift and failed verifications are sent to your security information and event management system.Out: audit events and node alerts in syslog or JSON.
Work APIInventory, release and update status available to your program's reporting and maintenance systems through the Moraph Work API.Out: nodes, releases, update status and exceptions.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

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.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

10 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Fleet status

For fleet operators and program leads

Every node with its platform, release, baseline status and last contact, with nodes that have stopped reporting shown first.

Break down by
Program, Unit, Platform type, Release, Last contact band
Delivered as
Live dashboard; CSV export
Used for
Seeing at a glance which nodes need attention.

Release rollout

For fleet operators, release managers and program leads

For a release, how many nodes have received, verified, staged, installed or rolled it back, and where it is waiting.

Break down by
Release, Stage, Platform type, Link type
Delivered as
Live dashboard; scheduled email
Used for
Tracking a release to completion across the fleet.

Pending approvals

For mission owners and fleet operators

Installations waiting for approval or deferred, with the reason recorded for each deferral.

Break down by
Mission owner, Platform, Release, Age
Delivered as
Live dashboard; scheduled email
Used for
Keeping updates moving without interrupting operations.

Security

Baseline compliance and drift

For security officer and fleet operators

Nodes in and out of their approved baseline, the drift found on each, and how each exception was resolved.

Break down by
Baseline version, Platform, Setting, Resolution
Delivered as
Live dashboard; PDF and CSV export
Used for
Keeping configuration within what the authorization allows.

Component exposure

For security officer and program leads

Nodes running a named component or version, whether a fix has been released and delivered, and nodes whose status is unknown.

Break down by
Component, Version, Release, Delivery status
Delivered as
On request in the product; CSV export
Used for
Answering what is exposed when a vulnerability is announced.

Verification failures

For security officer

Bundles a node rejected, with the reason, the node and the delivery path.

Break down by
Node, Bundle, Failure reason, Period
Delivered as
Live view; alert to your security monitoring
Used for
Investigating possible tampering or transfer errors.

Authorization and audit

Patch status evidence

For security officer, authorizing official's staff, inspectors

For each node, the releases and patches installed, when, under whose approval, and patches still outstanding.

Break down by
Node, Patch, Install date, Approver
Delivered as
PDF and CSV export
Used for
Supporting your RMF package and continuous monitoring.

Baseline change history

For security officer and assessors

Every change to an approved baseline, who proposed and approved it, and when it took effect on the fleet.

Break down by
Baseline, Change date, Approver, Change type
Delivered as
Live view; PDF and CSV export
Used for
Evidencing configuration management.

Audit trail extract

For inspectors and auditors

Who did what and when for a selected node, bundle, baseline or period, including approvals and deferrals.

Break down by
Record, User, Action, Date range
Delivered as
On request in the product; CSV and PDF export
Used for
Answering inspection requests without assembling evidence by hand.

Program

Fleet currency summary

For program managers

A periodic summary of how many nodes run the current release, how many are behind, open exceptions and releases delivered in the period.

Break down by
Period, Program, Unit
Delivered as
PDF; scheduled email
Used for
Program reviews and planning maintenance support.

Exports, access and evidence

  • Every report can be exported to CSV, and summary and evidence reports to PDF. Reports can be scheduled to arrive by email for the people entitled to see them.
  • Each report can be filtered and the filters saved, so a fleet operator or program manager can keep their own views.
  • Inventory, release and update data is available through the Moraph Work API for your program's maintenance and reporting systems.
  • Reports respect each viewer's role and fleet assignment, and inspectors can be given read-only access to reports and the audit trail.
  • Reports reflect what nodes last reported. Where a node has not reported, reports show its last known state and when that was, rather than assuming it is current.

Deployment

Where and how it runs

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 controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

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.

Limitations

What it does not do

Worth knowing before you evaluate it.

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

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

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

Questions

Frequently asked questions

Does it work when a node is out of contact for long periods?

Yes. Nodes keep running and queue their status reports while disconnected. Waiting updates and reports move at the next contact, and the inventory shows when each node last reported.

Can updates be delivered without any network link?

Yes. Bundles can be exported for transfer through your approved removable-media process. The node verifies the bundle on arrival exactly as it would for a network delivery.

Which Kubernetes distributions does it support?

The agent works with common conformant Kubernetes distributions used at the edge. The distributions and hardware in your fleet are confirmed during scoping.

Is it accredited for classified networks?

Moraph does not claim accreditation. Where you install it on a classified network, it is authorized and operated under your authority, and we provide control mappings and documentation to support your process.

How is it priced?

As a subscription, usually measured by the number of managed nodes, with implementation charged separately. See Working with Moraph for what drives a quotation.

Is there an accessibility conformance report?

Ask for one through the procurement request form at /how-to-buy/request, naming the version you are evaluating.

Next steps

Evaluate Tactical Edge Compute Node Manager

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: Tactical Edge Compute Node Manager guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: Tactical Edge Compute Node Manager support guide.

Related products