Aarna.ml and the Missing Cloud Around the GPU

Imagine buying a restaurant full of ovens, then discovering you have no menu, no reservations, no way to keep orders separate and nobody to collect the bill. That is the awkward position of a company that has bought GPUs but has yet to build a cloud. The machines are valuable. The service around them is what customers actually use. Aarna.ml, a San Jose software company, spent its last independent years building that service.

Its product, GPU Cloud Management Software, or GPU CMS, was the control plane for a provider that wanted to sell GPU-as-a-Service. A tenant could choose an instance; an operator could onboard hardware, assign capacity, observe usage and keep customers apart. Those verbs sound administrative until one customer’s training job collides with another’s storage or network. Then administration becomes the product.

The waiting room problem

A GPU cloud operator can begin with a spreadsheet and a human who allocates machines. That works while there are few customers, predictable jobs and plenty of slack. Growth makes the process brittle. Customers expect an instance when they click; operators need to know who owns which GPUs, what network they can see, where their data lives and what they owe. The costly chip becomes a waiting room whenever those questions require a support ticket.

Aarna.ml’s answer joined an admin console to a tenant-facing self-service interface. Providers could offer bare-metal servers, GPU-enabled virtual machines and Kubernetes environments from a shared pool. The company stressed “hard isolation”: separation down through compute, GPU, network, storage and high-speed fabric, rather than a neat label in a dashboard. The distinction matters most for customers that share costly infrastructure but cannot share data, policy or failures.

The practical example is storage. In Aarna.ml’s published VAST integration, a user specifies a storage size and the bare-metal node to mount it on. The software then creates tenant-specific quotas, network policies and mount points through APIs. The user gets the volume on the allocated machine without visiting a second portal. It is a small convenience with a large operational consequence: fewer manual handoffs, and fewer chances to attach the wrong customer’s data to the wrong machine.

The pivot had a long runway

Amar Kapadia and Sriram Rupanagunta were not newcomers to invisible infrastructure. The co-founders had previously built Aarohi Communications, a 10-gigabit Ethernet data processing startup acquired by Emulex. At Aarna, they first pursued a different puzzle: orchestration across 5G networks and edge sites. The company’s AMCOP platform managed cloud-native 5G network services and edge applications across Kubernetes clusters. It dealt in lifecycle management, automation and the untidy fact that real systems span many vendors and locations.

That history explains the GPU turn better than a fashionable suffix could. In 5G, software had to deploy workloads over distributed infrastructure while watching policy, network behavior and failures. GPU cloud providers faced another version of the same job, now with more expensive compute and customers asking for immediate access. Aarna’s public materials describe the move to GPU cloud management as a pivot. They do not publish a postmortem of a failed product. The visible change was a market decision: orchestration skills gained a new buyer.

There is a small archival wrinkle. Aarna’s LinkedIn profile lists 2020 as its founding year; a company-issued funding announcement says 2018. The useful part of the chronology is clearer: the 5G product preceded the GPU cloud push, and the acquisition followed it. The firm’s investor 3Lines announced the Armada deal in November 2025 and described inbound interest after Aarna gained traction in GPU orchestration.

What the buyer was really buying

Aarna’s customers were cloud operators and enterprises, not people shopping for a spare GPU on a credit card. The company named Tigo, LGE, Equinix, Keysight, CableLabs and Capgemini Engineering among its customers. Its 2024 pitch addressed NVIDIA Cloud Partners and GPU-as-a-Service providers. In plain terms, these buyers needed to sell capacity, allocate it safely and spend less staff time on every request. Aarna sold B2B software and demos; public pricing has not been disclosed.

The competitive alternative was often to stitch the service together in-house. A provider could combine Kubernetes, virtualisation, storage controls, networking tools, observability and a billing system. Aarna’s claim was that its control plane could coordinate those pieces, including the ones above and below Kubernetes. Its Red Hat partner listing described bare metal, VMs, dedicated OpenShift clusters and tenant isolation across network fabrics. That is a more specific proposition than a generic AI platform interface.

“GPU PaaS needs to be a complete stack with IaaS.”Aarna.ml product blog, April 2025

This is also where a prospective buyer should be fussy. Aarna’s marketing cited dramatic potential returns and high utilisation; those are vendor claims, not a published audit of customer results. The reproducible lesson is narrower and useful: map every step between a customer request and a billable, secure instance. If compute, storage, networking and permissions cannot be provisioned together, the bottleneck will simply move from the GPU to the operations team.

From racks to the edge

Armada’s acquisition gave the story another turn. The acquirer sells an edge computing platform, so a GPU cloud control plane fits naturally beside distributed compute and connectivity. Khasm Labs, which lists both companies in its ecosystem, says Aarna’s GPU CMS became Armada Bridge. The connection points toward a future in which GPU capacity may sit in more places than a central data center, while customers still expect the same orderly experience.

The conditions are demanding. Hard isolation requires control of the hardware, network fabric, storage and the operators’ workflows. It is most valuable when several tenants need safe access to costly shared machines. A small, single-team cluster with simple access patterns may not need that much machinery. A platform cannot compensate for insufficient GPU supply, poor network design or economics that fail even at high utilisation.

Still, the central insight travels well beyond Aarna. The most visible part of a cloud is the button. The business is everything that has to happen after someone presses it. Aarna.ml took a skill learned among 5G clusters, applied it to the GPU rush and sold the coordination. The chips were the attraction. The queue, the walls and the ledger were the work.