Autonomy Cloud.
One rack for Everything.
AI inference, cloud workloads, and sovereign governance — converged on a single platform, in a single rack, under your legal jurisdiction. Not a product category that existed before. Built because it needed to exist.
Two estates. Two bills. Two points of failure.
The conventional approach to sovereign AI requires two completely separate infrastructures. A GPU cluster for AI inference — power-hungry, physically large, and dependent on specialist HPC engineering. And separately, a cloud platform for everything else — VMware or equivalent, with its own management stack, licensing costs, and compliance posture.
These two estates cannot share hardware. They can't share a control plane. They can't share a power budget. You pay for both, staff both, assure both, and get sovereignty guarantees from neither — because both rely on US-incorporated software stacks subject to CLOUD Act and FISA extraterritorial reach.
Autonomy Cloud was built on a single premise: that the separation is unnecessary, and the cost of maintaining it is borne entirely by the customer.
Conventional approach
Autonomy Cloud
Based on comparison of 1 x 42RU Autonomy Rack hosting 70 x AI Accelerators, and providing capacity to run 4,769 mixed VM workloads with a conventional server estate alternative running NVIDIA H200 GPU plus VMware based hypervisor. 30KW rack power.All vendor recommended build-out instructions and blueprinted builds followed, all power quoted is maximum load. Full methodology available on request.
Purpose-built sovereign hardware. Open source software stack.
Zero proprietary lock-in.
Every layer of the Autonomy Cloud stack has been chosen to eliminate dependency on US-domiciled proprietary software. No VMware. No Broadcom. No licensing agreements subject to foreign jurisdiction. The software is open source — binaries compiled from published source code, with API exposure for all key services.
Software stack — open source throughout
Hypervisor
KVM — open source. Zero licensing. Replaces VMware entirely.
Containers
LXC / Kubernetes — native container support out of the box.
Control Plane
OpenNebula — single unified management for VMs, containers, and AI workloads.
Compatibility
Hypervisor integration is available for organisations with legacy VMware assets.
We use Qualcomm AI100 ultra accelerators as our primary AI card of choice,and in all EAR 4A090 markets; but can support many other GPUs with a low power draw upon request or in our SKUs to provide AI capabilities in markets constricted by US EAR export restrictions.
Not on the device.
Not in a hyperscale DC. The space in between.
The term "Edge AI" gets used loosely — sometimes to mean AI running on a smartphone or sensor (on-device inference), sometimes to mean anything that isn't a hyperscale data centre. Technically informed readers will rightly point out that these are wildly different things. They are.
True far-edge AI runs directly on the end device. That's not what Autonomy Cloud is. What we do is more accurately described as Near Edge, Fog AI, or MEC AI — depending on context.
We typically run sovereign AI inference on infrastructure at the network edge: in PoP rooms, exchange facilities, base station hubs, and local data centres. Close enough to deliver low latency. Powerful enough to run enterprise LLMs. Sovereign enough for regulated and sensitive data. Small enough to fit where conventional AI infrastructure can't go.
This intermediary layer — between the user's device and the hyperscale core — is where the most interesting and most consequential AI deployments happen. It's also where the conventional infrastructure model fails most completely: too power-hungry, too large, too jurisdictionally exposed, and too dependent on hyperscale connectivity to operate at the network edge.
When we say "Edge", we mean the infrastructure edge — the sovereign, distributed, near-edge layer where Autonomy Cloud is uniquely deployable. That's a real world benefit, not marketing.
PoP room to national platform. Same architecture throughout.
Autonomy Cloud scales from an 8 RU minimum entry point — deployable in any standard 19″ rack environment and scaleable 1RU at a time — through to full 42 RU racks and multi-rack federated deployments. The architecture is identical at every scale.
What changes is the platform capacity, not its complexity.
EDGE ENTRY
8 RU - 21RU Half-Rack
Deployable in PoP rooms, exchange facilities, mobile or vehicle-mounted configurations, and any constrained environment with a standard 19″ rack. Quiet enough to sit in an office corner.
At entry-level (8RU:4GPU) it draws under 2 kW — suitable for a domestic power circuit; whilst a 21RU:30GPU Half-Rack consumes just 10.5KW.
Telecoms edge · emergency services · remote government · island territories
FULL RACK
42 RU — reference model
The numbers are impressive:
35 compute nodes. 70 Qualcomm AI100 Ultra accelerator cards.
12,318 vCPU workload pool. 71,680 GB RAM. 150 TB usable storage.
Run AI Inference alongside up to 4,700 mixed VM's. A maximum verified draw of 23.1 kW — fits any standard data centre power envelope globally.
Enterprise · regulated sectors · national digital infrastructure
FEDERATED MESH
Multi-rack · multi-site
Multiple Autonomy deployments — across sites, cities, or countries — federated into a mesh. Each cluster operates independently. When connectivity is restored, clusters re-join automatically.
No manual intervention.
No central point of failure.
No blast radius between clusters.
Resilience architecture
ASSURED DECENTRALISED INFRASTRUCTURE (ADI)
ADI is the operational model that makes federated Autonomy deployments genuinely resilient rather than theoretically resilient.
Each cluster holds its own state, serves its own workloads, and makes its own routing decisions. A failure in one cluster — hardware, software, or physical — doesn't propagate. The failure domain is in the single cluster.
The broader mesh continues operating : and when connectivity to a failed cluster is restored, it re-starts, self-checks, then re-federates automatically and synchronises without needing any manual intervention.
The architecture briefing for Autonomy goes further than this page.
If you want the full technical picture — component specifications, deployment configurations, assurance posture — we do that in conversation, not in a brochure.
Request a technical briefing