Give the warfighter sovereign compute that never depends on a link home.
Mulga builds execution infrastructure for contested, disconnected, and austere environments. We exist so that mission-critical software—AI models, C2 applications, and decision-support tools—runs on operator-owned hardware at the tactical edge, independent of any cloud control plane.
Identity, permissions, and execution are enforced locally. Central systems may inform when connected, but they never gate operations. Disconnection is an operating condition, not a failure state.
Defense first. Dual-use by design.
Mulga is purpose-built for defense and national security—forward operating bases, mobile command posts, shipboard systems, and coalition environments where connectivity is contested and sovereignty is non-negotiable.
The same architecture serves critical infrastructure, remote industrial operations, and any environment where centralised cloud is unavailable, unreliable, or unacceptable.
Tactical edge and forward-deployed forces
Disconnected, denied, and austere environments
Coalition and multi-national operations
Critical infrastructure and remote industrial sites
Sovereign data processing where cloud is not an option
A local-first execution layer that replicates hyperscale cloud environments on operator-owned hardware. AWS-compatible APIs and SDKs let teams build, test, and deploy using familiar tooling—then run anywhere without cloud dependency.
AI and ML models deploy as standard mission workloads—field, swap, or roll back models without re-integration or touching the OS.
Mulga is not a cloud service, cloud extension, or AWS-managed edge offering. Mulga is a local-first execution layer that supports AWS-compatible APIs and development models, allowing mission software built for the cloud to run on operator-owned hardware at the tactical edge—without inheriting cloud-rooted authority or dependency. Developers can build against familiar AWS-style abstractions for compute, networking, and storage, then deploy that software onto Mulga on bare metal or rugged edge systems. Identity, permissions, and execution are enforced locally, not by AWS. AWS is treated as an interface and tooling ecosystem, not a control plane. Mulga does not require AWS IAM, STS, persistent connectivity, or cloud-rooted orchestration. When connectivity is available, cloud services can support development and analytics. When it isn't, Mulga continues to operate indefinitely. Mulga is AWS-compatible, not AWS-dependent.
Mission platforms provide C2, data fusion, workflows, and operator interfaces. Mulga does not. Mulga sits below mission platforms as a local-first execution layer. It provides an on-prem, cloud-like runtime you own and control—running on operator hardware and exposed through AWS-compatible APIs and SDKs—without cloud dependent control planes. Mission platforms and applications run on Mulga, side by side, isolated by default. Mulga handles execution, resource control, and survivability so platforms can focus on mission logic and operators. Mission platforms own mission logic. Mulga owns execution survivability.
No. Mulga is infrastructure only. It does not own mission data, provide C2 workflows, or present operator interfaces—those remain with mission platforms. Mulga provides a local-first execution layer that exposes AWS-compatible interfaces for compute, storage, and networking, allowing mission systems to run on operator-owned hardware without cloud dependency. Identity, permissions, and execution are enforced locally on the node, not by any external authority. Central systems may inform with updates or analytics when connected, but they can never gate execution or revoke control. Local decides. Central informs.
Nothing stops. Mulga is designed to treat disconnection as an operational condition, not a failure state. Identity, permissions, and execution continue to function indefinitely without reach-back. Losing the link removes dependency—it does not remove capability.
Mulga Spinifex runs on standard Linux-capable rugged edge hardware, including x86 and ARM systems. There is no proprietary appliance requirement. Mulga is hardware-agnostic and deploys across a wide range of edge platforms. For fast evaluation and fielding, Mulga will offer three fully optional, pre-integrated reference edge nodes—Lite, Standard, and Heavy—designed for trials, exercises, and rapid deployment. These systems are interchangeable with customer-selected hardware. Mulga also maintains a Validated Hardware List of tested platforms and recommended vendors. Mulga standardizes execution—not hardware.
As many as your mission requires. Mulga supports everything from single-node tactical deployments to distributed multi-node formations. Each node operates independently and remains locally authoritative—there is no requirement for a central cluster to maintain execution. For missions that require resilience and fault tolerance, Mulga is typically deployed across multiple nodes so execution continues even if a system is lost. A small group of nodes can provide redundancy without introducing a single point of failure. Architecture scales with mission needs, not with centralized control.
Yes. Mulga is designed to break the hardware–software stovepipe. Mission software can be deployed across diverse hardware fleets without re-integration or platform-specific rewrites. Vendors integrate once and run wherever Mulga runs.
Many programs stall because the infrastructure required for real deployment is fragile, bespoke, or non-repeatable. Mulga provides a pre-built, secure, and standardized execution layer, allowing teams to focus on mission logic instead of infrastructure plumbing. This reduces integration risk and shortens the path from prototype to fielded system.
Mulga aligns with distributed and coalition architectures by standardizing execution without forcing convergence. It does not replace existing systems. It allows them to run together—reliably—under contested conditions.
