Spinifex is an open-source, AGPL-3.0 infrastructure platform built by Mulga that recreates the AWS service surface — EC2, EBS, S3, VPC, IAM, ALB/NLB, EKS, ECR, ECS, and RDS — on bare metal, on-premises hardware, and edge sites, for teams that need AWS APIs and tooling but cannot or will not run in a hyperscaler cloud.

What it is

Spinifex is an AWS-compatible cloud platform written in Go. It exposes the AWS API surface on infrastructure the operator owns, so the same build shipped to AWS is served on local hardware: the same APIs, the same Terraform, the same SDKs. The stack runs on bare metal and sits on top of QEMU/KVM. Its compute component is a minimal VM orchestration layer built over QEMU that manages lifecycle operations such as start, stop, and terminate through QEMU's QMP interface. The managed services are built on that instance layer, so an EKS node group, an ECS container instance, and an RDS database are all Spinifex VMs on the operator's own hardware, each driven through its own AWS API.

The concrete problem it solves is environment, not feature gap. Some workloads cannot run in a hyperscaler at all: air-gapped sites, vehicles, vessels, factories, and clinics; data that must stay under a specific jurisdiction; and deployments where the operator needs control of the hardware, the network, the data, and the keys. The thing it replaces is the hyperscaler control plane. Teams keep the AWS CLI, the AWS SDKs, and Terraform, point them at a Spinifex endpoint, and change where the software runs rather than what it is. No workload rewrite is required, and the platform is designed to keep running through disconnection, with no external control plane.

Key capabilities

• Serves AWS-compatible APIs for EC2, EBS, S3, VPC, IAM, ALB/NLB, EKS, ECR, ECS, and RDS, all listed as Available.
• Runs EC2 VM lifecycle operations — start, stop, and terminate — through QEMU's QMP interface on bare metal.
• Supports cloud-init and IMDS metadata, key pairs, and tags for instances.
• Works with unmodified AWS CLI, AWS SDKs, and Terraform against a Spinifex endpoint.
• Operates offline-first and air-gapped, with no external control plane required to keep running.
• Deploys in three shapes from one platform: a partner Neocloud, on-premises hardware, and edge sites.
• Offers a hosted live sandbox with a real AWS-compatible endpoint, access keys, and console.

Who uses it and how

• Teams running an on-premises data centre host a multi-node HA cluster integrated with their existing storage and networking, keeping the stack, the data, and the jurisdiction in their own hands.
• Edge deployments put compute next to the data in air-gapped sites, vehicles, vessels, factories, and clinics, and continue running through disconnection.
• Organisations lifting and shifting existing workloads onto a partner Neocloud change an endpoint and keep the software, using GPU capacity such as H100, H200, and B200.
• Groups already invested in AWS tooling — AWS CLI, SDKs, Terraform — retarget that tooling without rewriting code.
• Edge AI workloads are an explicit target, with compute placed alongside the data rather than at a distant region.

Getting started

The README documents three deployment routes — partner Neocloud, on-premises, and edge — alongside an Installation section and docs. The fastest entry point it names is the hosted live demo: sign up at https://mulgadc.com/signup for a sandbox that is live in under a minute, needs no card and no install, lasts 72 hours, and provides a real AWS-compatible endpoint, access keys, and console with EC2, EBS, S3, VPC, IAM, EKS, and RDS ready to call.

How it compares

No list of paid products that Spinifex replaces is provided in the facts, and no comparable open-source project is named there either, so it stands alone in this registry. The comparison the README itself draws is against the hyperscalers, on the axes of where the software runs, who holds the data and keys, whether the cloud keeps running through disconnection, and whether the core is open and auditable under AGPL-3.0 rather than rented.

When to use it — and when not to

A self-hoster must supply the bare metal and the QEMU/KVM virtualization layer, and for the on-premises shape, the storage and networking that the multi-node HA cluster integrates with; the README excerpt provided here does not spell out further operational prerequisites such as database or mail services. Teams that want a fully managed cloud with no hardware to operate, or that need a permissive licence rather than AGPL-3.0 copyleft terms, should look elsewhere. Two honest limits: Bedrock is listed as Q3 2026 roadmap rather than available, so the AI deployment surface is not shipped yet, and adoption signals are modest — 177 stars, 10 forks, and 4 open issues at last push.