Who Spinifex is for#
Defense and Government Teams Running AWS Software in Air-Gapped Environments
Spinifex was designed for contested, denied, and disconnected environments. It runs offline with no external control plane, on hardware you own, so AWS-native workloads can deploy to classified networks, forward operating bases, or ships without a hyperscaler dependency.
Skip if:
If your AWS workloads can reach a public cloud region and you have no sovereignty or network isolation requirement, running directly on AWS is simpler and better supported.
AI and ML Teams Reducing GPU Workload Costs via Neocloud Partners
Spinifex lets you run AWS-native AI training and inference jobs on Neocloud partner hardware using the same Terraform and AWS SDKs your team already deploys with. AWS Bedrock-compatible support is roadmapped for Q3 2026, enabling Bedrock API calls to resolve to on-hardware models.
Skip if:
If your AI workloads are optimized for AWS SageMaker or managed services and you have no cost or sovereignty pressure driving migration, the migration effort may not pay off at this stage.
ISVs Shipping AWS-Native Products to Off-Cloud Customers
If your product is built on the AWS API surface (EC2, S3, EBS, RDS), Spinifex lets you ship it to customers in air-gapped, on-premise, or sovereign environments without a port. The customer runs Spinifex; your software points at a Spinifex endpoint and keeps working.
Skip if:
If your customers are comfortable with public cloud and have no data residency or network isolation requirements, a standard SaaS deployment is a simpler model.
Enterprises Moving Predictable AWS Workloads to On-Premise Hardware
For workloads with stable resource consumption, running Spinifex on owned hardware eliminates egress costs and per-resource billing. A Terraform profile swap redirects the workload from AWS to Spinifex with no code changes, and a predictable hardware cost replaces a variable cloud bill.
Skip if:
If your workloads are spiky or unpredictable in scale, AWS's elasticity is a genuine advantage that on-premise hardware cannot match without significant overprovisioning.
The problem it solves#
Running AWS-native software creates a hard dependency on public cloud infrastructure. For teams operating in air-gapped environments, sovereign jurisdictions, or contested edge sites, AWS regions are either inaccessible, noncompliant, or prohibited outright. For enterprises and AI companies with predictable, high-volume workloads, hyperscaler billing adds cost that grows with usage and never stabilizes.
The deeper problem is that the tooling a team built around AWS, the CLI scripts, Terraform modules, Kubernetes manifests, and SDK calls, couples tightly to the AWS API surface. Moving to a different cloud or to on-premise infrastructure has historically meant a rewrite, re-platform, or a long parallel migration. That friction keeps teams on the hyperscaler even when the business case for leaving is clear.
How it solves it#
AWS-Compatible API Surface Across Ten Services
Spinifex speaks EC2, S3, EBS, VPC, IAM, ALB, NLB, EKS, ECR, ECS, and RDS natively at the wire level. The AWS CLI, SDKs, and Terraform connect without modification; you change a profile or endpoint and your existing software keeps working.
Bare-Metal Compute via QEMU/KVM
EC2-compatible instances run directly on the metal using QEMU/KVM. There is no hypervisor abstraction layer eating performance. Instances launch with cloud-init metadata support and are manageable via the AWS CLI or any EC2-compatible SDK.
S3-Compatible Object Storage (Predastore)
Predastore provides a fully S3-compatible API with Signature V4 authentication, multipart uploads, and streaming reads/writes. Data is chunked and distributed across nodes using Reed-Solomon erasure coding, giving fault tolerance without paying for triple replication.
EBS-Compatible Block Storage (Viperblock)
Viperblock is a WAL-backed block storage service with replication across nodes, an in-memory read/write cache, and NVMe-backed WAL logs for high-throughput writes. Volumes support snapshots, attach/detach, and growable capacity. They connect to QEMU instances via NBD or virtio-blk.
Edge and Air-Gapped Operation, Fully Offline
Spinifex has no external control plane. All orchestration runs through systemd units and a NATS message bus on your own hardware. It runs through network disconnection on vehicles, vessels, edge racks, and air-gapped sites with no dependency on a hyperscaler or internet connectivity.
Message-Driven Stateless Architecture
Every AWS API call is authenticated at the gateway, published to a NATS subject, and answered by whichever daemon claims it. Daemons are stateless and scale horizontally by starting more. No etcd, no Kubernetes control plane, no external authority: just systemd units, a NATS cluster, and your hardware.
Strengths and trade-offs#
Strengths
- Zero Code Rewrites for Existing AWS WorkloadsBecause Spinifex implements the same AWS API surface at the wire level, every existing AWS CLI command, Terraform module, and SDK call works unchanged. You change where your software runs, not what it is. A profile swap in the AWS CLI is all the migration requires.
- Full Stack Sovereignty with Auditable SourceNo phone-home, no control plane dependency, no external authority. Your data, your keys, your network. AGPL-3.0 means you can read every line of code, modify it, and run it without restrictions on internal deployment. Unlike proprietary on-premise appliances, there is no vendor to lock you out.
- Engineering Depth Beneath the API LayerSpinifex rebuilt the storage and compute layers rather than wrapping another system's API. Predastore uses Reed-Solomon erasure coding; Viperblock uses a WAL-backed replication design built for node failure. This engineering depth is why existing workloads run unchanged instead of requiring workarounds.
- Three Deployment Shapes from One AWS-Compatible SurfaceNeocloud (lift-and-shift to a GPU-enabled partner with H100/H200/B200 capacity), on-premise (your own data center, multi-node HA), and edge (air-gapped, offline, vehicle-mounted). The AWS-compatible API is identical across all three, so workloads move between shapes without modification.
Trade-offs
- -Early-Stage Project with a Small CommunitySpinifex had 28 stars and 8 forks on GitHub at time of research, with 2 open issues. It is an actively developed early-access project with weekly releases, but its community and third-party ecosystem are small compared to LocalStack or mature self-hosted cloud platforms. Early adopters should expect rough edges and limited community-sourced integrations.
- -Linux-Only Install with System PrerequisitesInstallation requires Ubuntu 26.04 or Debian 13. Single-node setup requires a Linux bridge configured on the host for VM networking before the installer runs. There is no Docker-based quick-start for evaluation; you need a compatible Linux host or bare-metal hardware with KVM support.
- -AGPL-3.0 Requires Source Disclosure for SaaS DistributionAGPL-3.0 means that if you distribute a modified version of Spinifex as a service accessible to others, you must release the source changes. Teams building proprietary managed products on top of Spinifex need to verify whether a commercial license from Mulga is available.
Spinifex vs alternatives#
Spinifex vs AWS
Spinifex and AWS share an API surface. The decision between them is about where that surface runs and who controls the infrastructure underneath it.
| Feature | Spinifex | AWS |
|---|---|---|
| License | AGPL-3.0 | Proprietary |
| Infrastructure | Your hardware | Amazon data centers |
| EC2, S3, EBS, VPC, IAM | Available | Available |
| Offline / air-gapped operation | Yes | No |
| Control plane | Your nodes (NATS + systemd) | AWS |
| Pricing model | Hardware cost only | Per-resource billing |
Spinifex wins when the workload cannot or should not run in an AWS region: air-gapped sites, sovereign jurisdictions, cost-controlled on-premise deployments, and edge environments. Because the API surface is identical at the wire level, no code changes are required to move an existing AWS workload onto Spinifex. AWS is the better choice for elastic, variable-scale workloads that benefit from instant resource scaling, for teams that need services beyond Spinifex's current coverage, and for any workload without data residency or connectivity constraints.
Spinifex vs LocalStack Enterprise
LocalStack Enterprise emulates AWS APIs on a developer workstation or in CI/CD pipelines for dev and test purposes. Spinifex is a production-grade infrastructure platform designed for real workload deployment on hardware you own.
| Feature | Spinifex | LocalStack Enterprise |
|---|---|---|
| License | AGPL-3.0 | Proprietary (Enterprise) |
| Target environment | Production, edge, air-gapped | Development and testing |
| Real compute | QEMU/KVM bare metal | Emulated / mocked |
| Real storage | Viperblock + Predastore | Simulated in-process |
| Offline production use | Yes | No |
LocalStack Enterprise is the right fit when you need a fast, accurate AWS emulation layer for local development or integration tests with no infrastructure cost. Spinifex is the right fit when you need real compute, real storage, and real networking running production workloads on hardware you control.
Spinifex vs Azure Stack Hub
Azure Stack Hub is Microsoft's on-premise extension of Azure: a purpose-built hardware appliance that brings the Azure API surface to your data center.
| Feature | Spinifex | Azure Stack Hub |
|---|---|---|
| License | AGPL-3.0 (open source) | Proprietary |
| API surface | AWS (EC2, S3, EBS, VPC, IAM) | Azure |
| Hardware requirement | Commodity x86/ARM | Certified hardware only |
| Cost model | Hardware and power | Hardware plus licensing fees |
| Vendor lock-in | None (auditable source) | Microsoft |
Spinifex is the better fit for teams with existing AWS tooling, commodity hardware, and a preference for auditable open-source software. Azure Stack Hub is the better fit for organizations already standardized on Azure tooling and willing to pay for a fully supported, pre-validated appliance. Spinifex does not require certified hardware or Microsoft licensing; Azure Stack Hub provides a more turnkey experience with a higher total cost of ownership.
Quick start#
Single-node install runs via a bash installer on Ubuntu 26.04 or Debian 13; configure networking and start the service with three additional commands.
```bash
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
```What it's built on#
- Languages
- GoTypeScript
- Frameworks
- FastAPIReact
FAQ#
Is Spinifex a free alternative to AWS?
Yes. Spinifex is AGPL-3.0 licensed and free to run on your own hardware, with no per-request or per-resource charges. Your costs are the hardware and power. Mulga also offers a Neocloud partner ecosystem where you can run Spinifex workloads on rented GPU hardware (H100/H200/B200) at lower cost than hyperscaler rates.
Do I need to rewrite my AWS code to run it on Spinifex?
No. Spinifex implements the same AWS API surface at the wire level, including EC2, S3, EBS, VPC, IAM, ALB, EKS, ECR, ECS, and RDS. You change an AWS CLI profile or a Terraform endpoint variable; your existing code, scripts, and Kubernetes manifests keep working without modification.
What AWS services does Spinifex currently support?
EC2, EBS, S3, VPC, IAM, ALB, NLB, EKS, ECR, ECS, and RDS are available now. AWS Bedrock (AI foundation models) is on the roadmap for Q3 2026. New services ship under the same AWS API surface, so code written for AWS today keeps working when they land. Release notes track what has shipped.
Can Spinifex run completely offline and air-gapped?
Yes. Spinifex has no external control plane and no phone-home requirement. All orchestration runs through systemd units and a NATS message bus on your own nodes. It is designed for air-gapped, disconnected, and contested environments and runs through network outages with no dependency on internet connectivity or a hyperscaler.
What are the hardware and OS requirements?
Spinifex requires Ubuntu 26.04 or Debian 13, with CPU support for KVM virtualization (Intel, AMD, or ARM). GPU workloads are supported on NVIDIA and AMD hardware. A Linux bridge must be configured on the host for VM networking before installation. The single-node installer handles remaining setup via a bash script. Bare-metal deployments can use a bootable x86 ISO.
Similar open-source tools#
seaweedfs
One cluster: S3 store, POSIX files, and Iceberg tables
Storj
Decentralized S3 storage with end-to-end client-side encryption
MinIO AIStor
Hyperscale S3-compatible object storage for AI workloads
Omnara
Open-source agent deployment API. Self-host or use Omnara Cloud.
opendisplay
Turn any iPhone, iPad, or spare Mac into a free second Mac monitor
OpenResearch
Local-first workspace for parallel research agents and experiments.