As the use of generative AI becomes more widespread, so too does the discussion around the merits and feasibility of running AI locally. Weekend vibe-coders and full-time software companies alike are feeling the jaws of token economics close around them, causing many to explore open weight alternatives to the frontier models.
In many cases, the open weight models get the job done just fine. At Mulga, we believe that these open weight models will see increased use in production-grade applications. We also believe that further improvements to the models will allow them to run on ever smaller, lower powered local hardware. It's reasonable to conclude that such local AI applications would benefit from the scalability and security tools previously enjoyed only by workloads deployed in the cloud. That's one of the reasons we made Spinifex.
Cloud-native tools on your own hardware
Spinifex replicates AWS services — S3, EBS and EC2 — as well as fully fledged workload management tools such as EKS and IAM, all on your own hardware. In doing so, it provides a way to take local AI applications and scale them as you would a traditional cloud-native workload, but on hardware you own.
A real example
We recently published a Reference Architecture detailing how Spinifex's EKS implementation can be used to deploy EC2 instances on a Supermicro X14 2U CloudDC baremetal host — a dual-socket Xeon 6730P chassis carrying two NVIDIA RTX Pro 6000 Blackwell Server Edition GPUs (96 GiB GDDR7 each). Not only does Spinifex's EKS implementation behave in exactly the same way as that of AWS, but the worker nodes and other required peripheral infrastructure — EBS volumes for the nodes, ELBv2 to route traffic, IAM for cluster and node roles — are all declared via Terraform. The only change required is a single provider override pointing all API calls at the Spinifex endpoint:
provider "aws" {
endpoints {
ec2 = var.spinifex_endpoint
iam = var.spinifex_endpoint
sts = var.spinifex_endpoint
eks = var.spinifex_endpoint
ecr = var.spinifex_endpoint
acm = var.spinifex_endpoint
}
}
This is just one of the many Reference Architectures we have published specifically outlining how Spinifex can be used to deploy AI workloads to baremetal in a scalable manner, using cloud-like tools.
A coding agent platform, on your hardware
The more complex applications aren't as far off as they might sound. Take a coding agent harness — the kind that routes developer queries to a model, manages context windows, enforces access policies, and logs outputs for audit. Such a workload, which would normally be a nightmare to build and manage locally, maps almost directly onto AWS primitives that Spinifex already provides:
- EKS runs the agent orchestration layer and model-serving pods, scaling inference nodes up and down with demand
- IAM controls which teams and services can reach which models, with the same role-based policies you'd write for AWS
- S3 holds prompt libraries, fine-tune datasets, evaluation results, and output artifacts
- ELBv2 distributes requests across inference nodes as load shifts
The result is a private coding assistant platform that an entire engineering organisation can use, with proper access controls, audit logging, and no token bill. Sensitive code never leaves the building, model behaviour is reproducible and auditable, and when a better open weight model drops, it can be swapped in with ease.
For defence and industrial operators the implications go further. Codebases that can't touch a third-party API, such as classified systems, export-controlled IP or unreleased product code, can still benefit from AI-assisted development. The primary constraint is shifting from the quality of the model itself to whether you have the infrastructure to run it properly. Spinifex is that infrastructure.
Where this is going
Fundamentally, we believe that as the quality of open-source models continues to scale, so too should our ability to deploy them into real workloads. Spinifex provides the bridge to running AI applications that don't depend on the current political environment or the increasingly restrictive token economics of the frontier model providers.
If you're interested, check out our documentation and other Reference Architectures at docs.mulgadc.com, or sign up for our free sandbox.
