[opensourcedex]

Spinifex is a free, open source storage solutions project written in Go and released under AGPL-3.0. It has 408 GitHub stars, 27 forks and 4 open issues, and was last pushed 2 hours ago. On this registry it ranks #8 of 8 tracked projects in Storage Solutions, with 5 head-to-head comparisons available. It gained 82 stars over the last 30 tracked days.

What is Spinifex?

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.

project readme (upstream, from github) — read inline

Go License mulgadc.com

What is Spinifex? · Platform · Deploy · AWS Compatibility · Live Demo · Components · Architecture · Installation · Docs

Spinifex: the open, AWS-compatible cloud you run yourself

Spinifex, built by Mulga, recreates the AWS services your software already uses (EC2, EBS, S3, VPC, IAM) on infrastructure you control. Move workloads off the hyperscalers, run AI at a fraction of the cost, or take the cloud to the edge, without rewriting a line. The exact build you ship to AWS, Spinifex serves on your own hardware: same APIs, same Terraform, same SDKs.

What is Spinifex?

Spinifex is an open-source infrastructure platform that recreates the AWS service surface (EC2, EBS, S3, VPC, IAM) on bare-metal, edge, and on-premises environments. Run cloud-native software without a hyperscaler.

Built for teams that need:

  • The AWS tooling you already use (AWS CLI, SDKs, Terraform), with nothing to rewrite
  • Full control of the stack: your hardware, your network, your data, your keys
  • A cloud that keeps running offline, through disconnection, with no external control plane
  • An open core (AGPL-3.0), auditable and yours to keep, with no lock-in

You change where your software runs, not what it is.

The Platform

From commodity hardware up to unmodified AWS tooling, every layer is replaceable and yours to own.

Three Ways To Deploy

The same AWS-compatible platform runs in three shapes. Pick the one that matches your hardware.

Neocloud

Lift and shift onto a partner Neocloud without rewriting workloads. GPU capacity (H100 / H200 / B200), cheaper, available now. Change an endpoint, keep the software.

On-premise

Host Spinifex on your own hardware in your own data centre. You get a multi-node HA cluster integrated with your storage and networking, so the stack, the data, and the jurisdiction stay yours.

Edge

Cloud where the cloud can't reach. Air-gapped sites, vehicles, vessels, factories, and clinics. Compute next to the data, running through disconnection, on hardware you own. The same AWS APIs your software already uses.

AWS Compatibility

Spinifex speaks the AWS API surface. The AWS SDKs, AWS CLI, and Terraform all work unchanged, whether you deploy at the edge, on-premise, or on a partner Neocloud.

Service What it is Status
EC2 Compute Available
EBS Block Storage Available
S3 Object Storage Available
VPC Networking Available
IAM Identity & Auth Available
ALB / NLB Load Balancers Available
EKS Kubernetes Available
ECR Container Registry Available
ECS Container Service Available
RDS Databases Available
Bedrock AI Deployment Q3 2026

Roadmap items ship under the same AWS API surface. Code written for AWS today keeps working the moment they land. Track what's shipped in the release notes.

Live Demo

Create a live sandbox in under a minute. The fastest way to experience the stack. Try Spinifex against one of your own workloads on infrastructure we run for you.

  • Live in under a minute. No card, no install.
  • Yours for 72 hours to test and experiment.
  • Real AWS-compatible endpoint, access keys and console.
  • EC2, EBS, S3, VPC, IAM, EKS and RDS, ready to call.
  • Point your existing AWS CLI or Terraform straight at it.

Sign up at https://mulgadc.com/signup

Core Components

Spinifex (Compute and Platform Services – EC2, EKS, ECS, RDS)

Spinifex is a minimal VM orchestration layer built on top of QEMU, exposing an EC2 compatible API. It manages lifecycle operations like start, stop, and terminate through QEMU's QMP interface. Designed to be straightforward and scriptable, Spinifex lets you launch VMs with the AWS CLI, SDKs, or Terraform, without Kubernetes or a heavyweight orchestrator.

The managed services build on that same instance layer. An EKS node group, an ECS container instance, and an RDS database are Spinifex VMs on your own hardware, each driven through its own AWS API.

  • EC2 – VM lifecycle on bare metal, cloud-init and IMDS metadata, key pairs, tags, spot instances, capacity reservations, and GPU passthrough
  • EKS – Managed Kubernetes on k3s, with HA control planes, managed node groups, cluster add-ons, an OIDC provider, and IAM access entries
  • ECS – Task and service scheduling across container instances, with awsvpc ENIs, capacity providers, rolling deployments, and GPU-aware placement
  • ECR – Private container registry backed by Predastore, with content-addressed blobs deduplicated per account and lifecycle policies
  • RDS – Managed PostgreSQL and MariaDB, with parameter groups, automated backups, and DNS endpoints served by Northstar
  • ALB / NLB – Layer 7 load balancing on HAProxy and layer 4 on nginx stream, with health checks and ACM-issued listener certificates
  • VPC and IAM – OVN-backed networking and security groups, with roles, policies, and SigV4 auth applied across every service

Viperblock (Block Storage – EBS Alternative)

