Why defense compute at the tactical edge is a distinct fleet management problem
Defense and intelligence operations increasingly require containerized workloads to run at the physical point of data collection: on personnel in the field, on tactical vehicles, and at forward-deployed locations. The operational case is straightforward. Transmitting raw sensor data, imagery, and intelligence feeds back to a centralized processing facility over constrained, intermittent links consumes bandwidth that does not exist and introduces latency that is operationally unacceptable. Processing locally and transmitting only refined, decision-ready outputs changes that equation fundamentally.
The infrastructure problem this creates is less commonly understood. The field devices running these workloads operate in denied, disrupted, intermittent, and limited (DDIL) connectivity environments. The networks available are commercial: local cellular, LEO satellite uplinks, regional ISPs in austere locations. Those networks are inherently untrusted and actively monitored by adversaries. The conventional response, bolting a VPN onto the field device, requires open inbound ports, which means the device has a public IP presence that can be enumerated, scanned, and attacked. A field compute node with an exposed inbound port is a liability in a contested environment regardless of how capable the workloads running on it are.
The same problem exists at the other end of the deployment spectrum: fixed and semi-fixed defense installations running decades-old operational technology infrastructure with no centralized visibility, no early warning capability, and no management tooling that was designed for the security constraints of a defense environment. The OT devices that run power generation, HVAC, physical access control, and building management systems were not designed with network security in mind. Connecting them to any network using conventional approaches expands the attack surface rather than solving the visibility problem.
Three examples of how Portainer could help
Important: The scenarios on this page are examples of how Portainer could help in this sector. They are not Portainer customer references, partner references, or endorsed use cases. Named programs, platforms, and organizations are referenced solely on the basis of publicly available information from official government sources and published defense documentation. Portainer has no confirmed engagement, relationship, or involvement with any of the programs or organizations referenced here unless explicitly stated elsewhere. Nothing on this page should be read as implying otherwise.
Wearable compute, vehicle-mounted racks, and air-deployable field compute units at the hostile edge
Defense and intelligence operations require containerized workloads to run at the physical point of data collection: on personnel in the field, on tactical vehicles, and at forward-deployed positions. Transmitting raw sensor data over constrained, intermittent links to a centralized facility consumes bandwidth that does not exist and introduces latency that is operationally unacceptable. Processing locally and transmitting only refined, decision-ready outputs changes that equation fundamentally.
The architecture spans three hardware tiers. Wearable backpack compute runs Nova8 hardened OS, bootstrapping KubeSolo (under 200MB RAM) and auto-registering with the central Portainer instance on first connectivity. Vehicle-mounted micro-racks in Humvees and MRAPs extend the same Nova8 and KubeSolo stack with additional compute headroom, supporting heavier inference workloads and acting as local aggregation points. Air-deployable ruggedized field compute units: built to military transport specifications and compatible with C-17 and C-130 cargo configurations: run multi-node Kubernetes on Talos OS and can be brought operational within hours of reaching a forward position. All three tiers are governed from a single Portainer server at the command center. Xiid's Terniion secures the management channel on all tiers: outbound-only, triple-encrypted, process-to-process tunnels over any available commercial network. The field device has no public IP presence and cannot be enumerated by adversaries.
OT infrastructure visibility and management across fixed and semi-fixed defense installations
Defense installations run operational technology infrastructure that is in most cases decades old, proprietary, and entirely unmonitored at scale: power generation and distribution equipment, HVAC and environmental controls, physical access control, fire suppression, building management systems, and fuel monitoring. When a generator degrades or a cooling system fails, the failure is typically discovered after the fact. There is no unified visibility layer, no early warning, and no way for central facilities teams to understand the state of distributed infrastructure without dispatching personnel.
Containerized OT collector workloads deployed on small ruggedized gateway hardware adjacent to legacy PLCs and building systems (Modbus, BACnet, DNP3, PROFIBUS) collect and normalize telemetry and feed it back to a central operations dashboard. The gateway requires no modification to the underlying OT devices: it sits physically adjacent and handles all external communication on their behalf. Xiid's Terniion secures the backhaul: outbound-only SealedTunnel, no inbound exposure, legacy devices gain centralized visibility without any increase in attack surface.
Containerized workloads on autonomous aerial and maritime platforms
Autonomous aerial and unmanned surface platforms require containerized AI, computer vision, mission autonomy, and sensor fusion workloads to run directly on-platform: at operational speed, with no dependency on a live communications link to a command center. The platform must continue executing its mission if that link is lost entirely.
The U.S. Navy's Unmanned Surface Vessel Squadron Three (USVRON-3), established in May 2024 at Naval Amphibious Base Coronado, is referenced here solely as a publicly documented example of where Portainer could help. Portainer has no confirmed relationship, engagement, or involvement with USVRON-3 or any associated Navy program. The squadron operates Global Autonomous Reconnaissance Craft (GARC): 16-foot autonomous surface vessels built by Maritime Applied Physics Corporation. Its personnel are designated subject matter experts in computer vision, mission autonomy, navigation autonomy, data systems, AI, and machine learning on robotic autonomous system platforms, operating at the tactical edge. The Navy's broader Modular Attack Surface Craft program explicitly specifies containerized payload solutions and open architecture standards for autonomy, perception, and C2 software, and requires vessels to continue operating autonomously if communications with the control station are lost. The operational specifics of what runs on these platforms are not publicly disclosed. What is public is the architectural requirement: containerized workloads, open standards, DDIL autonomy, and AI inference on-platform.
Three tiers of field compute, one management plane
The tactical edge architecture is organized across three hardware tiers that share a common software philosophy but differ deliberately in compute headroom, form factor, and OS stack.
Wearable / backpack compute
Ruggedized compute small enough to carry in a backpack. Runs Nova8 hardened OS, bootstrapping KubeSolo (single-node Kubernetes, under 200MB RAM) and auto-registering with the central Portainer instance the moment connectivity is established. Personnel in the field have zero provisioning burden. Connects via LEO satellite uplink. All traffic carried through Terniion tunnel from first contact.
Vehicle-mounted micro-rack
The same Nova8 and KubeSolo stack deployed as a micro-rack in Humvees, MRAPs, and other tactical platforms. Additional compute headroom supports heavier inference workloads and allows the vehicle node to act as a local aggregation point for nearby wearable devices. Connectivity over cellular and SATCOM links, with Terniion re-establishing the tunnel automatically as the vehicle moves between networks.
Air-deployable field compute unit
A ruggedized compute unit built to military transport specifications, compatible with C-17 and C-130 cargo configurations. Transportable to a forward position and operational within hours of landing. Runs a multi-node Kubernetes cluster on Talos OS (immutable, no SSH attack surface). Provides the heavy compute layer of the field hierarchy: multi-stream AI inference, large-scale data processing, and local aggregation for the tiers above it. Connects via the same Terniion model.
All three tiers are governed from a single Portainer server at the command center. Workload deployments push from Portainer through the Terniion tunnels to target nodes without any field device needing to expose an inbound port to receive them. Intelligence data and operational telemetry flow back up the same tunnels.
How the Portainer and Terniion stack fits together
Deployment and management in practice
Field device powers on and bootstraps automatically
On wearable and vehicle-tier devices, Nova8 OS handles installation, hardening, and KubeSolo configuration from a pre-staged image. The Terniion STLink agent, deployed as a container, immediately closes all inbound firewall ports on the host and initiates an outbound-only encrypted tunnel to the self-hosted Terniion Connector fleet at the command center. The field operator has zero provisioning burden. The device appears in the central Portainer fleet view within seconds of establishing connectivity, with its node status, running workloads, and available resources visible.
Workloads deploy from command through the tunnel
Intelligence workloads, sensor processing applications, and OT collector stacks are defined as Kubernetes manifests or Helm charts in a Git repository. Portainer's GitOps engine targets the appropriate field devices and deploys through the Terniion-secured tunnel. The field device never opens an inbound port to receive the deployment. Container images are pulled from a self-hosted registry, also accessible only through the Terniion-protected backplane. Deployment status, container health, and resource utilization are visible in the central Portainer dashboard in real time.
DDIL connectivity is handled transparently
Terniion was engineered specifically for degraded network environments. The STLink agent maintains session persistence across high-latency, high-packet-loss connections, reducing network jitter by up to 96% over unstable links. When a field device loses connectivity entirely, the Portainer agent buffers state locally and continues running workloads. Update instructions queued while the device was offline are delivered automatically on reconnection. No manual intervention is required at the device.
OT gateways provide installation visibility without exposure
For fixed and semi-fixed installation infrastructure, small ruggedized OT gateway hardware is positioned adjacent to legacy PLCs and building management systems. The gateway runs containerized protocol adapter workloads (Node-RED for Modbus/BACnet/DNP3 translation, Telegraf for metric collection) managed by Portainer, with Terniion securing the backhaul. The legacy OT device is never connected to any public network. The gateway handles all external communication on its behalf, making the underlying device non-addressable while feeding normalized telemetry to the central operations dashboard.
RBAC scopes access by tier, site, and function
Portainer's RBAC model maps to the organizational structure of a defense deployment. A field operations team for a specific region sees only their devices. An OT facilities team at a specific installation sees only their gateways. An application team can deploy workloads to their assigned fleet without access to the underlying infrastructure configuration. All access is audit-logged. Every deployment, configuration change, and workload restart is recorded with the user, timestamp, and outcome.
Why Portainer for defense technology deployments
DADMS approved · FIPS 140-3 compliant · TAA compliant
Portainer is listed on the DoD Approved Products List via DADMS and is FIPS 140-3 compliant and TAA compliant. These are verifiable approvals that matter in federal procurement and security assessment contexts. Deploying a DADMS-listed, FIPS 140-3 validated platform directly reduces the documentation burden for the overall system ATO, because the compliance evidence for the platform itself has already been produced and accepted.
100% self-hosted · 100% air-gap · zero external dependencies
Portainer runs entirely on hardware the agency controls, in facilities the agency controls. There is no SaaS control plane, no licensing server that requires internet connectivity, no telemetry phoning home, and no third-party infrastructure in the data path. Air-gap operation is not a feature add-on: it is the default. An agency can deploy and operate Portainer across thousands of nodes with zero external network access whatsoever. This is a non-negotiable requirement in classified and sensitive compartmented environments, and Portainer satisfies it without compromise.
TAA compliant · New Zealand HQ · Five Eyes · US-deemed domestic supplier
Portainer is headquartered in New Zealand, a Five Eyes signals intelligence partner and a US-designated friendly nation. Under the Trade Agreements Act and US procurement policy, New Zealand is treated as a domestic supplier for federal acquisitions: Portainer does not carry the supply chain risk, foreign ownership concerns, or procurement friction associated with vendors from non-allied nations. For defense procurement teams navigating supplier vetting, this matters. It removes a category of risk that many alternative platforms cannot address.
Already deployed across defense agencies in Five Eyes member nations
Portainer is in active use across defense agencies in Five Eyes member nations. The platform is not being proposed for defense use: it is already there. That operational track record in sensitive government environments is a material differentiator from platforms that are proposing a first defense deployment.
One management plane for every deployment context
A wearable node in a contested environment, a vehicle rack advancing with a ground unit, a forward-deployed field compute unit, an OT gateway at a fixed installation, and an autonomous platform operating in a denied environment all appear in the same Portainer fleet view, receive deployments through the same toolchain, and are governed by the same RBAC and audit model. There is no separate management system per deployment context, no bespoke provisioning pipeline, and no single-point-of-failure engineer who built something custom.
DDIL-native: designed for intermittent and denied connectivity
The Portainer edge agent was designed from the ground up for environments where connectivity between the field device and the central management plane is not continuous. The agent buffers state locally, continues running workloads regardless of connectivity, and syncs with the central server when connectivity resumes. Update instructions queued while a device was offline or operating in a denied environment are delivered automatically on reconnection. This is not a contingency mode: it is the baseline operational behavior.
Commercial networks replace expensive military circuits
Provisioning a dedicated DISA circuit for a new tactical site takes six to eighteen months and carries significant recurring cost. Portainer operates identically over commercial broadband, cellular, LEO satellite, or any available IP network. When used with Xiid Terniion on the first two deployment contexts above, the commercial network is treated as fully untrusted by architecture: the security posture does not depend on the underlying network's integrity. Deployment timelines drop from months to days and cost drops proportionally.
Portainer is already in defense. Let's talk about your environment.
DADMS approved, FIPS 140-3 compliant, TAA compliant, Five Eyes supply chain. If you are scoping a tactical edge compute deployment, a defense installation OT management program, or an autonomous platform software architecture, talk to a solutions engineer.
Frequently asked questions
Direct answers to questions about Portainer's suitability for defense technology deployments.
Is Portainer approved for use on DoD networks?
Portainer is listed on the DoD Approved Products List via DADMS (Defense Acquisition Data Management System). It is FIPS 140-3 compliant and TAA compliant. These are verifiable approvals. Portainer does not currently hold a DoD Authority to Operate in its own right — an ATO is issued per deployment and per environment, not per product. Portainer's DADMS listing and compliance posture materially reduce the documentation burden when pursuing a system-level ATO.
Does Portainer support fully air-gapped defense deployments?
Yes. Portainer is 100% self-hosted and 100% air-gap capable. There is no SaaS control plane, no licensing server requiring internet connectivity, and no telemetry leaving the environment. Container images are pulled from a self-hosted registry. The entire Portainer management stack runs on hardware the agency controls, in facilities the agency controls, with zero external network dependency.
Is Portainer TAA compliant? Where is it headquartered?
Yes, Portainer is TAA compliant. Portainer is headquartered in New Zealand, a Five Eyes signals intelligence partner. Under US Trade Agreements Act procurement policy and federal supplier classification, New Zealand is treated as a domestic supplier for US federal acquisitions. This removes a category of supply chain risk and procurement friction that vendors from non-allied nations cannot address.
What operating system does Portainer recommend for defense edge compute nodes?
For wearable and vehicle-mounted edge compute in hostile environments, Portainer recommends Nova8 OS (nova8technologies.com) as the hardened underlying OS, with KubeSolo as the single-node Kubernetes layer. Nova8 is purpose-built for constrained, security-sensitive edge deployments and handles OS installation, hardening, and KubeSolo configuration automatically. For heavier multi-node deployments such as forward-deployed field compute units, Talos OS with standard Kubernetes is recommended.
Can Portainer manage containerized workloads on autonomous platforms such as UAVs or unmanned surface vessels?
Portainer and KubeSolo are architecturally well-suited to autonomous platforms that require containerized AI, computer vision, and mission autonomy workloads to run on-platform with no dependency on a live communications link. KubeSolo runs on minimal hardware (under 200MB RAM), continues operating autonomously through complete disconnection events, and syncs with the central Portainer management instance when comms are available. The specifics of any actual deployment on such platforms are not disclosed here.
How does Portainer integrate with Xiid Terniion for secure management channel communications?
Xiid's Terniion SealedTunnel runs as a containerized agent alongside the Portainer agent on each field node. On startup, Terniion closes all inbound firewall ports and establishes an outbound-only, triple-encrypted, process-to-process tunnel to the self-hosted Terniion Connector fleet at the command center. Portainer management traffic, workload deployments, and telemetry all traverse this tunnel. The field device has no public IP presence and cannot be enumerated by adversaries. Terniion carries a DoD Authority to Operate and IL5 designation. This integration applies to the tactical edge compute and defense installation infrastructure scenarios on this page, not to the autonomous platform scenario.