Spinifex Review

Spinifex is a platform that recreates core AWS services on your own hardware. Compute is EC2-compatible on QEMU/KVM with spot instances and GPU passthrough. Block storage is EBS-compatible and built on Viperblock, with snapshots, attach and detach, and growable volumes. Object storage is S3-compatible through Predastore, which uses gate, blob, and meta nodes with Reed-Solomon erasure coding, degraded writes, repair, and encryption at rest. Networking is VPC built on OVN with public and private subnets, security groups, route tables, and Elastic IPs. Around that it offers IAM with SigV4 authentication, ALB and NLB load balancers, ECR and ECS, EKS-compatible Kubernetes, and RDS-compatible databases. The README says Bedrock is targeted for Q4 2026.

Spinifex runs on Ubuntu 26.04 or Debian 13 and requires a Linux bridge on the host for VM networking. The recommended path is a bootable x86 ISO for bare metal, which is x86 only. For a single node on an existing server you run the install script, then setup-ovn.sh --management, spx admin init, and systemctl start spinifex.target, and verify by setting an AWS_PROFILE and running an AWS CLI command. The multi-node guide describes deploying across three or more servers to form an availability zone with clustered OVN, and upgrades can use the same installer as the original deployment or a manual path that lets you review configuration migrations first. The docs we read give no minimum CPU, RAM, disk, or NIC specifications, so check docs.mulgadc.com and size with the vendor.

The promise is that existing AWS tooling keeps working: you point the AWS CLI, SDK, or Terraform at your own endpoint and profile and use the same calls. It can run as a single node, a cluster, an edge box, or an air-gapped rack. This section reflects the repository and documentation; we did not install it.

• EC2-compatible compute on QEMU/KVM with spot instances and GPU passthrough
• S3-compatible object storage with erasure coding, repair, and encryption at rest
• EBS-compatible block storage with snapshots and growable volumes
• VPC networking on OVN with security groups, route tables, and Elastic IPs
• IAM with SigV4 and policy enforcement
• ALB and NLB, ECR and ECS, EKS-compatible Kubernetes, and RDS-compatible databases
• 392 AWS API operations listed in a published coverage report

• Reuses existing AWS tooling and Terraform instead of forcing a new API
• Covers the data-sovereignty and air-gapped use cases that public clouds cannot
• Multi-node design with replicated object storage and clustered networking
• Fast release cadence: v1.22.0 shipped a few days before this review, with a commit the same day

• Small and young (about 360 stars), so production hardening is something you must prove yourself
• A subset of AWS: the coverage report is a list of supported operations, and behavior of managed-service lookalikes such as RDS or EKS can differ from the real services
• No published hardware sizing, and the bare-metal installer is x86 only
• Running a private cloud means owning networking, upgrades, capacity, and incident response
• Open core with AGPL-3.0, so commercial use outside those terms needs a commercial license

Spinifex is free under AGPL-3.0, and your costs are hardware, networking, and operations. The project is described as open core with a commercial license and commercial support available from Mulga, but the pages we reviewed give no prices or support tiers, so contact the vendor.

AWS is a global managed cloud with hundreds of services, and Spinifex does not try to match that scope. It aims to give teams a compatible subset on infrastructure they own, so regulated or disconnected environments can keep AWS-shaped automation. LocalStack is the better known AWS emulator and focuses on local development and testing, while Spinifex positions itself for running real workloads on bare metal. If your needs are mostly EC2, S3, EBS, and VPC, Spinifex is relevant; if you depend on the long tail of AWS services, it is not a replacement.

• Organizations with sovereignty, air-gap, or on-premises requirements that already automate on AWS
• Edge and branch deployments that need EC2- and S3-style APIs locally
• Teams repatriating steady workloads while keeping Terraform and SDK code
• Labs and platform teams that want to run an AWS-shaped private cloud

• Startups that need a managed cloud with no hardware to run
• Workloads that rely on many AWS services beyond compute, storage, and networking
• Teams that need a long production track record before adopting infrastructure software