Viperblock is a high-performance, WAL-backed block storage service that replicates volumes across multiple nodes. It's built for reliability and speed, with support for snapshots, recovery, and direct connection to QEMU instances using NBD or virtio-blk.

  • Fast, durable virtual disks
  • Replication for resilience
  • Exposed over NBD or embedded in VMs
  • High performance WAL logs on local NVMe drives, reducing IO traffic to S3
  • In-memory read/write block cache

Predastore (Object Storage – S3-Compatible)

Predastore is a fully S3-compatible object storage system. It supports the AWS S3 API, including Signature V4 authentication, multipart uploads, and Terraform provisioning. Predastore chunks data and distributes it across nodes using Reed-Solomon erasure coding, so it survives node loss and suits large-scale or low-bandwidth sites.

  • S3-compatible API and auth
  • Multipart uploads, streaming reads/writes
  • Data redundancy with Reed-Solomon encoding

Northstar (Authoritative DNS)

Northstar is a lightweight authoritative DNS server that handles both internal service discovery and public-facing DNS for a Spinifex cluster. Zones are human-readable TOML files, served from the local filesystem or synced from Predastore, keeping DNS configuration in the same object storage as the rest of your infrastructure.

  • Authoritative DNS over UDP, TCP, and DNS-over-TLS
  • Service discovery for cluster components via SRV records
  • Zone files stored locally or in S3-compatible storage

Architecture at a Glance

Every AWS API call is authenticated at the gateway, published to a NATS subject, and answered by whichever daemon claims it. Daemons are stateless: scale horizontally by starting more. No etcd, no Kubernetes, no external control plane. Just systemd units, a NATS cluster, and your hardware. Deep dive: docs/DESIGN.md.

Self-hosted Installation

Installation requires an Ubuntu 26.04 or Debian 13 system. See the detailed documentation at docs.mulgadc.com for installing Spinifex.

Bare Metal ISO

The recommended installation is a bootable x86 installer for bare-metal hardware.

curl -fLO https://iso.mulgadc.com/spinifex.iso

Follow the USB install guide to write the ISO to USB and install on your hardware.

Single Node Install

Prerequisite: Spinifex requires a Linux bridge configured on the host for VM networking. See the single-node install guide for setup details.

curl -fsSL https://install.mulgadc.com | bash

sudo /usr/local/share/spinifex/setup-ovn.sh --management

sudo spx admin init --node node1 --nodes 1

sudo systemctl start spinifex.target

export AWS_PROFILE=spinifex

aws ec2 describe-instance-types

Development Setup

For a complete development environment see the Source Install documentation.

Spinifex UI

Spinifex ships with a built-in web console, an optional alternative to the AWS CLI, SDKs, and Terraform. If you know the AWS Management Console, the Spinifex UI fills the same role: a browser-based view of your instances, volumes, buckets, VPCs, and IAM resources, without leaving your own network.

Each node serves the console on port 3000 over TLS, and it comes up with spinifex.target:

  • Same API, different surface. The UI issues the same AWS SigV4 calls the CLI does, so RBAC, audit trails, and IAM policies apply the same way.
  • Single sign-on against your AWS credentials. Log in with the access keys from ~/.aws/credentials on the node where Spinifex is installed. There is no separate user database.
  • Self-hosted, works offline. The Spinifex binary embeds the UI and each node serves it directly, with no external CDN or analytics calls.

For the full walkthrough, covering first-time TLS certificate trust, login, and a feature tour, see Launching the Web UI in the cluster setup guide.

Development Philosophy

Built by Engineers, For Engineers

Spinifex is developed by experienced infrastructure engineers with deep AWS expertise, including former AWS team members who understand the intricacies of building production-grade cloud services. Our team brings decades of combined experience from AWS, enterprise infrastructure, and edge computing environments.

AI-Assisted Development

Spinifex is architected and implemented by experienced engineers, with Claude Code accelerating certain development tasks. The split keeps the quality and reliability standards that production infrastructure demands:

How We Use Claude Code:

  • Code Generation: Boilerplate AWS API structures and handlers
  • Documentation: Comprehensive development guides and API documentation
  • Testing: Test case generation and validation scenarios
  • Refactoring: Large-scale code restructuring and optimization

What Remains Human-Driven:

  • Architecture Decisions: Core system design and scalability choices
  • Security Implementation: Authentication, encryption, and threat modeling
  • Performance Optimization: Real-world performance tuning and benchmarking
  • Production Operations: Deployment strategies and operational procedures

Trademarks

"AWS", "Amazon Web Services", and all related service names (EC2, EBS, S3, VPC, IAM, and others) are trademarks of Amazon.com, Inc. or its affiliates. Mulga Defense Corporation and Spinifex are independent and not affiliated with, endorsed by, or sponsored by Amazon.com, Inc. or Amazon Web Services, Inc. References to AWS services describe interoperability and compatibility only.

License

Spinifex is open source under the GNU Affero General Public License v3.0, with a commercial license available. You're free to use, modify, and deploy it anywhere you need reliable infrastructure without depending on centralized cloud platforms.

Frequently asked questions

Is Spinifex free to use?

Spinifex is open source under the AGPL-3.0 licence. There is no licence fee and no seat count — you can self-host it or, where the project offers one, pay a vendor for a managed version instead.

What does Spinifex do?

AWS-compatible cloud APIs on infrastructure you control

What is Spinifex written in?

Spinifex is primarily written in Go. Its source is publicly available at https://github.com/mulgadc/spinifex, and it has 408 GitHub stars.